WordPress core CVE-2026-87902 ถูกโจมตีจริง (KEV) แก้ใน 7.1.2 อัปเดตด่วน
ทุกเว็บที่รัน WordPress รุ่นก่อน 7.1.2 หรือก่อนรุ่น backport ของสายนั้นต้องอัปเดตทันที เพราะ CISA ยืนยันแล้วว่ามีการโจมตีจริง และต้องเช็กด้วยว่าธีมที่ใช้อยู่เข้าเงื่อนไขหรือไม่
สรุปใน 1 นาที
- อาการ/ปัญหา
- ผู้โจมตีที่ไม่ล็อกอินทำให้ get_page_template() include ไฟล์ .php ในเครื่องที่อยู่นอกธีม จนรันโค้ดได้เมื่อเงื่อนไขครบ
- ใครควรอ่าน
- WordPress 7.1.0 ถึง 7.1.1 และสายเก่าทุกสายที่ยังไม่ถึงรุ่นแก้ โดยเสี่ยงจริงเมื่อธีมมีโฟลเดอร์ชื่อขึ้นต้น page- และเครื่องมีไฟล์ PHP ที่เว็บอ่านได้
- ทางแก้แบบสั้น
- อัปเดตเป็น 7.1.2 หรือรุ่น backport ของสายนั้น ตรวจธีมกับ register_argc_argv และตรวจหาร่องรอยหลังอัปเดต
พอดีเห็นรายการใหม่ใน CISA KEV เมื่อ 25 ก.ย. 2026 ชื่อ "WordPress Core Remote File Inclusion Vulnerability" ซึ่งเป็น CVE-2026-87902 ผมเลยย้อนไปอ่านต้นทางทั้งสามที่ ประกาศรุ่น 7.1.2 ของ WordPress, GitHub security advisory ของโครงการ และ record ใน NVD เพราะชื่อใน KEV กับชื่อใน advisory ไม่ตรงกันนัก และเรื่องนี้เป็น core ไม่ใช่ปลั๊กอิน เลยไม่มีทางเลี่ยงด้วยการไม่ติดตั้งอะไรเพิ่ม
เกิดอะไรขึ้น
ตามคำอธิบายใน advisory ผู้โจมตีที่ไม่ต้องล็อกอินสามารถทำให้ฟังก์ชัน get_page_template() ที่ใช้เลือกไฟล์ template ของหน้า include ไฟล์ .php ที่เว็บเซิร์ฟเวอร์อ่านได้ ซึ่ง อยู่นอกโฟลเดอร์ธีมที่ใช้งานอยู่ ได้ ตัวช่องโหว่จัดเป็น CWE-98 และชื่อใน advisory คือ "Unauthenticated path traversal in page-template resolution leading to conditional RCE" ส่วน CISA เรียกว่า Remote File Inclusion ผมเห็นว่าเรียกอะไรก็ตาม ผลที่ต้องจำคือ "include ไฟล์ในเครื่องแล้วอาจรันโค้ด"
คำว่า conditional สำคัญ ไม่ใช่ทุกเว็บที่รันรุ่นก่อนแพตช์จะโดนยึดได้ทันที advisory ระบุว่าต้องครบสองเงื่อนไข
- ธีมที่ใช้ (ธีมลูกหรือธีมแม่) มีโฟลเดอร์ระดับบนชื่อขึ้นต้นด้วย
page-advisory ยกตัวอย่างธีม Twenty Twelve, Twenty Fourteen และธีมของค่ายอื่นอย่าง Neve, Hestia, Sydney - มีไฟล์
.phpอยู่ในเครื่องและบัญชีของเว็บเซิร์ฟเวอร์อ่านได้ advisory ยกตัวอย่างpearcmd.phpของ PEAR เมื่อregister_argc_argvเป็น On และระบุว่า Docker image ทางการของphpกับค่าเริ่มต้นของ cPanel (PHP ก่อน 8.5) เข้าข่ายนี้
CISA เพิ่ม CVE-2026-87902 เข้า KEV เมื่อ 25 ก.ย. 2026 หมายความว่ามีหลักฐานการใช้ช่องโหว่นี้กับเป้าหมายจริง ไม่ใช่แค่ทฤษฎี ใครยังอยู่รุ่นก่อนแพตช์ให้ถือว่าเสี่ยงทันที
ระดับความรุนแรง
ตัวเลขจากแต่ละแหล่งไม่ตรงกัน ผมเลยแยกให้ดู
| แหล่ง | คะแนน | หมายเหตุ |
|---|---|---|
| GitHub advisory ของโครงการ | CVSS v4.0 = 9.2 Critical | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N |
| NVD (แหล่งรอง) | CVSS v3.1 = 8.1 High | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
| โครงการ WordPress (7.1.2) | Critical | ประกาศบอกแค่ว่าเป็นช่องโหว่ critical หนึ่งตัว |
| CISA KEV | ถูกโจมตีจริง | เพิ่ม 25 ก.ย. 2026 กำหนดแก้ 28 ก.ย. 2026 |
สองคะแนนใช้คนละระบบ (v4.0 กับ v3.1) และ vector ก็สะท้อนเรื่องเงื่อนไขไว้ทั้งคู่ คือ v3.1 ตั้ง AC:H ส่วน v4.0 ตั้ง AT:P (มี prerequisite) ผมไม่ได้เทียบว่าฝั่งไหนถูก สรุปเป็นภาษาคนทำงานได้ว่า ถ้าเข้าเงื่อนไขแล้ว ระบบทั้งเครื่องเสี่ยงโดยไม่ต้องมีบัญชีอะไรเลย แต่ถ้าไม่เข้าเงื่อนไขก็ยังไม่ใช่เหตุผลให้ค้างไว้ เพราะ CISA ถือว่ามีการโจมตีจริงแล้ว
ข้อกำหนดของ CISA ใน KEV (ตามที่ NVD อ้าง) คือให้ใช้มาตรการแก้ของผู้ผลิตตาม BOD 26-04 ทำ forensics triage และถ้าไม่มีมาตรการให้เลิกใช้ผลิตภัณฑ์ พร้อมประเมินว่าระบบเปิดสู่อินเทอร์เน็ตหรือไม่ ข้อกำหนดนี้ผูกกับหน่วยงานรัฐของสหรัฐเป็นหลัก แต่ใครอยากใช้เป็นเกณฑ์ตัวเองก็ไม่เสียหาย
รุ่นที่กระทบและรุ่นที่แก้
ลำดับเวลาที่ผมเรียงจากแหล่งต้นทาง รุ่น 7.1.1 (17 ก.ย.) ยังอยู่ในช่วงที่โดน ส่วน 7.1.2 (22 ก.ย.) คือรุ่นที่ปิดเรื่องนี้โดยเฉพาะ และโครงการระบุว่าการแก้ถูก backport ให้ทุกสายที่ยังเข้าเกณฑ์ ถึง 4.7
| สายที่ใช้ | ช่วงที่ได้รับผลกระทบ | รุ่นที่แก้ |
|---|---|---|
| 7.1 | 7.1.0 ถึง 7.1.1 | 7.1.2 |
| 7.0 | 7.0.0 ถึง 7.0.5 | 7.0.6 |
| 6.9 | 6.9.0 ถึง 6.9.8 | 6.9.9 |
| 6.8 | 6.8.0 ถึง 6.8.9 | 6.8.10 |
| 6.7 | 6.7.0 ถึง 6.7.8 | 6.7.9 |
| 6.6 | 6.6.0 ถึง 6.6.8 | 6.6.9 |
| 6.5 | 6.5.0 ถึง 6.5.11 | 6.5.12 |
| 6.4 | 6.4.0 ถึง 6.4.11 | 6.4.12 |
| 6.3 | 6.3.0 ถึง 6.3.11 | 6.3.12 |
| 6.2 | 6.2.0 ถึง 6.2.12 | 6.2.13 |
| 6.1 | 6.1.0 ถึง 6.1.13 | 6.1.14 |
| 6.0 | 6.0.0 ถึง 6.0.15 | 6.0.16 |
| 5.9 ลงไปถึง 4.7 | ทุกรุ่นก่อนรุ่นแก้ของสายนั้น | 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32, 4.7.37 |
วิธีแก้
- เช็กรุ่น ทุกเว็บและทุก container ที่รัน WordPress รวมเว็บเก่าที่ไม่มีคนดูแล
- อัปเดต เป็นรุ่นแก้ของสายที่ใช้ แล้วยืนยันด้วย checksum
- ตรวจเงื่อนไข ธีมที่มีโฟลเดอร์ page-* กับ register_argc_argv และ pearcmd.php
- ไล่หาร่องรอย โดยเฉพาะเว็บที่เปิดสู่เน็ตตั้งแต่ 22 ก.ย. ที่ยังไม่ได้อัปเดต
ทางเดียวที่ advisory ให้คือ อัปเดต advisory ไม่ได้ระบุ workaround ใดๆ ผมเลยแยกสิ่งที่ทำเพิ่มได้เป็นคนละส่วน และบอกไว้ชัดว่ามันไม่ใช่การแก้
# เช็กรุ่น แล้วอัปเดตเฉพาะ minor/security ในสายเดิม
wp core version
wp core update --minor
wp core verify-checksums
ถ้าอยู่สาย 7.1 และอยากข้ามไปรุ่นล่าสุดเลย ให้ดู wp core check-update ก่อน เครื่องที่ใช้ Docker image ของ php ต้อง build image ใหม่และ deploy ใหม่ ไม่ใช่แก้ไฟล์ในคอนเทนเนอร์ที่รันอยู่
advisory ไม่ได้ยืนยันวิธีเหล่านี้ว่าเป็น workaround ของโครงการ ผมเขียนตามเงื่อนไขที่ advisory ระบุเท่านั้น ปิด register_argc_argv และเอา pearcmd.php ออกจากเครื่องที่ไม่ได้ใช้ PEAR ช่วยปิดเส้นทางเดียวที่ advisory ยกตัวอย่าง แต่ตัวช่องโหว่ include ไฟล์ยังอยู่จนกว่าจะอัปเดต
# ธีมที่ใช้อยู่มีโฟลเดอร์ระดับบนชื่อ page-* หรือไม่
find /var/www/example.com/wp-content/themes -maxdepth 2 -type d -name 'page-*'
# มี pearcmd.php ในเครื่องหรือไม่
find / -name pearcmd.php -not -path '*/proc/*' 2>/dev/null
; php.ini ของ FPM/Apache (CLI เปิดค่านี้เสมอ เลยดูจาก CLI ไม่ได้)
register_argc_argv = Off
เช็กว่าโดนหรือยัง
advisory และประกาศ 7.1.2 ไม่ได้ปล่อย IOC ผมเลยจะไม่แต่งรูปแบบ request ขึ้นมาเอง ที่ทำได้จริงคือเช็กผลลัพธ์ปลายทางของการโจมตีแบบ RCE ทั่วไป
wp core verify-checksumsและwp plugin verify-checksums --allเพื่อดูไฟล์ที่ไม่ตรงต้นฉบับwp user list --role=administratorดูแอดมินที่ไม่ได้สร้างเอง- หาไฟล์
.phpใหม่ในwp-content/uploadsซึ่งปกติไม่ควรมีfind wp-content/uploads -name '*.php' -newermt '2026-09-17' - ดู access log ตั้งแต่ 22 ก.ย. เป็นต้นมา หาคำขอเว็บที่แปลกไปจากปกติหรือมีจำนวนพุ่ง แล้วเทียบกับเวลาที่ไฟล์แปลกๆ โผล่ในเครื่อง
- ถ้าเว็บเปิดสู่เน็ตและรุ่นยังต่ำกว่ารุ่นแก้ตั้งแต่ 22 ก.ย. ให้ถือว่าเสี่ยง ไล่ตรวจรหัสผ่านฐานข้อมูลและ salt ใน
wp-config.phpถ้าพบร่องรอย
ส่วนตัวผม
ส่วนตัวผม เรื่องนี้ไม่ควรรอรอบอัปเดตประจำเดือน ทั้งที่เงื่อนไขของมันแคบกว่าที่ชื่อ "RFI" ฟังดู เพราะ CISA ยืนยันการโจมตีแล้ว และ Docker image ทางการกับค่าเริ่มต้นของ cPanel ที่ advisory ระบุก็เป็นของที่คนใช้กันเยอะ ใครยังไม่ได้อัปเดตตั้งแต่ 22 ก.ย. ให้ถือเป็นงานด่วนที่ต้องจบก่อนงานอื่น แล้วค่อยมานั่งไล่ธีมกับ register_argc_argv ทีหลัง ตามกำลังคนของแต่ละที่
ปล. ข่าวบางเจ้าเขียนวันที่เส้นตายของ CISA ไม่ตรงกัน แต่ record ใน NVD ที่ผมเปิดเอง ระบุเพิ่ม KEV วันที่ 25 ก.ย. และกำหนดแก้ 28 ก.ย. 2026 ผมยึดตามนั้น
ที่มา: GitHub security advisory GHSA-7hp8-65ch-5whp (https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-7hp8-65ch-5whp), WordPress 7.1.2 Release (https://wordpress.org/news/2026/09/wordpress-7-1-2-release/), WordPress 7.1.1 (https://wordpress.org/news/2026/09/wordpress-7-1-1-maintenance-and-security-release/), NVD CVE-2026-87902 (https://nvd.nist.gov/vuln/detail/CVE-2026-87902), CISA KEV Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) ข้อมูลถึง 5 พ.ย. 2026 ถ้ามีรายละเอียดการโจมตีเพิ่มเดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
อยากให้เราทำให้ไหม?
ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai
ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย