PHP2Shell คืออะไร: ช่องโหว่ PHP ร้ายแรง 2 รายการ เวอร์ชันไหนโดน และควรแพตช์ระบบไหนก่อน
PHP2Shell คือช่องโหว่ PHP ร้ายแรง CVE-2026-109618 และ CVE-2026-109619 ดูว่าเวอร์ชันไหนโดน รุ่นที่แก้แล้ว ลำดับเหตุการณ์ตั้งแต่ 17 ต.ค. และควรแพตช์ระบบไหนก่อน
PHP2Shell คืออะไร: ช่องโหว่ PHP ร้ายแรง 2 รายการ เวอร์ชันไหนโดน และควรแพตช์ระบบไหนก่อน
PHP2Shell คือชื่อเรียกช่องโหว่ 2 รายการในตัว PHP เอง ได้แก่ CVE-2026-109618 และ CVE-2026-109619 ทีม PHP ให้คะแนน CVSS v4.0 ที่ 9.2 (Critical) ทั้งคู่ และระบุว่าคนนอกที่ไม่ต้องล็อกอินอาจสั่งรันโค้ดบนเซิร์ฟเวอร์ได้ ถ้าเงื่อนไขครบ ส่วนทางแก้ที่ครบจริงมีทางเดียวคืออัปเดตเป็น 8.5.12, 8.4.27, 8.3.36 หรือ 8.2.35 ซึ่งออกเมื่อ 21 ตุลาคม 2026 (ประกาศของ PHP) สำหรับ PHP 8.1 ลงไปไม่มีรุ่นทางการออกมา ทีมความปลอดภัยของ PHP ทำ source backport ขั้นต่ำไว้ให้ 7.4, 8.0 และ 8.1 ผู้ให้บริการบางรายออกแพ็กเกจที่ย้อนแก้ให้ ส่วนอีกทางคือย้ายไปสาขาที่ยังมีซัพพอร์ต
ที่ต้องรีบเพราะ Amazon Threat Intelligence เห็นความพยายามโจมตี PHP2Shell บนระบบล่อ (honeypot) ของตัวเองตั้งแต่ 17 ตุลาคม เร็วกว่าวันแพตช์ 4 วัน Amazon ระบุเองว่ายังไม่ชัดว่าความพยายามเหล่านั้นจะสำเร็จกับระบบจริงหรือไม่ และแหล่งข้อมูลที่บทความนี้ตรวจสอบยังไม่มีแห่งไหนรายงานการถูกเจาะที่ยืนยันแล้ว
ข้อมูลโดยย่อ
| |
|---|
| ชื่อเรียก | PHP2Shell |
| CVE | CVE-2026-109618 (RCE จากหน่วยความจำเสียหายตอน PHP ใช้หน่วยความจำหมด) และ CVE-2026-109619 (RCE จากข้อมูลสถานะค้างข้าม request) |
| คะแนน | CVSS v4.0 9.2 Critical ทั้งคู่ (PR:N คือไม่ต้องล็อกอิน ส่วน AC:H กับ AT:P คือโจมตียากและต้องมีเงื่อนไขเฉพาะบนเป้าหมาย) |
| ผลที่ตามมา | รันโค้ดโดยไม่ต้องล็อกอิน ด้วยสิทธิ์ของ web worker ที่รัน PHP อยู่ |
| แพตช์ออกเมื่อ | 21 ตุลาคม 2026 เวลา 14:00 UTC (21:00 น. เวลาไทย) |
| รุ่นที่แก้แล้ว | 8.5.12, 8.4.27, 8.3.36, 8.2.35 (8.1 และเก่ากว่าไม่มีรุ่นทางการ) |
| ได้รับผลกระทบ | PHP ที่ตอบ request เว็บทุกแบบ ทั้ง mod_php, PHP-FPM, php-cgi, FrankenPHP และ LiteSpeed โดยทีม PHP จัดให้ mod_php เสี่ยงที่สุด |
ช่องโหว่อยู่ที่ไหน WordPress หรือ Laravel ต้องแก้ไหม
อยู่ที่ตัว PHP ไม่ใช่ที่แอป ผู้วิเคราะห์อย่าง Sansec ระบุว่าเป็นบั๊กในเอนจินของ PHP แอปจึงโดนด้วย ต่อให้โค้ดของแอปสะอาด ไม่ว่าจะเป็น WordPress, Laravel หรือระบบที่ทีมเขียนเอง การอัปเดตตัวแอปอย่างเดียวไม่แก้ PHP ที่ยังไม่แพตช์ซึ่งรันอยู่ข้างใต้
ต้องเข้าเงื่อนไขอะไรถึงจะโดนจริง
ตามที่ AWS และทีม PHP เขียนไว้ ปมอยู่ที่การที่ PHP แกะ request แบบ multipart/form-data ก่อนที่โค้ดของแอปจะเริ่มทำงาน แปลว่าการมีหรือไม่มีหน้าอัปโหลดไฟล์ไม่ใช่เส้นแบ่งว่าโดนหรือไม่โดน ส่วนเงื่อนไขของสอง CVE ไม่เหมือนกัน
- CVE-2026-109618 บน mod_php คือกรณีที่ยืนยันแล้วว่าหนักสุด ประกาศช่องโหว่ของ PHP ระบุว่า request เดียวที่ไม่ต้องล็อกอินกระตุ้นได้ก่อนโค้ดแอปทำงาน และพิสูจน์การรันโค้ดบน Apache mod_php ที่ใช้ค่าขีดจำกัดเริ่มต้นกับ prefork worker แล้ว ส่วนบน PHP-FPM ถ้อยคำเรื่อง CVE นี้ต่างกัน ประกาศช่องโหว่ของ PHP ระบุว่า FPM เข้าข่ายจากการวิเคราะห์ซอร์สโค้ดแต่ยังไม่มี exploit เต็มรูปแบบ ขณะที่ โพสต์ของ PHP Foundation ระบุว่ายืนยัน RCE บน FPM ผ่านโค้ดระดับแอปแล้ว อย่าถือว่า FPM ปลอดภัย
- CVE-2026-109619 ต้องมีสอง request บน worker ตัวเดียวกัน คือ request ต้นทาง (producer) ที่ทิ้งข้อมูลสถานะค้างไว้ กับ request ปลายทาง (consumer) ที่มาใช้ข้อมูลนั้นก่อนระบบตั้งค่าใหม่ ตัวอย่าง producer ที่ยืนยันแล้วคือฟีเจอร์ session upload progress ซึ่งเปิดเป็นค่าเริ่มต้นและถูกกระตุ้นผ่านฟิลด์ฟอร์ม
PHP_SESSION_UPLOAD_PROGRESS และบน PHP 8.5 คือ fatal_error_backtraces เมื่อเปิดใช้งาน ทั้งสองเป็นตัวอย่าง ไม่ใช่รายการตัวกระตุ้นทั้งหมด
ความยากง่ายของการโจมตียังเถียงกันอยู่ Sansec รายงานวันที่ 22 ตุลาคมว่า PoC สาธารณะที่ทดสอบไม่ทำงานกับ PHP ติดตั้งค่าเริ่มต้น และส่วนใหญ่ต้องอาศัยช่อง local file inclusion ในแอปอีกชั้น ข้อนี้ไม่ได้แปลว่าปลอดภัย ทีม PHP ยังบอกชัดว่าให้อัปเดต
เวอร์ชันไหนโดน
| สาขา PHP | สถานะ | ต้องทำ |
|---|
| 8.5.x | แก้แล้วใน 8.5.12 | อัปเป็น 8.5.12 ขึ้นไป |
| 8.4.x | แก้แล้วใน 8.4.27 | อัปเป็น 8.4.27 ขึ้นไป |
| 8.3.x | แก้แล้วใน 8.3.36 | อัปเป็น 8.3.36 ขึ้นไป |
| 8.2.x | แก้แล้วใน 8.2.35 และสาขานี้หมดอายุ 31 ธันวาคม 2026 | อัปเป็น 8.2.35 แล้ววางแผนย้ายสาขา |
| 8.1 และเก่ากว่า | ไม่มีรุ่นทางการ | แพ็กเกจที่ผู้ให้บริการย้อนแก้ให้ หรือ source backport ขั้นต่ำของ PHP (เฉพาะ 7.4, 8.0 และ 8.1) ส่วนรุ่นที่เก่ากว่านั้นใช้การแก้ไขจากผู้ให้บริการที่ตรวจยืนยันแล้ว หรือย้ายสาขา |
หลังติดตั้งรุ่นที่แก้แล้ว ให้รีสตาร์ท PHP worker ทุกตัวตามที่ watchTowr แนะนำ ซึ่งเป็นคนละรอบกับการรีสตาร์ทหลังเปลี่ยนคอนฟิกที่พูดถึงด้านล่าง
มีสองเรื่องที่ตารางไม่ได้บอก
- บันทึก CVE ลิสต์เฉพาะสาขา 8.2 ถึง 8.5 แต่ไม่ได้แปลว่า 8.1 ลงไปไม่โดน แค่ไม่มีรุ่นทางการออกมา ส่วน Tenable ซึ่งอ้างงานของผู้รายงาน (Calif) ระบุว่าโค้ดช่วงที่มีปัญหาย้อนไปถึง PHP 5.4.0 ข้อนี้เป็นการวิเคราะห์ของบุคคลที่สาม ไม่ใช่ถ้อยแถลงของ PHP เอง
- ให้ตรวจสถานะแพตช์ของแพ็กเกจ อย่าดูแค่เลขเวอร์ชัน ทีม PHP แจ้งว่า distro และ LTS vendor ได้แพตช์ล่วงหน้า แพ็กเกจของ distro จึงอาจแก้แล้วทั้งที่เลขเวอร์ชันยังเป็นเลขเก่า ในทางกลับกัน Sansec ระบุว่า Docker image
php ตัวทางการไม่มีรุ่นแก้สำหรับ 8.1 ลงไป
ก่อนจะถึงขั้นนั้น ต้องรู้ก่อนว่า PHP รันอยู่ที่ไหนบ้าง บัญชีซอฟต์แวร์รายโฮสต์รายแพ็กเกจที่มีมุมมองวันหมดอายุการสนับสนุน (EOL) จะบอกได้ว่าโฮสต์ไหนมี PHP รุ่นไหน และตัวไหนอยู่บนสาขาที่หมดซัพพอร์ตแล้ว (8.1 ลงไป) หรือใกล้หมด (8.2 วันที่ 31 ธันวาคม 2026) ใน zcrX Agent บนโฮสต์รายงาน finding ระดับ host และ package ที่จับคู่กับ CVE advisory พร้อมบริบทสถานะ CISA KEV และ EPSS score และระบบติดตาม product lifecycle กับวัน EOL ของแต่ละซอฟต์แวร์ บทความนี้ไม่ได้อ้างว่า zcrX ตรวจจับ PHP2Shell หรือแสดง CVE ทั้งสองรายการนี้
ตอนนี้มีการโจมตีจริงหรือยัง
เส้นเวลาจากสิ่งที่ Amazon, ทีม PHP และผู้วิจัยรายงานไว้ (เวลาเป็น UTC)
- 17 ต.ค. Amazon เห็นความพยายามโจมตีครั้งแรกใน MadPot ระบบล่อของ AWS มาจาก IP ของเครือข่ายอำพรางตัวเชิงพาณิชย์
- 20 ต.ค. รหัส CVE หลุดตามเว็บบอร์ดพร้อมคะแนน 10.0 ซึ่งไม่ใช่คะแนนจริง ทีม PHP เลื่อนวันออกแพตช์จาก 22 เป็น 21 ต.ค. และผู้รายงานรายหนึ่งเผลอเผยแพร่วิดีโอ PoC ที่ใช้งานได้
- 21 ต.ค. 02:00 ถึง 08:00 Amazon พบ PoC ตัวแรกจากหลายตัว และเห็นความพยายามเพิ่มจากโครงสร้างอำพรางชุดอื่น
- 21 ต.ค. 14:00 ปล่อยแพตช์ ทีม PHP ระบุว่า ณ ตอนปล่อยยังไม่พบ exploit ที่ใช้งานได้จริง แต่ภายในไม่กี่ชั่วโมงก็มี PoC เพิ่มขึ้น
Amazon บอกว่าเห็น "การพยายามโจมตีในวงกว้าง" แต่ระบุเองว่ายังไม่ชัดว่าครั้งไหนจะสำเร็จกับระบบจริง ศูนย์ความปลอดภัยไซเบอร์แคนาดา (21 ต.ค.) ยังไม่พบการโจมตีที่ยืนยันได้ watchTowr รายงานว่า CVE ทั้งสองยังไม่อยู่ในแคตตาล็อก KEV ของ CISA ณ วันที่ 22 ต.ค. และ Dataminr เห็นแค่การสแกนกับ exploit ที่ใช้ไม่ได้ แหล่งข้อมูลที่ตรวจสอบยังไม่มีแห่งไหนรายงานการถูกเจาะที่ยืนยันแล้ว
Amazon ยังแนะนำให้เริ่มสืบจาก 17 ตุลาคม ไม่ใช่จากวันที่เปิดเผย ถ้า log ถูกลบทิ้งทุกไม่กี่วัน ก็อาจย้อนดูช่วงนั้นไม่ได้ การเก็บ log ให้นานพอเป็นงานหลักของ zcrLog ซึ่งตั้งระยะเก็บได้ตั้งแต่ 90 วันถึง 2 ปี แต่การเก็บ log ไว้อย่างเดียวยังไม่ใช่หลักฐานเรื่อง PHP2Shell เพราะ access log ทั่วไปมักไม่บันทึกเนื้อหาของ request สิ่งที่ตรวจได้จึงขึ้นกับว่าเก็บฟิลด์อะไรไว้ และบทความนี้ไม่ได้อ้างว่า zcrLog เก็บ log ของ Apache หรือ PHP-FPM
ควรแพตช์ระบบไหนก่อน
ศูนย์ความปลอดภัยไซเบอร์แคนาดา, NCSC และ watchTowr ตรงกันที่ว่าให้เริ่มจากระบบที่เปิดสู่อินเทอร์เน็ต ลำดับด้านล่างเรียบเรียงจากหลักนั้นกับข้อมูลของทีม PHP ไม่ใช่ลำดับทางการ
- เซิร์ฟเวอร์ที่เปิดสู่อินเทอร์เน็ตและรัน Apache กับ mod_php เพราะทีม PHP จัดเป็นกลุ่มเสี่ยงสุด
- เว็บสาธารณะอื่นที่รับ request body หรือไฟล์อัปโหลด ไม่ว่าจะใช้ PHP-FPM, FrankenPHP หรือ LiteSpeed
- ผลิตภัณฑ์ อุปกรณ์ และ container ที่ฝัง PHP มาด้วย ศูนย์ความปลอดภัยไซเบอร์แคนาดาและ NCSC ให้ไล่หาระบบแบบนี้ ถามผู้ขายว่ามีรุ่นอัปเดตหรือยัง
- ระบบบน PHP 8.1 ลงไป ไม่มีรุ่นทางการ ใช้แพ็กเกจที่ผู้ให้บริการย้อนแก้ให้ หรือ source backport ของ PHP (เฉพาะ 7.4, 8.0 และ 8.1) ส่วนรุ่นที่เก่ากว่านั้นใช้การแก้ไขจากผู้ให้บริการที่ตรวจยืนยันแล้วหรือย้ายสาขา ถ้าทำไม่ทันเวลา NCSC แนะนำให้พิจารณาถอดระบบออกจากอินเทอร์เน็ต
- ระบบภายในที่ไม่เปิดสู่อินเทอร์เน็ต ทำทีหลัง แต่อย่าลืม
ถ้าไล่เช็คลิสต์นี้แล้วพบว่ายังไม่มีรายการว่าโฮสต์ไหนรัน PHP รุ่นไหน ดูซอฟต์แวร์ที่ช่วยเรื่องนี้ได้ที่หน้าราคา โดยการแพตช์ไม่ต้องรอการซื้ออะไรทั้งนั้น
Amazon ฝากถึงฝ่ายบริหารว่า ช่องโหว่ร้ายแรงในระบบที่เปิดสู่อินเทอร์เน็ตควรวัดเวลาแพตช์เป็นชั่วโมง ไม่ใช่เป็นวัน ถ้ายังแพตช์ไม่ทัน ทีม PHP พูดชัดว่าไม่มีการตั้งค่าใดทำให้ปลอดภัยครบ การตั้ง session.upload_progress.enabled=0 และบน PHP 8.5 ตั้ง fatal_error_backtraces=0 ใน php.ini, FPM pool หรือคอนฟิกเซิร์ฟเวอร์ (ไม่ใช่ผ่าน ini_set() หรือ .user.ini) แล้วรีสตาร์ท PHP worker ทุกตัว ช่วยลดความเสี่ยงได้เพียงบางส่วน และ fatal_error_backtraces=0 ปิดได้เฉพาะเส้นทาง fatal backtrace ที่ยืนยันแล้วเท่านั้น
เราใช้ WAF อยู่ ถือว่าแพตช์แล้วไหม
ยังไม่ถือว่าแพตช์ เพราะ WAF แค่กรอง request ที่วิ่งเข้ามา ส่วน PHP ที่มีช่องโหว่ยังอยู่ที่เดิมทุกบรรทัด คู่มือของ AWS อธิบายเรื่องนี้ไว้ชัดเจนเป็นพิเศษ กฎ managed ชื่อ PHP2Shell_BODY (AWSManagedRulesPHPRuleSet เวอร์ชัน 2.3) ออกแบบมาสำหรับ CVE-2026-109619 ส่วน CVE-2026-109618 AWS แนะนำกฎ SizeRestrictions_BODY จาก Core rule set โพสต์เดียวกันระบุว่าเงื่อนไขบางอย่างอยู่ในคอนฟิกของเซิร์ฟเวอร์ซึ่งอยู่นอกขอบเขตของ AWS WAF, AWS WAF ไม่แกะเนื้อในของ multipart และถ้าแอปมีอัปโหลดไฟล์ AWS WAF ลดความเสี่ยงได้แต่ปิดช่องไม่ได้ AWS สรุปเองว่าอัปเกรด PHP คือทางแก้ที่ครบทางเดียว Sansec ก็เขียนทำนองเดียวกันว่าเส้นทางโจมตีทำงานภายใน PHP ก่อนโค้ดแอปและก่อนที่ Sansec Shield ผลิตภัณฑ์ของเขาเองจะได้เห็น นอกจากนี้ request ที่อ้อมไม่ผ่าน WAF ก็ไม่ได้รับการคัดกรองจาก WAF นั้น ซึ่ง Tenable ระบุไว้กับกฎของ Cloudflare
zcrWAF คัดกรองทราฟฟิกของเว็บไซต์และ API ก่อนถึงเซิร์ฟเวอร์จริง ตั้งกฎ Allow, Block หรือ Challenge เองได้ และมี security log ให้ย้อนดู แต่บทความนี้ไม่ได้อ้างว่า zcrWAF ตรวจจับหรือบล็อก PHP2Shell และ WAF ตัวไหนก็ไม่ใช่แพตช์ ถ้าเว็บสาธารณะยังไม่มีอะไรคั่นหน้าเซิร์ฟเวอร์จริงเลย ควรพิจารณาด่านคัดกรองควบคู่กับการแพตช์ ไม่ใช่แทนกัน zcrWAF มีแบบ Cloud/SaaS, Virtual Appliance และ ICT Hardware Appliance ราคาเป็นใบเสนอราคารายโครงการ และดูหน้าจอจริงได้ที่หน้าเดโม เรื่อง WAF พื้นฐานอ่านต่อได้ที่ WAF คืออะไร และ OWASP Top 10 กับ WAF
บทความนี้ยังตอบไม่ได้
บทความนี้บอกไม่ได้ว่าเว็บของคุณถูกเจาะไปแล้วหรือยัง เพราะต้องดู log ไฟล์ และโปรเซสบนเซิร์ฟเวอร์จริง และบอกไม่ได้ว่า PoC ที่หมุนเวียนอยู่ใช้ได้กับคอนฟิกของคุณหรือไม่ อีกเรื่องหนึ่งคือแหล่งข้อมูลที่ตรวจสอบไม่มีแห่งไหนเผยแพร่ตัวเลขว่ามีเว็บถูกเจาะจริงกี่แห่ง ข้อมูลทั้งหมดอัปเดต ณ 23 ตุลาคม 2026 ก่อนตัดสินใจให้เปิดประกาศที่ php.net อีกรอบ
บทความในชุด PHP2Shell
บทความนี้เป็นภาพรวม ที่เหลือแยกลงรายละเอียดตามงานที่ต้องทำ
- ตรวจให้ครบว่าทุกเว็บ ทุก container และทุกโฮสต์รัน PHP เวอร์ชันไหน
- WAF ทำอะไรได้และไม่ได้ก่อนแพตช์ PHP2Shell
- ล่าร่องรอยการโจมตีใน log ของเว็บเซิร์ฟเวอร์และ PHP-FPM
- เว็บ PHP อาจถูกเจาะไปแล้ว: webshell, การกักกัน และการเก็บหลักฐาน
อยากคุยกับ zcr เรื่องซอฟต์แวร์ หรืออยากให้แนะนำพาร์ทเนอร์ ติดต่อเรา ได้ตามช่องทางนี้ ส่วนงานประเมินระบบ การแพตช์ และการรับมือเหตุการณ์จริง ทำผ่านพาร์ทเนอร์
แหล่งที่มา
บทความที่เกี่ยวข้อง
อ่านต่อเพื่อดูพื้นฐานที่เกี่ยวข้อง
ผลิตภัณฑ์ที่เกี่ยวข้อง
ดูขอบเขตและสิ่งที่ต้องเตรียมก่อนคุยกับพาร์ทเนอร์ได้ที่ zcrWAF, zcrX และ zcrLog และดูราคาที่เผยแพร่ได้ที่หน้าราคา
