PHP2Shell คืออะไร? ช่องโหว่ PHP วิกฤต วิธีป้องกันและแก้ไข

PHP2Shell คือชื่อที่ใช้เรียกช่องโหว่สองรายการใน PHP ได้แก่ CVE-2026-109618 และ CVE-2026-109619 ทั้งคู่มีคะแนน CVSS v4.0 เท่ากับ 9.2/10 และอาจทำให้ผู้โจมตีที่ไม่ต้องเข้าสู่ระบบรันคำสั่งบนเซิร์ฟเวอร์ได้ ความเสี่ยงอยู่ที่ตัว PHP runtime ซึ่งประมวลผลคำขอเว็บ ไม่ได้เกิดจากธีมหรือปลั๊กอินตัวใดตัวหนึ่ง ดังนั้นเว็บ WordPress ที่อัปเดตทุกอย่างแล้วก็ยังต้องตรวจเวอร์ชัน PHP ของเซิร์ฟเวอร์ด้วย

บทความนี้อัปเดตตามประกาศของโครงการ PHP วันที่ 23 ตุลาคม 2026 หากคุณดูแลเว็บไซต์บริษัท ร้านค้าออนไลน์ หรือระบบภายในที่เปิดรับคำขอผ่านเว็บ ให้เริ่มจากตรวจว่า PHP ที่ให้บริการจริงได้รับแพตช์หรือยัง แล้ววางแผนอัปเดตโดยเร็ว ไม่ต้องรอให้พบอาการผิดปกติก่อน

PHP2Shell คืออะไร และทำไมจึงต้องรีบแก้

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

ตามประกาศความปลอดภัยของโครงการ PHP ระบบที่รัน PHP เพื่อรับคำขอเว็บมีความเสี่ยงทั้ง PHP-FPM, Apache mod_php, php-cgi, FrankenPHP และ LiteSpeed โดย PHP ระบุว่าการสาธิตโจมตีบน mod_php มีความเสี่ยงสูงเป็นพิเศษเพราะเกิดก่อนโค้ดแอปพลิเคชันทำงาน แต่คำว่า “เสี่ยงสูงกว่า” ไม่ได้แปลว่าสภาพแวดล้อมแบบอื่นปลอดภัย

สิ่งที่ต้องจำ: อัปเดต WordPress, Drupal หรือโค้ดเว็บอย่างเดียวไม่แก้ช่องโหว่นี้ จุดที่ต้องได้รับแพตช์คือ PHP ที่เซิร์ฟเวอร์ใช้ประมวลผลเว็บจริง

ช่องโหว่ PHP2Shell สองรายการต่างกันอย่างไร

PHP2Shell: CVE-2026-109618

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

PHP2Shell: CVE-2026-109619

รายการที่สองเกี่ยวกับสถานะภายในที่ยังค้างหลังหน่วยความจำถูกคืนไปแล้ว เมื่อ worker ตัวเดิมรับคำขอถัดไป สถานะนั้นอาจถูกใช้ก่อนเริ่มต้นใหม่อย่างถูกต้อง ช่องทางที่เกี่ยวข้องกับ session upload progress เป็นหนึ่งในเส้นทางที่โครงการ PHP ระบุให้ปิดชั่วคราวระหว่างติดตามแพตช์ถัดไป

รายละเอียดเชิงเทคนิคและเงื่อนไขของแต่ละรายการตรวจได้จากประกาศของทีม PHP โดยตรง: CVE-2026-109618 และ CVE-2026-109619

เว็บไซต์และระบบแบบไหนต้องตรวจ

ให้เริ่มจากทุกระบบที่มี PHP รับคำขอผ่านเว็บ ไม่ว่าจะเป็น WordPress, เว็บบริษัทที่พัฒนาเอง, ร้านค้าออนไลน์, API, เว็บหลังบ้าน หรือผลิตภัณฑ์สำเร็จรูปที่มี PHP ฝังอยู่ จุดที่มักตกหล่นคือเว็บทดสอบ ระบบเก่าที่ไม่อยู่ในรายการดูแล และ container image ที่ยังใช้ PHP รุ่นเดิม แม้หน้าเว็บหลักจะย้ายไปเครื่องใหม่แล้ว

