ผลกระทบและแนวทางป้องกันช่องโหว่ร้ายแรง "PHP2Shell" ใน PHP｜การทดสอบ RCE บนแอปพลิเคชันโดย ARTEX×GLM

PHP2Shell คือชื่อเรียกโดยรวมของช่องโหว่ระดับวิกฤต 2 รายการที่พบในการประมวลผลคำขอของ PHP ซึ่งนำไปสู่การเรียกใช้โค้ดจากระยะไกล (RCE) โดยไม่ต้องผ่านการตรวจสอบสิทธิ์ เมื่อวันที่ 21 ตุลาคม 2026 ได้มีการเผยแพร่เวอร์ชันแก้ไขฉุกเฉินสำหรับ CVE-2026-109618 และ CVE-2026-109619 ผู้ดูแลระบบ Web System ที่ใช้ PHP จำเป็นต้องตรวจสอบสภาพแวดล้อมการใช้งานและดำเนินการแก้ไขโดยเร็วที่สุด ประกาศอย่างเป็นทางการจาก PHP

ในทางกลับกัน แอปพลิเคชัน PHP ยังมีปัญหาที่นำไปสู่ RCE จากความบกพร่องในการประมวลผลอินพุตและฟังก์ชันการอัปโหลด ทางบริษัทได้ใช้ ARTEX และ GLM ในการตรวจสอบการฉีดคำสั่ง (Command Injection) และ RCE ผ่านการอัปโหลดในแอปพลิเคชัน PHP ที่สร้างขึ้นเอง โดยใช้เวลาในการวัดผลบนฐานข้อมูลจริงตั้งแต่การสร้างงานไปจนถึงการลงทะเบียนผลการตรวจพบที่ 104 วินาที และ 305 วินาที ตามลำดับ

การตรวจสอบด้วย ARTEX ในครั้งนี้มุ่งเน้นไปที่จุดอ่อนที่เตรียมไว้ในฝั่งแอปพลิเคชันเท่านั้น ไม่ได้รวมถึงการจำลอง PHP2Shell เอง ดังนั้นจึงจำเป็นต้องดำเนินการอัปเดตฉุกเฉินของตัว PHP และการแก้ไขฝั่งแอปพลิเคชันแยกจากกันตามสาเหตุของแต่ละปัญหา

ช่องโหว่ 2 รายการของ PHP2Shell เกี่ยวข้องกับการจัดการหน่วยความจำภายในและการประมวลผลคำขอของ PHP โดยมีการยืนยันเส้นทางที่นำไปสู่การรันโค้ดจาก HTTP request ก่อนการยืนยันตัวตน ซึ่งทั้งสองรายการมีความรุนแรงระดับ 9.2 (Critical) ตามมาตรฐาน CVSS v4.0

ความแตกต่างหลักของช่องโหว่ทั้ง 2 รายการอยู่ที่สถานการณ์ที่ทำให้เกิดสภาวะไม่พึงประสงค์:

Worker คือกระบวนการที่ทำหน้าที่ประมวลผลคำขอที่ฝั่งเซิร์ฟเวอร์ กรณีหลังเกี่ยวข้องกับการจัดการสถานะเมื่อกระบวนการเดียวต้องรับผิดชอบคำขอหลายรายการต่อเนื่องกัน ทั้งสองกรณีถูกรายงานว่าเป็นปัญหาที่สามารถนำไปสู่ RCE ได้โดยลำพัง

โดยเฉพาะใน Apache mod_php การวิเคราะห์คำขอก่อนที่แอปพลิเคชันจะเริ่มประมวลผลก็ถือเป็นช่องทางในการโจมตีเช่นกัน PHP-FPM ก็ได้รับผลกระทบด้วย โดยในปัญหาเรื่องสถานะภายในตกค้างนั้น ได้มีการพิสูจน์เส้นทาง RCE บน FPM อย่างเป็นทางการแล้ว ขอบเขตผลกระทบอย่างเป็นทางการจาก PHP

