สรุปสั้น

WordPress ปล่อยเวอร์ชัน 7.0.4 ซึ่งเป็นการอัปเดตที่เน้นด้านความปลอดภัยโดยเฉพาะ เพื่อปิดช่องโหว่รันโค้ดจากระยะไกลที่กระทบเว็บไซต์ซึ่งประมวลผลรูปภาพด้วยส่วนขยาย Imagick ร่วมกับ Ghostscript ช่องโหว่นี้ถูกกำหนดหมายเลข CVE-2026-65640 และมีรายละเอียดอยู่ใน GHSA-8vr3-7mxf-gx8w โดยถูกรายงานเข้ามาอย่างมีความรับผิดชอบจากทีมนักวิจัยของ pwn.ai ทีมความปลอดภัยของ WordPress เร่งให้เจ้าของเว็บไซต์อัปเดตทันที ไม่ว่าจะผ่านหน้าอัปเดตในแดชบอร์ดหรือดาวน์โหลดตรงจาก WordPress.org ส่วนเว็บไซต์ที่เปิดการอัปเดตอัตโนมัติเบื้องหลังไว้ควรได้รับแพตช์ไปแล้ว

เงื่อนไขการใช้ช่องโหว่คือผู้โจมตีต้องมีบัญชีระดับ Author ขึ้นไปบนเว็บไซต์เป้าหมาย จึงไม่ใช่การโจมตีแบบผ่านมาแล้วยิงได้เลยโดยไม่ต้องล็อกอิน แต่ระดับความเสี่ยงจริงขึ้นอยู่กับว่าใครถือบัญชีบนเว็บนั้นบ้าง เว็บไซต์ประเภทที่มีผู้เขียนหลายคน แพลตฟอร์มสมาชิก หรือเว็บของลูกค้าที่เปิดให้ผู้ร่วมเขียนสมัครเข้ามาได้อย่างหลวม ๆ จึงมีความเสี่ยงจริงจัง เพราะผู้ใช้ระดับ Author คนใดก็ตามสามารถลองอัปโหลดไฟล์ที่ฝังกับดักโดยปลอมตัวเป็นรูปภาพได้ ส่วนเว็บไซต์ที่จำกัดผู้ใช้ไว้เฉพาะทีมบรรณาธิการกลุ่มเล็กที่ไว้ใจได้ ถือว่ามีความเสี่ยงต่ำกว่ามาก

รากของปัญหาไม่ได้อยู่ที่โค้ดใดโค้ดหนึ่งพลาด แต่อยู่ที่ ความไม่ตรงกันของวิธีระบุชนิดไฟล์ระหว่างสองระบบ โดย ImageMagick ตัดสินชนิดไฟล์จากการอ่านเนื้อในของไฟล์จริง ขณะที่เมธอด WP_Image_Editor_Imagick::load() ของ WordPress ส่วนใหญ่เลือกเชื่อนามสกุลไฟล์แทน ผลคือไฟล์ที่ตั้งชื่อดูไม่มีพิษภัยอย่าง holiday.png อาจบรรจุโค้ด PostScript อยู่ข้างใน ผ่านด่านตรวจตอนอัปโหลดไปได้ แล้วยังถูกส่งต่อให้ Imagick ซึ่งจะจดจำ PostScript ที่ฝังอยู่และเรียก Ghostscript ขึ้นมารันให้

รายละเอียดข่าว

เว็บไซต์ Cyber Security News รายงานเมื่อวันที่ 13 สิงหาคม 2569 ว่า WordPress ได้ออกเวอร์ชัน 7.0.4 เพื่อปิดช่องโหว่ดังกล่าว โดยอธิบายว่าปัญหาเกิดจากการที่ WordPress พึ่งพา ImageMagick ในการย่อขนาดและประมวลผลรูปภาพในคลังสื่อ ซึ่ง ImageMagick ไม่ได้หยุดอยู่แค่ไฟล์ JPEG และ PNG แต่ยังเปิดไฟล์ PostScript, EPS และ PDF ได้ด้วย และเมื่อต้องเรนเดอร์รูปแบบเหล่านั้น มันจะส่งงานต่อให้ Ghostscript ซึ่งเป็นเครื่องมือที่มีประวัติยาวนานในการถูกหลอกให้รันคำสั่งที่ไม่ได้ตั้งใจ นักวิจัยด้านความปลอดภัยจะจดจำรูปแบบนี้ได้ทันทีว่าเป็นบั๊กตระกูลเดียวกับช่องโหว่ชุด “ImageTragick” ที่โด่งดังเมื่อหลายปีก่อน

