ใช้ WordPress เช็ค version ด่วน wp2shell โจมตีได้ โดยไม่ต้องล็อกอิน

ช่องโหว่ WordPress Core เปิดทางโจมตีโดยไม่ต้องล็อกอิน องค์กรควรเร่งแพตช์และตรวจสอบย้อนหลัง

เมื่อวันที่ 17 กรกฎาคม 2026 มีการเปิดเผยช่องโหว่สำคัญใน WordPress Core จำนวน 2 รายการ ได้แก่ CVE-2026-63030 และ CVE-2026-60137 ซึ่งสามารถนำมาเชื่อมต่อกันเป็นชุดการโจมตีที่เรียกว่า wp2shell

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

รายงาน Threat Advisory ของ CloudSEK ซึ่งรวบรวมข้อมูลถึงวันที่ 20 กรกฎาคม 2026 ระบุว่า พบความพยายามใช้ประโยชน์จากช่องโหว่นี้จริงภายในเวลาไม่นานหลังการเปิดเผย และมีการเผยแพร่โค้ด Proof of Concept ต่อสาธารณะแล้ว ทำให้องค์กรที่ยังใช้ WordPress เวอร์ชันที่ได้รับผลกระทบควรดำเนินการทันที

เกิดอะไรขึ้นกับ WordPress

wp2shell ไม่ได้เป็นช่องโหว่เดี่ยว แต่เป็นการนำช่องโหว่สองส่วนใน WordPress Core มาใช้งานร่วมกัน

ช่องโหว่แรกเกี่ยวข้องกับกระบวนการจัดการคำขอแบบ Batch ของ WordPress REST API ซึ่งอาจทำให้ระบบตรวจสอบสิทธิ์ผิดพลาด ส่วนช่องโหว่ที่สองเป็น SQL Injection ในกระบวนการค้นหาข้อมูลของ WordPress

เมื่อนำทั้งสองส่วนมาเชื่อมกัน ผู้โจมตีที่ไม่ได้เข้าสู่ระบบอาจส่งคำขอที่สร้างขึ้นเป็นพิเศษไปยัง REST API ของเว็บไซต์ เพื่อเข้าถึงข้อมูลในฐานข้อมูลได้

ข้อมูลที่ตกเป็นเป้าหมายอาจรวมถึง

• ชื่อบัญชีผู้ดูแล WordPress

• Password Hash

• ข้อมูลลูกค้าและผู้ใช้งาน

• API Key หรือ Secret ที่จัดเก็บอยู่ในฐานข้อมูล

• ข้อมูล Configuration ของเว็บไซต์

• ข้อมูลจากปลั๊กอิน E-commerce หรือระบบสมาชิก

หลังได้ข้อมูลบัญชีหรือ Secret แล้ว ผู้โจมตีอาจนำไปถอดรหัส ทดลองใช้ซ้ำ หรือเข้าสู่ระบบด้วยสิทธิ์ Administrator จากนั้นติดตั้งปลั๊กอินอันตราย สร้างบัญชีลับ หรือฝัง Web Shell เพื่อรักษาสิทธิ์ในการเข้าถึงระบบ

กล่าวได้ว่า เส้นทางการโจมตีอาจเริ่มจากการอ่านฐานข้อมูล และจบลงด้วยการควบคุมเว็บไซต์อย่างเต็มรูปแบบ

ทำไมเหตุการณ์นี้จึงมีความเสี่ยงสูง

CloudSEK จัดระดับความรุนแรงของภัยคุกคามนี้เป็น Critical และระบุสถานะการใช้ประโยชน์จากช่องโหว่ว่า Active, confirmed

ปัจจัยที่ทำให้ความเสี่ยงสูงประกอบด้วย

โจมตีได้โดยไม่ต้องล็อกอิน

ผู้โจมตีไม่จำเป็นต้องมี Username หรือ Password ล่วงหน้า และไม่ต้องหลอกให้ผู้ใช้งานกดลิงก์หรือเปิดไฟล์

เป็นช่องโหว่ใน WordPress Core

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

มีโค้ด Proof of Concept เผยแพร่แล้ว

รายงานระบุว่ามีการเผยแพร่โค้ดทดสอบการโจมตีบน GitHub ตั้งแต่วันที่ 18 กรกฎาคม 2026 ซึ่งช่วยลดความซับซ้อนในการนำช่องโหว่ไปใช้งานจริง

พบความพยายามโจมตีหลังเปิดเผยเพียงไม่นาน

