PHP2Shell: สาเหตุและแนวทางการแก้ไข

แหล่งที่มาได้รับการตรวจสอบ ณ วันที่ 22 ตุลาคม 2026 Audience: ตัวดำเนินการแอปพลิเคชัน PHP, ระบบตอบสนองด้านความปลอดภัย และวิศวกรที่ดูแลสร้าง PHP แบบกำหนดเอง

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

TL;DR: ขั้นตอนการซ่อมและคำแนะนำ

อัปเกรดรันไทม์ PHP: อัปเกรดสาขาที่เกี่ยวข้องเป็นอย่างน้อย 8.2.35, 8.3.36, 8.4.27 หรือ 8.5.12 สำหรับแพ็คเกจการแจกจ่าย ใช้เวอร์ชันแพ็คเกจที่สมบูรณ์ซึ่งผู้จำหน่ายยืนยันการแก้ไข CVE ทั้งสอง S1 S10
แทนที่กระบวนการเก่าทั้งหมด: รีสตาร์ทหรือโรลโอเวอร์ทุก PHP worker บริการโฮสติ้ง และคอนเทนเนอร์หลังจากอัปเกรด และยืนยันว่าอินสแตนซ์เก่าได้ออกแล้ว
ตรวจสอบผ่านเส้นทางคำขอ Web จริง: ตรวจสอบ Web SAPI เวอร์ชันแพ็คเกจเต็ม และอินสแตนซ์ที่กำลังทำงานอยู่ การตรวจสอบ php -v เพียงอย่างเดียวไม่ได้แสดงว่าบริการสดได้รับการแก้ไขแล้ว
เรียกใช้การตรวจสอบการถดถอยทางธุรกิจและกู้คืนงบประมาณทรัพยากรปกติ: ทดสอบการเข้าสู่ระบบ การจัดการเซสชัน การอัปโหลด การนำเข้า และการจัดการข้อผิดพลาด หากขีดจำกัดหน่วยความจำ PHP ถูกลบออกชั่วคราว ให้เรียกคืนงบประมาณจำกัดที่เหมาะสมหลังจากการแพตช์
หากการอัพเกรดทันทีเป็นไปไม่ได้: จำกัดการรับส่งข้อมูลที่ไม่น่าเชื่อถือก่อนที่จะถึง PHP ประเมินการปิดใช้งานความคืบหน้าในการอัปโหลดและ Backtraces ร้ายแรงของ PHP 8.5 ตามที่อธิบายไว้ในส่วน 5 การบรรเทาการกำหนดค่าและกฎ WAF มีความครอบคลุมที่จำกัด และไม่สามารถแทนที่การอัพเกรดได้ S1 S2 S3

1. ภาพรวมช่องโหว่และการตัดสินความเสี่ยง

PHP2Shell ในบทความนี้อ้างถึงช่องโหว่ระดับ Critical สองช่องโหว่ที่เปิดเผยอย่างเป็นทางการโดย PHP เมื่อวันที่ 21 ตุลาคม 2026 ทั้งสองช่องโหว่เกี่ยวข้องกับการจัดการวงจรการใช้งานหน่วยความจำและคำขอของกลไก PHP ซึ่งก่อให้เกิดความเสี่ยงของการเรียกใช้โค้ดจากระยะไกลโดยไม่ได้รับอนุญาต S1 S2 S3

โครงการ	CVE-2026-109618	CVE-2026-109619
ชื่ออย่างเป็นทางการ	RCE via OOM corruption	RCE via stale global state
ประเด็นหลัก	หน่วยความจำไม่เพียงพอทำให้เกิดการกระโดดที่ผิดปกติ ออกจากสถานะที่ยังไม่เสร็จสิ้นการเตรียมใช้งาน	สถานะโกลบอลที่เหลืออยู่ในผู้ปฏิบัติงานชี้ไปที่หน่วยความจำคำขอที่เผยแพร่
เวลาที่เกิดขึ้นโดยทั่วไป	การเริ่มต้น การดำเนินการ หรือการล้างข้อมูลของคำขอปัจจุบัน	คำขอก่อนหน้าจะออกจากสถานะ และคำขอที่ตามมาจะใช้สถานะนั้นล่วงหน้า
OOM เป็นเงื่อนไขที่จำเป็นหรือไม่?	เป็นของกลไกการกระตุ้นหลักของช่องโหว่	ไม่; ข้อผิดพลาดร้ายแรงอื่น ๆ และการล้างข้อมูลหลังการวินิจฉัยอาจเกี่ยวข้องด้วย
ทิศทางการซ่อมแซมขั้นพื้นฐาน	จัดการความล้มเหลวในการจัดสรรอย่างปลอดภัยและการยุติคำขอ	แก้ไขความเป็นเจ้าของของรัฐ กำหนดเวลาการล้างข้อมูล และการเริ่มต้นใช้งานล่วงหน้า
ข้อกำหนดในการกำจัด	จะต้องได้รับการซ่อมแซม	ต้องซ่อมแซมไปพร้อมๆ กัน