ตามข้อมูลของ WordPress การแก้ไขจะถูกย้อนแพตช์กลับไปถึงสาย 4.7 และรวมอยู่ในเวอร์ชัน 7.1 RC3 ที่กำลังจะออก แม้ในทางปฏิบัติจะมีเพียงเวอร์ชันล่าสุดเท่านั้นที่ได้รับการสนับสนุนอย่างต่อเนื่องเต็มรูปแบบ ผู้ดูแลเว็บไซต์จึงควรตรวจสอบเวอร์ชันที่ใช้อยู่และอัปเดตโดยไม่รอช้า โดยเฉพาะเว็บไซต์ที่ให้สิทธิ์อัปโหลดไฟล์แก่คนนอกทีมหลัก

ข้อสังเกตเรื่องการจัดระดับความรุนแรง: พาดหัวของบทความต้นทางใช้คำว่า “Critical” แต่เนื้อความของบทความเองระบุชัดว่าการใช้ช่องโหว่ต้องมีสิทธิ์ระดับ Author ขึ้นไป และไม่ใช่การโจมตีแบบไม่ต้องยืนยันตัวตน อีกทั้งรายงานไม่ได้ให้คะแนน CVSS อย่างเป็นทางการไว้ ผู้ที่ต้องประเมินความเสี่ยงจริงจึงควรยึดเงื่อนไขการใช้ประโยชน์เป็นหลัก มากกว่าจะยึดคำว่า “วิกฤต” ที่ปรากฏบนพาดหัว นอกจากนี้ยังไม่มีรายงานว่าช่องโหว่นี้ถูกนำไปใช้โจมตีจริง และยังไม่ปรากฏโค้ดสาธิตการโจมตีต่อสาธารณะ ณ เวลาที่รายงาน

ต่อมาเว็บไซต์ SecurityWeek รายงานเมื่อวันที่ 13 สิงหาคม 2569 พร้อมตัวเลขที่เติมช่องว่างนี้ โดยระบุว่า CVE-2026-65640 มีคะแนน CVSS 8.8 และถูกจัดอยู่ในระดับความรุนแรงสูง ไม่ใช่ระดับวิกฤต ซึ่งสอดคล้องกับข้อสังเกตข้างต้น เนื่องจากเงื่อนไขที่ต้องมีบัญชีระดับ Author ขึ้นไปเป็นสิ่งที่ดึงคะแนนลงมาจากระดับสูงสุด ผู้ที่ต้องจัดลำดับงานแพตช์จึงควรใช้ตัวเลขนี้ประกอบ แทนการยึดคำพาดหัวจากสำนักข่าวใดสำนักข่าวหนึ่ง

รายงานฉบับเดียวกันยังระบุที่มาของบทวิเคราะห์ทางเทคนิคให้ชัดขึ้นว่า คำอธิบายเรื่องความไม่ตรงกันระหว่างวิธีระบุชนิดไฟล์ของ ImageMagick กับของ WordPress มาจากบริษัท Patchstack ซึ่งเป็นบริษัทด้านการจัดการช่องโหว่ในระบบนิเวศของ WordPress โดย Patchstack สรุปความเสี่ยงในเชิงปฏิบัติไว้ว่า “หากคุณดูแลสิ่งพิมพ์ที่มีผู้เขียนหลายคน เว็บไซต์สมาชิก เว็บไซต์ของลูกค้าที่มีผู้ร่วมเขียน หรืออะไรก็ตามที่เปิดให้ลงทะเบียนได้หรือจัดการการลงทะเบียนอย่างหลวม ๆ การที่ผู้ใช้ระดับ Author อัปโหลด ‘รูปภาพ’ ที่ฝังกับดักไว้คือภัยคุกคามที่เกิดขึ้นได้จริง ไม่ใช่เรื่องในทางทฤษฎี”

รายละเอียดช่องโหว่

โดยปกติ ฟังก์ชัน wp_check_filetype_and_ext() ของ WordPress มีหน้าที่จับความไม่ตรงกันระหว่างนามสกุลไฟล์กับเนื้อในระหว่างการอัปโหลดตามปกติอยู่แล้ว ปัญหาคือ ไม่ใช่ทุกเส้นทางอัปโหลดที่จะวิ่งผ่านการตรวจนี้ โดยมีอย่างน้อยสองเส้นทางที่เขียนไบต์ลงดิสก์ตรง ๆ ด้วย wp_upload_bits() ซึ่งข้ามการตรวจเนื้อในไปทั้งหมด ได้แก่ เมธอด wp.uploadFile ของ XML-RPC และรูทีนดึงภาพปกจากไฟล์ MP3 ที่อัปโหลดเข้ามา ทั้งสองเส้นทางนี้จึงกลายเป็นประตูสำรองให้ผู้โจมตีวางเพย์โหลดที่เป็นอันตรายลงไปได้

