--- title: "PHP2Shell: สาเหตุและแนวทางการแก้ไข" description: "ทำความเข้าใจข้อบกพร่องวงจรการใช้งาน PHP2Shell, การอัพเกรดรันไทม์, การบรรเทาปัญหาชั่วคราว, การเลือกแพตช์ และการตรวจสอบผ่านเส้นทางคำขอ Web ที่ใช้งานจริง" language: "th" url: "https://keendigit.com/th/insights/php2shell-remediation-guide" author: "KeenDigit" published: "2026-10-22" --- # PHP2Shell: สาเหตุและแนวทางการแก้ไข ทำความเข้าใจข้อบกพร่องวงจรการใช้งาน PHP2Shell, การอัพเกรดรันไทม์, การบรรเทาปัญหาชั่วคราว, การเลือกแพตช์ และการตรวจสอบผ่านเส้นทางคำขอ Web ที่ใช้งานจริง **แหล่งที่มาได้รับการตรวจสอบ ณ วันที่ 22 ตุลาคม 2026** **Audience: ตัวดำเนินการแอปพลิเคชัน PHP, ระบบตอบสนองด้านความปลอดภัย และวิศวกรที่ดูแลสร้าง PHP แบบกำหนดเอง** บทความนี้สรุปสาเหตุ ขอบเขตของผลกระทบ กระบวนการซ่อมแซมอย่างเป็นทางการ มาตรการบรรเทาผลกระทบชั่วคราว และการใช้งานแพทช์อย่างเป็นทางการของช่องโหว่ PHP2Shell ข้อความหลักอ้างอิงโดยใช้ตัวเลข เช่น [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1); ลิงก์แหล่งที่มาทั้งหมดแสดงอยู่ในภาคผนวกท้ายข้อความ ส่วนการกำหนดค่าคือเทมเพลตการปรับใช้ ซึ่งจำเป็นต้องปรับเปลี่ยนตามเวอร์ชันจริง ความจุทางธุรกิจ และความสัมพันธ์ที่สืบทอดการกำหนดค่า ## TL;DR: ขั้นตอนการซ่อมและคำแนะนำ 1. **อัปเกรดรันไทม์ PHP**: อัปเกรดสาขาที่เกี่ยวข้องเป็นอย่างน้อย **8.2.35, 8.3.36, 8.4.27 หรือ 8.5.12** สำหรับแพ็คเกจการแจกจ่าย ใช้เวอร์ชันแพ็คเกจที่สมบูรณ์ซึ่งผู้จำหน่ายยืนยันการแก้ไข CVE ทั้งสอง [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1)[S10](https://keendigit.com/th/insights/php2shell-remediation-guide#source-10) 2. **แทนที่กระบวนการเก่าทั้งหมด**: รีสตาร์ทหรือโรลโอเวอร์ทุก PHP worker บริการโฮสติ้ง และคอนเทนเนอร์หลังจากอัปเกรด และยืนยันว่าอินสแตนซ์เก่าได้ออกแล้ว 3. **ตรวจสอบผ่านเส้นทางคำขอ Web จริง**: ตรวจสอบ Web SAPI เวอร์ชันแพ็คเกจเต็ม และอินสแตนซ์ที่กำลังทำงานอยู่ การตรวจสอบ `php -v` เพียงอย่างเดียวไม่ได้แสดงว่าบริการสดได้รับการแก้ไขแล้ว 4. **เรียกใช้การตรวจสอบการถดถอยทางธุรกิจและกู้คืนงบประมาณทรัพยากรปกติ**: ทดสอบการเข้าสู่ระบบ การจัดการเซสชัน การอัปโหลด การนำเข้า และการจัดการข้อผิดพลาด หากขีดจำกัดหน่วยความจำ PHP ถูกลบออกชั่วคราว ให้เรียกคืนงบประมาณจำกัดที่เหมาะสมหลังจากการแพตช์ 5. **หากการอัพเกรดทันทีเป็นไปไม่ได้**: จำกัดการรับส่งข้อมูลที่ไม่น่าเชื่อถือก่อนที่จะถึง PHP ประเมินการปิดใช้งานความคืบหน้าในการอัปโหลดและ Backtraces ร้ายแรงของ PHP 8.5 ตามที่อธิบายไว้ในส่วน 5 การบรรเทาการกำหนดค่าและกฎ WAF มีความครอบคลุมที่จำกัด และไม่สามารถแทนที่การอัพเกรดได้ [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3) ## 1. ภาพรวมช่องโหว่และการตัดสินความเสี่ยง PHP2Shell ในบทความนี้อ้างถึงช่องโหว่ระดับ Critical สองช่องโหว่ที่เปิดเผยอย่างเป็นทางการโดย PHP เมื่อวันที่ 21 ตุลาคม 2026 ทั้งสองช่องโหว่เกี่ยวข้องกับการจัดการวงจรการใช้งานหน่วยความจำและคำขอของกลไก PHP ซึ่งก่อให้เกิดความเสี่ยงของการเรียกใช้โค้ดจากระยะไกลโดยไม่ได้รับอนุญาต [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3) | โครงการ | CVE-2026-109618 | CVE-2026-109619 | | --------------------------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | ชื่ออย่างเป็นทางการ | RCE via OOM corruption | RCE via stale global state | | ประเด็นหลัก | หน่วยความจำไม่เพียงพอทำให้เกิดการกระโดดที่ผิดปกติ ออกจากสถานะที่ยังไม่เสร็จสิ้นการเตรียมใช้งาน | สถานะโกลบอลที่เหลืออยู่ในผู้ปฏิบัติงานชี้ไปที่หน่วยความจำคำขอที่เผยแพร่ | | เวลาที่เกิดขึ้นโดยทั่วไป | การเริ่มต้น การดำเนินการ หรือการล้างข้อมูลของคำขอปัจจุบัน | คำขอก่อนหน้าจะออกจากสถานะ และคำขอที่ตามมาจะใช้สถานะนั้นล่วงหน้า | | OOM เป็นเงื่อนไขที่จำเป็นหรือไม่? | เป็นของกลไกการกระตุ้นหลักของช่องโหว่ | ไม่; ข้อผิดพลาดร้ายแรงอื่น ๆ และการล้างข้อมูลหลังการวินิจฉัยอาจเกี่ยวข้องด้วย | | ทิศทางการซ่อมแซมขั้นพื้นฐาน | จัดการความล้มเหลวในการจัดสรรอย่างปลอดภัยและการยุติคำขอ | แก้ไขความเป็นเจ้าของของรัฐ กำหนดเวลาการล้างข้อมูล และการเริ่มต้นใช้งานล่วงหน้า | | ข้อกำหนดในการกำจัด | จะต้องได้รับการซ่อมแซม | ต้องซ่อมแซมไปพร้อมๆ กัน | พื้นฐาน: กระดานข่าวความปลอดภัยอย่างเป็นทางการสองรายการและการส่งการแก้ไข [S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3)[S4](https://keendigit.com/th/insights/php2shell-remediation-guide#source-4) ### 1.1 ทำความเข้าใจการปรับใช้ที่ได้รับผลกระทบ PHP พิจารณาอย่างเป็นทางการ **ทั้งหมด PHP การจัดการการปรับใช้ Web คำขอ** ที่มีความเสี่ยงได้แก่ PHP-FPM , Apache mod\_php , php-cgi , FrankenPHP , และ LiteSpeed . ที่แสดงให้เห็น mod\_php การโจมตีสามารถเกิดขึ้นได้ก่อนที่โค้ดของแอปพลิเคชันจะทำงาน ดังนั้นการตรวจสอบการเข้าสู่ระบบ มิดเดิลแวร์ของเฟรมเวิร์ก และการตรวจสอบความถูกต้องของการอัปโหลดแอปพลิเคชันจึงไม่ครอบคลุมเส้นทางนั้น [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1) จำเป็นต้องแยกแยะระหว่าง "การปรับใช้งานจำเป็นต้องได้รับการแก้ไข" และ "ห่วงโซ่การโจมตีบางอย่างได้รับการพิสูจน์แล้วอย่างสมบูรณ์" การประกาศของ CVE-2026-109618: FPM จะออกจากกระบวนการลูกหลังจากการเริ่มต้นคำขอล้มเหลว โดยบล็อกเส้นทางการล้างข้อมูลที่สอดคล้องกันของ mod\_php หลังจากการเริ่มต้นล้มเหลว อย่างไรก็ตาม เส้นทาง OOM หลังจากการเริ่มทำงานสำเร็จแล้วยังคงมีความเสี่ยง การประกาศยังตั้งข้อสังเกตอีกว่าการใช้ประโยชน์จาก FPM เต็มรูปแบบสำหรับ CVE นี้ยังไม่ได้แสดงให้เห็น ข้อจำกัดนี้ไม่สามารถใช้เพื่ออนุมานว่า FPM ปลอดภัย โดยเฉพาะอย่างยิ่ง CVE-2026-109619 ไม่สามารถละเลยได้ [S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3) ขอบเขตการอนุญาตทันทีเพื่อการใช้ประโยชน์ที่ประสบความสำเร็จขึ้นอยู่กับข้อมูลประจำตัวของกระบวนการที่โฮสต์ PHP และทรัพยากรที่กระบวนการสามารถเข้าถึงได้ โดยทั่วไป ควรให้ความสนใจกับโค้ดของเว็บไซต์ ไดเร็กทอรีการอัพโหลด ข้อมูลรับรองฐานข้อมูล โทเค็นบริการ และความสามารถในการเข้าถึงเครือข่ายภายใน "การเรียกใช้โค้ดจากระยะไกล" ไม่ได้หมายถึงการได้รับสิทธิ์รูทโดยธรรมชาติ การตัดสินผลที่ตามมาที่นี่ขึ้นอยู่กับโมเดลการอนุญาตกระบวนการ และผลกระทบที่เกิดขึ้นจริงจำเป็นต้องได้รับการประเมินร่วมกับสิทธิ์การใช้งาน สคริปต์ CLI แบบครั้งเดียวทั่วไปไม่มีรายการ HTTP เหมือนกัน แต่กระบวนการที่จัดการงานภายนอกเป็นเวลานานใน CLI หรือโหมดแบบฝังควรยังคงรวมอยู่ในสินค้าคงคลังรันไทม์และวงจรชีวิต เฉพาะการพึ่งพา CMS, เฟรมเวิร์ก หรือ Composer เท่านั้นที่ได้รับการอัปเดต และกลไก PHP พื้นฐานจะไม่ถูกแทนที่โดยอัตโนมัติ ## 2. การวิเคราะห์สาเหตุ ### 2.1 ทำความเข้าใจวงจรชีวิตทั้งสองก่อน PHP worker มักจะจัดการคำขอหลายรายการติดต่อกัน หน่วยความจำที่จัดสรรในระหว่างการร้องขอสามารถปล่อยออกมาได้อย่างสม่ำเสมอเมื่อสิ้นสุดคำขอ ในขณะที่ตัวผู้ปฏิบัติงานและฟิลด์ส่วนกลางบางส่วนยังคงมีอยู่ ดังนั้นเครื่องยนต์จึงต้องรักษาข้อจำกัดไว้ 2 ประการ: - **ข้อจำกัดในการเริ่มต้น**: ข้อมูลที่โค้ดอื่นมองเห็นได้จะต้องอยู่ในสถานะที่สามารถอ่าน สำรวจ และทำลายได้อย่างปลอดภัย - **Lifecycle constraint**: เมื่อหน่วยความจำคำขอได้รับการปลดปล่อยแล้ว ฟิลด์ที่มีอายุยาวนานกว่าจะต้องไม่ถือว่าที่อยู่ภายในหน่วยความจำนั้นเป็นสถานะที่ถูกต้องต่อไป ข้อจำกัดทั้งสองนี้สอดคล้องกับโหมดความล้มเหลวหลักของช่องโหว่ทั้งสองกลุ่ม กระบวนการต่อไปนี้เป็นคำอธิบายกลไกที่รวมการประกาศและการคอมไพล์แพตช์ ไม่ได้หมายความว่าทุกการใช้งานจะมีเส้นทางที่เข้าถึงได้เหมือนกันทุกประการ [S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3)[S5](https://keendigit.com/th/insights/php2shell-remediation-guide#source-5) ### 2.2 CVE-2026-109618: OOM ขัดจังหวะการอัปเดตสถานะที่ยังไม่เสร็จสิ้น การใช้งานแบบเก่าใช้การข้ามประเภทที่ไม่ใช่ภายในเครื่อง `longjmp()` เพื่อจัดการ OOM และเส้นทางที่เกี่ยวข้องจะออกจากบริบทการดำเนินการปัจจุบันผ่าน `zend_bailout()` อันตรายคือโค้ด C ชิ้นหนึ่งอาจเผยแพร่อ็อบเจ็กต์ อาร์เรย์ หรือสถานะคำขอใหม่ไปยังโค้ดอื่น แต่ยังไม่ได้เริ่มต้นฟิลด์ทั้งหมดให้เสร็จสิ้น ในเวลานี้ ความล้มเหลวในการจัดสรรใดๆ ในเวลาที่เกี่ยวข้องอาจทำให้ขั้นตอนการปิดปกติถูกข้ามไป [S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2) กระบวนการล้มเหลวสามารถแบ่งออกเป็นสี่ขั้นตอน: 1. สร้างหรืออัปเดตโครงสร้างภายในคำขอและทำให้สามารถเข้าถึงได้ 2. การจัดสรรหน่วยความจำในภายหลังล้มเหลว และ OOM ถูกทริกเกอร์ 3. โฟลว์การดำเนินการกระโดดออกจากฟังก์ชันปัจจุบัน และโค้ดเดิมที่ใช้ในการเริ่มต้นหรือสถานะการคืนค่าจะไม่ถูกดำเนินการ 4. คำขอล้างข้อมูลจะประมวลผลโครงสร้างเหล่านี้ต่อไปและถือว่าเนื้อหาที่ไม่ถูกต้องเป็นช่องหรือที่อยู่ที่ถูกต้อง ปัญหาไม่ใช่ว่าหน่วยความจำไม่เพียงพอจะทำให้ RCE เสมอไป แต่การอ่อนล้าของหน่วยความจำ **จะเปลี่ยนโฟลว์การควบคุมและละเมิดสมมติฐานของเครื่องยนต์เกี่ยวกับโครงสร้างที่ถูกต้อง** การจัดสรรที่ล้มเหลวไม่จำเป็นต้องเกี่ยวข้องกับโครงสร้างที่อ่านไม่ถูกต้องในที่สุด [S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2) #### เหตุใดคำขอขนาดเล็กจึงทำให้หน่วยความจำไม่เพียงพอ จำนวนไบต์ในเนื้อหาคำขอและการใช้งานฮีปหลังการแยกวิเคราะห์ไม่เหมือนกัน ฟิลด์ A อาจสอดคล้องกับสตริง องค์ประกอบอาร์เรย์ และออบเจ็กต์ข้อมูลเมตาหลายรายการภายใน PHP ความซับซ้อนของโครงสร้างอินพุตจะส่งผลต่อระดับการขยายหน่วยความจำ ปัญหาเกี่ยวกับหลายส่วนที่ระบุไว้ในประกาศอย่างเป็นทางการ ได้แก่: ช่องว่างการตรวจสอบขนาดเริ่มต้นเมื่อความยาวการประกาศที่มีอยู่หายไป จำนวนส่วนหัวสำหรับส่วนเดียวไม่ถูกจำกัดเพียงพอ และการควบคุมไฟล์ว่างยังคงสร้างข้อมูลเมตา โดยมีชื่อที่ซ้อนกันเพิ่มภาระงานของอาร์เรย์เพิ่มเติม การคลี่คลาย การถอดรหัส หรือการกำหนดอินพุตใหม่ของแอปพลิเคชันเองอาจเป็นแหล่งที่มาของ OOM [S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2) สามารถสรุปข้อสรุปการป้องกันได้สองประการ: - ข้อจำกัดเนื้อหาของคำขอจะต้องดำเนินการให้มากที่สุดเท่าที่จะเป็นไปได้ก่อนเข้าสู่ PHP และต้องพิจารณาความยาวการอ่านจริงและความซับซ้อนของโครงสร้างด้วย - การจำกัดขนาดไฟล์ จำนวนไฟล์ หรือการปิดพอร์ทัลอัปโหลดเพียงพอร์ทัลเดียวไม่สามารถครอบคลุมแหล่งที่มาของ OOM ทั้งหมดได้ #### เหตุใดการรับรองความถูกต้องของแอปพลิเคชันจึงอาจล่าช้าเกินไป ใน mod\_php เนื้อความคำขออาจถูกแยกวิเคราะห์โดยอัตโนมัติในระหว่างขั้นตอนการเริ่มต้นคำขอ แม้ว่าการเริ่มต้นระบบจะล้มเหลว การล้างข้อมูลคำขอที่เกี่ยวข้องจะยังคงดำเนินการอยู่ เส้นทางการโจมตีที่ได้รับการยืนยันจึงสามารถเกิดขึ้นก่อนรหัสแอปพลิเคชันได้ เพื่อลดความเสี่ยงในขั้นตอนนี้ จำเป็นต้องวางข้อจำกัดไว้ที่พร็อกซีย้อนกลับ เซิร์ฟเวอร์ Web หรือขอบเขตอื่นที่อยู่ก่อนหน้าการประมวลผลคำขอ PHP [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2) ### 2.3 CVE-2026-109619: หน่วยความจำคำขอได้รับการเผยแพร่แล้ว การอ้างอิงทั่วโลกยังคงอยู่ ปัญหานี้เกี่ยวข้องกับข้อผิดพลาด เซสชัน ออบเจ็กต์ หรือสถานะส่วนขยาย: ฟิลด์นี้ถูกจัดเก็บไว้ในตำแหน่งการเข้าถึงระยะยาวของผู้ปฏิบัติงาน แต่ข้อมูลที่อ้างอิงโดยฟิลด์นั้นเป็นของคำขอเดียว ตราบใดที่การอ้างอิงไม่ได้รับการล้างข้อมูลอย่างถูกต้องก่อนที่จะปล่อยฮีปคำขอ คำขอที่ตามมาอาจพบสถานะห้อยต่องแต่ง ก่อให้เกิดการใช้งานแบบไร้การใช้งาน [S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3) การวิเคราะห์อย่างเป็นทางการแบ่งเงื่อนไขการแสวงหาผลประโยชน์ออกเป็น "ผู้ผลิต" และ "ผู้บริโภค": | บทบาทหรือเงื่อนไข | ความหมาย | ผลกระทบต่อการป้องกัน | | ----------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- | | ผู้ผลิตของรัฐ | ใส่รัฐที่เป็นของคำขอนี้ลงในตำแหน่งที่ยังสามารถเข้าถึงได้ในภายหลัง | เพื่อตรวจสอบว่าการล้างข้อมูลที่เกี่ยวข้องเสร็จสมบูรณ์หลังจากออกอย่างผิดปกติหรือไม่ | | สถานะยังคงอยู่ | ยังไม่เคลียร์ หรือถูกเคลียร์แล้วเติมใหม่โดยการดำเนินการล่าช้า | การเคลียร์เพียงครั้งเดียวในช่วงการปิดเครื่องก่อนหน้านี้อาจไม่เพียงพอ | | คนงานนำมาใช้ใหม่ | ผู้ปฏิบัติงานคนเดียวกันยังคงดำเนินการตามคำขอในภายหลัง | ผู้ปฏิบัติงานหลายคนเป็นเพียงส่วนต่างของกำหนดการ ไม่ใช่การรับประกันความปลอดภัยของหน่วยความจำ | | ผู้บริโภคล่วงหน้า | อ่าน ปล่อย หรือกำหนดค่าคงเหลือก่อนที่จะเริ่มต้นสถานะที่เกี่ยวข้องตามปกติ | ต้องตรวจสอบ INI เซสชัน และเส้นทางอื่นๆ ก่อนที่จะเริ่มต้น | ต้องปฏิบัติตามเงื่อนไขเหล่านี้ร่วมกัน บันทึกข้อผิดพลาดใดๆ เพียงอย่างเดียวไม่ได้พิสูจน์ว่าช่องโหว่ดังกล่าวถูกโจมตีได้สำเร็จ [S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3) #### ไม่จำเป็นต้องใช้ OOM เป็นข้อกำหนดเบื้องต้นที่จำเป็น ข้อผิดพลาดร้ายแรงสามารถขัดขวางการเผยแพร่และการฟื้นฟูสถานะที่จับคู่กัน ความล้มเหลวในการคอมไพล์หรือการแยกวิเคราะห์ ข้อผิดพลาดที่ไม่ถูกตรวจจับ ความล้มเหลวของ `require` และการหมดเวลาดำเนินการ อาจทำให้สถานะบางอย่างล้าหลังได้ การวินิจฉัยที่ไม่ร้ายแรงล่าช้าในการล้างข้อมูลยังสามารถเติมข้อมูลข้อผิดพลาดที่ถูกล้างไปแล้วอีกครั้ง [S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3) ดังนั้นการเปลี่ยน `memory_limit` เป็นไม่จำกัดจึงไม่ครอบคลุมชุดช่องโหว่นี้ #### "ก่อนการเริ่มต้น" จะต้องได้รับการปฏิบัติแยกกัน ระยะเวลาของผู้บริโภคที่ได้รับการยืนยันทั้งสองประเภทจะแตกต่างกัน: - **Early INI Diagnostics**: การกำหนดค่าบางอย่างใช้กับคำเตือนปัญหาคำขอ การแจ้งให้ทราบ หรือการเลิกใช้งานก่อนการเตรียมใช้งานตัวดำเนินการปกติ และการประมวลผลการวินิจฉัยอาจเข้าถึงสถานะข้อผิดพลาดเก่า - **ความคืบหน้าการอัปโหลดเซสชัน**: เซสชันอาจถูกประมวลผลล่วงหน้าในระหว่างกระบวนการแยกวิเคราะห์คำขอ แต่โมดูลปกติ `RINIT` ยังไม่เสร็จสมบูรณ์ ไม่สามารถอนุมานได้ว่าไม่มีเส้นทางอยู่เนื่องจากแอปพลิเคชันไม่ได้เรียก `session_start()` อย่างชัดเจน [S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3) การกำหนดค่า INI ไม่ใช่ทั้งหมดที่มีกำหนดเวลาความเสี่ยงเท่ากัน การกำหนดค่าระดับไดเร็กทอรีของ mod\_php และ `PHP_VALUE` / `PHP_ADMIN_VALUE` ที่ส่งผ่านโดย FPM front-end จำเป็นต้องแยกความแตกต่างจากการกำหนดค่าการเริ่มต้น `php.ini`, FPM pool ทั่วไป และ FPM `.user.ini` ส่วนหลังมีกำหนดเวลาการกำหนดค่าที่แตกต่างกันและไม่สามารถเรียกรวมกันว่าผู้บริโภคในยุคแรกเดียวกันได้ [S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3) การปิด `display_errors`, `log_errors` การลด `error_reporting` หรือใช้ `@` จะส่งผลต่อการมองเห็นการวินิจฉัยเท่านั้น อาจเข้าถึงสถานะภายในที่เกี่ยวข้องก่อนที่จะตัดสินใจว่าจะส่งออกบันทึกหรือไม่ [S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3) ## 3. การเลือกเวอร์ชันการซ่อมแซมและแพตช์ ### 3.1 พื้นฐานการแก้ไขต้นทางอย่างเป็นทางการ | สาขา PHP ปัจจุบัน | เวอร์ชันแรกที่มีการแก้ไขอย่างเป็นทางการนี้ | ข้อเสนอแนะ | | ----------------------- | ------------------------------------------ | ----------------------------------------------------------------------------------------------- | | 8.2 | 8.2.35 | อัปเกรดเป็นเวอร์ชันนี้หรือเวอร์ชันถัดมาที่มีการแก้ไขเดียวกัน | | 8.3 | 8.3.36 | เช่นเดียวกับข้างต้น | | 8.4 | 8.4.27 | เช่นเดียวกับข้างต้น | | 8.5 | 8.5.12 | เช่นเดียวกับข้างต้น | | 8.1 และเวอร์ชันก่อนหน้า | การสนับสนุนทั่วไปขั้นต้นได้สิ้นสุดลงแล้ว | จัดลำดับความสำคัญของการโยกย้ายไปยังสาขาที่รองรับ การตรวจสอบระยะสั้นหรือ backport ของผู้ผลิต LTS | เวอร์ชันและสถานะการสนับสนุนอิงตามประกาศอย่างเป็นทางการของ PHP และไทม์ไลน์คือวันที่ 22 ตุลาคม 2026 [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1) สิ่งเหล่านี้คือ **เกณฑ์เวอร์ชันที่แก้ไขแล้วสำหรับแต่ละสาขา** ไม่สามารถแทนที่ด้วยคำสั่งที่ว่าทุกเวอร์ชันที่ต่ำกว่า 8.5.12 มีความเสี่ยง: เวอร์ชันเช่น 8.2.35 และ 8.4.27 ในสาขาอื่นมีการแก้ไขอยู่แล้ว ### 3.2 ตรวจสอบเวอร์ชันแพ็คเกจการแจกจ่ายแบบเต็ม Distros มักจะเพิ่มการแก้ไขด้านความปลอดภัยตามเวอร์ชันอัปสตรีมที่เก่ากว่า การยอมรับควรตรวจสอบเวอร์ชันที่วางจำหน่าย แหล่งที่มาของพื้นที่เก็บข้อมูล เวอร์ชันแพ็คเกจเต็ม และกระดานข่าวความปลอดภัย ตัวอย่างเช่น เวอร์ชันแพ็กเกจโปรแกรมแก้ไข Ubuntu 24.04 LTS ที่แสดงสำหรับ Ubuntu USN-8948-1 คือ: ```text 8.3.6-0ubuntu0.24.04.13 ``` ส่วนต้นน้ำยังคงเป็น `8.3.6` แต่เวอร์ชันแพ็คเกจเต็มของการแจกจ่ายนั้นรวมอยู่ในประกาศการแก้ไขนี้ ข้อสรุปนี้ใช้กับการกระจายและแหล่งที่มาของแพ็กเกจที่สอดคล้องกันเท่านั้น และไม่สามารถสรุปกับบิลด์ใดๆ ที่แสดง `8.3.6` ด้วย [S10](https://keendigit.com/th/insights/php2shell-remediation-guide#source-10) ### 3.3 การเลือกแพทช์ที่เหมาะสม | ฉาก | แผนลำดับความสำคัญ | ประเด็นสำคัญสำหรับการยอมรับ | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | | การใช้แพ็คเกจการแจกจ่าย PHP | ติดตั้งการอัปเดตความปลอดภัยที่เผยแพร่โดยผู้ผลิต | ประกาศครอบคลุมทั้ง CVE; เวอร์ชันแพ็คเกจที่สมบูรณ์นั้นถูกต้อง | | ใช้คอนเทนเนอร์ PHP อย่างเป็นทางการหรืออิมเมจที่สร้างขึ้นเอง | อัปเดตรันไทม์พื้นฐาน สร้างใหม่ และปรับใช้ | อินสแตนซ์ที่ทำงานอยู่จะใช้อิมเมจใหม่ สำเนาเก่าทั้งหมดจะออกแล้ว | | สาขาที่รองรับที่รวบรวมเอง | ใช้เวอร์ชันความปลอดภัยอย่างเป็นทางการของสาขานี้หรือชุดแพทช์อย่างเป็นทางการแบบเต็ม | การจับคู่สาขา การพึ่งพาให้สมบูรณ์ ความเข้ากันได้ของส่วนขยาย และการผ่านการถดถอย | | ขึ้นอยู่กับ 7.4, 8.0, 8.1 | จัดลำดับความสำคัญของ backport ของผู้ขาย ประเมินสาขารหัสต้นทางเหตุฉุกเฉินอย่างเป็นทางการหากจำเป็น | ระบุการเปลี่ยนแปลงพฤติกรรมและกำหนดเวลาการโยกย้ายไปยังเวอร์ชันที่รองรับ | แพตช์อย่างเป็นทางการได้รับการเผยแพร่แล้ว และการแก้ไขจริงควรเริ่มจากแพตช์เหล่านี้ ข้อมูลโค้ดในส่วนที่ 6 มีวัตถุประสงค์เพื่อแสดงการออกแบบและการตรวจสอบไฮไลท์ และไม่ถือเป็นแพตช์ที่สมบูรณ์ที่สามารถนำไปใช้ได้อย่างอิสระ [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1)[S4](https://keendigit.com/th/insights/php2shell-remediation-guide#source-4)[S6](https://keendigit.com/th/insights/php2shell-remediation-guide#source-6) ## 4. กระบวนการซ่อมแซมอย่างเป็นทางการ ### 4.1 รายการรันไทม์ที่จัดการคำขอจริง ขอแนะนำให้จัดทำบัญชีแยกประเภทโดยย่อเพื่อบันทึกอย่างน้อย: - ชื่อโดเมนหรือบริการรายการ, แบ็กเอนด์พร็อกซีย้อนกลับ, PHP SAPI - สาขา PHP เวอร์ชันแพ็คเกจเต็มหรือการแยกย่อยอิมเมจ แหล่งที่มาของบิลด์ - FPM pool, หน่วยบริการจริง, คอนเทนเนอร์หรือ Pod, จำนวนเรพลิกา - โหลดส่วนขยาย การกำหนดค่าหลัก และไฟล์การกำหนดค่าเพิ่มเติมแล้ว - มี PHP เวอร์ชันอื่นๆ, สำเนาการปรับใช้เก่า หรือพอร์ทัลต้นทางที่สามารถเข้าถึงได้โดยตรงหรือไม่ นี่เป็นคำแนะนำในการติดตั้งเพื่อให้ "อัปเกรดแล้ว" สามารถสอดคล้องกับรายการการเข้าชมจริงแต่ละรายการได้ โดยเฉพาะอย่างยิ่งตรวจสอบว่าบรรทัดคำสั่ง PHP และ Web PHP ใช้เวอร์ชันที่แตกต่างกันหรือไม่ รูปภาพถูกสร้างขึ้น แต่คอนเทนเนอร์เก่ายังคงทำงานอยู่ ส่วนหนึ่งของพูลหรือสำเนาไม่ได้ถูกแทนที่ เป็นต้น ### 4.2 เลือกและปรับใช้การอัปเดตที่ถูกต้อง ยืนยันเวอร์ชันการแก้ไขตามส่วนที่ 3 โดยควรใช้แหล่งแพ็กเกจที่เชื่อถือได้ที่มีอยู่หรือสายการสร้างที่มีการควบคุม ขอบเขตการอัปเดตควรรวมส่วนประกอบที่โฮสต์คำขอจริง ๆ เช่นแพ็คเกจ FPM, โมดูล Apache PHP, ไบนารี CGI หรือบิลด์บริการที่ฝัง PHP ไว้ ก่อนอัปเกรด ให้เก็บการกำหนดค่าและรายการแพ็คเกจไว้ และตรวจสอบการเริ่มต้นและบริการหลักในสภาพแวดล้อมที่คล้ายกับการใช้งานจริง สำหรับส่วนขยายที่ต้องดูแลรักษาเอง ให้ตรวจสอบความเข้ากันได้ของบิลด์และรันที่สอดคล้องกับเวอร์ชัน PHP การเลือกคอมมิตที่เกี่ยวข้องจากสาขาอื่นไม่ได้รับประกันว่าชุดการแก้ไขทั้งหมดจะถูกนำมาใช้ ### 4.3 รีสตาร์ทหรือโรลโอเวอร์อินสแตนซ์ที่กำลังทำงานอยู่ การติดตั้งไฟล์และการโหลดโค้ดใหม่ลงในกระบวนการเป็นสองสิ่งที่แตกต่างกัน ควรเริ่มบริการที่เกี่ยวข้องใหม่อีกครั้ง หรือการเปลี่ยนกลิ้งควรเสร็จสิ้น และผู้ปฏิบัติงานเก่าและคอนเทนเนอร์เก่าควรได้รับการยืนยันว่าออกจากการทำงานแล้ว สำหรับ mod\_php ให้รีสตาร์ทกระบวนการ Apache ที่โฮสต์โมดูล บริการที่ฝัง PHP จำเป็นต้องเปลี่ยนกระบวนการโฮสต์ สำหรับ FPM การล้างข้อมูล OPcache ไม่ได้แทนที่การอัปเดตรันไทม์และการเลิกจ้างคนทำงานเก่า เมื่อใช้การสลับอย่างค่อยเป็นค่อยไป คุณต้องตรวจสอบว่ากระบวนการรุ่นเก่ายังคงจัดการการเชื่อมต่อที่ยาวนานหรือคำขอที่ค้างอยู่หรือไม่ บันทึกการยอมรับควรรวมถึงบริการจริง เวอร์ชันการใช้งาน เวลาที่การเปลี่ยนแปลงเสร็จสมบูรณ์ และผลลัพธ์การออกจากอินสแตนซ์เก่า ### 4.4 ตรวจสอบผ่านการร้องขอ Web จริง ขอแนะนำให้รวมหลักฐานต่อไปนี้เข้าด้วยกันแทนที่จะอาศัยคำสั่งเวอร์ชันเดียวเพียงอย่างเดียว: | หลักฐาน | สิ่งที่พิสูจน์ได้ | พิสูจน์อะไรคนเดียวไม่ได้ | | ---------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------ | | ตัวจัดการแพ็คเกจหรือข้อมูลเมตาของรูปภาพ | แหล่งที่มาของการติดตั้งและบิลด์แบบเต็ม | การรับส่งข้อมูลถูกเปลี่ยนมาใช้อินสแตนซ์นี้ | | กระบวนการและสถานะการใช้งาน | ผู้ปฏิบัติงานหรือตู้คอนเทนเนอร์ทำการเปลี่ยนให้เสร็จสิ้น | จะต้องกำหนดเส้นทางทางเข้าภายนอก | | ผลการวินิจฉัยแบบจำกัดที่เข้าถึงได้ผ่านทางพอร์ทัลจริง | Web SAPI จริงและการกำหนดค่าที่ทำงานอยู่ | ไม่ว่า backport การเปิดตัวจะครอบคลุม CVE สองตัวหรือไม่ | | ประกาศผู้ขายหรือบันทึกการแก้ไขที่สมบูรณ์ | การแก้ไขข้อบกพร่องนี้รวมอยู่ในโครงสร้างนี้ | แบบจำลองทั้งหมดถูกปรับใช้ | สามารถตรวจสอบ `PHP_VERSION`, `PHP_SAPI`, ไฟล์การกำหนดค่าที่โหลด และการกำหนดค่าฉุกเฉินได้ผ่านความสามารถในการวินิจฉัยภายในที่มีอยู่ หรือพอร์ทัลการวินิจฉัยชั่วคราวที่ควบคุมด้วยการเข้าถึง ตรวจสอบให้แน่ใจว่าคำขอไม่ได้ส่งคืนโดยตรงโดย CDN หรือแคชของเพจ ลบรายการวินิจฉัยชั่วคราวเมื่อเสร็จสิ้น โดยทั่วไป `php -v` จะระบุเฉพาะไบนารี CLI ที่เลือกโดยเชลล์ในปัจจุบันเท่านั้น คำสั่งเช่น `php-fpm -i` ไม่เทียบเท่ากับการตรวจสอบผู้ปฏิบัติงานที่มีอยู่ซึ่งได้รับการรับส่งข้อมูล อย่าเปิดเผยเพจ `phpinfo()` ที่สมบูรณ์ต่อเครือข่ายสาธารณะเป็นเวลานาน ### 4.5 การตรวจสอบการถดถอยทางธุรกิจและการลบการตั้งค่าฉุกเฉิน ตรวจสอบการเข้าสู่ระบบตามปกติ การอ่านและการเขียนเซสชัน แบบฟอร์มและการอัปโหลด การนำเข้า การจัดการข้อผิดพลาด และความเสถียรของผู้ปฏิบัติงานเกี่ยวกับฟังก์ชันที่ได้รับผลกระทบจากการเปลี่ยนแปลงนี้ ตรวจสอบว่าอัตราข้อผิดพลาด ความล่าช้าในการตอบสนอง หน่วยความจำสูงสุด การออกจากกระบวนการ และความถี่ในการสร้างใหม่นั้นผิดปกติหรือไม่ หากตั้งค่า `memory_limit=-1` ไว้ชั่วคราว งบประมาณที่จำกัดซึ่งตรงกับความจุทางธุรกิจจะถูกเรียกคืนหลังจากแพตช์อย่างเป็นทางการมีผล หากตั้งค่า `pm.max_requests=1` ไว้ การกำหนดค่าวงจรชีวิตที่ประเมินความจุจะถูกกู้คืนหลังจากการซ่อมแซมได้รับการยืนยัน ขีดจำกัดขนาดอินพุตและการควบคุมการเข้าถึงแหล่งที่มาสามารถคงไว้ได้ตามความต้องการทางธุรกิจ หากปัญหาความเข้ากันได้เกิดขึ้นระหว่างการอัพเกรด ควรให้ความสำคัญกับการระงับพอร์ทัลที่ได้รับผลกระทบ การจำกัดการเข้าถึงจากภายนอก หรือการปรับแอปพลิเคชันก่อนที่จะย้อนกลับ การอนุญาตให้รันไทม์ที่ไม่ได้รับการซ่อมแซมให้บริการเครือข่ายสาธารณะโดยตรงอีกครั้งจะเป็นการเปิดความเสี่ยงเดิมอีกครั้ง ## 5. มาตรการบรรเทาผลกระทบเมื่อไม่สามารถอัพเกรดได้ทันที ส่วนนี้มีจุดมุ่งหมายเพื่อลดการสัมผัสในระยะสั้นหรือปรับปรุงความพร้อมใช้งาน แต่ละการวัดจะครอบคลุมเฉพาะเส้นทางที่เฉพาะเจาะจง และการรวมกันของมาตรการหลายอย่างไม่เทียบเท่ากับการซ่อมแซมที่สมบูรณ์ [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3) ### 5.1 จัดลำดับความสำคัญการควบคุมการรับส่งข้อมูลก่อน PHP หากบริการอนุญาต ให้จำกัดปลายทางที่มีความละเอียดอ่อนชั่วคราวไว้เฉพาะกับแหล่งที่เชื่อถือได้ หรือบังคับใช้การควบคุมการเข้าถึงก่อน PHP สำหรับการอัปโหลดปริมาณงาน จำกัดขนาดเนื้อหาคำขอ จำนวนฟิลด์ จำนวนชิ้นส่วน ส่วนหัวต่อชิ้นส่วน และความลึกของการซ้อน บริการที่ไม่จำเป็นต้องมีหลายส่วนสามารถปฏิเสธได้ที่ส่วนหน้า [S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2) ข้อจำกัดเหล่านี้ครอบคลุมทางเข้า PHP ทั้งหมด การสกัดกั้น URL ที่ชื่อ "อัปโหลด" เท่านั้นจะพลาดรายการอื่นๆ ที่ PHP ยังคงแยกวิเคราะห์โดยอัตโนมัติในเนื้อหาคำขอ สำหรับกรณีต่างๆ เช่น การถ่ายโอนแบบเป็นก้อน ไม่มีความยาวที่ประกาศไว้ ฯลฯ ขีดจำกัดควรขึ้นอยู่กับขนาดการอ่านจริง แอปพลิเคชันควรมีงบประมาณขนาดเอาต์พุตของตัวเองเมื่อขยายขนาดหรือขยายเนื้อหาอีกครั้ง ### เทมเพลตการกำหนดค่า 5.2 FPM pool วางการตั้งค่าต่อไปนี้ในส่วนการกำหนดค่า **FPM pool ที่ให้บริการการร้องขอ** จริง ไม่ใช่คำต่อคำใน `php.ini` ค่า 8M และ 4M เป็นตัวอย่างในการปรับให้เข้ากับปริมาณงาน เว้นที่ว่างไว้สำหรับฟิลด์แบบฟอร์มและขอบเขตหลายส่วนเมื่อจำกัดคำขอ POST ทั้งหมด [S11](https://keendigit.com/th/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/th/insights/php2shell-remediation-guide#source-12) ```ini ; Temporary mitigation: evaluate capacity before applying. php_admin_value[memory_limit] = -1 php_admin_value[post_max_size] = 8M php_admin_value[upload_max_filesize] = 4M php_admin_flag[session.upload_progress.enabled] = off ``` **PHP 8.5** เท่านั้น บวก: ```ini php_admin_flag[fatal_error_backtraces] = off ``` หน้าที่และขอบเขตของแต่ละรายการมีดังนี้: | การกำหนดค่า | ผลที่คาดหวัง | คำอธิบายของข้อจำกัดที่ต้องคงไว้ | | ------------------------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | `memory_limit=-1` | ลบเงื่อนไขทริกเกอร์ขีดจำกัดบนของหน่วยความจำคำขอ PHP ที่คาดการณ์ได้ | ไม่ได้ป้องกันความล้มเหลวในการจัดสรรพื้นฐาน การยกเลิกงบประมาณเดิมอาจเพิ่มความเสี่ยงที่หน่วยความจำจะหมดและการหยุดชะงักของบริการ | | `post_max_size` ที่เล็กกว่า | ลดขนาดของข้อมูลที่เข้าสู่กระบวนการแยกวิเคราะห์ | parser ที่ไม่ได้แก้ไขได้ทราบช่องว่างแล้ว ไม่สามารถป้องกันการขยายหน่วยความจำได้อย่างอิสระ | | `upload_max_filesize < post_max_size` | จำกัดขนาดไฟล์เดียวและสำรองพื้นที่เหนือศีรษะของคำขอ | ไม่จำกัดฟิลด์ ข้อมูลเมตา หรือการจัดสรรในแอปทั้งหมด | | ปิดความคืบหน้าการอัปโหลด | บล็อกเส้นทางที่เกี่ยวข้องกับเซสชันที่ยืนยันแล้ว | ไม่ครอบคลุมถึงตัวแปรสถานะสากลอื่นๆ | | PHP 8.5 ปิดรอยย้อนกลับที่ร้ายแรง | บล็อกยืนยันผู้ผลิตสถานะที่เกี่ยวข้อง | ไม่ครอบคลุมเส้นทางอื่น เช่น เซสชัน | ขอบเขตมาตรการมาจากประกาศอย่างเป็นทางการ สำหรับไวยากรณ์พูลและความหมายการกำหนดค่าระดับการจัดการ โปรดดูคู่มือ PHP [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1)[S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/th/insights/php2shell-remediation-guide#source-11) การตั้งค่า `php_admin_*` ระดับการจัดการไม่สามารถแทนที่โดยแอปพลิเคชันผ่าน `ini_set()` การกำหนดค่าขาเข้าระดับไดเรกทอรีและส่วนหน้าทั้งหมดควรยังคงได้รับการตรวจสอบเพื่อยืนยันว่าค่าในคำขอจริงเป็นไปตามที่คาดไว้ หลังจากแก้ไขแล้ว ให้สร้างผู้ปฏิบัติงานทั้งหมดขึ้นใหม่เพื่อป้องกันไม่ให้กระบวนการที่มีอยู่คงสถานะเก่าต่อไป หากคุณเลือกที่จะแก้ไข `php.ini` โดยตรง ควรเปลี่ยนไวยากรณ์เป็น: ```ini memory_limit = -1 post_max_size = 8M upload_max_filesize = 4M session.upload_progress.enabled = Off ``` ต่างจาก `php_admin_value` ในพูล เพียงการตั้งค่า `memory_limit=-1` ใน `php.ini` ไม่ได้ป้องกันแอปจากการแก้ไขอีกครั้ง ควรตรวจสอบเฟรมเวิร์ก รหัสแอปพลิเคชัน และการกำหนดค่าอื่นๆ เพื่อดูว่าได้รีเซ็ตค่าที่จำกัดหรือไม่ เมื่อจำเป็นต้องมีการบังคับใช้ ให้ใช้การตั้งค่าระดับการจัดการที่เหมาะสมสำหรับ SAPI ปัจจุบัน และตรวจสอบค่าที่มีประสิทธิผลจริง [S11](https://keendigit.com/th/insights/php2shell-remediation-guide#source-11)[S12](https://keendigit.com/th/insights/php2shell-remediation-guide#source-12) เพิ่ม `fatal_error_backtraces = Off` สำหรับ PHP 8.5 เท่านั้น อย่าใช้ `ini_set()` ระดับแอปพลิเคชันเป็นวิธีแก้ปัญหาชั่วคราวในการปิดใช้งานความคืบหน้าในการอัปโหลด และอย่าพึ่งพา FPM `.user.ini` เพื่อให้มีประสิทธิภาพก่อนที่จะขอการแยกวิเคราะห์ [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1)[S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3) ### 5.3 จัดการค่าใช้จ่ายในการลบขีดจำกัดหน่วยความจำ PHP `memory_limit=-1` เป็นการบรรเทาเส้นทางชั่วคราวสำหรับสภาพแวดล้อมที่ไม่ได้แก้ไข และไม่ควรคัดลอกเป็นการกำหนดค่าเริ่มต้นในระยะยาว เมื่อแอปพลิเคชันหรือคำขอไม่สามารถควบคุมได้ จะสามารถใช้หน่วยความจำของโฮสต์ได้มากขึ้น ดังนั้น ก่อนการใช้งาน คุณควรประเมินจำนวนการทำงานพร้อมกัน ผู้ปฏิบัติงานเดี่ยวสูงสุด และความจุบริการทั้งหมด และปรับใช้ขีดจำกัดอินพุตส่วนหน้า [S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2) ขีดจำกัดหน่วยความจำของคอนเทนเนอร์หรือ cgroup สามารถให้ขอบเขตความพร้อมใช้งาน แต่ไม่รับประกันว่าการจัดสรรจะไม่มีวันล้มเหลว คอนเทนเนอร์ทั้งหมด ต้นแบบ และผู้ปฏิบัติงานทั้งหมดอาจถูกยกเลิกเมื่อมีการทริกเกอร์ขีดจำกัด ความละเอียดของการแยกและกลยุทธ์การยกเลิกจำเป็นต้องได้รับการประเมินร่วมกับการใช้งาน และไม่สามารถเรียกได้ว่าเป็นการป้องกันที่สมบูรณ์สำหรับ CVE ทั้งสองนี้ [S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2) อย่าแทนที่กลยุทธ์ข้างต้นด้วย `RLIMIT_AS`, `RLIMIT_DATA` หรือข้อจำกัดพื้นที่ที่อยู่กระบวนการที่เกี่ยวข้อง พวกเขาอาจทำให้การจัดสรรพื้นฐานล้มเหลวโดยตรงในเส้นทาง OOM ที่ยังคงมีปัญหา [S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2) ### ตัวอย่างการกำหนดค่า 5.4 Nginx ใช้ได้กับการปรับใช้งานโดยที่ Nginx ส่งต่อคำขอไปยัง PHP-FPM สามารถตั้งค่าได้ที่ระดับการกำหนดค่าของบริการโฮสติ้งจริง: ```nginx client_max_body_size 8m; fastcgi_request_buffering on; ``` `client_max_body_size` จำกัดขนาดเนื้อหาคำขอ `fastcgi_request_buffering on` อนุญาตให้ Nginx อ่านเนื้อหาคำขอที่สมบูรณ์ก่อน จากนั้นจึงส่งไปที่แบ็กเอนด์ FastCGI ไม่ว่าจะมีผลบังคับใช้ใน `server` หรือ `location` บางอย่างจำเป็นต้องได้รับการตรวจสอบร่วมกับความสัมพันธ์ของการสืบทอดและความคุ้มครองที่มีอยู่ [S13](https://keendigit.com/th/insights/php2shell-remediation-guide#source-13)[S14](https://keendigit.com/th/insights/php2shell-remediation-guide#source-14) **เฉพาะเมื่อธุรกิจไม่ต้องการหลายส่วน** คุณสามารถเพิ่มกฎการปฏิเสธไปยังทางเข้าบริการที่เกี่ยวข้อง: ```nginx if ($http_content_type ~* "multipart/form-data") { return 403; } ``` นี่เป็นเทมเพลตข้อจำกัดรายการแบบง่ายที่ใช้ `if` และ `return` ไม่ใช่กฎการกรองทั่วไปสำหรับช่องโหว่ของ Parser ตรวจสอบไวยากรณ์การกำหนดค่าและคำขอปกติก่อนใช้งาน และตรวจสอบว่า `error_page` แบบกำหนดเองเปลี่ยนเส้นทางคำขอ 403 ไปยัง PHP หรือไม่ การจับคู่สตริงไม่ได้ให้การรับประกันที่สมบูรณ์สำหรับความแตกต่างในการแยกวิเคราะห์ทั้งหมด [S15](https://keendigit.com/th/insights/php2shell-remediation-guide#source-15) นอกจากนี้ การกำหนดค่าเหล่านี้ไม่ได้จำกัดจำนวนข้อมูล จำนวนฟิลด์ หรือจำนวนของอ็อบเจ็กต์ PHP โดยอัตโนมัติที่แอปพลิเคชันสามารถขยายขนาดได้ ธุรกิจที่ต้องอัปโหลดควรใช้ข้อจำกัดเพิ่มเติมที่เข้าใจโครงสร้างของคำขอของตน ### 5.5 การลดหย่อนทางเลือก: หนึ่งคำขอต่อผู้ปฏิบัติงาน FPM สำหรับการปรับใช้ FPM ที่สามารถจ่ายค่าใช้จ่ายได้ การตั้งค่าระยะสั้นสามารถประเมินได้: ```ini pm.max_requests = 1 ``` และสร้างคนงานที่มีอยู่ขึ้นมาใหม่ จะบล็อกห่วงโซ่คำขอข้ามที่อธิบายไว้ที่ระดับการใช้ซ้ำของผู้ปฏิบัติงาน แต่จะเพิ่มค่าใช้จ่ายในการสร้างกระบวนการและการเริ่มต้น ในเวลาเดียวกัน ไม่สามารถซ่อมแซมคำขอเดียวกัน OOM และปัญหาการล้างข้อมูลของ CVE-2026-109618 ได้ เมื่อค่าน้อยกว่าแต่มากกว่า 1 ก็ยังคงมีหน้าต่างคำขอใช้ซ้ำ [S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3)[S11](https://keendigit.com/th/insights/php2shell-remediation-guide#source-11) ### ขีดจำกัดความครอบคลุม 5.6 WAF และ Cloudflare Cloudflare ได้ประกาศการเตรียมการใช้งานสำหรับการป้องกัน PHP2Shell รวมถึงแผน Free เมื่อใช้บริการ คุณควรตรวจสอบว่าการรับส่งข้อมูลจริงผ่านพร็อกซีหรือไม่ กฎการป้องกันมีผลหรือไม่ และไซต์ต้นทางสามารถข้ามโดยตรงได้หรือไม่ สำหรับแผนแบบชำระเงิน คุณจะต้องตรวจสอบการกำหนดค่าและข้อยกเว้นของกฎที่ได้รับการจัดการที่เกี่ยวข้องด้วย [S16](https://keendigit.com/th/insights/php2shell-remediation-guide#source-16) การตรวจจับบางอย่างที่ผู้ขายอธิบายไว้ใช้สัญญาณตอบสนอง ดังนั้นการป้องกันทั้งหมดจึงไม่สามารถตีความได้ว่า "การโจมตีทุกครั้งจะถูกบล็อกก่อนที่จะไปถึง PHP" WAF สามารถช่วยลดการสัมผัสและให้ข้อมูลเชิงสังเกตได้ แต่ยังคงจำเป็นต้องอัปเกรดเป็น PHP อย่างต่อเนื่อง [S16](https://keendigit.com/th/insights/php2shell-remediation-guide#source-16) ### 5.7 ทำไมมาตรการทั่วไปจึงไม่เพียงพอ | มาตรการหรือการตัดสิน | ข้อบกพร่อง | | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | ปิดเฉพาะ `file_uploads` | ไม่สามารถครอบคลุมการประมวลผลหลายส่วนทั้งหมดและใช้เส้นทาง OOM ของตัวเอง | | การตั้งค่า `enable_post_data_reading=Off` | เปลี่ยนพฤติกรรมการเติม POST/FILES โดยอัตโนมัติ แอปพลิเคชันยังสามารถอ่านเนื้อหาคำขอได้และอาจขัดขวางการดำเนินธุรกิจตามปกติ | | ปิดการแสดงข้อผิดพลาด บันทึก หรือใช้ `@` | การประมวลผลการวินิจฉัยภายในอาจยังคงเข้าถึงสถานะห้อยต่องแต่ง | | เพิ่มปริมาณคนงาน | อย่าสร้างกลไกการล้างสถานะที่ปลอดภัย หรือกำจัดการใช้ซ้ำของผู้ปฏิบัติงานคนเดียว | | กำหนดค่าเฉพาะ `disable_functions` หรือ `open_basedir` | ข้อจำกัดเหล่านี้ไม่สามารถแก้ไขความเสียหายของหน่วยความจำชั้นกลไก C ได้ | | ตรวจสอบเวอร์ชันหรือสำเนาเดียวเพียงครั้งเดียว | ไม่สามารถพิสูจน์ได้ว่าทางเข้าและอินสแตนซ์ที่ทำงานอยู่ทั้งหมดถูกแทนที่แล้ว | | ไม่เห็นบันทึกข้อยกเว้น | ไม่สามารถพิสูจน์ได้ว่าไม่มีช่องโหว่หรือไม่เคยถูกโจมตีมาก่อน | ในหมู่พวกเขาพื้นฐานกลไกการกำหนดค่าและช่องโหว่ของ PHP สามารถพบได้ใน [S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2)[S3](https://keendigit.com/th/insights/php2shell-remediation-guide#source-3)[S12](https://keendigit.com/th/insights/php2shell-remediation-guide#source-12) การตัดสินเกี่ยวกับขอบเขตความครอบคลุม การยอมรับ และการอนุญาตจะขึ้นอยู่กับข้อเสนอแนะในการดำเนินการที่นำเสนอโดยกลไกเหล่านี้ ## 6. แนวคิดในการนำไปปฏิบัติและจุดตรวจสอบของแพทช์อย่างเป็นทางการ ### 6.1 ใช้การแก้ไขที่สมบูรณ์สำหรับสาขาที่ถูกต้อง การส่งตัวแทนอย่างเป็นทางการสำหรับ PHP 8.5 คือ: ```text 31c0ea7d7ff1d1fccb6492e52dab544011628065 Avoid state corruption via bailout ``` คอมมิตเชื่อมโยง CVE สองตัวอย่างชัดเจน ทั้งเพื่อปรับกลไกการออก OOM และเพื่อแก้ไขสถานะโกลบอลที่อาจเข้าถึงได้ในระหว่างขั้นตอนการเริ่มต้น ส่งหน้าที่มีความแตกต่างแบบเต็ม โปรดดูที่ [S4](https://keendigit.com/th/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/th/insights/php2shell-remediation-guide#source-5) สาขาอื่นๆ ควรใช้การเผยแพร่การรักษาความปลอดภัยอย่างเป็นทางการหรือแพตช์ที่ตรงกันของตนเอง และไม่สามารถสันนิษฐานได้ว่าการเปลี่ยนแปลงใน 8.5 สามารถนำไปใช้กับเวอร์ชันเก่าๆ ได้โดยตรง ### การซ่อมแซม 6.2 OOM: กู้คืนสถานะที่ประมวลผลได้ก่อน จากนั้นจึงยุติคำขอ การใช้งานอย่างเป็นทางการจะแนะนำการประมวลผล OOM แบบอ่อนและแบบแข็งสองระดับ: เมื่อถึงขีดจำกัดแบบซอฟต์ สถานะที่รอดำเนินการจะถูกบันทึก และทางออกที่มีการควบคุมจะดำเนินการในตำแหน่งที่ปลอดภัย เช่น VM; อินเทอร์เฟซการจัดสรรที่ล้มเหลวช่วยให้ผู้เรียกสามารถจัดการความล้มเหลวได้อย่างชัดเจน สำหรับการจัดสรรที่ไม่สามารถส่งคืนความล้มเหลวได้โดยตรง หากคาดว่าจะเกินเกณฑ์ฮาร์ดที่สูงกว่า กระบวนการจะถูกยกเลิกโดยตรงเพื่อหลีกเลี่ยงการประมวลผลคำขอต่อไปในสถานะระดับกลางที่ไม่ปลอดภัย [S2](https://keendigit.com/th/insights/php2shell-remediation-guide#source-2)[S5](https://keendigit.com/th/insights/php2shell-remediation-guide#source-5) ต่อไปนี้เป็นข้อความที่ตัดตอนมาจากรหัสคีย์ในส่วนต่าง 8.5 ที่ใช้เพื่อทำเครื่องหมายว่าอยู่ระหว่างดำเนินการ OOM: ```c EG(delayed_oom).state = ZEND_OOM_STATE_PENDING; zend_atomic_bool_store_ex(&EG(vm_interrupt), true); ``` การจัดการขัดจังหวะ VM และตำแหน่งที่ปลอดภัยอื่นๆ เรียก `zend_handle_delayed_oom()` ในเวลาต่อมา บริบทการเรียกใช้โค้ดผู้ใช้ใช้เส้นทางคลี่คลายที่มีการควบคุม พาธ OOM ฮาร์ดเรียก `_exit(137)` [S5](https://keendigit.com/th/insights/php2shell-remediation-guide#source-5) จากมุมมองของการออกแบบ การเปลี่ยนแปลงที่สำคัญคือ: **หลีกเลี่ยงการข้ามสแต็กการเรียก C โดยพลการเมื่อโครงสร้างอยู่ในสถานะระดับกลาง และวางทางออกไว้ที่ตำแหน่ง** ที่สามารถรักษาข้อจำกัดของรัฐได้ หลังจากทริกเกอร์ขีดจำกัดซอฟต์แล้ว อาจจำเป็นต้องใช้หน่วยความจำเพิ่มเติมเพื่อทำให้กระบวนการเสร็จสมบูรณ์ ดังนั้นจึงไม่สามารถเข้าใจขีดจำกัดซอฟต์ใหม่ได้ว่าเป็นขีดจำกัดบนที่แน่นอนสำหรับหน่วยความจำทั้งหมดของกระบวนการ และไม่สามารถสรุปได้ว่า "PHP ได้ลบ `zend_bailout()` ทั้งหมดแล้ว" โปรแกรมแก้ไขยังคงใช้กลไกที่เกี่ยวข้องในบริบทเฉพาะ สิ่งที่ได้รับการแก้ไขคือจังหวะเวลาทางออกที่เป็นอันตรายและการจัดการของรัฐที่เกี่ยวข้อง [S5](https://keendigit.com/th/insights/php2shell-remediation-guide#source-5) ### 6.3 อัปเดตผู้เรียกการจัดสรรและการแยกวิเคราะห์หลายส่วนพร้อมกัน หากคุณเปลี่ยนฟังก์ชันการจัดสรรเป็น "ส่งคืน NULL เมื่อล้มเหลว" และผู้เรียกเดิมยังคงถือว่าตัวชี้ที่ถูกต้องถูกส่งกลับเสมอ คุณจะแนะนำการเข้าถึงตัวชี้ null ใหม่หรือการล้างข้อมูลที่ไม่สมบูรณ์ อินเทอร์เฟซการจัดสรรที่ล้มเหลวในแพตช์จะต้องได้รับการตรวจสอบร่วมกับการตรวจสอบผู้โทรและการแพร่กระจายข้อยกเว้น [S5](https://keendigit.com/th/insights/php2shell-remediation-guide#source-5) การแก้ไขที่เกี่ยวข้องกับหลายส่วนยังรวมถึงการดำเนินการตรวจสอบสะสมตามปริมาณการอ่านจริง ลดการประมวลผลส่วนหัวที่ไม่มีประโยชน์หรือซ้ำกัน และการใช้ตรรกะทางออกและการล้างข้อมูลที่สอดคล้องกันเมื่อ OOM อยู่ระหว่างการพิจารณา การเปลี่ยนแปลงเหล่านี้ทั้งลดการขยายทรัพยากร และทำให้ parser สอดคล้องกับโปรโตคอล OOM ใหม่ [S5](https://keendigit.com/th/insights/php2shell-remediation-guide#source-5) สำหรับทีมที่ดูแลสาขาของตนเอง ขอแนะนำให้ประเด็นต่อไปนี้เป็นจุดเน้นของการตรวจสอบโค้ด: - สถานะจะปรากฏแก่โลกภายนอกก่อนที่จะเริ่มต้นใช้งานโดยสมบูรณ์หรือไม่? - หลังจากการจัดสรรล้มเหลวหรือข้อยกเว้นในการโทรกลับ ความเป็นเจ้าของยังคงไม่ซ้ำกันและไม่คลุมเครือหรือไม่ - คุณสามารถไปถึงทางออกการล้างข้อมูลแบบรวมศูนย์ได้หรือไม่หากคุณล้มเหลวกลางคัน? - ฟังก์ชันการล้างข้อมูลสามารถจดจำฟิลด์ที่ไม่ได้เตรียมใช้งานหรือปล่อยให้ว่างได้หรือไม่ - งบประมาณการแยกวิเคราะห์ขึ้นอยู่กับปริมาณการประมวลผลจริง ไม่ใช่แค่การอ้างสิทธิ์คำขอที่เชื่อถือได้หรือไม่ - ผู้โทรทั้งหมดจัดการค่าส่งคืนความล้มเหลวใหม่หรือไม่ คำถามเหล่านี้เป็นคำถามทบทวนที่สรุปตามกลไกการแก้ไข และไม่ใช่ข้อสรุปของการตรวจสอบที่เสร็จสมบูรณ์แล้วสำหรับฐานรหัสที่ไม่มีให้ ### การแก้ไขคำขอข้าม 6.4: การเริ่มต้นก่อนหน้านี้ การล้างข้อมูลครั้งสุดท้ายในภายหลัง สอดคล้องกับ CVE-2026-109619 แพตช์จะปรับขอบเขตวงจรชีวิตหลายรายการพร้อมกัน ไฟล์และการดำเนินการที่แสดงด้านล่างใช้ PHP 8.5 อย่างเป็นทางการที่แตกต่างกันเป็นตัวอย่าง [S5](https://keendigit.com/th/insights/php2shell-remediation-guide#source-5) | ที่ตั้ง | เปลี่ยนทิศทาง | แก้ไขปัญหาแล้ว | | -------------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------- | | `Zend/zend_execute_API.c` ฯลฯ | รีเซ็ตสถานะของตัวดำเนินการ เช่น ข้อผิดพลาด ข้อยกเว้น ตัวจัดการ วัตถุ ฯลฯ | หลังจากที่คำขอสิ้นสุดลง ก็ยังมีข้อมูลอ้างอิงเก่าๆ ที่สามารถเข้าถึงได้ในคำขอถัดไป | | เส้นทางเริ่มต้นของ `main/main.c` | โทร `php_basic_early_rinit()` ก่อนเปิดใช้งาน SAPI | เมื่อผู้บริโภคในยุคแรกเกิดขึ้น สถานะที่เกี่ยวข้องยังไม่ได้รับการเตรียมใช้งาน | | ปิดเส้นทางของ `main/main.c` | ทำลาย HTTP globals และทำเครื่องหมายเป็นไม่ได้กำหนด | ค่าที่นำออกใช้ยังถือว่าเป็นออบเจ็กต์ที่ถูกต้อง | | ก่อนที่คำขอฮีปจะถูกปลดปล่อยในที่สุด | ล้างข้อความแสดงข้อผิดพลาดล่าสุดอีกครั้ง | การวินิจฉัยการล้างข้อมูลล่าช้า repopulate สถานะข้อผิดพลาด | | `ext/session/session.c` | ความคืบหน้าในการอัปโหลด เส้นทางเริ่มต้นจะเริ่มต้นได้ทั่วโลกเซสชันแรก | โมดูลปกติ RINIT เข้าถึงสถานะเก่าก่อนหน้านี้ | | รหัสที่เกี่ยวข้องกับการทำให้เป็นอนุกรม | จำกัดการแยกวิเคราะห์คลาสและการเรียกกลับของผู้ใช้ในการประมวลผลเบื้องต้น | รันโค้ดผู้ใช้เพิ่มเติมเมื่อการกำหนดค่าเริ่มต้นไม่เสร็จสมบูรณ์ | ตัวอย่างเช่น ลำดับการเริ่มต้นระบบประกอบด้วย: ```c zend_activate(); php_basic_early_rinit(); sapi_activate(); ``` หลังจากที่ HTTP globals ถูกทำลาย ให้เพิ่มเครื่องหมายสถานะล้มเหลว: ```c zval_ptr_dtor(&PG(http_globals)[i]); ZVAL_UNDEF(&PG(http_globals)[i]); ``` ข้อความที่ตัดตอนมาเหล่านี้แสดงหลักการสองประการ: **เริ่มต้นก่อนผู้บริโภคที่เร็วที่สุดเท่าที่จะเป็นไปได้ และดำเนินการล้างข้อมูลขั้นสุดท้ายหลังจากการดำเนินการครั้งล่าสุดที่อาจสร้างสถานะขึ้นใหม่** การรีเซ็ตตัวชี้เฉพาะระหว่าง RINIT ปกติหรือขั้นตอนการปิดระบบก่อนหน้านี้อาจพลาดการเข้าถึงก่อนหน้านี้หรือในภายหลัง [S5](https://keendigit.com/th/insights/php2shell-remediation-guide#source-5) ### 6.5 เหตุใดจึงไม่แนะนำให้ทำการ "ซ่อมแบบขั้นตอนเดียว" ด้วยตัวเอง? การแทนที่ `zend_bailout()` ทั้งหมดด้วย `_exit()` หรือเพียงแค่เพิ่มการตรวจสอบตัวชี้ null ในรายการบางรายการ จะขยายบริบทการดำเนินการที่แตกต่างกันจำนวนมาก พวกเขาอาจละเว้นช่องสถานะอื่นๆ หรืออาจเปลี่ยนการทำลาย การขยายการโทรกลับ ดำเนินการโฮสต์ และร้องขอความหมายการสิ้นสุด สำหรับเวอร์ชันที่รองรับ การแก้ไขแบบเต็มที่เผยแพร่ไปแล้วจะมีความสำคัญกว่า การโยกย้ายสาขาของตนเองควรบันทึกแหล่งที่มาของแพตช์ เส้นพื้นฐานที่เกี่ยวข้อง การจัดการข้อขัดแย้งและการเปลี่ยนแปลงพฤติกรรม และใช้กรณีการใช้งานการถดถอยต้นน้ำที่สอดคล้องกันและการตรวจสอบกระบวนการทางธุรกิจนี้ คำแนะนำนี้มาจากการวิเคราะห์ขอบเขตของแพตช์ระหว่างตัวจัดสรร, VM, เซสชันและการเปลี่ยนแปลงวงจรการใช้งานของคำขอ [S4](https://keendigit.com/th/insights/php2shell-remediation-guide#source-4)[S5](https://keendigit.com/th/insights/php2shell-remediation-guide#source-5) ## 7. backport ฉุกเฉินของ PHP 7.4, 8.0, 8.1 PHP จัดเตรียม backport ซอร์สโค้ดขั้นต่ำอย่างเป็นทางการของสามสาขาเก่าตามความรุนแรง ชื่อสาขาคือ: ```text PHP-7.4-CVE-2026-109618-109619 PHP-8.0-CVE-2026-109618-109619 PHP-8.1-CVE-2026-109618-109619 ``` สำหรับลิงก์สาขา โปรดดูที่ [S7](https://keendigit.com/th/insights/php2shell-remediation-guide#source-7)[S8](https://keendigit.com/th/insights/php2shell-remediation-guide#source-8)[S9](https://keendigit.com/th/insights/php2shell-remediation-guide#source-9) สิ่งเหล่านี้คือการส่งมอบฉุกเฉินสำหรับช่องโหว่นี้ และไม่ได้แสดงถึงการกลับมาสู่การสนับสนุนอัปสตรีมปกติสำหรับสาขาเก่า และไม่ได้แทนที่การอัปเดตความปลอดภัยอื่นๆ [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1) ### 7.1 ใช้แบ็คพอร์ต PHP 8.1 เป็นตัวอย่าง การส่งที่เกี่ยวข้องสำหรับ PHP 8.1 คือ: ```text 1d7dec178a094e6e75b229ce22754045f8c6070a ``` กลยุทธ์ของบริษัทเน้นที่ความล้มเหลวอย่างรวดเร็ว: การเรียก `_exit(1)` หลังจากส่งออกการวินิจฉัยในพาธ OOM ที่สอดคล้องกัน และรวมถึงสถานะส่วนกลางและการแก้ไขอื่นๆ ที่เกี่ยวข้อง ในขณะที่ปิดใช้งานการประมวลผลความคืบหน้าการอัปโหลดเซสชันที่เกี่ยวข้องภายใน สำหรับการส่งซอร์สโค้ดที่เกี่ยวข้อง โปรดดูที่ [S6](https://keendigit.com/th/insights/php2shell-remediation-guide#source-6) นี่คือความแตกต่างด้านพฤติกรรมจากการออกแบบ OOM ล่าช้าที่สมบูรณ์ยิ่งขึ้นในสาขาที่ได้รับการสนับสนุน เพียงเพราะการกำหนดค่ายังคงแสดงว่าความคืบหน้าในการอัปโหลดเปิดอยู่ ไม่ได้หมายความว่าลักษณะการประมวลผลภายในหลังจาก Backport นี้จะยังคงไม่เปลี่ยนแปลง ### 7.2 ราคาที่คุณต้องยอมรับเมื่อปรับใช้ การออกจากกระบวนการโดยตรงอาจทำให้คำขอปัจจุบันล้มเหลว โดยข้ามการเรียกกลับการปิดระบบ PHP ปกติและส่วนหนึ่งของการปิดแอปพลิเคชัน ถ้าโฮสต์ใช้โมเดลเธรด ก็จำเป็นต้องประเมินผลกระทบของการออกจากกระบวนการโฮสต์ทั้งหมดกับงานอื่นๆ ที่เกิดขึ้นพร้อมกัน ผู้จัดการกระบวนการสามารถดึงกระบวนการเปลี่ยนทดแทนได้ทันเวลาหรือไม่ ควรรวมอยู่ในการตรวจสอบด้วย ดังนั้นผู้ใช้เวอร์ชันเก่าควรพิจารณาตามลำดับ: 1. ย้ายไปยังสาขา PHP ที่รองรับและเวอร์ชันที่แก้ไขแล้ว 2. ใช้รุ่นที่ครอบคลุมทั้งการอัปเดตของผู้ผลิต CVE หรือ LTS อย่างชัดเจน 3. หากอยู่ภายใต้ซอร์สโค้ดเวอร์ชันเก่าจริงๆ ให้ใช้แบ็คพอร์ตฉุกเฉินอย่างเป็นทางการของเวอร์ชันที่ตรงกันเพื่อตรวจสอบการเปลี่ยนแปลงและความเข้ากันได้ทั้งหมด และจัดเตรียมการโยกย้ายในภายหลัง "backport ขั้นต่ำ" ในที่นี้อธิบายถึงความเข้ากันได้และขอบเขตการใช้งานที่ทางการเลือกไว้ และไม่ควรตีความโดยอัตโนมัติว่าเป็น "การแก้ไขช่องโหว่ที่ทราบว่าไม่สมบูรณ์" คุณควรตัดสินตามซอร์สโค้ดของสาขาที่เกี่ยวข้องและประกาศของผู้ผลิต และอย่าลบการเปลี่ยนแปลงที่รองรับด้วยตัวคุณเอง [S1](https://keendigit.com/th/insights/php2shell-remediation-guide#source-1)[S6](https://keendigit.com/th/insights/php2shell-remediation-guide#source-6) ## 8. เกณฑ์การยอมรับและการตรวจสอบติดตามผล ขอแนะนำให้ใช้ผลลัพธ์ต่อไปนี้เป็นพื้นฐานในการซ่อมแซมนี้: | รายการรับ | มาตรฐานความสําเร็จ | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | ความคุ้มครองช่องโหว่ | ประกาศเกี่ยวกับการสร้างหรือผู้จำหน่ายแก้ไข CVE-2026-109618 และ CVE-2026-109619 อย่างชัดเจน | | ความคุ้มครองการปรับใช้ | พอร์ทัล พูล บริการ และแบบจำลองทั้งหมดใช้รันไทม์ที่ได้รับการซ่อมแซม | | กระบวนการมีผลใช้บังคับ | ผู้ปฏิบัติงานเก่า กระบวนการโฮสต์เก่า และคอนเทนเนอร์เก่าทั้งหมดจะออกจากระบบ | | การตรวจสอบคำขอจริง | ยืนยัน SAPI แล้ว สร้างและกำหนดค่าด้วยลิงก์ Web จริงเพื่อกำจัดการนำแคชไปในทางที่ผิด | | ความพร้อมทางธุรกิจ | ฟังก์ชันหลักเช่นเซสชัน การอัปโหลด การนำเข้า และการจัดการข้อผิดพลาดกลับมาตามปกติ | | ยุติมาตรการชั่วคราว | หน่วยความจำไม่จำกัดและการกำหนดค่าการรีไซเคิลผู้ปฏิบัติงานระดับสูงได้รับการกู้คืนตามแผนความจุหรือมีเหตุผลที่ชัดเจนในการเก็บรักษา | | หลักฐานการเปลี่ยนแปลง | บันทึกเวอร์ชันแพ็คเกจหรือการแยกรูปภาพ ขอบเขตการอัปเดต เวลาที่เสร็จสมบูรณ์ และผลการตรวจสอบ | ข้างต้นเป็นข้อเสนอแนะในการดำเนินการ หากคุณต้องการตรวจสอบพฤติกรรมของ OOM ทางออกที่ผิดปกติ หรือแพตช์แบบกำหนดเอง คุณควรใช้การทดสอบการถดถอยอัปสตรีมหรือการฉีดข้อผิดพลาดแบบควบคุมในสภาพแวดล้อมแบบแยก เพื่อหลีกเลี่ยงการสร้างหน่วยความจำที่ไม่เพียงพอในสภาพแวดล้อมการผลิตซ้ำๆ เป็นวิธีการยอมรับ นอกจากนี้ ให้ตรวจสอบเหตุการณ์ร้ายแรงของ PHP, พนักงานขัดข้อง, การรีสตาร์ทที่ผิดปกติ, อัตราข้อผิดพลาดของคำขอ และเหตุการณ์ WAF ก่อนและหลังการอัปเดต บันทึกสามารถให้เบาะแสการสืบสวนเท่านั้น การเกิดขึ้นของ OOM ไม่ได้หมายความว่ามีการใช้ประโยชน์ และการไม่มีการแจ้งเตือนไม่ได้พิสูจน์ว่าไม่มีการใช้ประโยชน์เกิดขึ้น การอัพเกรดแก้ไขเส้นทางช่องโหว่ที่สามารถเข้าถึงได้ในอนาคต หากพบความผิดปกติ เช่น การงัดแงะไฟล์หรือการรั่วไหลของข้อมูลประจำตัว ควรดำเนินการตรวจสอบเหตุการณ์แยกต่างหาก ## ภาคผนวก: แหล่งอ้างอิงและลิงก์ ลิงค์แหล่งที่มาทั้งหมดรวบรวมไว้ด้านล่าง คำแนะนำ แพตช์ และคำแนะนำของผู้จำหน่ายสะท้อนถึงการตรวจสอบ ณ วันที่ **22 ตุลาคม 2026** การปรับใช้ครั้งต่อไปควรตรวจสอบการอัปเดตของผู้ขาย การอ้างอิงที่มีหมายเลขกำกับในข้อความอ้างอิงถึงรายการเหล่านี้ ### S1 — PHP กระดานข่าวความปลอดภัยอย่างเป็นทางการและเวอร์ชันการซ่อมแซม - ที่มา: โครงการ PHP, 21 ตุลาคม 2026 - วัตถุประสงค์: ขอบเขตความเสี่ยง เวอร์ชันการซ่อมแซมอย่างเป็นทางการ 4 เวอร์ชัน มาตรการชั่วคราวอย่างเป็นทางการ และคำแนะนำในการส่งกลับฉุกเฉินสำหรับสาขาเก่า - ลิงก์: [PHP 2026 This security bulletin](https://www.php.net/archive/2026.php#2026-10-21-5) อยู่ในคลังประกาศประจำปี ### S2 — CVE-2026-109618 กระดานข่าวทางเทคนิคอย่างเป็นทางการ - ที่มา: php/php-src GitHub Security Advisory, 21 ตุลาคม 2026 - การระบุ: GHSA-w8hw-w9fx-j79w - วัตถุประสงค์: ขอบเขตความครอบคลุมสำหรับ OOM, การขยายหลายส่วน, ความแตกต่าง SAPI และการบรรเทาผลกระทบ - ลิงค์: [RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) ### S3 — CVE-2026-109619 กระดานข่าวทางเทคนิคอย่างเป็นทางการ - ที่มา: php/php-src GitHub Security Advisory, 21 ตุลาคม 2026 - การระบุ: GHSA-6wmf-4rv5-p3rp - วัตถุประสงค์: สถานะห้อยต่องแต่งของคำขอข้าม ผู้ผลิตและผู้บริโภค การเริ่มต้นตั้งแต่เนิ่นๆ การลดการกำหนดค่า - ลิงค์: [RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) ### S4 — การส่งการแก้ไขอย่างเป็นทางการของ PHP 8.5 - ที่มา: php/php-src - ส่ง: `31c0ea7d7ff1d1fccb6492e52dab544011628065` - วัตถุประสงค์: ยืนยันการส่งอย่างเป็นทางการเพื่อแก้ไขช่องโหว่สองรายการพร้อมกัน และอธิบายทิศทางการเปลี่ยนแปลงโดยรวม - ลิงค์: [Avoid state corruption via bailout](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065) ### S5 — PHP 8.5 ได้รับการบูรณะอย่างเป็นทางการและความแตกต่างที่สมบูรณ์ - ที่มา: แตกต่างจากการส่งอย่างเป็นทางการฉบับเดียวกัน - วัตถุประสงค์: ตรวจสอบการใช้งานเฉพาะของตัวจัดสรร VM, HTTP globals เซสชัน การทำให้เป็นอนุกรม และวงจรชีวิตของคำขอ - ลิงค์: [official complete diff](https://github.com/php/php-src/commit/31c0ea7d7ff1d1fccb6492e52dab544011628065.diff) ### S6 — PHP 8.1 การส่งเอกสารแบ็คพอร์ตฉุกเฉินอย่างเป็นทางการ - ที่มา: php/php-src - ส่ง: `1d7dec178a094e6e75b229ce22754045f8c6070a` - วัตถุประสงค์: ตรวจสอบการออกจากสาขาเก่าอย่างรวดเร็วและอัปโหลดการเปลี่ยนแปลงพฤติกรรมความคืบหน้า - ลิงค์: [PHP 8.1 Emergency backport submission](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a) - ลิงค์: [corresponds to complete diff](https://github.com/php/php-src/commit/1d7dec178a094e6e75b229ce22754045f8c6070a.diff) ### S7 — PHP 7.4 สาขาแบ็คพอร์ตฉุกเฉินอย่างเป็นทางการ - แหล่งที่มา: สาขาซอร์สโค้ด php/php-src, PHP ที่ระบุไว้ในกระดานข่าวความปลอดภัยอย่างเป็นทางการ - ลิงค์: [PHP-7.4-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-109619) ### S8 — PHP 8.0 สาขาแบ็คพอร์ตฉุกเฉินอย่างเป็นทางการ - แหล่งที่มา: สาขาซอร์สโค้ด php/php-src, PHP ที่ระบุไว้ในกระดานข่าวความปลอดภัยอย่างเป็นทางการ - ลิงค์: [PHP-8.0-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.0-CVE-2026-109618-109619) ### S9 — PHP 8.1 สาขาแบ็คพอร์ตฉุกเฉินอย่างเป็นทางการ - แหล่งที่มา: สาขาซอร์สโค้ด php/php-src, PHP ที่ระบุไว้ในกระดานข่าวความปลอดภัยอย่างเป็นทางการ - ลิงค์: [PHP-8.1-CVE-2026-109618-109619](https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619) ### S10 — Ubuntu กระดานข่าวความปลอดภัย USN-8948-1 - ที่มา: Canonical / Ubuntu, 21 ตุลาคม 2026 - วัตถุประสงค์: เผยแพร่ backport และตัวอย่างเวอร์ชันแพ็คเกจที่สมบูรณ์ - ลิงค์: [USN-8948-1: PHP vulnerabilities](https://ubuntu.com/security/notices/USN-8948-1) ### S11 — คู่มือ PHP-FPM Configuration - ที่มา: เอกสารอย่างเป็นทางการของ PHP - วัตถุประสงค์: ซีแมนทิกส์การกำหนดค่า เช่น `php_admin_value`, `php_admin_flag`, `pm.max_requests` เป็นต้น - ลิงค์: [PHP-FPM Configuration](https://www.php.net/manual/en/install.fpm.configuration.php) ### S12 — คู่มือการกำหนดค่า PHP Core INI - ที่มา: เอกสารอย่างเป็นทางการของ PHP - วัตถุประสงค์: คำจำกัดความและขอบเขตของเนื้อหาคำขอ การอัปโหลด หน่วยความจำ และการกำหนดค่าการอ่าน POST อัตโนมัติ - ลิงค์: [Description of core php.ini directives](https://www.php.net/manual/en/ini.core.php) ### S13 — Nginx ร้องขอขีดจำกัดขนาดเนื้อหา - ที่มา: เอกสารอย่างเป็นทางการของ Nginx - วัตถุประสงค์: ความหมายของ `client_max_body_size` และระดับการกำหนดค่าที่ใช้ได้ - ลิงค์: [ngx\_http\_core\_module / client\_max\_body\_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) ### S14 — บัฟเฟอร์คำขอ Nginx FastCGI - ที่มา: เอกสารอย่างเป็นทางการของ Nginx - วัตถุประสงค์: ลำดับการประมวลผลและฟังก์ชันของ `fastcgi_request_buffering` - ลิงค์: [ngx\_http\_fastcgi\_module / fastcgi\_request\_buffering](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_request_buffering) ### S15 — Nginx สภาพสินค้าและคำแนะนำในการคืนสินค้า - ที่มา: เอกสารอย่างเป็นทางการของ Nginx - วัตถุประสงค์: ไวยากรณ์การกำหนดค่าของ `if` และ `return` - ลิงค์: [ngx\_http\_rewrite\_module](https://nginx.org/en/docs/http/ngx_http_rewrite_module.html#if) ### S16 — คำแนะนำในการป้องกัน Cloudflare PHP2Shell - ที่มา: บล็อกอย่างเป็นทางการของ Cloudflare - วัตถุประสงค์: คำอธิบายขอบเขตการใช้งาน WAF, การจัดเตรียมแผน Free และกลไกการตรวจจับ - ลิงค์: [Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/) ## ให้คำปรึกษาด้านการรักษาความปลอดภัย ต้องการความช่วยเหลือในการอัปเดตระบบ PHP ของคุณหรือไม่? เราสามารถประเมินความเสี่ยง วางแผนการอัปเดต และตรวจสอบแอปพลิเคชันที่ทำงานอยู่ [หารือเกี่ยวกับการอัปเดตความปลอดภัย]() [หน้าเดิม]() · [ดัชนีเนื้อหา]() KeenDigit LLC · รหัสการยื่นไวโอมิง: 2026-002106155 [ตรวจสอบกับรัฐมนตรีต่างประเทศไวโอมิง]() © 2026 KeenDigit LLC · เชอริแดน ไวโอมิง สหรัฐอเมริกา · สงวนลิขสิทธิ์.