บริษัทด้านความปลอดภัยหลายแห่งรายงานความพยายามใช้ประโยชน์จากช่องโหว่ภายในวันเดียวกับที่มีการเปิดเผยข้อมูล

การโจมตีช่วงแรกอาจทิ้งร่องรอยไม่มาก

ในขั้นแรก ผู้โจมตีอาจอ่านข้อมูลจากฐานข้อมูลผ่าน Blind SQL Injection ซึ่งอาจไม่สร้างไฟล์ใหม่หรือแสดง Error ที่ชัดเจน ทำให้องค์กรไม่ควรสรุปว่าปลอดภัยเพียงเพราะยังไม่พบ Web Shell

WordPress เวอร์ชันที่ได้รับผลกระทบ

ตามข้อมูลในรายงาน CloudSEK เวอร์ชันที่ได้รับผลกระทบแบ่งออกเป็นสองกลุ่ม

ได้รับผลกระทบจากชุดการโจมตีเต็มรูปแบบ

• WordPress 6.9.0–6.9.4

• WordPress 7.0.0–7.0.1

เว็บไซต์ในกลุ่มนี้อาจถูกโจมตีตั้งแต่ขั้นตอน SQL Injection ไปจนถึงการยกระดับผลกระทบเป็น Remote Code Execution

ได้รับผลกระทบเฉพาะส่วน SQL Injection

• WordPress 6.8.0–6.8.5

เวอร์ชันที่มีการแก้ไขแล้ว (ควรเร่งอัพเดท)

• WordPress 6.8.6

• WordPress 6.9.5

• WordPress 7.0.2

• WordPress 7.1 Beta 2

WordPress เวอร์ชันก่อน 6.8.0 ถูกระบุว่าไม่อยู่ในขอบเขตของช่องโหว่ชุดนี้ อย่างไรก็ตาม การใช้ WordPress รุ่นเก่าไม่ควรถูกมองว่าเป็นทางเลือกที่ปลอดภัย เพราะอาจมีช่องโหว่อื่นที่ไม่ได้รับการแก้ไขแล้ว

ผลกระทบที่อาจเกิดขึ้นกับธุรกิจ

ข้อมูลรั่วไหล

ผู้โจมตีอาจเข้าถึงข้อมูลผู้ใช้งาน ข้อมูลลูกค้า Password Hash และ Secret ที่เว็บไซต์หรือปลั๊กอินจัดเก็บไว้ในฐานข้อมูล

หากเว็บไซต์เชื่อมต่อกับระบบสมาชิก ระบบขายสินค้า หรือระบบรับชำระเงิน ผลกระทบอาจครอบคลุมข้อมูลส่วนบุคคลและข้อมูลทางธุรกิจที่มีความอ่อนไหว

เว็บไซต์ถูกแก้ไขหรือใช้เผยแพร่เนื้อหาอันตราย

เว็บไซต์ที่ถูกยึดอาจถูกนำไปใช้แสดงโฆษณาสแปม เปลี่ยนเส้นทางผู้เข้าชมไปยังเว็บไซต์หลอกลวง ฝังมัลแวร์ หรือสร้างหน้า Phishing ภายใต้โดเมนที่น่าเชื่อถือ

สูญเสียความน่าเชื่อถือและอันดับการค้นหา

การถูกฝัง SEO Spam หรือ Redirect อันตรายอาจทำให้เว็บไซต์ถูก Search Engine ลดอันดับหรือขึ้นคำเตือน ส่งผลต่อชื่อเสียงและการเข้าถึงลูกค้าในระยะยาว

เว็บไซต์หยุดให้บริการ

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

องค์กรที่ใช้ WordPress ต้องทำอะไรทันที

1. อัปเดต WordPress Core

อัปเดตระบบไปยังเวอร์ชันที่แก้ไขแล้วให้เร็วที่สุด

• สาย 6.8.x ให้อัปเดตเป็น 6.8.6 หรือใหม่กว่า

• สาย 6.9.x ให้อัปเดตเป็น 6.9.5 หรือใหม่กว่า

• สาย 7.0.x ให้อัปเดตเป็น 7.0.2 หรือใหม่กว่า

ไม่ควรรอรอบ Maintenance ตามปกติสำหรับเว็บไซต์ที่เปิดให้เข้าถึงจากอินเทอร์เน็ต

2. ยืนยันว่าอัปเดตสำเร็จจริง

แม้ WordPress จะเปิดใช้ Forced Automatic Update แต่การอัปเดตอาจล้มเหลวได้จากหลายสาเหตุ เช่น

