สรุปสั้น

WordPress ออกแพตช์แก้ช่องโหว่ reflected cross-site scripting หรือ XSS บนหน้าจอล็อกอิน ซึ่งใช้งานได้โดยไม่ต้องยืนยันตัวตนก่อน และกระทบทุกเวอร์ชันของระบบจัดการเนื้อหาตัวนี้ ช่องโหว่ถูกติดตามในรหัส CVE-2026-64638 ระดับความรุนแรงสูงที่คะแนน CVSS 8.9 และไม่ต้องการสิทธิ์ใด ๆ จากฝั่งผู้โจมตี

ทีมวิจัย pwn.ai ซึ่งเป็นผู้ค้นพบและแบ่งปันรายละเอียดเชิงเทคนิคให้ The Hacker News สาธิตว่าช่องโหว่นี้สามารถร้อยต่อไปสู่การรันโค้ด PHP บนเซิร์ฟเวอร์ได้ เมื่อผู้ดูแลระบบที่ล็อกอินค้างอยู่เข้าไปมีปฏิสัมพันธ์กับหน้าเว็บที่ผู้โจมตีควบคุม ซึ่งในการสาธิตของทีมคือการคลิกเพียงครั้งเดียวตามปกติ นักวิจัยระบุว่าการโจมตีได้ผลกับการติดตั้ง WordPress ค่าเริ่มต้น และไม่ต้องอาศัยการตั้งค่าโฮสต์หรือการติดตั้งที่ผิดปกติแต่อย่างใด

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

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 7 สิงหาคม 2569 ว่า ทีมนักวิจัยเรียกห่วงโซ่การโจมตีนี้ว่า XSS2Shell และระบุว่าระบบอัตโนมัติของตนเป็นผู้ค้นพบและทำซ้ำห่วงโซ่ช่องโหว่นี้ได้ หลังจากถูกป้อนงานวิจัย Same Origin Method Execution หรือ SOME ของนาย Paulos Yibelo เมื่อปี 2565 เป็นจุดตั้งต้น

บริษัทระบุว่างานชิ้นนี้ใช้เวลาเกือบ 4 วัน โดยใช้โมเดลโอเพนซอร์สและกระบวนการทำงานแบบหลายเอเจนต์ ห่วงโซ่ถูกทำซ้ำได้สำเร็จเมื่อวันที่ 26 กรกฎาคม และรายงานไปยัง WordPress ในวันถัดมา ซึ่งทาง WordPress ให้เครดิตทีมงาน pwn.ai ในการค้นพบและเปิดเผยช่องโหว่อย่างมีความรับผิดชอบ

กรณีนี้จึงเป็นอีกตัวอย่างของแนวโน้มที่เห็นชัดขึ้นเรื่อย ๆ ในปีนี้ คือการใช้ระบบอัตโนมัติที่ขับเคลื่อนด้วยโมเดลภาษามาค้นหาและร้อยห่วงโซ่ช่องโหว่ในซอฟต์แวร์ที่ผ่านการตรวจสอบมาแล้วนับไม่ถ้วน เว็บไซต์ Cloud Thunder เคยรายงานกรณีลักษณะเดียวกันไว้แล้วใน เครื่องปั๊มช่องโหว่ด้วย AI ที่ค้นพบ zero-day SQL injection ในปลั๊กอิน WordPress

ในแง่ของหลักฐาน ต้องระบุให้ชัดว่ามีการแบ่งระดับกันอยู่ หลักฐานที่ทีมนักวิจัยส่งให้ The Hacker News จากระบบจริงหยุดอยู่แค่ตัว XSS เท่านั้น โดยพวกเขาทำซ้ำ XSS บนหน้าล็อกอินแบบไม่ต้องมีคุกกี้ได้กับการติดตั้ง WordPress 7.0.2 จำนวน 2 แห่ง บนโปรไฟล์ Chrome ใหม่ที่ไม่มีคุกกี้หรือข้อมูลรับรองของ WordPress อยู่เลย แต่ ไม่ได้ลองสร้าง Application Password อัปโหลดไฟล์ ฝังตัว หรือรันโค้ด PHP บนระบบเหล่านั้น ส่วนห่วงโซ่การรันโค้ด PHP แบบครบวงจรถูกสาธิตแยกต่างหากบนการติดตั้ง WordPress 7.0.2 ที่สะอาดในเครื่องท้องถิ่น

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

