PHP ออกแพตช์ฉุกเฉินแล้ว: อัปเป็น 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 ด่วน
แพตช์ที่ PHP นัดไว้ ออกแล้วคืนนี้ 21 ตุลาคม 2026 ตามเวลาที่ประกาศ ถ้าเว็บของคุณรัน PHP อยู่ ให้อัปเป็นรุ่นต่อไปนี้ตามสายที่ใช้: 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 ทีม PHP ติดป้ายทั้งสี่รุ่นว่าเป็น security release และขอให้ผู้ใช้ทุกคนในสายนั้นอัปเกรด (PHP) บทความนี้ต่อจากข่าวเตือนเมื่อเช้า PHP เตรียมแพตช์ฉุกเฉินคืนนี้ 3 ทุ่ม ซึ่งตอนนั้นยังไม่รู้เลขรุ่น ตอนนี้รู้แล้วครับ
สรุป 30 วินาที
- ช่องโหว่ระดับ critical สองจุด คือ CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) และ CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) ทั้งคู่ทำให้คนนอก สั่งรันโค้ดบนเซิร์ฟเวอร์ได้โดยไม่ต้องล็อกอิน (GitHub)
- รุ่นที่โดนคือทุกรุ่นที่ต่ำกว่า 8.2.35, 8.3.36, 8.4.27 และ 8.5.12 ของสายที่ยังซัพพอร์ตอยู่ (GitHub)
- ทีม PHP บอกชัดว่า การอัปเดตคือทางแก้ที่เชื่อได้ทางเดียว ไม่มีการตั้งค่าใดปิดได้ครบ (GitHub)
ทำไมเรื่องนี้เกี่ยวกับคุณ
ถ้าคุณมีเว็บขายของ เว็บบริษัท เว็บโรงเรียน หรือหน้าจองคิวที่ทำด้วย WordPress หรือระบบที่เขียนด้วย PHP เรื่องนี้เกี่ยวกับคุณโดยตรง แม้จะไม่เคยพิมพ์คำว่า PHP เลยสักครั้ง เพราะช่องโหว่อยู่ที่ตัวภาษาที่รันอยู่บนเซิร์ฟเวอร์ ไม่ใช่ปลั๊กอินตัวใดตัวหนึ่ง การอัปเดตธีมหรือปลั๊กอินในหน้าแอดมินจึงไม่ได้แก้ปัญหานี้ ต้องอัปตัว PHP บนเครื่องเท่านั้น (PHP ChangeLog)
สิ่งที่คนนอกได้ถ้ายิงสำเร็จคือสิทธิ์เท่ากับโปรแกรมที่รันเว็บ ภาษาง่ายๆ คือเข้าไปเปิดไฟล์ของเว็บได้ อ่านรหัสผ่านฐานข้อมูลที่เก็บในไฟล์ตั้งค่าได้ และแก้หน้าเว็บให้แอบเก็บข้อมูลบัตรหรือข้อมูลลูกค้าได้ (GitHub) สำหรับร้านค้าออนไลน์ นี่คือความเสี่ยงต่อทั้งเงินและความเชื่อใจของลูกค้า ส่วนคนที่ใช้โฮสต์แบบแชร์ ภาระอัปเดตตกอยู่ที่ผู้ให้บริการ แต่ภาระการตามถามว่าทำแล้วหรือยังยังเป็นของเราครับ
รุ่นที่ต้องอัป
| สาย PHP | รุ่นที่แก้แล้ว |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
ข้อมูลจากหน้า releases และ ChangeLog ของ php.net ซึ่งระบุการแก้ทั้งสอง GHSA ไว้ในหมวด Core (PHP ChangeLog) ถ้าคุณยังใช้ PHP 8.1 หรือเก่ากว่า สายนั้นหมดซัพพอร์ตแล้ว ไม่มีรุ่นแก้ให้ ทางออกคือย้ายขึ้นสายที่ยังได้แพตช์ (PHP)
ทำงานยังไง (พร้อมอุปมาไทย)
ลองนึกถึงร้านข้าวแกงที่มีพนักงานล้างจานคนเดียวรับจานจากทุกโต๊ะ ช่องแรกเหมือนลูกค้าแกล้งสั่งอาหารจนถาดล้น พนักงานเลยวางมือกลางคัน ทิ้งจานที่ยังล้างไม่เสร็จไว้บนเคาน์เตอร์ แล้วคนเก็บร้านก็หยิบจานสกปรกนั้นไปใช้ต่อ ช่องที่สองเหมือนพนักงานลืมเก็บกระดาษจดออเดอร์ของโต๊ะก่อน พอโต๊ะถัดไปมาถึง ก็ทำงานตามโน้ตเก่าที่คนร้ายเขียนทิ้งไว้ ทั้งสองแบบทำให้คนนอกแทรกคำสั่งของตัวเองเข้าไปในครัวได้
CVE-2026-109618: RCE ผ่านหน่วยความจำพังตอนเมมเต็ม เวลา PHP ใช้หน่วยความจำจนชนเพดาน มันกระโดดออกจากงานกลางคัน บางจังหวะทิ้งสถานะในหน่วยความจำแบบยังตั้งค่าไม่เสร็จ แล้วขั้นตอนปิดคำขอไปอ่านของพังนั้นต่อ คนร้ายบังคับให้เมมเต็มได้ด้วยคำขออัปโหลดแบบ multipart ที่จัดมาเป็นพิเศษ ทีมยืนยันว่ายิง RCE สำเร็จบน Apache mod_php ด้วยค่าเริ่มต้น ก่อนโค้ดเว็บของคุณจะได้ทำงานเลยด้วยซ้ำ (GitHub)
CVE-2026-109619: RCE ผ่านสถานะค้างข้ามคำขอ worker ของ PHP เก็บสถานะบางอย่างไว้ เช่น error หรือ session แล้วลืมล้างก่อนคืนหน่วยความจำ คำขอถัดไปที่ตกมาที่ worker เดิมจึงไปใช้ของที่ถูกคืนไปแล้ว (use-after-free) ทีมยืนยัน RCE ได้ทั้ง mod_php และ PHP-FPM (GitHub)
จุดสังเกตคือ ผลกระทบที่ยืนยันแล้วคือรันโค้ดได้ด้วยสิทธิ์ของบัญชีที่รันเว็บ ไม่ใช่ root โดยตรง แต่แค่นั้นก็พอให้อ่านไฟล์ตั้งค่า รหัสฐานข้อมูล หรือฝังโค้ดในเว็บได้แล้ว
ใครโดนบ้าง
- Apache mod_php เสี่ยงสุด เพราะยืนยัน RCE แล้วทั้งสองช่องโหว่ (GitHub)
- PHP-FPM (Nginx ส่วนใหญ่) ยืนยัน RCE แล้วสำหรับ CVE-2026-109619 ส่วนอีกตัวทีมวิเคราะห์ว่าเสี่ยงแต่ยังไม่ได้สาธิตครบ (GitHub)
- FrankenPHP และ LiteSpeed (LSAPI) ทีมประเมินจากโค้ดว่ามีแนวโน้มโดนเช่นกัน (GitHub)
- เว็บ WordPress, ร้านค้าออนไลน์ หรือเว็บที่เขียนเองบน PHP ก็โดนในระดับตัวภาษา ไม่ขึ้นกับปลั๊กอิน
ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน
- ข่าวเตือนเมื่อวานจาก BleepingComputer อ้าง watchTowr ว่ายังไม่พบการโจมตีจริง ประกาศของ GitHub ตอนนี้ก็ไม่ได้บอกว่ามีการโจมตีจริงแล้ว แต่ทั้งหมดเป็นสถานะ ณ เวลาที่เขียน ไม่ใช่คำรับรองว่าปลอดภัย (BleepingComputer)
- สำหรับ CVE-2026-109618 บน PHP-FPM ทีม PHP ยังใช้คำว่าวิเคราะห์จากโค้ดแล้วเสี่ยง แต่ยังไม่มีการสาธิตโจมตีครบ ส่วน FrankenPHP และ LiteSpeed ก็เป็นการประเมินจากโค้ดเช่นกัน ไม่ควรตีความว่าปลอดภัย (GitHub)
- ChangeLog บน php.net ลงวันที่ 22 ต.ค. ขณะที่หน้า releases ระบุ 21 ต.ค. แต่เป็นเลขรุ่นเดียวกัน ไม่ต้องรอรุ่นอื่น (PHP ChangeLog)
- แพ็กเกจของ Ubuntu, Debian และ Docker image ทางการอาจตามมาช้ากว่าซอร์สโค้ดหลายชั่วโมงถึงหลายวัน บทความนี้ยังไม่ยืนยันเลขแพ็กเกจของ distro ใด ต้องดูจากประกาศของ distro เอง
แล้วเราควรทำอะไร
- เช็กรุ่น รัน
php -vบนเซิร์ฟเวอร์ (หรือดูphpinfo()แล้วลบไฟล์ทิ้งหลังดู) ถ้าเลขต่ำกว่าตารางด้านบน ต้องอัป อย่าลืมว่า CLI กับ FPM อาจคนละรุ่นกัน ให้เช็กphp-fpm -vด้วย - ใช้โฮสติ้ง ทักโฮสต์ถามตรงๆ ว่าอัปเป็นรุ่นในตารางแล้วหรือยัง และเมื่อไร ถ้าเลือกรุ่น PHP เองได้ในแผงควบคุม ให้เลือกรุ่นที่แก้แล้ว
- Ubuntu/Debian อัปผ่าน
apt update && apt upgradeแล้วดูประกาศ USN/DSA ของ distro ว่าแพ็กเกจออกแล้วหรือยัง distro มักแพตช์ย้อน (backport) โดยไม่เปลี่ยนเลขรุ่นหลัก จึงต้องดูเลขแพ็กเกจในประกาศของ distro แทนphp -vอย่างเดียว - Docker ดึง image ใหม่ (
docker pull php:8.x-...) แล้ว build/deploy ใหม่ การรีสตาร์ตคอนเทนเนอร์เดิมไม่ได้อัปอะไร - รีสตาร์ต Apache หรือ PHP-FPM หลังอัป เพราะ worker ที่ค้างอยู่ยังรันโค้ดเก่า
- ใครยังอัปไม่ได้ ให้พิจารณาปิดหรือแยกเว็บที่เปิดสู่อินเทอร์เน็ตชั่วคราว เพราะทีม PHP ยืนยันว่าไม่มีการตั้งค่าใดกันได้ครบ (GitHub)
ผมมองว่า…
ข่าวนี้หนักกว่าแพตช์รายเดือนทั่วไป เพราะช่องแรกยิงได้ก่อนโค้ดเว็บเริ่มทำงาน แปลว่าเว็บที่เขียนดีแค่ไหนก็ช่วยไม่ได้ ตอนนี้รายละเอียดเทคนิคเปิดเผยแล้ว ช่วงเวลาระหว่างแพตช์ออกกับคนเริ่มยิงจริงมักสั้นมาก ผมจึงมองว่าไม่ควรรอถึงพรุ่งนี้เช้าครับ