พื้นฐาน: กระดานข่าวความปลอดภัยอย่างเป็นทางการสองรายการและการส่งการแก้ไข S2 S3 S4

1.1 ทำความเข้าใจการปรับใช้ที่ได้รับผลกระทบ

PHP พิจารณาอย่างเป็นทางการ ทั้งหมด PHP การจัดการการปรับใช้ Web คำขอ ที่มีความเสี่ยงได้แก่ PHP-FPM , Apache mod_php , php-cgi , FrankenPHP , และ LiteSpeed . ที่แสดงให้เห็น mod_php การโจมตีสามารถเกิดขึ้นได้ก่อนที่โค้ดของแอปพลิเคชันจะทำงาน ดังนั้นการตรวจสอบการเข้าสู่ระบบ มิดเดิลแวร์ของเฟรมเวิร์ก และการตรวจสอบความถูกต้องของการอัปโหลดแอปพลิเคชันจึงไม่ครอบคลุมเส้นทางนั้น S1

จำเป็นต้องแยกแยะระหว่าง “การปรับใช้งานจำเป็นต้องได้รับการแก้ไข” และ “ห่วงโซ่การโจมตีบางอย่างได้รับการพิสูจน์แล้วอย่างสมบูรณ์” การประกาศของ CVE-2026-109618: FPM จะออกจากกระบวนการลูกหลังจากการเริ่มต้นคำขอล้มเหลว โดยบล็อกเส้นทางการล้างข้อมูลที่สอดคล้องกันของ mod_php หลังจากการเริ่มต้นล้มเหลว อย่างไรก็ตาม เส้นทาง OOM หลังจากการเริ่มทำงานสำเร็จแล้วยังคงมีความเสี่ยง การประกาศยังตั้งข้อสังเกตอีกว่าการใช้ประโยชน์จาก FPM เต็มรูปแบบสำหรับ CVE นี้ยังไม่ได้แสดงให้เห็น ข้อจำกัดนี้ไม่สามารถใช้เพื่ออนุมานว่า FPM ปลอดภัย โดยเฉพาะอย่างยิ่ง CVE-2026-109619 ไม่สามารถละเลยได้ S2 S3

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

สคริปต์ CLI แบบครั้งเดียวทั่วไปไม่มีรายการ HTTP เหมือนกัน แต่กระบวนการที่จัดการงานภายนอกเป็นเวลานานใน CLI หรือโหมดแบบฝังควรยังคงรวมอยู่ในสินค้าคงคลังรันไทม์และวงจรชีวิต เฉพาะการพึ่งพา CMS, เฟรมเวิร์ก หรือ Composer เท่านั้นที่ได้รับการอัปเดต และกลไก PHP พื้นฐานจะไม่ถูกแทนที่โดยอัตโนมัติ

2. การวิเคราะห์สาเหตุ

2.1 ทำความเข้าใจวงจรชีวิตทั้งสองก่อน

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

ดังนั้นเครื่องยนต์จึงต้องรักษาข้อจำกัดไว้ 2 ประการ:

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

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

2.2 CVE-2026-109618: OOM ขัดจังหวะการอัปเดตสถานะที่ยังไม่เสร็จสิ้น

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

กระบวนการล้มเหลวสามารถแบ่งออกเป็นสี่ขั้นตอน:

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

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

เหตุใดคำขอขนาดเล็กจึงทำให้หน่วยความจำไม่เพียงพอ

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

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

สามารถสรุปข้อสรุปการป้องกันได้สองประการ:

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