ต้นตอของปัญหาอยู่ที่วิธีที่ WordPress จัดการกับชื่อผู้ใช้จากการล็อกอินที่ล้มเหลว ตามคำอธิบายของนักวิจัย ค่าที่ผู้ใช้กรอกจะผ่านฟังก์ชัน sanitize_user() และ wp_strip_all_tags() ซึ่งอาศัย strip_tags() ของ PHP อยู่เบื้องหลัง ปัญหาคือสตริงที่ดูคล้ายแท็กแต่มีอักขระเว้นวรรคตามหลังเครื่องหมาย < ทันที สามารถรอดผ่านตัวแยกวิเคราะห์นั้นไปได้ในฐานะข้อความธรรมดา

หลังจากนั้น WordPress ส่งค่าเดียวกันผ่าน wp_kses_post() ซึ่งใช้ตัวแยกวิเคราะห์คนละตัว และตัวนี้ตีความข้อมูลเดิมว่าเป็น HTML ที่อนุญาต ผลลัพธ์คือมีองค์ประกอบ DOM ที่ผู้โจมตีควบคุมได้ปรากฏขึ้นจริงบนหน้าล็อกอินที่ล้มเหลว นี่คือรูปแบบคลาสสิกของช่องโหว่ที่เกิดจากการมีตัวแยกวิเคราะห์สองตัวที่ตีความข้อมูลเดียวกันไม่ตรงกัน

องค์ประกอบเหล่านั้นไปมีปฏิสัมพันธ์กับ user-profile.js ของ WordPress เอง ซึ่งเป็นสคริปต์จัดการโปรไฟล์ที่ถูกโหลดบนหน้าล็อกอินด้วยเพราะหน้านั้นรองรับการรีเซ็ตรหัสผ่าน ปัญหาคือองค์ประกอบบางอย่างที่สคริปต์คาดหวังกลับไม่มีอยู่บนหน้านั้น ทำให้ช่องกรอก 2 ช่องที่หายไปคืนค่าเป็น undefined ทั้งคู่ ซึ่งทำให้การเปรียบเทียบความเท่ากันผ่านเงื่อนไขไปได้ ขณะเดียวกันตัวแปร ajaxurl ที่ปกติไม่ถูกกำหนดค่าบนหน้านี้ก็สามารถถูกทับด้วยองค์ประกอบ DOM ที่ฉีดเข้าไปได้ ผลคือ JavaScript ของ WordPress เองถูกบังคับให้ยิงคำขอ REST ไปยังปลายทางที่ผู้โจมตีเลือก ภายใต้ origin เดียวกัน

จากนั้นนักวิจัยใช้การรองรับ JSONP ของ REST ใน WordPress เพื่อเปลี่ยนคำขอนั้นให้กลายเป็น JavaScript ที่ทำงานภายใต้ origin ของเว็บไซต์ และในกรณีที่การตั้งค่าปฏิเสธคำขอ REST แบบไม่ระบุตัวตนด้วย HTTP 401 พารามิเตอร์ _envelope=1 สามารถห่อการปฏิเสธนั้นไว้ในการตอบกลับ HTTP 200 ชั้นนอก ทำให้ jQuery ประมวลผลการตอบกลับต่อในฐานะสคริปต์ได้ นักวิจัยยังพบในการทดสอบว่า Content Security Policy แบบใช้ nonce ร่วมกับ strict-dynamic ไม่สามารถบล็อกเส้นทางที่สาธิต ได้

เส้นทางจาก XSS ไปสู่การรันโค้ด PHP ต่อยอดจากเทคนิค SOME ของนาย Yibelo ซึ่งอาศัยห่วงโซ่คุณสมบัติของ JSONP ที่ระบบอนุญาต เพื่อเรียกใช้เมธอดในหน้าต่างเบราว์เซอร์อีกบานหนึ่ง เส้นทางหนึ่งที่ pwn.ai สาธิตคือใช้ XSS บน origin ของ WordPress ไปสั่งงานปุ่มอนุมัติ Application Password ที่มีมากับระบบอยู่แล้ว ภายในเซสชันของผู้ดูแลระบบที่ล็อกอินอยู่ WordPress จะสร้างข้อมูลรับรองสำหรับ API ขึ้นมาแล้วส่งต่อไปยัง success_url แบบ HTTPS ที่ผู้โจมตีเลือกไว้