• เว็บที่เปิดสาธารณะ: ให้ลำดับแรก เพราะผู้โจมตีส่งคำขอได้โดยตรง
• เว็บภายในและระบบหลังบ้าน: ตรวจด้วย เพราะอาจเข้าถึงผ่าน VPN, พนักงาน หรือระบบเชื่อมต่ออื่น
• Shared Hosting: ถามผู้ให้บริการว่า PHP ของเว็บไซต์ได้รับแพตช์หรือ backport สำหรับ CVE ทั้งสองแล้วหรือยัง
• Container และ Managed Service: ตรวจ image หรือ runtime ที่กำลังรันอยู่จริง ไม่ใช่เพียงเวอร์ชันที่ระบุในไฟล์ตั้งค่า

สำหรับเว็บ WordPress เจ้าของเว็บอาจเห็นเวอร์ชัน PHP ในหน้า Site Health หรือแผงควบคุม Hosting แต่การยืนยันว่าแพตช์ถูกนำไปใช้จริงควรดูข้อมูลแพ็กเกจจากผู้ดูแลเซิร์ฟเวอร์ด้วย โดยเฉพาะระบบที่ผู้ผลิต Linux backport แพตช์โดยไม่เปลี่ยนเลขเวอร์ชันหลัก

PHP เวอร์ชันไหนแก้ PHP2Shell แล้ว

โครงการ PHP ออกเวอร์ชันแก้ไขเมื่อวันที่ 21 ตุลาคม 2026 ดังนี้

• สาย 8.5: 8.5.12 หรือใหม่กว่าในสายเดียวกัน
• สาย 8.4: 8.4.27 หรือใหม่กว่าในสายเดียวกัน
• สาย 8.3: 8.3.36 หรือใหม่กว่าในสายเดียวกัน
• สาย 8.2: 8.2.35 หรือใหม่กว่าในสายเดียวกัน

PHP 8.1 และเก่ากว่านั้นไม่ได้รับอัปเดตปกติจากโครงการ PHP แล้ว หากยังใช้รุ่นเก่า ให้ตรวจแพตช์ backport จากผู้จำหน่ายระบบหรือวางแผนย้ายไปสายที่ยังรองรับ อย่าสรุปจากตัวเลขเวอร์ชันอย่างเดียวว่าแพตช์ไม่มีหรือมี เพราะแพ็กเกจ Linux บางชุดคงเลขเวอร์ชันเดิมและเพิ่มแพตช์ผ่าน revision ของแพ็กเกจ

วิธีแก้ไข PHP2Shell อย่างเป็นขั้นตอน

1. ทำรายการระบบที่ใช้ PHP: รวบรวมโดเมน เครื่องเซิร์ฟเวอร์ Hosting, container, ระบบทดสอบ และผู้รับผิดชอบ อย่าดูแค่เว็บไซต์หน้าแรก
2. ยืนยัน runtime ที่ให้บริการจริง: ตรวจเวอร์ชัน PHP ของเว็บและข้อมูลแพ็กเกจจากผู้ให้บริการ แยกออกจากเวอร์ชัน PHP ที่เครื่องผู้ดูแลใช้ผ่าน command line
3. เตรียมจุดย้อนกลับ: สำรองไฟล์ ฐานข้อมูล และค่าตั้งระบบก่อนอัปเดต ตรวจว่ากู้คืนได้ และนัดช่วงเปลี่ยนแปลงที่ทีมพร้อมเฝ้าระวัง
4. อัปเดตจากแหล่งที่เชื่อถือได้: ใช้แพ็กเกจหรือ image ของผู้ผลิตที่มีแพตช์สำหรับ CVE-2026-109618 และ CVE-2026-109619 ไม่ติดตั้งไฟล์แก้จากแหล่งที่ไม่ทราบที่มา
5. รีสตาร์ตหรือเปลี่ยน worker ทั้งชุด: ให้กระบวนการ PHP ที่ยังถือโค้ดเก่าหยุดทำงาน รวมถึง container หรือ node หลัง load balancer ที่ยังไม่ได้เปลี่ยน
6. ทดสอบงานธุรกิจ: ตรวจหน้าเว็บ การล็อกอิน ฟอร์มอัปโหลด คำสั่งซื้อ การจ่ายเงิน งานตามเวลา และการเชื่อม API ตามระบบที่มีจริง
7. ยืนยันผลและเฝ้าดู: บันทึกเวอร์ชันหรือแพ็กเกจที่ใช้งานจริง เวลาเปลี่ยน และผลตรวจ Log/Monitoring หลังอัปเดต

