WordPress CVE-2026-87902 เข้า KEV: อัปเดตแม้ RCE ต้องมีเงื่อนไขร่วม

WordPress เผยแพร่แพตช์สำหรับ CVE-2026-87902 เมื่อ 22 กันยายน และ CISA เพิ่มช่องโหว่นี้เข้า Known Exploited Vulnerabilities catalog วันที่ 25 กันยายน 2026 ครับ จุดอ่อนอยู่ในการหา page template ที่ทำให้ผู้โจมตีไม่ต้องล็อกอินสามารถชี้การ include ไปยังไฟล์ PHP ที่อ่านได้ภายนอก directory ของธีม ภายใต้เงื่อนไขของธีมและเซิร์ฟเวอร์บางชุด มันต่อไปเป็น remote code execution ได้

คำว่า “มีเงื่อนไข” ไม่ใช่เหตุผลให้ชะลอ patch เพราะ CISA KEV บอกว่ามีหลักฐาน exploitation จริงแล้ว สิ่งที่ทีมต้องทำคืออัปเดต branch ที่ใช้อยู่ ตรวจว่าทุก instance ได้รับ backport ที่ถูกต้อง และค้นหาสัญญาณผิดปกติโดยไม่รอพิสูจน์ก่อนว่า environment ตรงเงื่อนไข RCE ทุกข้อหรือไม่

เกิดอะไรขึ้น: สรุป 30 วินาที

WordPress advisory ให้คะแนน CVSS v4 9.2 Critical และระบุ affected ranges ตั้งแต่ 4.7 จนถึง 7.1.1 แพตช์ออกเป็น 7.1.2, 7.0.6, 6.9.9, 6.8.10 และ backport ต่อเนื่องทุก branch ที่ระบุจนถึง 4.7.37 ผู้โจมตี network ไม่ต้องมีบัญชีและไม่ต้องให้ผู้ใช้คลิก แต่การเปลี่ยนจาก local file include ไป RCE ต้องมี attack requirements เพิ่ม

เงื่อนไขที่ advisory เปิดเผยมีสองกลุ่ม หนึ่ง ธีมแม่หรือลูกที่ active ต้องมี top-level directory ชื่อขึ้นต้นด้วย page- เช่น directory สำหรับ page templates สอง ต้องมี local PHP file ที่ web-server account อ่านได้และ environment เอื้อต่อการเปลี่ยน include เป็น execution Advisory ยกตัวอย่างการตั้งค่า PHP/แพ็กเกจบางแบบ แต่ทีมป้องกันไม่จำเป็นต้องจำลอง exploit เพื่อประเมิน เพราะการ patch core ตัดเส้นทางต้นเหตุ

NVD เป็นแหล่งติดตาม CVE และ CISA KEV feed เปลี่ยนสถานะจากความเสี่ยงเชิงทฤษฎีเป็นรายการที่ต้อง prioritize จาก evidence การถูกใช้จริง วันที่ประกาศ vendor กับวันที่เข้า KEV ห่างกันไม่กี่วัน นี่คือเหตุผลที่ asset inventory กับ auto-update visibility สำคัญกว่ารอรอบ patch รายเดือน

ทำไมเรื่องนี้เกี่ยวกับคุณ

WordPress มักกระจายอยู่หลายที่กว่าที่ทีมกลางคิด: เว็บไซต์แคมเปญ, microsite ของ vendor, staging เก่า, container image ใน registry และ instance ที่ agency ดูแล ช่องโหว่ core ที่ครอบ branch ย้อนหลังมากทำให้ “เราใช้เวอร์ชันเก่าแต่ stable” ไม่ใช่ boundary ที่ปลอดภัย ต้องตรวจ patch release ของ branch นั้นจริง

เว็บไซต์ที่ไม่ได้เก็บข้อมูลสำคัญยังมีมูลค่าแก่ผู้โจมตีในฐานะจุดแจก malware, SEO spam, redirect phishing หรือฐานย้ายต่อไป credential/cloud metadata การเข้าควบคุม PHP process ยังอาจอ่าน database credential กับ secret ใน config ตามสิทธิ์ของ process ดังนั้น impact ไม่จำกัดที่หน้าเว็บถูกเปลี่ยน