เหตุใดการรับรองความถูกต้องของแอปพลิเคชันจึงอาจล่าช้าเกินไป

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

2.3 CVE-2026-109619: หน่วยความจำคำขอได้รับการเผยแพร่แล้ว การอ้างอิงทั่วโลกยังคงอยู่

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

การวิเคราะห์อย่างเป็นทางการแบ่งเงื่อนไขการแสวงหาผลประโยชน์ออกเป็น “ผู้ผลิต” และ “ผู้บริโภค”:

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

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

ไม่จำเป็นต้องใช้ OOM เป็นข้อกำหนดเบื้องต้นที่จำเป็น

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

ดังนั้นการเปลี่ยน memory_limit เป็นไม่จำกัดจึงไม่ครอบคลุมชุดช่องโหว่นี้

”ก่อนการเริ่มต้น” จะต้องได้รับการปฏิบัติแยกกัน

ระยะเวลาของผู้บริโภคที่ได้รับการยืนยันทั้งสองประเภทจะแตกต่างกัน:

Early INI Diagnostics: การกำหนดค่าบางอย่างใช้กับคำเตือนปัญหาคำขอ การแจ้งให้ทราบ หรือการเลิกใช้งานก่อนการเตรียมใช้งานตัวดำเนินการปกติ และการประมวลผลการวินิจฉัยอาจเข้าถึงสถานะข้อผิดพลาดเก่า
ความคืบหน้าการอัปโหลดเซสชัน: เซสชันอาจถูกประมวลผลล่วงหน้าในระหว่างกระบวนการแยกวิเคราะห์คำขอ แต่โมดูลปกติ RINIT ยังไม่เสร็จสมบูรณ์ ไม่สามารถอนุมานได้ว่าไม่มีเส้นทางอยู่เนื่องจากแอปพลิเคชันไม่ได้เรียก session_start() อย่างชัดเจน S3

การกำหนดค่า INI ไม่ใช่ทั้งหมดที่มีกำหนดเวลาความเสี่ยงเท่ากัน การกำหนดค่าระดับไดเร็กทอรีของ mod_php และ PHP_VALUE / PHP_ADMIN_VALUE ที่ส่งผ่านโดย FPM front-end จำเป็นต้องแยกความแตกต่างจากการกำหนดค่าการเริ่มต้น php.ini, FPM pool ทั่วไป และ FPM .user.ini ส่วนหลังมีกำหนดเวลาการกำหนดค่าที่แตกต่างกันและไม่สามารถเรียกรวมกันว่าผู้บริโภคในยุคแรกเดียวกันได้ S3

การปิด display_errors, log_errors การลด error_reporting หรือใช้ @ จะส่งผลต่อการมองเห็นการวินิจฉัยเท่านั้น อาจเข้าถึงสถานะภายในที่เกี่ยวข้องก่อนที่จะตัดสินใจว่าจะส่งออกบันทึกหรือไม่ S3

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

สิ่งเหล่านี้คือ เกณฑ์เวอร์ชันที่แก้ไขแล้วสำหรับแต่ละสาขา ไม่สามารถแทนที่ด้วยคำสั่งที่ว่าทุกเวอร์ชันที่ต่ำกว่า 8.5.12 มีความเสี่ยง: เวอร์ชันเช่น 8.2.35 และ 8.4.27 ในสาขาอื่นมีการแก้ไขอยู่แล้ว

3.2 ตรวจสอบเวอร์ชันแพ็คเกจการแจกจ่ายแบบเต็ม

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

ตัวอย่างเช่น เวอร์ชันแพ็กเกจโปรแกรมแก้ไข Ubuntu 24.04 LTS ที่แสดงสำหรับ Ubuntu USN-8948-1 คือ:

8.3.6-0ubuntu0.24.04.13

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

3.3 การเลือกแพทช์ที่เหมาะสม