ผลกระทบครอบคลุมถึงสภาพแวดล้อม PHP ที่ประมวลผล Web request รวมถึง CGI และรันไทม์ที่ฝังอยู่ในผลิตภัณฑ์ต่างๆ แม้เงื่อนไขในการโจมตีจริงจะขึ้นอยู่กับเวอร์ชันของ PHP การตั้งค่า และการทำงานของ Worker แต่การปรับปรุงแก้ไขก็เป็นสิ่งจำเป็นสำหรับโครงสร้างอื่นๆ นอกเหนือจาก mod_php ด้วย คำแนะนำจาก CERT-EU

ทาง IPA ได้ออกประกาศเมื่อวันที่ 21 ตุลาคม โดยขอให้ตรวจสอบระบบที่ใช้งานและเตรียมการนำเวอร์ชันแก้ไขมาใช้โดยเร็ว ประกาศล่วงหน้าจาก IPA

สิ่งที่ต้องให้ความสำคัญเป็นอันดับแรกคือการนำการแก้ไขไปปรับใช้กับ PHP ที่บริการของคุณใช้งานอยู่จริง โดยไม่ต้องรอผลการตรวจสอบจาก AI ให้ตรวจสอบข้อมูลการแก้ไขจาก OS, โฮสติ้ง และผลิตภัณฑ์ที่คุณใช้งานอยู่

เวอร์ชันแก้ไขที่ทาง PHP ประกาศอย่างเป็นทางการเมื่อวันที่ 21 ตุลาคม มีทั้งหมด 4 ซีรีส์ดังนี้ โปรดอัปเดตเป็นเวอร์ชันแก้ไขที่ตรงกับซีรีส์ที่คุณใช้งานอยู่ หรือเวอร์ชันที่ใหม่กว่าซึ่งรวมการแก้ไขดังกล่าวไว้แล้ว

นอกจากนี้ยังมีการทำ Backport ซึ่งเป็นการนำการแก้ไขไปรวมไว้ในเวอร์ชันเดิมโดยผู้จัดจำหน่าย ดังนั้นอย่าตัดสินเพียงแค่เลขเวอร์ชันเท่านั้น แต่ให้ตรวจสอบข้อมูลแพ็กเกจที่ได้รับการแก้ไขจากผู้จัดจำหน่ายด้วย สำหรับ PHP ที่มาพร้อมกับคอนเทนเนอร์หรือผลิตภัณฑ์นั้น การอัปเดต PHP ที่ฝั่งโฮสต์เพียงอย่างเดียวจะไม่สามารถแทนที่ PHP ในส่วนดังกล่าวได้ จึงจำเป็นต้องดำเนินการแยกต่างหาก ข้อมูลการตอบสนองจาก NCSC-NL

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

มาตรการชั่วคราวอย่างการตั้งค่า session.upload_progress.enabled=Off เป็นการตั้งค่าเพื่อยับยั้งช่องทางการโจมตีบางส่วนที่ได้รับการยืนยันแล้ว โดยคุณต้องเปลี่ยนการตั้งค่าในจุดที่มีผลก่อนการวิเคราะห์คำขอ (Request) และจำเป็นต้องรีสตาร์ท Worker ทั้งหมด อย่างไรก็ตาม วิธีนี้ไม่ได้เป็นการแก้ไขช่องโหว่ทั้ง 2 รายการอย่างสมบูรณ์

มาตรการแก้ไขถาวรคือการนำการแก้ไข (Patch) ไปปรับใช้ หากยังไม่สามารถดำเนินการได้ทันที ให้ปรึกษากับผู้ให้บริการของคุณเพื่อตัดสินใจเกี่ยวกับมาตรการชั่วคราว ซึ่งรวมถึงการจำกัดขอบเขตการเข้าถึงหรือการระงับการให้บริการชั่วคราว มาตรการบรรเทาผลกระทบและข้อจำกัดจาก CERT-EU

จากการตรวจสอบของเรา เราได้ใช้สื่อการสอน PHP ที่มีการฝังจุดอ่อนที่ทราบกันดีไว้ในฝั่งแอปพลิเคชัน และยืนยันการทำงานบนฝั่งเซิร์ฟเวอร์ด้วย RCE จำนวน 2 ประเภท โดยผลลัพธ์ที่ตรวจพบ (finding) ถูกบันทึกไว้รายการละ 1 รายการ

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