อีกมุมคือเงื่อนไขธีม ทีมอาจเช็กแล้วพบว่า active theme ไม่มี directory ตามรูปแบบ จึงคิดว่ารอด แต่ธีมเปลี่ยนได้, child theme ต่างกันตาม site, image รุ่นถัดไปอาจเพิ่ม package หรือ config ใหม่ และ LFI เองก็เป็น boundary violation แม้ยังไม่ต่อเป็น RCE คำตอบที่ทนกว่าคือ patch พร้อม hardening ไม่ใช่เก็บ spreadsheet ว่าเงื่อนไขวันนี้ไม่ครบ

ทำงานยังไง: จากชื่อ template ไปนอกขอบธีม

ปกติ page template resolver ควรเลือกไฟล์ที่อยู่ในขอบเขต theme ที่เชื่อถือได้ เปรียบเหมือนบรรณารักษ์รับชื่อหนังสือแล้วค้นเฉพาะชั้นที่กำหนด Path traversal เกิดเมื่อ input ทำให้ตัว resolver เดินขึ้นหรือเบนออกจากชั้น ไปชี้ไฟล์ local ที่อยู่นอก theme directory การ include ไฟล์ PHP ต่างจากอ่าน text ธรรมดา เพราะ runtime อาจประมวลผล code ในไฟล์นั้น

อย่างไรก็ดี “ชี้ไฟล์ PHP ได้” กับ “รันคำสั่งผู้โจมตีได้” ยังมีช่องว่าง ผู้โจมตีต้องหา target ที่อ่านได้และมี behavior ซึ่งควบคุมต่อได้ Environment บางชุดมี utility PHP หรือ configuration ที่เพิ่มเส้นทางนั้น จึงเกิดคำว่า conditional RCE แต่จากมุม defense เราไม่ควรไล่พิสูจน์ target ทุกไฟล์ก่อน patch เพราะ inventory ของ package และ config เปลี่ยนตลอด

แพตช์ที่ถูกต้องต้องทำให้ template resolution อยู่ภายใน allowed theme roots หลัง canonicalize path ไม่ใช่กรอง substring อย่างเดียว Symlink, encoded separators และความต่างของ platform filesystem เป็นเหตุผลที่ path security ต้องใช้ primitive มาตรฐานและ test edge cases ทีม application ไม่ควรเขียน WAF ruleแทน core patchเป็นมาตรการถาวร เพราะ WAF เห็น request representation แต่ไม่รู้ final path semantics ใน PHP/WordPress ครบ

เรื่องเงินและผลกระทบ

ต้นทุน patch WordPress จำนวนมากไม่ใช่เวลา download แต่คือการกลัว plugin/theme regression วิธีลดความเสี่ยงไม่ใช่เลื่อน patch แต่ทำ deployment ring: clone production data แบบลบ secret/PII, อัปเดต core, smoke test login/content/forms/cache แล้ว rollout site เสี่ยงต่ำก่อน จากนั้นเร่ง public-facing sites พร้อม rollback ที่ไม่ย้อนกลับไปเวอร์ชันมีช่องโหว่นานเกินจำเป็น

Incident cost ของเว็บถูกยึดรวม downtime, forensic, credential rotation, customer notification, search reputation และ cleanup persistence ผู้โจมตีอาจวาง web shell หรือแก้ scheduled task ก่อนทีม patch ถ้า host ถูก exploit แล้ว การอัปเดต coreอย่างเดียวไม่คืน trust ต้อง rebuild จาก known-good artifact, rotate secrets และตรวจ data/config changes

ทีมที่ใช้ managed WordPress ควรขอหลักฐานจาก provider: current core version ของแต่ละ site, เวลา deploy patch, image/build identifier และผลตรวจ compromise ไม่ใช่คำตอบว่า “เปิด auto-update แล้ว” เพราะ maintenance window, failed update หรือ immutable image pipeline อาจทำให้ config เปิดแต่ instance ไม่เปลี่ยน

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

Advisory ระบุเงื่อนไข RCE อย่างชัด แต่ CISA KEV feed มักสรุปสั้นว่า vulnerability ถูก exploit โดยไม่แจก telemetry, campaign scale หรือ target profile ทั้งหมด เราจึงรู้ว่าต้อง prioritize แต่ยังไม่ควรเดาว่าทุก exploitation จบเป็น RCE หรือธีมใดถูกโจมตีมากที่สุด