ฉาก	แผนลำดับความสำคัญ	ประเด็นสำคัญสำหรับการยอมรับ
การใช้แพ็คเกจการแจกจ่าย PHP	ติดตั้งการอัปเดตความปลอดภัยที่เผยแพร่โดยผู้ผลิต	ประกาศครอบคลุมทั้ง CVE; เวอร์ชันแพ็คเกจที่สมบูรณ์นั้นถูกต้อง
ใช้คอนเทนเนอร์ PHP อย่างเป็นทางการหรืออิมเมจที่สร้างขึ้นเอง	อัปเดตรันไทม์พื้นฐาน สร้างใหม่ และปรับใช้	อินสแตนซ์ที่ทำงานอยู่จะใช้อิมเมจใหม่ สำเนาเก่าทั้งหมดจะออกแล้ว
สาขาที่รองรับที่รวบรวมเอง	ใช้เวอร์ชันความปลอดภัยอย่างเป็นทางการของสาขานี้หรือชุดแพทช์อย่างเป็นทางการแบบเต็ม	การจับคู่สาขา การพึ่งพาให้สมบูรณ์ ความเข้ากันได้ของส่วนขยาย และการผ่านการถดถอย
ขึ้นอยู่กับ 7.4, 8.0, 8.1	จัดลำดับความสำคัญของ backport ของผู้ขาย ประเมินสาขารหัสต้นทางเหตุฉุกเฉินอย่างเป็นทางการหากจำเป็น	ระบุการเปลี่ยนแปลงพฤติกรรมและกำหนดเวลาการโยกย้ายไปยังเวอร์ชันที่รองรับ

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

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 S2 S3

5.1 จัดลำดับความสำคัญการควบคุมการรับส่งข้อมูลก่อน PHP

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

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

เทมเพลตการกำหนดค่า 5.2 FPM pool

วางการตั้งค่าต่อไปนี้ในส่วนการกำหนดค่า FPM pool ที่ให้บริการการร้องขอ จริง ไม่ใช่คำต่อคำใน php.ini ค่า 8M และ 4M เป็นตัวอย่างในการปรับให้เข้ากับปริมาณงาน เว้นที่ว่างไว้สำหรับฟิลด์แบบฟอร์มและขอบเขตหลายส่วนเมื่อจำกัดคำขอ POST ทั้งหมด S11 S12

; 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 เท่านั้น บวก:

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 S2 S3 S11

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

หากคุณเลือกที่จะแก้ไข php.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 S12

เพิ่ม fatal_error_backtraces = Off สำหรับ PHP 8.5 เท่านั้น อย่าใช้ ini_set() ระดับแอปพลิเคชันเป็นวิธีแก้ปัญหาชั่วคราวในการปิดใช้งานความคืบหน้าในการอัปโหลด และอย่าพึ่งพา FPM .user.ini เพื่อให้มีประสิทธิภาพก่อนที่จะขอการแยกวิเคราะห์ S1 S3

5.3 จัดการค่าใช้จ่ายในการลบขีดจำกัดหน่วยความจำ PHP

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

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

อย่าแทนที่กลยุทธ์ข้างต้นด้วย RLIMIT_AS, RLIMIT_DATA หรือข้อจำกัดพื้นที่ที่อยู่กระบวนการที่เกี่ยวข้อง พวกเขาอาจทำให้การจัดสรรพื้นฐานล้มเหลวโดยตรงในเส้นทาง OOM ที่ยังคงมีปัญหา S2

ตัวอย่างการกำหนดค่า 5.4 Nginx

ใช้ได้กับการปรับใช้งานโดยที่ Nginx ส่งต่อคำขอไปยัง PHP-FPM สามารถตั้งค่าได้ที่ระดับการกำหนดค่าของบริการโฮสติ้งจริง:

client_max_body_size 8m;
fastcgi_request_buffering on;

client_max_body_size จำกัดขนาดเนื้อหาคำขอ fastcgi_request_buffering on อนุญาตให้ Nginx อ่านเนื้อหาคำขอที่สมบูรณ์ก่อน จากนั้นจึงส่งไปที่แบ็กเอนด์ FastCGI ไม่ว่าจะมีผลบังคับใช้ใน server หรือ location บางอย่างจำเป็นต้องได้รับการตรวจสอบร่วมกับความสัมพันธ์ของการสืบทอดและความคุ้มครองที่มีอยู่ S13 S14

เฉพาะเมื่อธุรกิจไม่ต้องการหลายส่วน คุณสามารถเพิ่มกฎการปฏิเสธไปยังทางเข้าบริการที่เกี่ยวข้อง:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