ในสื่อการสอนทั้ง 2 ชุด เราได้เปลี่ยนข้อมูลที่กำหนดให้และขอบเขตที่ AI ใช้ในการสำรวจ

ระยะเวลาที่ใช้เป็นค่าที่วัดจากตัวอย่างความสำเร็จอย่างละ 1 ครั้งในแต่ละสื่อการสอน

ARTEX คือโครงสร้างพื้นฐานสำหรับการทดสอบการเจาะระบบ (Penetration Testing) ที่ช่วยให้เอเจนต์ซึ่งใช้ LLM สามารถควบคุมเครื่องมือ ตรวจสอบเป้าหมาย และรายงานผลลัพธ์ได้ ในครั้งนี้เราได้ใช้การกำหนดค่าสำหรับการตรวจสอบที่รวมเข้ากับ GLM เพื่อตรวจสอบการทำงานของแอปพลิเคชันโดยอ้างอิงจากคำขอ (HTTP request) และการตอบกลับ (response) โดยไม่ได้ตั้งสมมติฐานว่าจะต้องอ่านโค้ดภายในของแอปพลิเคชันเป้าหมาย

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

เป้าหมายถูกจำกัดไว้เฉพาะสภาพแวดล้อมการตรวจสอบภายในเครื่อง (Local) ที่บริษัทของเราดูแลเท่านั้น การวาง ARTEX และแอปพลิเคชันเป้าหมายไว้ในเครื่อง รวมถึงการทำให้ระบบทำงานแบบออฟไลน์โดยสมบูรณ์โดยรวมถึงการสื่อสารกับโมเดลการอนุมาน (Inference model) นั้น เป็นการตั้งค่าและการตรวจสอบในส่วนที่แยกต่างหากออกไป

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

สิ่งที่ ARTEX รับผิดชอบคือ การสำรวจ Web app, การทดลองดำเนินการที่เป็นไปได้, การตรวจสอบการตอบสนองและผลลัพธ์การทำงาน และการลงทะเบียน finding ในส่วนที่สองนั้น ได้ดำเนินการโดยไม่ได้แจ้งตำแหน่งของฟังก์ชันอัปโหลดหรือวิธีการหลีกเลี่ยงที่เฉพาะเจาะจงให้ทราบ

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

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

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

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

ข้อมูลผู้ใช้ที่ได้รับกลับมาแสดงให้เห็นว่าคำสั่งถูกดำเนินการภายใต้สิทธิ์ของผู้ใช้ที่เรียกใช้งาน Web App นั้นๆ ซึ่งยังไม่ใช่การยืนยันว่าสามารถยกระดับสิทธิ์เป็นผู้ดูแลระบบ (Administrator) หรือการบุกรุกออกไปนอกคอนเทนเนอร์ได้

OS Command Injection คือปัญหาที่ความหมายของคำสั่งที่ถูกดำเนินการเปลี่ยนแปลงไปตามอินพุตจากภายนอก โดยผลกระทบจะขึ้นอยู่กับสิทธิ์ของกระบวนการ (Process) นั้นๆ และข้อมูลที่สามารถเข้าถึงได้ CWE-78

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

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

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

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

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

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

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

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

ARTEX ได้เข้าถึงโค้ดสำหรับตรวจสอบที่อัปโหลดขึ้นไป และตรวจสอบผลลัพธ์ของคำสั่งที่ส่งค่าผู้ใช้งานที่ดำเนินการ (execution user) ออกมา นอกจากนี้ยังได้เปรียบเทียบด้วยว่า หากอัปโหลดรูปภาพปกติจะไม่ได้รับผลลัพธ์เดียวกัน

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

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

สื่อการสอนทั้ง 2 รายการมีการลงทะเบียน finding ในเวลาอันสั้น ในการประเมินการใช้งานจริง นอกจากระยะเวลาที่ใช้แล้ว จำเป็นต้องตรวจสอบบันทึกการดำเนินการที่มีการเขียนข้อมูลและการประมวลผลการตรวจสอบด้วย

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

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

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

