ช่องโหว่ WordPress ถูกโจมตีจริง CISA สั่งอุดภายใน 6 พ.ย. เจ้าของเว็บควรเช็กอะไร

CISA ขึ้นบัญชี WordPress Core เป็นช่องโหว่ที่ถูกโจมตีจริง

บัญชีที่ CISA ใช้ชื่อว่า Known Exploited Vulnerabilities หรือ KEV แปลตรงตัวคือรายการช่องโหว่ที่รู้แล้วว่าถูกนำไปใช้โจมตี รายการของ WordPress Core ใช้ชื่อช่องโหว่ว่า TOCTOU Race Condition คำอธิบายใน KEV ระบุว่าเป็น race condition ที่อาจเปิดทางให้ผู้โจมตีที่ไม่ต้องล็อกอินรันโค้ดบนเซิร์ฟเวอร์ในช่วงอัปเกรด สาเหตุมาจากพาธ staging ที่เดาได้และเข้าถึงผ่านเว็บได้ ในการอัปเกรดแบบ full-package

สิ่งที่ KEV ให้ทำคือใช้มาตรการลดความเสี่ยงของผู้พัฒนา ทำตามแนวทาง CISA BOD 26-04 ทำ forensic triage (การตรวจเบื้องต้นเพื่อหาร่องรอยการถูกเจาะ) และประเมินว่าสินทรัพย์แต่ละชิ้นเปิดสู่อินเทอร์เน็ตหรือไม่

เส้นตาย 6 พ.ย. ผูกกับหน่วยงานรัฐบาลกลางสหรัฐฯ ไม่ใช่กฎหมายหรือข้อบังคับของไทย เจ้าของเว็บทั่วไปจึงไม่ได้อยู่ภายใต้เส้นตายนี้ แต่ควรถือเป็นสัญญาณให้รีบดำเนินการ เพราะ CISA กำหนดเวลาไว้เพียงไม่กี่วัน

WordPress 7.1.4 ออกแล้ว แต่ยังยืนยันไม่ได้ว่าแก้ช่องโหว่นี้

WordPress ออกรุ่นความปลอดภัย 7.1.4 เมื่อ 28 ต.ค. 2569 ประกาศของ WordPress.org แก้ความเสี่ยงที่อาจเปิดทางให้รันโค้ดระยะไกลในกระบวนการอัปเกรด แก้ช่องโหว่ XSS (การแทรกสคริปต์ผ่านหน้าเว็บ) หลายจุด แก้ช่องโหว่ที่ทำให้ระบบล่มในส่วน Interactivity API และอัปเดตใบรับรอง root ที่มากับระบบ ประกาศแนะนำให้อัปเดตทันที

เรื่องที่ต้องระวังคือ ประกาศ 7.1.4 ไม่ระบุหมายเลข CVE และรายการใน KEV ก็ไม่ได้บอกรุ่นที่ได้รับผลกระทบหรือรุ่นที่แก้แล้ว จึงยังยืนยันไม่ได้ว่า 7.1.4 แก้ CVE-2026-119977 โดยตรง ที่พูดได้คือลักษณะช่องโหว่ใน KEV ใกล้เคียงกับข้อแก้เรื่องกระบวนการอัปเกรดในประกาศ 7.1.4 เจ้าของเว็บควรอ่านรายละเอียดรุ่นที่ได้รับผลกระทบจาก WordPress.org และติดตามประกาศเพิ่มเติม ประกาศยังระบุว่าแพตช์ความปลอดภัยถูกย้อนไปใส่ในรุ่นเก่าที่ยังรับการแก้ไข ย้อนไปถึง 4.7 และกำลังทยอยออก แต่มีเพียงรุ่นล่าสุดที่ได้รับการสนับสนุนเต็มรูปแบบ

ขั้นตอนอัปเดตและเปิดอัปเดตอัตโนมัติ

วิธีที่ง่ายที่สุดคือเข้าแดชบอร์ด WordPress ไปที่เมนู Updates แล้วกด Update Now หรือดาวน์โหลดแพ็กเกจจาก WordPress.org มาอัปเกรดเอง เป้าหมายคือให้เว็บอยู่ที่ 7.1.4 หรือรุ่นที่ใหม่กว่า ถ้าไม่แน่ใจว่าเว็บใช้รุ่นอะไร ให้สอบถามผู้ให้บริการโฮสติ้งหรือผู้ดูแลเว็บ

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

ก่อนอัปเดตให้สำรองข้อมูลเสมอ สำรองทั้งฐานข้อมูลและไฟล์ WordPress ทั้งหมด รวมถึงไฟล์ .htaccess แล้วตรวจว่าไฟล์สำรองใช้งานได้จริง

เว็บที่เปิดอัปเดตอัตโนมัติอยู่แล้วจะอัปเดตเอง ตามประกาศ 7.1.4 ระบบอัปเดตเบื้องหลังเริ่มทำงานให้ไซต์ที่รองรับ การอัปเดตรุ่นย่อยของแกนหลักเปิดเป็นค่าเริ่มต้น และเว็บที่ติดตั้งใหม่ตั้งแต่ WordPress 5.6 จะได้อัปเดตรุ่นใหญ่ของแกนหลักอัตโนมัติด้วย ยกเว้นระบบตรวจพบว่าใช้ version control ผู้ดูแลเว็บยังตรวจได้ว่าไฟล์ wp-config.php ไม่ได้ตั้งค่า WP_AUTO_UPDATE_CORE เป็น false และไม่ได้ปิดตัวอัปเดตทั้งระบบด้วย AUTOMATIC_UPDATER_DISABLED การปิดแบบหลังนี้ไม่แนะนำอย่างยิ่ง

ขั้นตอนที่ควรทำตามลำดับมีดังนี้

• สำรองฐานข้อมูลและไฟล์ทั้งหมด แล้วทดสอบว่าเปิดไฟล์สำรองได้
• เข้า Dashboard แล้วไปที่ Updates เพื่ออัปเดตแกนหลักของ WordPress
• อัปเดตปลั๊กอินและธีม และลบปลั๊กอินที่ไม่ได้ใช้
• ตรวจว่า wp-config.php ไม่ได้ปิดอัปเดตอัตโนมัติของแกนหลัก
• เปิดเว็บดูหน้าหลักและหน้าสำคัญว่ายังใช้งานได้ปกติ

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

ร่องรอยที่บอกว่าเว็บอาจถูกเจาะ และสิ่งที่ต้องทำต่อ

คู่มือเสริมความปลอดภัยของ WordPress ชี้ว่า log ของเซิร์ฟเวอร์เป็นเครื่องมือหลักในการหาร่องรอย เพราะบันทึก IP เวลา และการกระทำไว้ ควรดูด้วยว่ามีไฟล์ถูกเปลี่ยนหรือเพิ่มโดยที่เราไม่ได้ทำหรือไม่ ซึ่งตรวจได้ด้วยเครื่องมืออย่าง diff หรือ Git และมีบริการตรวจความสมบูรณ์ของเว็บจากภายนอกที่ช่วยจับการเปลี่ยนหน้าเว็บหรือมัลแวร์ได้

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

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

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

ที่มา: Cybersecurity and Infrastructure Security Agency (CISA) บัญชี Known Exploited Vulnerabilities Catalog, ประกาศ WordPress 7.1.4 Security Release ของ WordPress.org, คู่มือ Upgrading WordPress และคู่มือ Hardening WordPress ของ developer.wordpress.org