นี่เป็นเทมเพลตข้อจำกัดรายการแบบง่ายที่ใช้ if และ return ไม่ใช่กฎการกรองทั่วไปสำหรับช่องโหว่ของ Parser ตรวจสอบไวยากรณ์การกำหนดค่าและคำขอปกติก่อนใช้งาน และตรวจสอบว่า error_page แบบกำหนดเองเปลี่ยนเส้นทางคำขอ 403 ไปยัง PHP หรือไม่ การจับคู่สตริงไม่ได้ให้การรับประกันที่สมบูรณ์สำหรับความแตกต่างในการแยกวิเคราะห์ทั้งหมด S15

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

5.5 การลดหย่อนทางเลือก: หนึ่งคำขอต่อผู้ปฏิบัติงาน FPM

สำหรับการปรับใช้ FPM ที่สามารถจ่ายค่าใช้จ่ายได้ การตั้งค่าระยะสั้นสามารถประเมินได้:

pm.max_requests = 1

และสร้างคนงานที่มีอยู่ขึ้นมาใหม่ จะบล็อกห่วงโซ่คำขอข้ามที่อธิบายไว้ที่ระดับการใช้ซ้ำของผู้ปฏิบัติงาน แต่จะเพิ่มค่าใช้จ่ายในการสร้างกระบวนการและการเริ่มต้น ในเวลาเดียวกัน ไม่สามารถซ่อมแซมคำขอเดียวกัน OOM และปัญหาการล้างข้อมูลของ CVE-2026-109618 ได้ เมื่อค่าน้อยกว่าแต่มากกว่า 1 ก็ยังคงมีหน้าต่างคำขอใช้ซ้ำ S3 S11

ขีดจำกัดความครอบคลุม 5.6 WAF และ Cloudflare

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

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

5.7 ทำไมมาตรการทั่วไปจึงไม่เพียงพอ

มาตรการหรือการตัดสิน	ข้อบกพร่อง
ปิดเฉพาะ `file_uploads`	ไม่สามารถครอบคลุมการประมวลผลหลายส่วนทั้งหมดและใช้เส้นทาง OOM ของตัวเอง
การตั้งค่า `enable_post_data_reading=Off`	เปลี่ยนพฤติกรรมการเติม POST/FILES โดยอัตโนมัติ แอปพลิเคชันยังสามารถอ่านเนื้อหาคำขอได้และอาจขัดขวางการดำเนินธุรกิจตามปกติ
ปิดการแสดงข้อผิดพลาด บันทึก หรือใช้ `@`	การประมวลผลการวินิจฉัยภายในอาจยังคงเข้าถึงสถานะห้อยต่องแต่ง
เพิ่มปริมาณคนงาน	อย่าสร้างกลไกการล้างสถานะที่ปลอดภัย หรือกำจัดการใช้ซ้ำของผู้ปฏิบัติงานคนเดียว
กำหนดค่าเฉพาะ `disable_functions` หรือ `open_basedir`	ข้อจำกัดเหล่านี้ไม่สามารถแก้ไขความเสียหายของหน่วยความจำชั้นกลไก C ได้
ตรวจสอบเวอร์ชันหรือสำเนาเดียวเพียงครั้งเดียว	ไม่สามารถพิสูจน์ได้ว่าทางเข้าและอินสแตนซ์ที่ทำงานอยู่ทั้งหมดถูกแทนที่แล้ว
ไม่เห็นบันทึกข้อยกเว้น	ไม่สามารถพิสูจน์ได้ว่าไม่มีช่องโหว่หรือไม่เคยถูกโจมตีมาก่อน

ในหมู่พวกเขาพื้นฐานกลไกการกำหนดค่าและช่องโหว่ของ PHP สามารถพบได้ใน S2 S3 S12 การตัดสินเกี่ยวกับขอบเขตความครอบคลุม การยอมรับ และการอนุญาตจะขึ้นอยู่กับข้อเสนอแนะในการดำเนินการที่นำเสนอโดยกลไกเหล่านี้

6. แนวคิดในการนำไปปฏิบัติและจุดตรวจสอบของแพทช์อย่างเป็นทางการ

6.1 ใช้การแก้ไขที่สมบูรณ์สำหรับสาขาที่ถูกต้อง

การส่งตัวแทนอย่างเป็นทางการสำหรับ PHP 8.5 คือ:

