ช่องโหว่ WordPress CVE-2026-119977: ถูกโจมตีจริงแล้ว เช็คและอัปเดตทุกรุ่น 4.7–7.1

01เกิดอะไรขึ้น

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

เวลาอัปเดต WordPress core แบบทั้งชุด WordPress จะดาวน์โหลดไฟล์รุ่นใหม่ แล้วแตกไฟล์ไว้ชั่วคราวในโฟลเดอร์ใต้ wp-content/upgrade/ ก่อนคัดลอกไปแทนของเดิม ในรุ่น 7.1.3 และเก่ากว่า โฟลเดอร์นี้ตั้งชื่อตามชื่อไฟล์ของรุ่นที่ดาวน์โหลด จึงเดาชื่อได้ และเปิดผ่านเว็บได้ ผู้โจมตีที่ส่ง request ได้ทันในช่วงไม่กี่วินาทีที่ไฟล์ยังอยู่ จะเรียกไฟล์ PHP ในโฟลเดอร์นั้นและรันโค้ดบนเซิร์ฟเวอร์ได้โดยไม่ต้องล็อกอิน

รุ่น 7.1.4 แก้โดยเติมตัวอักษรสุ่ม 16 ตัวต่อท้ายชื่อโฟลเดอร์ทุกครั้ง ทำให้เดาไม่ได้อีก ทีม WordPress ออกรุ่นแก้ไขพร้อมกันให้ทุกสายตั้งแต่ 4.7 ขึ้นไป

02ใครได้รับผลกระทบ

ปลั๊กอินและธีมไม่เกี่ยวกับช่องโหว่นี้ การอัปเดตปลั๊กอินอย่างเดียวจึงไม่พอ ต้องอัปเดต WordPress core

03รุ่นที่แก้แล้ว แยกตามสาย

ให้ดูเลข 2 หลักแรกของรุ่นที่ใช้อยู่ แล้วอัปเดตเป็นรุ่นในตารางหรือใหม่กว่า รายการนี้มาจากช่วงรุ่นที่ได้รับผลกระทบในบันทึก CVE และสถานะรุ่นจาก api.wordpress.org

• 7.1.x7.1.4
• 7.0.x7.0.8
• 6.9.x6.9.11
• 6.8.x6.8.12
• 6.7.x6.7.11
• 6.6.x6.6.11
• 6.5.x6.5.14
• 6.4.x6.4.14
• 6.3.x6.3.14
• 6.2.x6.2.15
• 6.1.x6.1.16
• 6.0.x6.0.18
• 5.9.x5.9.20
• 5.8.x5.8.19
• 5.7.x5.7.21
• 5.6.x5.6.23
• 5.5.x5.5.24
• 5.4.x5.4.25
• 5.3.x5.3.27
• 5.2.x5.2.30
• 5.1.x5.1.28
• 5.0.x5.0.31
• 4.9.x4.9.35
• 4.8.x4.8.34
• 4.7.x4.7.39

ทีม WordPress ดูแลเต็มรูปแบบเฉพาะรุ่นล่าสุด รุ่นแก้ไขของสายเก่าเป็นการแก้ช่องโหว่ร้ายแรงเท่านั้น เว็บที่ยังอยู่สาย 6.x หรือเก่ากว่าควรวางแผนขึ้น 7.1

04วิธีเช็ครุ่น WordPress

ผ่านหน้าแดชบอร์ด

เข้าเมนู แดชบอร์ด → อัปเดต (Dashboard → Updates) จะเห็นรุ่นที่ใช้อยู่ และปุ่มอัปเดตถ้ามีรุ่นใหม่

ผ่าน WP-CLI บนเซิร์ฟเวอร์

wp core version

ไม่มี WP-CLI

grep "wp_version =" wp-includes/version.php

เช็คว่าปิดอัปเดตอัตโนมัติไว้หรือไม่

grep -nE "WP_AUTO_UPDATE_CORE|AUTOMATIC_UPDATER_DISABLED" wp-config.php

ถ้าเห็น AUTOMATIC_UPDATER_DISABLED เป็น true หรือ WP_AUTO_UPDATE_CORE เป็น false แปลว่าเว็บไม่อัปเดตเอง ต้องอัปเดตด้วยมือ

05วิธีอัปเดตอย่างปลอดภัย

ขั้นที่ 1: ปิดการเรียกไฟล์ใน wp-content/upgrade ผ่านเว็บ

WordPress แตกไฟล์ผ่านระบบไฟล์ของเซิร์ฟเวอร์ ไม่ได้เรียกโฟลเดอร์นี้ผ่านเว็บ การปิดจึงไม่กระทบการอัปเดตตามปกติ แต่ควรลองบนเว็บทดสอบก่อนถ้าโฮสติ้งมีระบบอัปเดตของตัวเอง

location ^~ /wp-content/upgrade/ {
    deny all;
}

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

