สรุปสั้น
คำขอ HTTP แบบไม่ระบุตัวตนเพียงคำขอเดียวสามารถรันโค้ดบนเว็บไซต์ WordPress ได้ และเนื่องจากบั๊กอยู่ในตัว core เอง เว็บไซต์ที่ติดตั้งแบบเปล่าโดยไม่มีปลั๊กอินสักตัวก็ยังถูกโจมตีได้ เว็บไซต์ที่ใช้เวอร์ชัน 6.9 และ 7.0 ทุกแห่งอยู่ในระยะการโจมตีจนกระทั่งวันศุกร์ที่ผ่านมา เมื่อ WordPress ปล่อยเวอร์ชัน 6.9.5 และ 7.0.2 พร้อมเปิดใช้สิ่งที่เรียกว่าการบังคับอัปเดต (forced updates) ผ่านระบบอัปเดตอัตโนมัติ ช่องโหว่ชุดนี้ถูกเรียกรวมกันว่า wp2shell ซึ่งแท้จริงประกอบด้วยบั๊ก 2 ตัวที่ต่างก็มีหมายเลข CVE ของตัวเองแล้ว ได้แก่ CVE-2026-63030 ซึ่งเป็นความสับสนของเส้นทาง batch ใน REST API และ CVE-2026-60137 ซึ่งเป็นช่องโหว่ SQL injection ใน WordPress core เมื่อนำสองตัวนี้มาต่อกันจะพาคำขอแบบไม่ระบุตัวตนไปจนถึงการรันโค้ดได้
นาย Adam Kues จากบริษัท Assetnote ซึ่งเป็นหน่วยงานด้านการบริหารพื้นผิวการโจมตีของบริษัท Searchlight Cyber เป็นผู้ค้นพบบั๊กเส้นทาง batch และรายงานผ่านโครงการ HackerOne ของ WordPress โดยรายงานที่เผยแพร่ภายใต้ชื่อ wp2shell ระบุว่าการโจมตีนี้ “ไม่มีเงื่อนไขเบื้องต้นใดๆ และผู้ใช้ที่ไม่ระบุตัวตนสามารถใช้โจมตีได้” ส่วนช่องโหว่ SQL injection ถูกรายงานแยกต่างหากโดยนักวิจัยที่ใช้ชื่อ TF1T, dtro และ haongo แม้บริษัท Searchlight จะยังไม่เผยแพร่รายงานเทคนิคฉบับเต็มของตนและแนะนำให้เจ้าของเว็บไปตรวจสอบผ่านเครื่องมือที่ wp2shell.com แต่การสงวนข้อมูลนั้นแทบไม่มีความหมายอีกต่อไป เพราะแพตช์เป็นสาธารณะและนักวิจัยรายอื่นได้อ่านโค้ดที่แก้ไขจนเข้าใจกลไกทั้งหมด และมีโค้ดพิสูจน์แนวคิดที่ใช้งานได้จริงถูกอัปโหลดขึ้น GitHub แล้ว
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานและอัปเดตข้อมูลเมื่อวันที่ 18 กรกฎาคม 2569 ว่าช่องโหว่ทั้งสองรายการได้รับหมายเลข CVE เรียบร้อยแล้ว กลไกการทำงานฉบับเต็มถูกเผยแพร่ต่อสาธารณะ มีการค้นพบเงื่อนไขเพิ่มเติมเกี่ยวกับระบบแคชวัตถุแบบถาวร (persistent object cache) และมีโค้ดพิสูจน์แนวคิดที่ใช้งานได้จริงเผยแพร่ออกมาแล้ว
ประเด็นสำคัญที่ผู้ดูแลเว็บไซต์ต้องเข้าใจคือบั๊กทั้งสองตัวไม่ได้กระทบเวอร์ชันเดียวกัน ซึ่งเป็นกุญแจสำคัญในการประเมินว่าใครเสี่ยงกับอะไร ช่องโหว่ SQL injection ย้อนกลับไปถึงเวอร์ชัน 6.8 ขณะที่ความสับสนของเส้นทาง batch ซึ่งเป็นส่วนที่เปลี่ยนการโจมตีฐานข้อมูลแบบจำกัดขอบเขตให้กลายเป็นการรันโค้ดโดยไม่ต้องยืนยันตัวตน มีอยู่ตั้งแต่เวอร์ชัน 6.9 เป็นต้นไปเท่านั้น ช่วงเวอร์ชันจึงแยกออกเป็น 6.8.0 ถึง 6.8.5 ที่มีเฉพาะ SQL injection แก้ไขแล้วใน 6.8.6, เวอร์ชัน 6.9.0 ถึง 6.9.4 ที่มีห่วงโซ่ RCE เต็มรูปแบบ แก้ไขแล้วใน 6.9.5 และเวอร์ชัน 7.0.0 ถึง 7.0.1 ที่มีห่วงโซ่ RCE เช่นกัน แก้ไขแล้วใน 7.0.2 ส่วนเวอร์ชัน 7.1 beta2 มีการแก้ไขทั้งสองรายการแล้ว ทั้งนี้ WordPress ยังไม่ได้ระบุว่าการบังคับอัปเดตครอบคลุมถึงเว็บไซต์ที่ปิดการอัปเดตอัตโนมัติไว้หรือไม่ ผู้ดูแลจึงควรตรวจสอบเวอร์ชันที่ใช้งานจริงแทนที่จะสันนิษฐานว่าแพตช์มาถึงแล้ว
บทความของบริษัท Searchlight ประเมินว่ามีเว็บไซต์กว่า 500 ล้านแห่งทั่วโลกที่ใช้ WordPress แต่ตัวเลขนั้นคือฐานการติดตั้งทั้งหมด ไม่ใช่จำนวนเว็บไซต์ที่เสี่ยงจริง เพราะห่วงโซ่ RCE มีอยู่ตั้งแต่เวอร์ชัน 6.9 ซึ่งออกเมื่อวันที่ 2 ธันวาคม 2568 เท่านั้น หมายความว่าทุกเว็บไซต์ที่เปิดรับเส้นทางการรันโค้ดนี้ล้วนใช้เวอร์ชันที่ออกมาไม่ถึงแปดเดือน และยังไม่มีประกาศใดระบุว่ามีจำนวนเท่าใด
รายละเอียดช่องโหว่
ห่วงโซ่การโจมตีนี้เกิดจากความผิดพลาดเล็กๆ สองจุดที่มาบรรจบกัน จุดแรกคือช่องโหว่ SQL injection ซึ่งอยู่ในพารามิเตอร์ author__not_in ของคลาส WP_Query หากส่งค่าเป็นสตริงแทนที่จะเป็นอาร์เรย์ การตรวจสอบที่คาดหวังว่าจะได้รับอาร์เรย์จะถูกข้ามไป ทำให้ค่าดิบถูกส่งลงไปในคำสั่งฐานข้อมูลโดยตรง จุดที่สองคือวิธีเข้าถึงพารามิเตอร์นั้นโดยไม่ต้องล็อกอิน ซึ่งเป็นหน้าที่ของเส้นทาง batch โดยเส้นทาง /wp-json/batch/v1 ของ WordPress จะรันคำขอย่อยหลายรายการในการเรียกครั้งเดียว และติดตามผลด้วยอาร์เรย์สองชุดที่ทำงานคู่ขนานกัน เมื่อเกิดข้อผิดพลาดในคำขอย่อยรายการใดรายการหนึ่ง อาร์เรย์ทั้งสองจะเหลื่อมกันไปหนึ่งตำแหน่ง ส่งผลให้คำขอหนึ่งไปทำงานภายใต้ตัวจัดการของอีกคำขอหนึ่ง
เมื่อนำความสับสนนี้มาซ้อนกันหลายชั้น จะสามารถเดินผ่านรายการอนุญาต (allow-list) ของ endpoint และพาข้อมูลนำเข้าของผู้โจมตีไปลงในคำสั่งฐานข้อมูลที่มีช่องโหว่ได้โดยไม่ต้องยืนยันตัวตน ทั้งนี้ endpoint แบบ batch มีมาตั้งแต่เวอร์ชัน 5.6 ในปี 2563 แต่ความสับสนที่นำมาใช้โจมตีนี้เป็นของใหม่ที่เกิดขึ้นในเวอร์ชัน 6.9
คะแนนความรุนแรงของช่องโหว่ชุดนี้เป็นเรื่องที่ต้องอ่านอย่างระมัดระวัง ประกาศเตือนของ WordPress เองจัดห่วงโซ่ RCE ไว้ที่ระดับ Critical แต่ระเบียนของ CVE ให้คะแนนเพียง 7.5 ซึ่งเป็นระดับ High และตัวชี้วัดผลกระทบให้เครดิตเฉพาะการเข้าถึงข้อมูล ไม่ได้นับความเสียหายต่อความถูกต้องของข้อมูลหรือความพร้อมใช้งานที่ควรเกิดจากการรันโค้ด ขณะที่ช่องโหว่ SQL injection กลับได้คะแนนสูงกว่า 9.1 ซึ่งอยู่ในระดับ Critical กล่าวคือบั๊กที่ทุกคนเรียกว่า RCE ระดับวิกฤตกลับเป็นตัวที่ได้คะแนนต่ำกว่าตามหมายเลขของมันเอง เพราะระบบให้คะแนนตอบแทนการเข้าถึงฐานข้อมูลโดยตรงของ SQL injection และมองความสับสนของเส้นทางแบบแยกเดี่ยวว่าเป็นเพียงข้อบกพร่องด้านการแยกวิเคราะห์ข้อมูล ผู้ดูแลจึงควรติดตามทั้งสอง CVE ไม่ใช่ยึดตามป้ายกำกับของตัวใดตัวหนึ่ง
มีเงื่อนไขหนึ่งที่ช่วยลดรัศมีความเสียหายลง คือเส้นทางการรันโค้ดจะทำงานได้เฉพาะเมื่อเว็บไซต์ไม่ได้ใช้ระบบแคชวัตถุแบบถาวร ตามข้อมูลจากบริษัท Cloudflare ที่ปล่อยกฎ WAF ออกมาพร้อมกับการเปิดเผยช่องโหว่ แต่เนื่องจากการติดตั้งแบบมาตรฐานไม่มีแคชดังกล่าว ความเสี่ยงของการติดตั้งพื้นฐานจึงยังคงอยู่เต็มที่ เว็บไซต์ที่วาง Redis หรือ Memcached เป็นแคชวัตถุแบบถาวรอาจหลุดพ้นจากเส้นทางนี้ แต่นั่นเป็นเพียงผลข้างเคียง ไม่ใช่การแก้ไข และไม่ครอบคลุมช่องโหว่ SQL injection แต่อย่างใด สำหรับเครื่องมือสแกน บริษัท Rapid7 ระบุว่าการตรวจสอบแบบยืนยันตัวตนสำหรับ InsightVM และ Nexpose จะพร้อมใช้งานวันที่ 20 กรกฎาคม ส่วนช่องโหว่นี้ยังไม่อยู่ในแคตตาล็อก KEV ของ CISA ซึ่งต้องอาศัยหลักฐานการโจมตีจริงที่ยืนยันแล้ว และยังไม่มีรายงานการโจมตีจนถึงวันที่ 18 กรกฎาคม 2569
ผลกระทบต่อไทย
WordPress เป็นระบบจัดการเนื้อหาที่ครองส่วนแบ่งสูงที่สุดในประเทศไทย ตั้งแต่เว็บไซต์หน่วยงานราชการ โรงเรียนและมหาวิทยาลัย โรงพยาบาล สื่อออนไลน์ ไปจนถึงเว็บไซต์ธุรกิจขนาดเล็กและร้านค้าออนไลน์ การที่ช่องโหว่อยู่ในตัว core ไม่ใช่ปลั๊กอิน ทำให้คำแนะนำเดิมที่ว่า “ลดจำนวนปลั๊กอินเพื่อลดความเสี่ยง” ใช้ไม่ได้กับกรณีนี้ เว็บไซต์ที่ติดตั้งแบบสะอาดที่สุดก็ยังถูกโจมตีได้เท่ากัน
ความเสี่ยงเฉพาะของไทยอยู่ที่เว็บไซต์จำนวนมากถูกจ้างทำครั้งเดียวแล้วไม่มีผู้ดูแลต่อเนื่อง ปิดการอัปเดตอัตโนมัติไว้เพราะกลัวธีมหรือปลั๊กอินพัง หรือใช้โฮสติ้งราคาประหยัดที่ไม่มีทีมความปลอดภัยคอยดูแล เว็บไซต์กลุ่มนี้จะไม่ได้รับการบังคับอัปเดตและจะยังคงมีช่องโหว่อยู่ต่อไปอีกนาน ขณะที่การโจมตี WordPress เป็นจำนวนมากในระดับอุตสาหกรรมเป็นเรื่องปกติไปแล้ว โดยก่อนที่เซิร์ฟเวอร์ของกลุ่มหนึ่งจะรั่วไหลเมื่อเดือนมิถุนายน กลุ่มที่ใช้ชื่อ WP-SHELLSTORM อ้างว่าเจาะเว็บไซต์ได้กว่า 17,000 แห่งด้วยช่องโหว่ในปลั๊กอินแคชเพียงตัวเดียวที่เปิดเผยและแพตช์ไปแล้ว ทั้งที่ต้องอาศัยการตั้งค่าที่ไม่ใช่ค่าเริ่มต้นด้วยซ้ำ แต่ครั้งนี้ช่องโหว่เป็นสาธารณะ แพตช์แล้ว และทำงานได้บนการตั้งค่าเริ่มต้น ซึ่งอันตรายกว่ามาก และเมื่อเว็บไซต์ราชการหรือโรงพยาบาลถูกยึด ผลที่ตามมามักไม่ใช่แค่หน้าเว็บถูกเปลี่ยน แต่เป็นการฝังหน้าฟิชชิงหรือกระจายมัลแวร์ในนามหน่วยงานที่ประชาชนไว้วางใจ
คำแนะนำ
สิ่งที่ต้องทำเป็นอันดับแรกคืออัปเดต WordPress เป็นเวอร์ชัน 6.8.6, 6.9.5 หรือ 7.0.2 ตามสายที่ใช้งานอยู่ทันที และต้องเข้าไปตรวจสอบหมายเลขเวอร์ชันที่ทำงานอยู่จริงด้วยตนเอง ไม่ควรสันนิษฐานว่าการบังคับอัปเดตทำงานสำเร็จ โดยเฉพาะเว็บไซต์ที่เคยปิดการอัปเดตอัตโนมัติหรือแก้ไขไฟล์ core เอง
สำหรับเว็บไซต์ที่ยังอัปเดตไม่ได้ในทันที มาตรการบรรเทาทั้งหมดที่บริษัท Searchlight เสนอสรุปได้เป็นการกันผู้เรียกที่ไม่ระบุตัวตนออกจาก endpoint แบบ batch ซึ่งล้วนเป็นเพียงมาตรการชั่วคราวและอาจทำให้การเชื่อมต่อกับระบบอื่นที่ถูกต้องเสียหายได้ ประกอบด้วยการบล็อกที่ระดับ WAF ทั้งเส้นทาง /wp-json/batch/v1 และ rest_route=/batch/v1 ซึ่งต้องบล็อกทั้งคู่ เพราะกฎที่ครอบคลุมเฉพาะเส้นทาง /wp-json จะเปิดช่องให้เรียกผ่าน query string ได้อยู่ดี โดยบริษัท Cloudflare ระบุว่า WAF แบบจัดการของตนบล็อกห่วงโซ่นี้ให้เว็บไซต์ที่อยู่หลังบริการแล้ว อีกทางเลือกคือปิดการใช้งาน WordPress REST API ซึ่งจะตัดการเข้าถึง REST แบบไม่ยืนยันตัวตนทั้งหมด หรือใช้ปลั๊กอินขนาดสั้นที่บริษัท Searchlight เผยแพร่ ซึ่งจะปฏิเสธคำขอ /batch/v1 แบบไม่ระบุตัวตนตั้งแต่ขั้น rest_pre_dispatch
หลังอัปเดตแล้วยังไม่ควรวางใจ ควรตรวจสอบร่องรอยการบุกรุกย้อนหลัง ทั้งบัญชีผู้ดูแลที่ถูกสร้างขึ้นใหม่ ไฟล์ PHP แปลกปลอมในโฟลเดอร์ uploads งานตามกำหนดเวลา (cron) ที่ไม่คุ้นเคย และการแก้ไขไฟล์ธีมหรือปลั๊กอินที่ไม่ได้เกิดจากทีมงาน พร้อมทั้งตรวจล็อกของเว็บเซิร์ฟเวอร์ย้อนหลังเพื่อหาคำขอที่ยิงเข้ามาที่ batch/v1 เพราะโค้ดโจมตีถูกเผยแพร่แล้วและการกวาดโจมตีเป็นวงกว้างมักตามมาภายในไม่กี่วัน