การแก้ไขถูกส่งใน commit 7daaa50 ซึ่งเขียนฟังก์ชัน load() ใหม่ให้ตรวจสอบเนื้อในของไฟล์ก่อนที่จะสร้างออบเจ็กต์ Imagick ขึ้นมา โดยโค้ดใหม่จะสแกนก้อนข้อมูลส่วนแรกของทุกไฟล์ที่อัปโหลด แล้วบล็อกทุกอย่างที่มีลายเซ็นของ PostScript หรือ EPS รวมถึงไฟล์ที่อ้างว่าเป็น PDF แต่ไม่มีเฮดเดอร์ %PDF- ของจริง และไฟล์บีบอัดอย่าง gzip หรือ bzip2 ที่ ImageMagick จะแตกออกให้เองอย่างเงียบ ๆ

แพตช์ยังปิดกลเม็ดที่แนบเนียนกว่านั้นอีกชั้น คือการที่ผู้โจมตีสามารถเติมตัวระบุรูปแบบไฟล์ไว้หน้าชื่อไฟล์ เช่น EPS:innocent.png เพื่อบังคับให้ ImageMagick เลือกใช้ตัวถอดรหัสที่อันตราย โดยโค้ดใหม่จะตัดและตรวจสอบส่วนนำหน้าเหล่านี้ พร้อมระวังไม่ให้เกิดผลบวกลวงกับตัวอักษรระบุไดรฟ์บนระบบ Windows และใช้การตรวจแบบเดียวกันนี้กับชื่อไฟล์ที่มาจาก URL ระยะไกลหรือมาจากสตรีมด้วย

จุดที่ควรจดจำจากเคสนี้ในเชิงหลักการคือ ช่องโหว่ไม่ได้เกิดจาก Ghostscript หรือ ImageMagick มีบั๊กใหม่ แต่เกิดจากการที่ระบบสองตัวซึ่งทำงานต่อกันใช้ “นิยามของชนิดไฟล์” คนละแบบ ระบบหนึ่งเชื่อชื่อ อีกระบบหนึ่งเชื่อเนื้อใน ช่องว่างระหว่างสองนิยามนี้เองคือพื้นที่ที่ผู้โจมตีเข้าไปยืน ซึ่งเป็นรูปแบบที่พบซ้ำในระบบประมวลผลไฟล์แทบทุกประเภท ไม่เฉพาะรูปภาพ

ผลกระทบ

ผลกระทบจริงของช่องโหว่นี้แยกเป็นสองกลุ่มอย่างชัดเจน กลุ่มแรกคือเว็บไซต์ที่ไม่ได้เปิดใช้ส่วนขยาย Imagick หรือไม่มี Ghostscript ติดตั้งอยู่บนเซิร์ฟเวอร์ ซึ่งจะไม่ได้รับผลกระทบจากเส้นทางนี้เลย กลุ่มที่สองคือเว็บไซต์ที่ใช้ Imagick ร่วมกับ Ghostscript ซึ่งเป็นค่าปกติของโฮสติงหลายราย และมีผู้ใช้ระดับ Author หรือสูงกว่าอยู่หลายบัญชี กลุ่มหลังนี้เท่ากับว่าผู้ใช้ทุกคนที่มีสิทธิ์อัปโหลดไฟล์ล้วนมีเส้นทางไปสู่การรันโค้ดบนเซิร์ฟเวอร์อยู่ในมือ

สิ่งที่ทำให้เงื่อนไข “ต้องมีบัญชี” ไม่น่าอุ่นใจอย่างที่ฟัง คือบัญชีระดับ Author เป็นสิ่งที่ได้มาไม่ยากในหลายบริบท ทั้งเว็บที่เปิดรับผู้เขียนรับเชิญ เว็บสมาชิกที่เลื่อนขั้นผู้ใช้อัตโนมัติ และเว็บของลูกค้าที่เอเจนซีสร้างบัญชีทิ้งไว้จำนวนมากโดยไม่เคยเก็บกวาด ยิ่งไปกว่านั้น รหัสผ่านของบัญชีระดับกลางเหล่านี้มักไม่ได้ถูกบังคับด้วย MFA เหมือนบัญชีผู้ดูแลระบบ ทำให้การยึดบัญชี Author ผ่านรหัสผ่านที่รั่วจาก infostealer เป็นเรื่องที่เกิดขึ้นเป็นปกติ และเมื่อยึดได้แล้ว ช่องโหว่นี้ก็เปลี่ยนบัญชีที่ดูไม่มีอันตรายให้กลายเป็นการยึดเซิร์ฟเวอร์ได้ทันที

