"WordPress เตือน PHP ช่องโหว่ RCE: CVE-2026-109618/109619"
"ผู้ดูแลเว็บที่ใช้ PHP ต้องตรวจรุ่นและติดตั้งแพตช์ทันที เพราะช่องโหว่อาจเปิดให้รันโค้ดจากระยะไกลโดยไม่ต้องยืนยันตัวตน"
สรุปใน 1 นาที
- อาการ/ปัญหา
- PHP จัดการหน่วยความจำและสถานะข้ามคำขอผิดพลาด จนอาจนำไปสู่การรันโค้ดด้วยสิทธิ์ของ web worker
- ใครควรอ่าน
- เซิร์ฟเวอร์ที่รับคำขอเว็บด้วย PHP รวมถึง WordPress และแอป PHP อื่นต้องตรวจสอบ
- ทางแก้แบบสั้น
- อัปเดตเป็น PHP 8.2.35, 8.3.36, 8.4.27 หรือ 8.5.12 ตามสาย หรือใช้แพ็กเกจที่ผู้จำหน่ายยืนยันว่า backport แพตช์แล้ว
พอดีเห็น WordPress ออกประกาศ Critical PHP Security Release วันที่ 21 ตุลาคม 2026 เตือนให้เจ้าของเว็บอัปเดต PHP ทันที หลังโครงการ PHP แก้ช่องโหว่ร้ายแรงสองรายการ ปัญหาอยู่ใน PHP ที่ใช้รันเว็บ เลยกระทบแอป PHP อื่นด้วย WordPress ระบุว่าไม่ต้องอัปเดตตัว WordPress เพื่อแก้เรื่องนี้ และไม่มีแผนออกอัปเดตสำหรับสองช่องโหว่นี้ ตามประกาศ WordPress
เกิดอะไรขึ้น
CVE-2026-109618 เกิดเมื่อหน่วยความจำไม่พอ หรือ OOM ขณะ PHP ยังเตรียมข้อมูลคำขอไม่เสร็จ PHP หยุดงาน แต่ขั้นตอนเก็บกวาดคำขออาจนำข้อมูลที่ไม่สมบูรณ์ไปใช้ต่อ ผู้พัฒนาทดสอบบน Apache mod_php แล้วว่ารันโค้ดจากระยะไกลโดยไม่ต้องล็อกอินได้ โค้ดทำงานด้วยสิทธิ์ของ web worker แม้ใช้ข้อจำกัดหน่วยความจำและข้อมูลขาเข้าตามปกติ คะแนน CVSS v4.0 อยู่ที่ 9.2 ระดับ Critical ตามรายละเอียดจากทีม PHP
CVE-2026-109619 เกิดเมื่อ worker ยังเก็บตัวชี้ไปยังหน่วยความจำของคำขอที่คืนไปแล้ว คำขอถัดไปที่เข้า worker เดิมอาจใช้ข้อมูลเก่านั้น เกิด use-after-free ซึ่งนำไปสู่ข้อมูลรั่วและ RCE ได้ ทีม PHP ทดสอบยืนยันกรณี session upload progress ทั้งบน mod_php และ PHP-FPM แต่เงื่อนไขขึ้นกับแอปและการตั้งค่า คะแนนอยู่ที่ 9.2 ระดับ Critical เช่นกัน ตามคำอธิบาย CVE-2026-109619
ใครโดนและรุ่นที่แก้
ทีม PHP ให้ผู้ใช้งานที่รับคำขอเว็บตรวจสอบทั้งหมด รวมถึง PHP-FPM, mod_php, php-cgi, FrankenPHP และ LiteSpeed โดยประเมินความเสี่ยงสูงสุดที่ mod_php ซึ่งมีกรณีโจมตีก่อนโค้ดแอปเริ่มทำงาน รุ่นแก้ไขตามประกาศ PHP วันที่ 21 ตุลาคม 2026 มีดังนี้
| สาย PHP | รุ่นในสายที่ได้รับผลกระทบ | รุ่นที่แก้ทั้งสองรายการ |
|---|---|---|
| 8.2 | ต่ำกว่า 8.2.35 | 8.2.35 |
| 8.3 | ต่ำกว่า 8.3.36 | 8.3.36 |
| 8.4 | ต่ำกว่า 8.4.27 | 8.4.27 |
| 8.5 | ต่ำกว่า 8.5.12 | 8.5.12 |
PHP 8.1 และเก่ากว่าไม่ได้รับอัปเดตตามปกติจากโครงการ PHP แล้ว ผู้จำหน่าย Linux หรือบริการ LTS บางรายอาจมีแพตช์ backport ให้ ต้องตรวจประกาศของผู้จำหน่ายโดยตรง ทีม PHP ยังเตรียม source-backport ขั้นต่ำสำหรับ 7.4, 8.0 และ 8.1 ไว้ช่วยผู้ที่คอมไพล์เอง แต่ไม่ได้หมายความว่าสายเหล่านี้กลับมาได้รับการสนับสนุนตามปกติ
ต้องทำอะไร
เริ่มจากดู PHP ที่เว็บใช้งานจริง ใน WordPress เปิด Tools > Site Health > Info > Server หรือดูจากแผงควบคุมโฮสติ้ง จากนั้นตรวจว่าผู้ให้บริการติดตั้งรุ่นแก้ไขหรือแพ็กเกจ backport แล้วหรือยัง WordPress ระบุว่าโฮสต์อาจกำลังอัปเดตและวางกฎ WAF แต่เจ้าของเว็บยังต้องติดตามสถานะให้แน่ชัด
สำหรับผู้ดูแลระบบโดยตรง แนะนำให้สำรองข้อมูล ตรวจความเข้ากันได้ของแอป แล้วติดตั้งแพตช์ตามช่องทางของผู้จำหน่าย ตรวจรุ่นที่เว็บใช้ซ้ำหลังอัปเดตและทดสอบการทำงานหลัก อย่าถือว่าการอัปเดตตัว WordPress หรือปลั๊กอินเท่ากับแก้ PHP แล้ว เพราะเป็นคนละส่วนของระบบ
หากยังแพตช์ไม่ได้ ทีม PHP มีวิธีลดความเสี่ยงบางกรณี เช่น ตั้ง session.upload_progress.enabled=0 ให้มีผลก่อน PHP อ่านคำขอ แล้วรีสตาร์ต worker ทุกตัว สำหรับ PHP 8.5 ให้ตั้ง fatal_error_backtraces=0 ด้วย ส่วน OOM มีคำแนะนำให้ใช้ memory_limit=-1 ร่วมกับการจำกัดทรัพยากรภายนอก วิธีเหล่านี้มีข้อจำกัด ต้องอ่านเงื่อนไขทั้งหมดในคำแนะนำ PHP ก่อนใช้
การตั้งค่าเหล่านี้ไม่ปิดช่องโหว่ครบทุกเส้นทาง การอัปเดตยังเป็นทางแก้ที่สมบูรณ์ หากใช้ PHP ก่อน 8.2 และยังแก้ไขไม่ได้ WordPress แนะนำให้พิจารณานำเซิร์ฟเวอร์ออฟไลน์ระหว่างเตรียมอัปเกรด
ส่วนตัวผมให้เรื่องนี้เป็นงานแพตช์เร่งด่วน เพราะผลกระทบไปถึงการรันโค้ดโดยไม่ต้องยืนยันตัวตน ที่มา: Critical PHP Security Release (https://wordpress.org/news/2026/10/critical-php-security-release/) เดี๋ยวกลับมาแก้เพิ่มให้ภายหลังครับ
อยากให้เราทำให้ไหม?
ให้เราช่วยติดตั้ง ตั้งค่า ย้ายระบบ หรือแก้ปัญหาเซิร์ฟเวอร์ เพื่อให้คุณมีเวลาไปทำงานที่สำคัญกว่า
เคยเจองานแบบนี้ไหม? ติดตรงไหน?
มาแลกวิธีกันต่อในบอร์ด LinuxThai
ความคิดเห็น 0
ยังไม่มีความคิดเห็น — เป็นคนแรกเลย