31c0ea7d7ff1d1fccb6492e52dab544011628065
Avoid state corruption via bailout

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

การซ่อมแซม 6.2 OOM: กู้คืนสถานะที่ประมวลผลได้ก่อน จากนั้นจึงยุติคำขอ

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

ต่อไปนี้เป็นข้อความที่ตัดตอนมาจากรหัสคีย์ในส่วนต่าง 8.5 ที่ใช้เพื่อทำเครื่องหมายว่าอยู่ระหว่างดำเนินการ OOM:

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

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

และไม่สามารถสรุปได้ว่า “PHP ได้ลบ zend_bailout() ทั้งหมดแล้ว” โปรแกรมแก้ไขยังคงใช้กลไกที่เกี่ยวข้องในบริบทเฉพาะ สิ่งที่ได้รับการแก้ไขคือจังหวะเวลาทางออกที่เป็นอันตรายและการจัดการของรัฐที่เกี่ยวข้อง S5

6.3 อัปเดตผู้เรียกการจัดสรรและการแยกวิเคราะห์หลายส่วนพร้อมกัน

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

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

สำหรับทีมที่ดูแลสาขาของตนเอง ขอแนะนำให้ประเด็นต่อไปนี้เป็นจุดเน้นของการตรวจสอบโค้ด:

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

คำถามเหล่านี้เป็นคำถามทบทวนที่สรุปตามกลไกการแก้ไข และไม่ใช่ข้อสรุปของการตรวจสอบที่เสร็จสมบูรณ์แล้วสำหรับฐานรหัสที่ไม่มีให้

การแก้ไขคำขอข้าม 6.4: การเริ่มต้นก่อนหน้านี้ การล้างข้อมูลครั้งสุดท้ายในภายหลัง

สอดคล้องกับ CVE-2026-109619 แพตช์จะปรับขอบเขตวงจรชีวิตหลายรายการพร้อมกัน ไฟล์และการดำเนินการที่แสดงด้านล่างใช้ PHP 8.5 อย่างเป็นทางการที่แตกต่างกันเป็นตัวอย่าง S5

ที่ตั้ง	เปลี่ยนทิศทาง	แก้ไขปัญหาแล้ว
`Zend/zend_execute_API.c` ฯลฯ	รีเซ็ตสถานะของตัวดำเนินการ เช่น ข้อผิดพลาด ข้อยกเว้น ตัวจัดการ วัตถุ ฯลฯ	หลังจากที่คำขอสิ้นสุดลง ก็ยังมีข้อมูลอ้างอิงเก่าๆ ที่สามารถเข้าถึงได้ในคำขอถัดไป
เส้นทางเริ่มต้นของ `main/main.c`	โทร `php_basic_early_rinit()` ก่อนเปิดใช้งาน SAPI	เมื่อผู้บริโภคในยุคแรกเกิดขึ้น สถานะที่เกี่ยวข้องยังไม่ได้รับการเตรียมใช้งาน
ปิดเส้นทางของ `main/main.c`	ทำลาย HTTP globals และทำเครื่องหมายเป็นไม่ได้กำหนด	ค่าที่นำออกใช้ยังถือว่าเป็นออบเจ็กต์ที่ถูกต้อง
ก่อนที่คำขอฮีปจะถูกปลดปล่อยในที่สุด	ล้างข้อความแสดงข้อผิดพลาดล่าสุดอีกครั้ง	การวินิจฉัยการล้างข้อมูลล่าช้า repopulate สถานะข้อผิดพลาด
`ext/session/session.c`	ความคืบหน้าในการอัปโหลด เส้นทางเริ่มต้นจะเริ่มต้นได้ทั่วโลกเซสชันแรก	โมดูลปกติ RINIT เข้าถึงสถานะเก่าก่อนหน้านี้
รหัสที่เกี่ยวข้องกับการทำให้เป็นอนุกรม	จำกัดการแยกวิเคราะห์คลาสและการเรียกกลับของผู้ใช้ในการประมวลผลเบื้องต้น	รันโค้ดผู้ใช้เพิ่มเติมเมื่อการกำหนดค่าเริ่มต้นไม่เสร็จสมบูรณ์

ตัวอย่างเช่น ลำดับการเริ่มต้นระบบประกอบด้วย:

zend_activate();
php_basic_early_rinit();
sapi_activate();