• ปิดระบบ Automatic Update

• File Permission ไม่ถูกต้อง

• ใช้กระบวนการ Deploy ผ่าน Version Control

• มีหลาย Server หรือหลาย Instance

• เว็บไซต์ Staging และเว็บไซต์แคมเปญไม่อยู่ภายใต้การดูแลส่วนกลาง

ทีมไอทีจึงควรตรวจสอบหมายเลขเวอร์ชันของทุกเว็บไซต์โดยตรง ไม่ควรสันนิษฐานว่าเว็บไซต์ทั้งหมดได้รับการอัปเดตแล้ว

3. สำรวจ WordPress ทั้งหมดขององค์กร

ควรรวบรวม Inventory ให้ครอบคลุมมากกว่าเว็บไซต์หลัก เช่น

• เว็บไซต์บริษัท

• Landing Page

• Campaign Website

• เว็บไซต์ของบริษัทในเครือ

• เว็บไซต์ Staging หรือ Development

• เว็บไซต์ที่ Agency หรือผู้รับเหมาดูแล

• เว็บไซต์เก่าที่ยังเปิดให้เข้าถึงจากอินเทอร์เน็ต

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

4. ตรวจสอบ Log ย้อนหลังตั้งแต่วันที่ 17 กรกฎาคม

ค้นหาคำขอที่เกี่ยวข้องกับเส้นทางต่อไปนี้

/wp-json/batch/v1
?rest_route=/batch/v1

ควรให้ความสนใจเป็นพิเศษกับ

• POST Request จาก IP ที่ไม่เคยพบ

• Request จำนวนมากในช่วงเวลาสั้น

• คำขอที่ใช้เวลาตอบสนองแตกต่างกันเป็นจังหวะ

• ค่าที่ผิดปกติในพารามิเตอร์ author__not_in

• การติดตั้งหรืออัปโหลดปลั๊กอินที่ไม่มี Change Request รองรับ

อย่างไรก็ตาม การเข้าถึง Batch Endpoint เพียงอย่างเดียวไม่สามารถยืนยันว่าเป็นการโจมตีได้ ต้องพิจารณารูปแบบ Request และเหตุการณ์อื่นร่วมกัน

5. ตรวจสอบบัญชีและไฟล์ผิดปกติ

ค้นหาสัญญาณที่อาจบ่งชี้ว่าผู้โจมตีเข้าถึงระบบสำเร็จแล้ว เช่น

• มีบัญชี Administrator ใหม่

• มีการล็อกอินจากประเทศหรือ Hosting Provider ที่ไม่คุ้นเคย

• มีปลั๊กอินที่ไม่ทราบที่มา

• มีไฟล์ PHP อยู่ใน wp-content/uploads/

• มีไฟล์ใน Plugin Directory ถูกแก้ไขโดยไม่มีประวัติ Deploy

• มี Cron Job หรือ Scheduled Task ใหม่

• มีการแก้ไข wp-config.php

• มีการเปลี่ยนค่า Redirect หรือ Site URL

6. เปลี่ยน Credential และ Secret ของเว็บไซต์ที่เคยเปิดเผย

เว็บไซต์ที่ใช้เวอร์ชัน 6.9.0–6.9.4 หรือ 7.0.0–7.0.1 และเปิดให้เข้าถึงจากอินเทอร์เน็ตหลังวันที่ 17 กรกฎาคม ควรถูกพิจารณาว่าอาจมีความเสี่ยง แม้ยังไม่พบหลักฐานการโจมตี

ควรพิจารณาเปลี่ยน

• รหัสผ่าน Administrator

• รหัสผ่านฐานข้อมูล

• API Key และ Access Token

• WordPress Authentication Keys และ Salts

• Credential ของ Hosting และ Control Panel

• Credential ของบริการอื่นที่ใช้รหัสผ่านเดียวกัน

การติดตั้งแพตช์จะหยุดการโจมตีครั้งใหม่ แต่ไม่ทำให้ Password Hash หรือ Secret ที่อาจถูกขโมยไปก่อนหน้าใช้งานไม่ได้

7. ตรวจสอบการทำงานของ WAF

ผู้ใช้ Cloudflare ควรตรวจสอบว่า Managed Rules สำหรับช่องโหว่นี้อยู่ในสถานะ Block ไม่ใช่ Log Only และไม่มีการตั้งค่า Override ที่ลดระดับการป้องกัน