อย่าวางไฟล์ .htaccess ไว้ในโฟลเดอร์ wp-content/upgrade/ เอง เพราะ WordPress ล้างไฟล์ทุกไฟล์ในโฟลเดอร์นี้ก่อนอัปเดตทุกครั้ง และอย่าวางไว้ระหว่าง # BEGIN WordPress กับ # END WordPress เพราะ WordPress เขียนส่วนนั้นทับได้ จากนั้นลองเปิด https://เว็บของคุณ/wp-content/upgrade/ ต้องได้หน้า 403

ขั้นที่ 2: สำรองข้อมูล แล้วอัปเดต

สำรองไฟล์และฐานข้อมูลก่อน แล้วกด อัปเดตตอนนี้ ในหน้าแดชบอร์ด หรือใช้ WP-CLI

wp db export backup-before-7.1.4.sql
wp core update
wp core update-db
wp core version

ถ้าต้องอยู่สายเดิม ใช้ wp core update --minor เพื่อขึ้นรุ่นแก้ไขล่าสุดของสายที่ใช้อยู่ บน cPanel ใช้ WP Toolkit กดอัปเดตได้เหมือนกัน

ขั้นที่ 3: เปิดอัปเดตอัตโนมัติไว้

หลังขึ้น 7.1.4 แล้ว WordPress ตั้งชื่อโฟลเดอร์อัปเดตแบบสุ่ม การอัปเดตครั้งต่อไปจึงไม่เปิดช่องนี้ ควรเปิดอัปเดตอัตโนมัติอย่างน้อยสำหรับรุ่นแก้ไข (minor) เพื่อให้ได้แพตช์ความปลอดภัยทันทีที่ออก

06เช็คว่าถูกเจาะไปแล้วหรือยัง

โฟลเดอร์ชั่วคราวถูกลบหลังอัปเดตเสร็จ ร่องรอยหลักจึงอยู่ใน access log ของเว็บเซิร์ฟเวอร์ ให้เช็คย้อนหลังให้ครอบคลุมทุกครั้งที่เว็บเคยอัปเดต

zgrep -hE "/wp-content/upgrade/[^ ]*\.php" /var/log/nginx/access.log* | tail -50

wp core verify-checksums

find wp-content/uploads -name "*.php"

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

07ช่องโหว่อื่นที่ 7.1.4 แก้ในรอบเดียวกัน

นอกจาก CVE-2026-119977 แล้ว รุ่น 7.1.4 ยังแก้ช่องโหว่อีกหลายรายการ ส่วนใหญ่เป็น stored XSS ที่ผู้ใช้ซึ่งมีสิทธิ์เขียนเนื้อหาฝังสคริปต์ไว้ในหน้าเว็บได้

• stored XSS ผ่าน block markup, บล็อก Categories, Playlist, image และ comments pagination
• stored XSS และ denial of service ใน Interactivity API
• stored XSS ใน Customizer selective refresh, ชื่อผู้ใช้ที่สร้างมาเฉพาะ และคำขอลบข้อมูลส่วนบุคคล (Privacy Data Removal)
• ผู้ใช้ที่ไม่ได้ล็อกอินค้นเจอ Customizer changeset ที่ยังไม่เผยแพร่
• Notes ที่ผู้ใช้สิทธิ์สูงแต่ไม่มีสิทธิ์แก้โพสต์อ่านได้
• อัปเดตรายการ root certificate หลังการเพิกถอนของ eMudhra

อัปเดตเป็น 7.1.4 ครั้งเดียวได้การแก้ไขครบทุกรายการ

08คำถามที่พบบ่อย

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

1. WordPress 7.1.4 Security Release (28 ต.ค. 2569)
2. CVE.org: CVE-2026-119977 (CNA: Wordfence)
3. Wordfence: WordPress Core 4.7 – 7.1.3 Unauthenticated Remote Code Execution
4. CISA: Known Exploited Vulnerabilities Catalog (เพิ่ม CVE-2026-119977 เมื่อ 3 พ.ย. 2569)
5. WordPress Trac: class-wp-upgrader.php ในรุ่น 7.1.3 (โฟลเดอร์ที่ชื่อเดาได้)
6. WordPress Trac: class-wp-upgrader.php ในรุ่น 7.1.4 (ตั้งชื่อโฟลเดอร์แบบสุ่ม)
7. BleepingComputer: CISA flags WordPress RCE flaw as actively exploited in attacks (4 พ.ย. 2569)
8. WordPress Developer Resources: WP-CLI wp core
9. WordPress Developer Resources: Configuring Automatic Background Updates

ข้อมูลในคู่มือนี้รวบรวมจากประกาศของ WordPress, บันทึก CVE, CISA และ Wordfence ณ 9 พ.ย. 2569 เวลา 20:00 น. สถานการณ์อาจเปลี่ยนแปลง โปรดตรวจประกาศล่าสุดก่อนดำเนินการ คู่มือนี้ไม่มีรายละเอียดวิธีโจมตี