หลังจากที่ HTTP globals ถูกทำลาย ให้เพิ่มเครื่องหมายสถานะล้มเหลว:

zval_ptr_dtor(&PG(http_globals)[i]);
ZVAL_UNDEF(&PG(http_globals)[i]);

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

6.5 เหตุใดจึงไม่แนะนำให้ทำการ “ซ่อมแบบขั้นตอนเดียว” ด้วยตัวเอง?

การแทนที่ zend_bailout() ทั้งหมดด้วย _exit() หรือเพียงแค่เพิ่มการตรวจสอบตัวชี้ null ในรายการบางรายการ จะขยายบริบทการดำเนินการที่แตกต่างกันจำนวนมาก พวกเขาอาจละเว้นช่องสถานะอื่นๆ หรืออาจเปลี่ยนการทำลาย การขยายการโทรกลับ ดำเนินการโฮสต์ และร้องขอความหมายการสิ้นสุด

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

7. backport ฉุกเฉินของ PHP 7.4, 8.0, 8.1

PHP จัดเตรียม backport ซอร์สโค้ดขั้นต่ำอย่างเป็นทางการของสามสาขาเก่าตามความรุนแรง ชื่อสาขาคือ:

PHP-7.4-CVE-2026-109618-109619
PHP-8.0-CVE-2026-109618-109619
PHP-8.1-CVE-2026-109618-109619

สำหรับลิงก์สาขา โปรดดูที่ S7 S8 S9 สิ่งเหล่านี้คือการส่งมอบฉุกเฉินสำหรับช่องโหว่นี้ และไม่ได้แสดงถึงการกลับมาสู่การสนับสนุนอัปสตรีมปกติสำหรับสาขาเก่า และไม่ได้แทนที่การอัปเดตความปลอดภัยอื่นๆ S1

7.1 ใช้แบ็คพอร์ต PHP 8.1 เป็นตัวอย่าง

การส่งที่เกี่ยวข้องสำหรับ PHP 8.1 คือ:

1d7dec178a094e6e75b229ce22754045f8c6070a

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

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

7.2 ราคาที่คุณต้องยอมรับเมื่อปรับใช้

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

ดังนั้นผู้ใช้เวอร์ชันเก่าควรพิจารณาตามลำดับ:

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

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

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 อยู่ในคลังประกาศประจำปี

S2 — CVE-2026-109618 กระดานข่าวทางเทคนิคอย่างเป็นทางการ

ที่มา: php/php-src GitHub Security Advisory, 21 ตุลาคม 2026
การระบุ: GHSA-w8hw-w9fx-j79w
วัตถุประสงค์: ขอบเขตความครอบคลุมสำหรับ OOM, การขยายหลายส่วน, ความแตกต่าง SAPI และการบรรเทาผลกระทบ
ลิงค์: RCE via OOM corruption

S3 — CVE-2026-109619 กระดานข่าวทางเทคนิคอย่างเป็นทางการ

ที่มา: php/php-src GitHub Security Advisory, 21 ตุลาคม 2026
การระบุ: GHSA-6wmf-4rv5-p3rp
วัตถุประสงค์: สถานะห้อยต่องแต่งของคำขอข้าม ผู้ผลิตและผู้บริโภค การเริ่มต้นตั้งแต่เนิ่นๆ การลดการกำหนดค่า
ลิงค์: RCE via stale global state

S4 — การส่งการแก้ไขอย่างเป็นทางการของ PHP 8.5

ที่มา: php/php-src
ส่ง: 31c0ea7d7ff1d1fccb6492e52dab544011628065
วัตถุประสงค์: ยืนยันการส่งอย่างเป็นทางการเพื่อแก้ไขช่องโหว่สองรายการพร้อมกัน และอธิบายทิศทางการเปลี่ยนแปลงโดยรวม
ลิงค์: Avoid state corruption via bailout

S5 — PHP 8.5 ได้รับการบูรณะอย่างเป็นทางการและความแตกต่างที่สมบูรณ์

ที่มา: แตกต่างจากการส่งอย่างเป็นทางการฉบับเดียวกัน
วัตถุประสงค์: ตรวจสอบการใช้งานเฉพาะของตัวจัดสรร VM, HTTP globals เซสชัน การทำให้เป็นอนุกรม และวงจรชีวิตของคำขอ
ลิงค์: official complete diff