NVD อาจอัปเดต enrichment, CPE หรือ scoring ภายหลัง ขณะที่ GitHub advisory จาก upstream เป็น source ที่ละเอียดที่สุดเรื่อง affected/patched branches ณ วันที่ตรวจ ถ้าตัวเลขใน scanner ไม่ตรง ให้ใช้ upstream version matrix ตรวจ package จริงแล้วคุย vendor อย่าปล่อย false negative เพียงเพราะ CPE mapping ยังตามไม่ทัน

ยังไม่มีเหตุผลให้เผยหรือทดลอง payload ใน production การยิง request เพื่อ “ดูว่าโดนไหม” อาจสร้างผลข้างเคียงและบันทึกข้อมูลอ่อนไหว ทีมควรใช้ authenticated inventory, file/package version และ passive log hunting ก่อน หากต้องทำ validation เชิงรุกให้ทำใน isolated fixture ที่ไม่มีข้อมูล/credential และใช้วิธีจาก vendor หรือผู้ทดสอบที่ได้รับอนุญาต

แล้วเราควรทำอะไร

เริ่มจากหยุดการเดา ดึง inventory ของ public WordPress ทั้งหมดจาก DNS, CDN/WAF, load balancer, cloud account, container registry และ CMDB จับคู่ owner กับ core branch ตรวจจาก package/image/build metadata ไม่เชื่อ version ที่หน้า HTML อย่างเดียว เพราะอาจถูกซ่อนหรือ cache

อัปเดตเป็น patch ของ branch ตาม upstream: 7.1.2, 7.0.6, 6.9.9, 6.8.10 หรือ patch backport ที่ advisory ระบุสำหรับ branch ของคุณ ถ้า branch หมดการสนับสนุนเชิงปฏิบัติ ให้ย้ายไป maintained line แทนการอยู่กับ backport ตลอด ทดสอบ theme/plugin flow หลัก แต่ตั้ง timebox ไม่ให้ regression fear กลายเป็นข้ออ้างเลื่อนช่องโหว่ KEV

ระหว่าง rollout ลด attack surface: จำกัด PHP filesystem permission, เอา package/utility ที่ไม่ใช้, ปิด editor/install surface ที่ production ไม่ต้องมี, ให้ web process เขียนได้เฉพาะ directory จำเป็น และแยก secret จาก web root สำรองข้อมูลกับ config ก่อนเปลี่ยน แต่ห้ามใช้ backup หลัง incident โดยไม่ตรวจว่าเกิดก่อน compromise

ทำ threat hunt จากเวลา disclosure ย้อนและต่อเนื่อง ดู request anomaly ต่อ template endpoints, PHP errors ที่มี path ผิดปกติ, process child จาก web server, ไฟล์ PHP ใหม่/แก้ไข, admin/user ที่เพิ่ม, scheduled tasks, outbound connection และการเปลี่ยน plugin/theme baseline Log ที่ไม่มี full query ยังช่วยด้วย status/latency/path pattern แต่อย่า publish sensitive request data

หลัง patch ยืนยันสามชั้น: control plane รายงาน desired version, instance จริงรายงาน patched version/build และ external health check ผ่าน ทบทวน checksum/immutable image, restartเฉพาะตาม runbook ของระบบ ไม่แก้ production โดย hand และเก็บ evidence ของเวลา patch กับ asset scope หากพบ indicator ให้เข้าสู่ incident response: isolate, preserve evidence, rebuild known-good, rotate database/API/admin credentials และตรวจ lateral movement

Recap

CVE-2026-87902 เป็น Critical และอยู่ใน CISA KEV แล้ว
อัปเดตทุก branch เป็น patch ที่ upstream ระบุ ไม่ใช่เฉพาะ latest major
อย่าชะลอเพราะ RCE ต้องมี theme/server precondition
inventory public, staging, vendor-managed และ immutable images ให้ครบ
harden PHP filesystem/write permission และลด package ที่ไม่ใช้
hunt request, file, process, account และ outbound anomalies
หากมี evidence compromise ให้ rebuild และ rotate secret ไม่ใช่ patch อย่างเดียว
เก็บหลักฐาน desired version, runtime version และ external health หลัง rollout