การทดสอบครั้งแรกมีรายการที่ถูกบล็อก 0 รายการ และถูกปฏิเสธ 0 รายการ ในการทดสอบครั้งที่สอง มีบันทึกเหตุการณ์ที่การตรวจสอบหมดเวลา (timeout) 1 รายการ เนื่องจากรูปแบบการตอบกลับของโมเดลที่ใช้ตัดสินการดำเนินการมีความบกพร่อง

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

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

จากการวัดเวลาตั้งแต่การสร้างงานบน DB จนถึงเวลาที่ลงทะเบียน finding พบว่าสื่อการสอนเรื่องการฉีดคำสั่ง (Command Injection) ใช้เวลา 104 วินาที และสื่อการสอนผ่านการอัปโหลดใช้เวลา 305 วินาที โดยเวลาดังกล่าวไม่รวมถึงเวลาในการสร้างแอปพลิเคชัน การตั้งค่าสภาพแวดล้อม การตรวจสอบด้วยตนเอง และการเริ่มต้นระบบ ซึ่งเป็นค่าที่วัดจากตัวอย่างความสำเร็จเพียงครั้งเดียวของแต่ละสื่อการสอน

ในกรณีที่สองซึ่งดำเนินการโดยไม่แจ้งจุดอ่อนที่เฉพาะเจาะจง ก็สามารถเข้าถึงขั้นตอนการตรวจสอบการทำงานและการลงทะเบียนได้จากการสำรวจภายในเวลาประมาณ 5 นาที ผู้ตรวจสอบรายงานว่าการสำรวจมีความคืบหน้าโดยไม่มีสภาวะหยุดนิ่ง (Idle) ที่ดูเหมือนการประมวลผลค้างเหมือนที่เคยเป็นมาก่อน ทั้งนี้ ผลลัพธ์ดังกล่าวไม่ใช่การวัดอัตราการใช้งาน CPU หรือ GPU

ในการดำเนินการครั้งอื่นในอดีต มีบันทึกว่าใช้เวลาประมาณ 34 นาทีกว่าจะพบ finding แรก อย่างไรก็ตาม เนื่องจากไม่ใช่การเปรียบเทียบภายใต้เงื่อนไข เป้าหมาย คำสั่ง การตั้งค่า และจุดเริ่มต้นการวัดที่เหมือนกัน จึงไม่สามารถคำนวณอัตราการปรับปรุงประสิทธิภาพของ GLM หรืออัตราการเร่งความเร็วของ ARTEX ได้ ผลลัพธ์ในครั้งนี้เป็นเพียงกรณีตัวอย่างที่สามารถพิสูจน์ได้ในระยะเวลาอันสั้นภายใต้เงื่อนไขที่มีการเชื่อมต่อกับเป้าหมายและกำหนดเป้าหมายไว้เรียบร้อยแล้ว

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

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

ก่อนอื่น ให้ตรวจสอบว่าสามารถดำเนินการประมวลผลแบบเดียวกันโดยไม่ต้องเรียกใช้ OS command ได้หรือไม่ แนวทางการป้องกันของ OWASP ก็ให้ความสำคัญกับการหลีกเลี่ยงการเรียกใช้คำสั่งโดยตรง หากสามารถใช้ไลบรารีหรือ API ทดแทนได้

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

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

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

นอกจากนี้ จำเป็นต้องตั้งค่าไม่ให้มีการรันสคริปต์ในพื้นที่จัดเก็บไฟล์ หากเป็นไปได้ควรจัดเก็บไฟล์ไว้นอกพื้นที่ที่เปิดเผยต่อสาธารณะ (Web Public Directory) และออกแบบวิธีการเผยแพร่ไฟล์ให้เหมาะสม ในกรณีที่มีโครงสร้างที่สามารถรันไฟล์หลังการจัดเก็บได้เหมือนกับสื่อการสอนนี้ การปฏิเสธเพียงนามสกุลไฟล์เดียวไม่ถือเป็นมาตรการป้องกันที่เพียงพอ

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

ขอสรุปประเด็นที่มักจะสับสนระหว่างการปรับปรุงแก้ไขตัว PHP กับการตรวจสอบแอปพลิเคชันในครั้งนี้