จุดที่แยบยลคือ Application Password เป็นข้อมูลรับรองที่เพิกถอนได้และมีไว้สำหรับการเข้าถึงผ่าน API ดังนั้นเส้นทางนี้จึงไม่ต้องขโมยรหัสผ่านหลักของผู้ดูแลระบบเลย นักวิจัยใช้ข้อมูลรับรองนั้นเข้าถึง REST แบบยืนยันตัวตนแล้วเผยแพร่หน้าเพจของ WordPress ที่บรรจุ JavaScript ภายใต้ origin เดียวกัน เมื่อเซสชันของผู้ดูแลระบบที่ยังคงอยู่เปิดหน้านั้น สคริปต์ก็ดึง nonce สำหรับอัปโหลดปลั๊กอินมาได้ แล้วอัปโหลดไฟล์ ZIP ที่ผู้โจมตีเตรียมไว้ จากนั้นสามารถเรียก PHP จากปลั๊กอินที่ถูกแตกไฟล์แล้วได้โดยตรง โดยที่ปลั๊กอินนั้นไม่จำเป็นต้องถูกเปิดใช้งานด้วยซ้ำ นอกจากนี้นักวิจัยยังระบุว่ามีเส้นทางจาก XSS ไปสู่การรันโค้ดได้หลายทาง ทั้งแบบติดตั้งปลั๊กอินและแบบอัปโหลด ZIP ตามอำเภอใจ

ผลกระทบ

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

หากการรันโค้ด PHP สำเร็จ ผลที่ตามมาตามที่รายงานระบุคือข้อมูลรับรองฐานข้อมูลใน wp-config.php ถูกเปิดเผย ผู้โจมตีสามารถสร้างบัญชีผู้ดูแลระบบไว้ฝังตัวถาวรและแก้ไขเนื้อหาได้ ไฟล์และความลับทั้งหมดที่ PHP worker อ่านได้ก็ถูกเปิดเผย และสามารถรันคำสั่งระดับระบบปฏิบัติการด้วยสิทธิ์ของ worker นั้นได้ ในทางปฏิบัตินี่เท่ากับการยึดเว็บไซต์อย่างสมบูรณ์

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

จุดที่ผู้ดูแลควรใส่ใจเป็นพิเศษคือ ตัว XSS เองยังคงเป็นความเสี่ยงแม้จะไม่ต่อยอดเป็นการรันโค้ด และนักวิจัยระบุชัดว่ามาตรการเสริมความแข็งแรงที่คนนิยมใช้กับ WordPress ไม่ควรถูกถือว่าเป็นการบรรเทาที่ครบถ้วน สำหรับ XSS ที่เป็นต้นเหตุ การติดตั้งอัปเดตความปลอดภัยจึงเป็นสิ่งที่จำเป็น ไม่ใช่ทางเลือก

คำแนะนำ

อัปเดต WordPress เป็นเวอร์ชัน 7.0.3 หรือเวอร์ชันที่ย้อนแพตช์แล้วในสายที่ใช้อยู่โดยเร็วที่สุด เว็บไซต์ที่เปิดการอัปเดตพื้นหลังอัตโนมัติไว้ควรได้รับแพตช์ความปลอดภัยนี้เองอยู่แล้ว แต่ผู้ดูแลควรเข้าไปตรวจยืนยันเวอร์ชันจริงในหน้าผู้ดูแลระบบ ไม่ควรสันนิษฐานว่าอัปเดตสำเร็จ

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

สำหรับผู้ดูแลระบบ ควรลดโอกาสที่เงื่อนไขของการโจมตีจะครบด้วยการแยกเบราว์เซอร์หรือโปรไฟล์เบราว์เซอร์ที่ใช้เข้าหน้าผู้ดูแล WordPress ออกจากที่ใช้ท่องเว็บทั่วไป และออกจากระบบเมื่อไม่ได้ใช้งาน แทนที่จะปล่อยเซสชันค้างไว้ตลอดเวลา

นอกจากนี้ควรตรวจสอบรายการ Application Password ที่มีอยู่ในบัญชีผู้ดูแลระบบทุกบัญชี และเพิกถอนรายการที่ไม่รู้จักหรือไม่ได้ใช้งานแล้ว เพราะเส้นทางที่นักวิจัยสาธิตอาศัยกลไกนี้โดยตรง พร้อมกับตรวจหาบัญชีผู้ดูแลระบบที่ถูกสร้างขึ้นโดยไม่มีที่มา ปลั๊กอินที่ถูกอัปโหลดเข้ามาแต่ไม่ได้ถูกเปิดใช้งาน และไฟล์ PHP แปลกปลอมในไดเรกทอรีปลั๊กอิน ซึ่งเป็นร่องรอยที่ตรงกับห่วงโซ่การโจมตีนี้

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