S6 — PHP 8.1 การส่งเอกสารแบ็คพอร์ตฉุกเฉินอย่างเป็นทางการ

ที่มา: php/php-src
ส่ง: 1d7dec178a094e6e75b229ce22754045f8c6070a
วัตถุประสงค์: ตรวจสอบการออกจากสาขาเก่าอย่างรวดเร็วและอัปโหลดการเปลี่ยนแปลงพฤติกรรมความคืบหน้า
ลิงค์: PHP 8.1 Emergency backport submission
ลิงค์: corresponds to complete diff

S7 — PHP 7.4 สาขาแบ็คพอร์ตฉุกเฉินอย่างเป็นทางการ

แหล่งที่มา: สาขาซอร์สโค้ด php/php-src, PHP ที่ระบุไว้ในกระดานข่าวความปลอดภัยอย่างเป็นทางการ
ลิงค์: PHP-7.4-CVE-2026-109618-109619

S8 — PHP 8.0 สาขาแบ็คพอร์ตฉุกเฉินอย่างเป็นทางการ

แหล่งที่มา: สาขาซอร์สโค้ด php/php-src, PHP ที่ระบุไว้ในกระดานข่าวความปลอดภัยอย่างเป็นทางการ
ลิงค์: PHP-8.0-CVE-2026-109618-109619

S9 — PHP 8.1 สาขาแบ็คพอร์ตฉุกเฉินอย่างเป็นทางการ

แหล่งที่มา: สาขาซอร์สโค้ด php/php-src, PHP ที่ระบุไว้ในกระดานข่าวความปลอดภัยอย่างเป็นทางการ
ลิงค์: PHP-8.1-CVE-2026-109618-109619

S10 — Ubuntu กระดานข่าวความปลอดภัย USN-8948-1

ที่มา: Canonical / Ubuntu, 21 ตุลาคม 2026
วัตถุประสงค์: เผยแพร่ backport และตัวอย่างเวอร์ชันแพ็คเกจที่สมบูรณ์
ลิงค์: USN-8948-1: PHP vulnerabilities

S11 — คู่มือ PHP-FPM Configuration

ที่มา: เอกสารอย่างเป็นทางการของ PHP
วัตถุประสงค์: ซีแมนทิกส์การกำหนดค่า เช่น php_admin_value, php_admin_flag, pm.max_requests เป็นต้น
ลิงค์: PHP-FPM Configuration

S12 — คู่มือการกำหนดค่า PHP Core INI

ที่มา: เอกสารอย่างเป็นทางการของ PHP
วัตถุประสงค์: คำจำกัดความและขอบเขตของเนื้อหาคำขอ การอัปโหลด หน่วยความจำ และการกำหนดค่าการอ่าน POST อัตโนมัติ
ลิงค์: Description of core php.ini directives

S13 — Nginx ร้องขอขีดจำกัดขนาดเนื้อหา

ที่มา: เอกสารอย่างเป็นทางการของ Nginx
วัตถุประสงค์: ความหมายของ client_max_body_size และระดับการกำหนดค่าที่ใช้ได้
ลิงค์: ngx_http_core_module / client_max_body_size

S14 — บัฟเฟอร์คำขอ Nginx FastCGI

ที่มา: เอกสารอย่างเป็นทางการของ Nginx
วัตถุประสงค์: ลำดับการประมวลผลและฟังก์ชันของ fastcgi_request_buffering
ลิงค์: ngx_http_fastcgi_module / fastcgi_request_buffering

S15 — Nginx สภาพสินค้าและคำแนะนำในการคืนสินค้า

ที่มา: เอกสารอย่างเป็นทางการของ Nginx
วัตถุประสงค์: ไวยากรณ์การกำหนดค่าของ if และ return
ลิงค์: ngx_http_rewrite_module

S16 — คำแนะนำในการป้องกัน Cloudflare PHP2Shell

ที่มา: บล็อกอย่างเป็นทางการของ Cloudflare
วัตถุประสงค์: คำอธิบายขอบเขตการใช้งาน WAF, การจัดเตรียมแผน Free และกลไกการตรวจจับ
ลิงค์: Cloudflare deploys protections against php2shell vulnerability