ถ้าต้องเปลี่ยน PHP ข้ามสายหลัก ควรทดสอบความเข้ากันได้ของธีม ปลั๊กอิน และโค้ดเดิมบนเว็บทดสอบก่อน แต่ไม่ควรปล่อยระบบที่เสี่ยงสูงไว้โดยไม่มีแผนหรือกำหนดเวลาชัดเจน

ถ้าอัปเดต PHP ทันทีไม่ได้ ควรทำอย่างไร

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

ประกาศ PHP ยังระบุการตั้งค่าชั่วคราวสำหรับบางเส้นทางโจมตี เช่น ปิด session.upload_progress.enabled และรีสตาร์ต worker ทั้งหมด หากจำเป็นต้องใช้มาตรการระดับ PHP อื่น ควรให้ผู้ดูแลระบบประเมินผลต่อการใช้งานและทรัพยากร เพราะการเปลี่ยนค่า memory หรือข้อจำกัดคำขอโดยไม่ทดสอบอาจทำให้บริการล่มได้

ข้อมูลเพิ่มวันที่ 23 ตุลาคม 2026: หลังออกแพตช์ PHP แนะนำให้ปิด session.upload_progress.enabled จนกว่าจะมี bugfix release ถัดไป เพื่อปิดเส้นทาง RCE ที่พบได้ภายใต้การตั้งค่าและโค้ดที่ค่อนข้างเฉพาะ หากแอปไม่ได้เปลี่ยน session.serialize_handler ระหว่างรันตามเงื่อนไขที่ประกาศ ความเสี่ยงส่วนนี้อาจไม่เข้าเงื่อนไข แต่ผู้ดูแลควรตรวจการตั้งค่าจริงและติดตามประกาศรุ่นถัดไป

ถ้าสงสัยว่าเว็บถูกโจมตีไปแล้ว

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

สิ่งที่เจ้าของเว็บไซต์ควรถามผู้ให้บริการ Hosting วันนี้

• เว็บไซต์ของเราใช้ PHP runtime และแพ็กเกจรุ่นใดอยู่จริง?
• แพตช์สำหรับ CVE-2026-109618 และ CVE-2026-109619 ถูกติดตั้งครบทุก node หรือยัง?
• หากเป็น backport มีเลข revision หรือประกาศจากผู้ผลิตที่ใช้ยืนยันได้หรือไม่?
• worker หรือ container ถูกรีสตาร์ตหลังอัปเดตครบหรือยัง?
• มี Log หรือการแจ้งเตือนความพยายามโจมตีที่เกี่ยวข้องกับเว็บของเราหรือไม่?
• มีแผนรับมือประกาศเพิ่มเติมเรื่อง session upload progress หรือไม่?

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

สรุป: ปิดความเสี่ยงที่ PHP runtime และตรวจผลให้ครบ

PHP2Shell เป็นช่องโหว่ระดับวิกฤตใน PHP สองรายการที่ต้องแก้ด้วยแพตช์ของ PHP หรือแพ็กเกจที่ผู้ผลิต backport แล้ว ตรวจทุกเว็บที่ใช้ PHP โดยเฉพาะระบบเปิดสาธารณะ อัปเดตให้ถึงเวอร์ชันที่แก้แล้ว รีสตาร์ต worker ทดสอบธุรกรรมจริง และตรวจ Log ย้อนหลัง หากยังอัปเดตไม่ได้ ให้ลดพื้นที่เสี่ยงชั่วคราวพร้อมกำหนดเวลาลงแพตช์ที่แน่นอน