ต้องตรวจสอบด้วยว่า Origin Server ไม่สามารถถูกเข้าถึงโดยตรงจากอินเทอร์เน็ต เพราะผู้โจมตีอาจข้าม WAF และส่งคำขอเข้าสู่ Server ได้โดยตรง

8. หากยังแพตช์ไม่ได้ ให้ใช้มาตรการชั่วคราว

องค์กรสามารถบล็อกหรือจำกัดการเข้าถึง

/wp-json/batch/v1
?rest_route=/batch/v1

รวมถึงจำกัด Anonymous REST API Access ที่ WAF หรือ Reverse Proxy

มาตรการนี้ควรใช้เป็นเพียงสะพานชั่วคราว เนื่องจากอาจส่งผลกระทบต่อระบบหรือปลั๊กอินที่ใช้งาน REST API และไม่ควรนำมาใช้ทดแทนการอัปเดต WordPress

บทเรียนสำคัญ

สิ่งที่องค์กรต้องแยกให้ออกมีสองประเด็น

1. ระบบได้รับการแก้ไขเพื่อป้องกันการโจมตีครั้งใหม่แล้วหรือไม่

1. ก่อนติดตั้งแพตช์ เคยมีผู้โจมตีเข้าถึงข้อมูลหรือฝังช่องทางกลับเข้าสู่ระบบแล้วหรือไม่

การอัปเดต WordPress ตอบได้เฉพาะคำถามแรก ส่วนคำถามที่สองต้องอาศัยการตรวจสอบ Log, Threat Hunting, Credential Rotation และการค้นหา Persistence ภายในระบบ

หากเว็บไซต์เคยใช้เวอร์ชันที่ได้รับผลกระทบและเปิดจากอินเทอร์เน็ต องค์กรไม่ควรหยุดเพียงการกด Update แต่ควรตรวจสอบย้อนหลังอย่างจริงจัง

BMSP และ CloudSEK ช่วยให้องค์กรมองเห็นภัยคุกคามจากภายนอกได้อย่างไร

จากเหตุการณ์ wp2shell แสดงให้เห็นว่า ช่วงเวลาระหว่างการเปิดเผยช่องโหว่กับการเริ่มโจมตีจริงอาจเหลือเพียงไม่กี่ชั่วโมง

BMSP ให้บริการโซลูชัน Digital Risk Protection (DRP), Dark Web Monitoring และ Cyber Threat Intelligence จาก CloudSEK เพื่อช่วยให้องค์กรตรวจพบความเสี่ยงที่เกิดขึ้นนอกขอบเขตระบบภายใน เช่น

• Credential ของพนักงานหรือลูกค้ารั่วไหล

• มีผู้โจมตีประกาศขายสิทธิ์เข้าถึงเว็บไซต์

• มีข้อมูลขององค์กรปรากฏใน Stealer Log

• มีการพูดถึง Exploit หรือช่องโหว่ที่เกี่ยวข้องกับระบบขององค์กร

• พบโดเมนปลอม เว็บไซต์ Phishing หรือการแอบอ้างแบรนด์

• พบ Digital Asset ที่เปิดเผยต่ออินเทอร์เน็ตโดยองค์กรไม่ทราบ

• มีข้อมูลสำคัญถูกเผยแพร่หรือซื้อขายบน Dark Web และ Underground Forum

การเชื่อมข้อมูล Threat Intelligence เข้ากับ SOC, Vulnerability Management และ Incident Response จะช่วยให้องค์กรจัดลำดับความสำคัญของความเสี่ยงได้ตามสถานการณ์จริง และตอบสนองก่อนที่ข้อมูลหรือสิทธิ์เข้าถึงจะถูกนำไปขยายผล

สรุปสาระสำคัญ

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

สิ่งที่องค์กรควรดำเนินการทันทีคือ

• อัปเดต WordPress เป็นเวอร์ชันล่าสุด

• ตรวจสอบทุกเว็บไซต์และทุก Instance

• ตรวจสอบ Log ย้อนหลังตั้งแต่วันที่ 17 กรกฎาคม 2026

• ตรวจหาบัญชี ปลั๊กอิน และไฟล์ที่ผิดปกติ

• เปลี่ยนรหัสผ่านและ Secret ของระบบที่เคยเปิดเผย

• ยืนยันว่า WAF ทำงานในโหมด Block

• ทำ Threat Hunting แม้ติดตั้งแพตช์แล้ว

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

อ้างอิง: CloudSEK Threat Advisory: “wp2shell: WordPress Core Pre-Authentication RCE Chain”, รายงานรวบรวมข้อมูล ณ วันที่ 20 กรกฎาคม 2026