การแก้ไข PHP2Shell เป็นการจัดการกับปัญหา 2 ประการในตัว PHP เอง ไม่ใช่การแก้ไขโดยอัตโนมัติสำหรับกรณีที่เป็นอันตราย เช่น การป้อนข้อมูลเข้าสู่คำสั่ง OS เหมือนในเนื้อหาการเรียนรู้นี้ หรือการรันโค้ดในปลายทางที่อัปโหลดไฟล์ ดังนั้น นอกจากการอัปเดต PHP แล้ว คุณยังจำเป็นต้องแก้ไขการใช้งาน (Implementation) ของแอปพลิเคชันและการตั้งค่าเซิร์ฟเวอร์ด้วย

สิ่งที่ได้สาธิตในครั้งนี้คือการทำ Command Injection และ RCE ผ่านการอัปโหลดไฟล์ ส่วนเวลา 104 วินาทีและ 305 วินาทีนั้นเป็นบันทึกสำหรับสื่อการสอนทั้งสองชุดนี้ ไม่ใช่เวลาในการทำซ้ำ CVE-2026-109618/CVE-2026-109619

ในการประเมินความสามารถในการรับมือกับ PHP2Shell จำเป็นต้องมีการตรวจสอบแยกต่างหากในสภาพแวดล้อมจำลองที่ตรงตามเงื่อนไขผลกระทบของ CVE นั้นๆ โดยจะทำการประเมินโดยรวบรวมหลักฐานที่สามารถระบุสาเหตุได้ และผลลัพธ์การเปรียบเทียบที่แสดงให้เห็นว่าไม่สามารถทำได้ในเวอร์ชันที่แก้ไขแล้ว

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

ในสื่อการสอนครั้งนี้ที่ใช้ ARTEX และ GLM เราได้ตรวจสอบการทำ Command Injection ฝั่งแอปพลิเคชันและการทำ RCE ผ่านการอัปโหลด ซึ่งใช้เวลาตั้งแต่การสร้าง Task ไปจนถึงการลงทะเบียน Finding อยู่ที่ 104 วินาที และ 305 วินาทีตามลำดับ ผลลัพธ์ที่ได้คือความสำเร็จในการดำเนินการตรวจสอบแบบหลายขั้นตอนโดยไม่แจ้งจุดที่เปราะบางอย่างเฉพาะเจาะจง โปรดประเมินผลการพิสูจน์โดยอ้างอิงจากการเปรียบเทียบกับระบบปกติและบันทึกการดำเนินการ จากนั้นให้ดำเนินการอัปเดตตัว PHP และแก้ไขฝั่งแอปพลิเคชันแยกกันตามลำดับ

เอกสารอ้างอิง (วันที่ตรวจสอบ: 22 ตุลาคม 2026)

• บันทึกการตรวจสอบสื่อการสอน PHP ที่เราจัดทำขึ้นเอง และค่าที่วัดได้จริงในฐานข้อมูลตั้งแต่การสร้าง Task ไปจนถึงการลงทะเบียน Finding โดยตัวอย่างความสำเร็จ ระยะเวลาที่ใช้ และผลการตรวจสอบการดำเนินการของแต่ละวิธีจะอ้างอิงจากบันทึกเหล่านี้
• PHP Official: การแก้ไขฉุกเฉินและคำแนะนำด้านความปลอดภัย ณ วันที่ 21 ตุลาคม 2026
• PHP Official: ข้อมูลทางเทคนิคของ CVE-2026-109618
• PHP Official: ข้อมูลทางเทคนิคของ CVE-2026-109619
• IPA: คำขอให้เตรียมความพร้อมเกี่ยวกับช่องโหว่ของ PHP
• CERT-EU: คำแนะนำเกี่ยวกับช่องโหว่ร้ายแรงของ PHP
• NCSC เนเธอร์แลนด์: ข้อมูลการรับมือ PHP2Shell
• CWE-78: OS Command Injection
• CWE-434: Unrestricted Upload of File with Dangerous Type
• OWASP: แนวทางการป้องกัน OS Command Injection
• OWASP: แนวทางการป้องกันการอัปโหลดไฟล์