ในเชิงภาพรวม นี่เป็นช่องโหว่ตัวที่สองในแกนหลักของ WordPress ภายในเดือนเดียว ต่อจากช่องโหว่ XSS บนหน้าล็อกอินที่ไม่ต้องล็อกอินซึ่งปิดไปในเวอร์ชัน 7.0.3 (ดู โพสต์ 2026/08/043 ) และยังตามหลังกรณี wp2shell ในเดือนกรกฎาคมที่ผู้โจมตีไล่สแกนทั่วอินเทอร์เน็ตหลังโค้ดสาธิตหลุดออกมา (ดู โพสต์ 2026/07/231 ) ความถี่ระดับนี้แปลว่าองค์กรที่ยังใช้กระบวนการอัปเดต WordPress แบบรายไตรมาสหรือรอรอบบำรุงรักษาประจำ กำลังใช้กรอบเวลาที่ไม่สอดคล้องกับความเป็นจริงของแพลตฟอร์ม

คำแนะนำ

สิ่งที่ต้องทำก่อนอื่นคืออัปเดตเป็น WordPress 7.0.4 ทันที และตรวจสอบว่าเว็บไซต์เปิดการอัปเดตอัตโนมัติเบื้องหลังไว้จริงหรือไม่ เพราะหลายเว็บที่คิดว่าเปิดอยู่กลับถูกปิดไว้จากการตั้งค่าของโฮสต์หรือปลั๊กอินจัดการอัปเดต จากนั้นควรตรวจว่าเซิร์ฟเวอร์ใช้ Imagick และมี Ghostscript ติดตั้งอยู่หรือไม่ หากงานของเว็บไซต์ไม่จำเป็นต้องประมวลผลไฟล์ PostScript, EPS หรือ PDF ผ่าน ImageMagick การปิดตัวถอดรหัสเหล่านั้นในนโยบายของ ImageMagick (policy.xml) เป็นการลดพื้นที่โจมตีที่ได้ผลถาวรกว่าการรอแพตช์รายครั้ง

ถัดมาควรทบทวนรายชื่อบัญชีผู้ใช้ทั้งหมดที่มีสิทธิ์ระดับ Author ขึ้นไป ลบบัญชีที่ไม่ได้ใช้งาน ลดสิทธิ์บัญชีที่ไม่จำเป็นต้องอัปโหลดไฟล์ และบังคับ MFA กับบัญชีที่เหลือ โดยเฉพาะบนเว็บไซต์ที่เปิดรับผู้เขียนจากภายนอก นอกจากนี้ควรพิจารณาปิด XML-RPC หากไม่ได้ใช้งานจริง เนื่องจากเมธอด wp.uploadFile คือหนึ่งในสองเส้นทางที่ข้ามการตรวจชนิดไฟล์ในเคสนี้ และ XML-RPC ยังเป็นเป้าของการโจมตีแบบเดารหัสผ่านมาอย่างยาวนานอยู่แล้ว

ในแง่การตรวจสอบย้อนหลัง ควรไล่ดูไฟล์ในโฟลเดอร์อัปโหลดที่มีนามสกุลเป็นรูปภาพแต่มีเนื้อในขึ้นต้นด้วยลายเซ็นของ PostScript หรือ EPS รวมถึงไฟล์ที่อ้างว่าเป็น PDF แต่ไม่มีเฮดเดอร์ %PDF- และตรวจล็อกของเว็บเซิร์ฟเวอร์หาการเรียก xmlrpc.php ที่ผิดปกติในช่วงก่อนหน้าการแพตช์ พร้อมมองหาไฟล์ PHP ที่ถูกสร้างขึ้นใหม่ในโฟลเดอร์อัปโหลด ซึ่งเป็นร่องรอยมาตรฐานของการฝังเว็บเชลล์หลังใช้ช่องโหว่ประเภทนี้สำเร็จ

แหล่งอ้างอิง