ThaiCERT ขอแนะนำหน่วยงานเร่งตรวจสอบและอัปเดต PHP ให้ครอบคลุมทุกระบบ เพื่อลดความเสี่ยงจากช่องโหว่ PHP2Shell - Thailand Computer Emergency Response Team (ThaiCERT)

เนื่องจากช่องโหว่ PHP2Shell เกิดขึ้นใน PHP ซึ่งเป็นองค์ประกอบพื้นฐานที่ใช้ประมวลผลเว็บไซต์และระบบสารสนเทศอย่างแพร่หลาย จึงอาจส่งผลกระทบต่อระบบหลายประเภท และเปิดโอกาสให้ผู้โจมตีสั่งรันโค้ดจากระยะไกลโดยไม่ต้องยืนยันตัวตน ทั้งนี้ ความสำเร็จของการโจมตีขึ้นอยู่กับรูปแบบการติดตั้ง การตั้งค่า และเงื่อนไขของแต่ละระบบ เพื่อสนับสนุนให้หน่วยงานสามารถตรวจสอบและแก้ไขได้อย่างครอบคลุม ศูนย์ประสานการรักษาความมั่นคงปลอดภัยระบบคอมพิวเตอร์แห่งชาติ (ThaiCERT) จึงได้รวบรวมแนวทางตรวจสอบและอัปเดต PHP สำหรับระบบแต่ละประเภท โดยขอให้หน่วยงานสำรวจทั้งเว็บไซต์ ระบบภายในองค์กร และระบบที่ผู้ให้บริการภายนอกดูแล โดยเฉพาะ PHP ที่ติดตั้งแยกหลายเวอร์ชัน หรือเป็นองค์ประกอบภายในซอฟต์แวร์และอุปกรณ์หลายรุ่น ซึ่งการอัปเดตตัวแอปพลิเคชัน เครื่องโฮสต์ หรือระบบบริหารจัดการเพียงอย่างเดียว อาจไม่ครอบคลุม PHP ที่เป็นส่วนประกอบของแพลตฟอร์มที่ใช้งานอยู่ หน่วยงานจึงควรตรวจสอบ PHP ที่แต่ละบริการเรียกใช้จริง และยืนยันผลหลังอัปเดตให้ครบทุกระบบ ตามแนวทางต่อไปนี้ [1][2][3]

1. สิ่งที่หน่วยงานควรดำเนินการทันที 1.1 สำรวจการใช้งาน PHP ตรวจสอบว่าแต่ละเว็บไซต์และบริการใช้ PHP ชุดใด รวมถึงระบบภายในและระบบที่ผู้ให้บริการภายนอกดูแล 1.2 เตรียมการและดำเนินการอัปเดต สำรองข้อมูล ทดสอบความเข้ากันได้ และอัปเดต PHP ผ่านช่องทางที่ผู้ผลิตหรือผู้ดูแลแพ็กเกจรองรับ 1.3 เริ่มบริการใหม่และยืนยันผล เริ่มกระบวนการให้บริการใหม่ และยืนยันว่าทุกเครื่องใช้ PHP ที่ได้รับการแก้ไขแล้ว 1.4 เก็บหลักฐานและปรับปรุงระบบสำรอง บันทึกผลการแก้ไข และตรวจแพตช์ก่อนนำระบบสำรองหรืออิมเมจเก่ากลับมาให้บริการ การอัปเดตเว็บไซต์ แอปพลิเคชัน เครื่องโฮสต์ หรือ Control Panel เพียงอย่างเดียว ไม่ได้ยืนยันว่า PHP ทุกชุดได้รับการแก้ไขแล้ว

2. สำรวจการใช้งาน PHP ให้ครอบคลุม 8 กลุ่มระบบ รายการต่อไปนี้ใช้เป็นแนวทางสำรวจ โดยแต่ละระบบอาจอยู่ในหลายกลุ่ม และ ไม่ได้หมายความว่าทุกผลิตภัณฑ์ได้รับผลกระทบ ต้องตรวจสอบเวอร์ชัน สถานะแพตช์ และประกาศของผู้ผลิตประกอบ เว็บไซต์ เว็บแอปพลิเคชัน และระบบภายในองค์กร ตรวจสอบเว็บไซต์สาธารณะ ระบบ CMS, Intranet, HR, ERP, CRM, Helpdesk ระบบจัดซื้อ และพอร์ทัลพนักงานที่ใช้งาน PHP แม้ไม่ได้เปิดสู่อินเทอร์เน็ต โดยระบุ PHP ที่แต่ละบริการเรียกใช้ ตำแหน่งติดตั้ง และไฟล์ตั้งค่าให้ชัดเจน หากให้บริการหลายเครื่อง ต้องตรวจสอบและอัปเดตให้ครบทุกเครื่อง ระบบหลังบ้านแอปมือถือและ API ตรวจสอบเซิร์ฟเวอร์ API และบริการหลังบ้านที่ประมวลผลด้วย PHP การอัปเดตแอปบนโทรศัพท์ไม่ได้ยืนยันว่า PHP ฝั่งเซิร์ฟเวอร์ได้รับการแก้ไขแล้ว หากมีหลายเครื่องอยู่หลัง Load Balancer หรือมีหลายชุดให้บริการ ต้องอัปเดตและยืนยันผลให้ครบทุกชุด ระบบบริหารจัดการและ Hosting Control Panel ตรวจสอบทั้ง PHP ที่ตัวระบบบริหารจัดการใช้ หากมี และ PHP ที่กำหนดให้แต่ละเว็บไซต์ ซึ่งอาจเป็นคนละชุดกัน สำหรับ cPanel ให้ตรวจสอบ PHP รายโดเมนผ่าน MultiPHP Manager และติดตั้งหรืออัปเดตแพ็กเกจผ่าน EasyApache 4 ระบบจัดการแพ็กเกจ หรือช่องทางของผู้จำหน่ายตามประเภทแพ็กเกจ ส่วน Plesk ให้ตรวจสอบเวอร์ชันและ PHP Handler ของแต่ละเว็บไซต์ผ่าน PHP Settings [4][5] การเปลี่ยน PHP ค่าเริ่มต้นของเครื่องอาจไม่เปลี่ยน PHP ของเว็บไซต์เดิมทุกแห่ง จึงต้องตรวจสอบรายเว็บไซต์และทุกเวอร์ชันที่ยังใช้งาน ซอฟต์แวร์หรืออุปกรณ์สำเร็จรูปจากผู้ขาย ตรวจสอบผลิตภัณฑ์ที่มีหน้าเว็บบริหารจัดการหรืออาจมี PHP เป็นส่วนประกอบ โดยแจ้งชื่อผลิตภัณฑ์ รุ่น และเวอร์ชันให้ผู้ผลิตยืนยันผลกระทบ พร้อมขอแพตช์หรือเฟิร์มแวร์ที่เกี่ยวข้อง ใช้วิธีอัปเดตที่ผู้ผลิตรองรับ ไม่ควรนำ PHP รุ่นใหม่ไปแทนที่ไฟล์ภายในผลิตภัณฑ์เองโดยไม่มีคำแนะนำจากผู้ผลิต Container และ Docker Image ตรวจสอบ PHP ภายในคอนเทนเนอร์ที่กำลังทำงาน และอิมเมจที่เตรียมไว้สำหรับนำกลับมาใช้งาน จากนั้นปรับปรุง Base Image หรือแพ็กเกจ สร้างอิมเมจใหม่ ทดสอบ และนำคอนเทนเนอร์จากอิมเมจที่แก้ไขแล้วขึ้นให้บริการ [6] การอัปเดตเครื่องโฮสต์หรือดาวน์โหลดอิมเมจใหม่เพียงอย่างเดียวยังไม่ครอบคลุมคอนเทนเนอร์เดิม หากกำหนด Image Digest ไว้ ต้องปรับให้ชี้ไปยังอิมเมจที่แก้ไขแล้วด้วย

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

ระบบทดสอบ ระบบเก่า และระบบสำรอง ตรวจสอบ Development, UAT, Staging และ DR รวมถึงเครื่องเสมือน อิมเมจต้นแบบ และชุดติดตั้งที่เตรียมนำกลับมาใช้ ให้ปรับปรุงชุดที่พร้อมเปิดบริการและกำหนดขั้นตอนตรวจแพตช์ก่อนนำระบบเก่ากลับมาใช้งาน หากกู้คืนจากข้อมูลสำรองหรือ Snapshot เก่า ให้ ตรวจสอบและแก้ไข PHP ในเครือข่ายที่แยกไว้ ก่อนเชื่อมต่อกลับเข้าเครือข่ายให้บริการ

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

3. ขั้นตอนตรวจสอบและอัปเดต PHP ตรวจสอบ PHP ให้ตรงกับบริการจริง ใช้ php -v ตรวจสอบเวอร์ชัน และ php –ini ตรวจสอบไฟล์ตั้งค่าได้ แต่ผลเป็นของ PHP ที่คำสั่งนั้นเรียกใช้ ซึ่ง อาจต่างจาก PHP ของเว็บไซต์หรือ PHP-FPM จึงต้องตรวจสอบการตั้งค่าเว็บเซิร์ฟเวอร์ บริการ และ Control Panel ประกอบ [7][8] หากจำเป็นต้องสร้างหน้าตรวจสอบข้อมูล PHP ผ่านเว็บ ให้แสดงข้อมูลเท่าที่จำเป็น จำกัดการเข้าถึงเฉพาะผู้ดูแล และลบออกหลังตรวจสอบ เลือกรุ่นหรือแพ็กเกจที่มีแพตช์ครอบคลุมทั้งสอง CVE รุ่น PHP ที่แก้ไข CVE-2026-109618 และ CVE-2026-109619 ได้แก่ 8.2.35, 8.3.36, 8.4.27 และ 8.5.12 หรือรุ่นใหม่กว่าที่มีแพตช์และยังได้รับการสนับสนุน [1] หากใช้แพ็กเกจจากผู้จำหน่ายระบบปฏิบัติการหรือผู้ให้บริการสนับสนุนระยะยาว ให้ตรวจสอบประกาศและหมายเลขแพ็กเกจ เพราะอาจมีการนำแพตช์กลับมาใช้โดยหมายเลขเวอร์ชัน PHP หลักไม่เปลี่ยน สำหรับ PHP 8.1 หรือต่ำกว่า ให้ตรวจสอบกับผู้จำหน่ายว่ามีแพตช์ครอบคลุมหรือไม่ และวางแผนย้ายไปยังรุ่นที่ยังได้รับการสนับสนุน ไม่ควรถือว่ารุ่นเก่าปลอดภัยเพียงเพราะไม่มีรายการอัปเดต [1] สำรองข้อมูลทดสอบและข้อมูลอัปเดต สำรองฐานข้อมูล ไฟล์แอปพลิเคชัน และไฟล์ตั้งค่า พร้อมเตรียมแผนกู้คืน ทดสอบฟังก์ชันสำคัญและส่วนขยาย โดยเฉพาะเมื่อย้ายข้ามสายเวอร์ชัน แล้วอัปเดตผ่านช่องทางที่ผู้ผลิตหรือผู้ดูแลแพ็กเกจรองรับ เริ่มบริการใหม่และยืนยันผลอัปเดตของ PHP เริ่มบริการ PHP หรือเว็บเซิร์ฟเวอร์ที่เกี่ยวข้องใหม่ตามรูปแบบการติดตั้ง โดยตรวจให้แน่ใจว่ากระบวนการเดิมถูกแทนที่ทั้งหมด สำหรับคอนเทนเนอร์ ให้นำชุดจากอิมเมจที่แก้ไขแล้วขึ้นให้บริการ ตรวจยืนยันผ่านบริการจริงให้ครบทุกเว็บไซต์ ทุกเครื่อง และทุกคอนเทนเนอร์ พร้อมทดสอบการเข้าสู่ระบบ การเชื่อมต่อฐานข้อมูล และฟังก์ชันสำคัญ เก็บหลักฐานสถานะแพตช์ วันที่ดำเนินการ และผู้รับผิดชอบไว้ตรวจสอบย้อนหลัง หากพบสัญญาณผิดปกติ ให้ตรวจสอบร่องรอยการบุกรุกเพิ่มเติม เพราะการอัปเดตไม่ได้ลบมัลแวร์หรือช่องทางเข้าถึงที่ผู้โจมตีอาจติดตั้งไว้ก่อนหน้า

4. มาตรการชั่วคราวเมื่อยังไม่สามารถอัปเดตได้ มาตรการต่อไปนี้ลดความเสี่ยงเฉพาะบางเส้นทาง และไม่ทดแทนการติดตั้งแพตช์ ให้ผู้ดูแลประเมินผลกระทบ ทดสอบ และกำหนดกรอบเวลาแก้ไขให้ชัดเจน จำกัดการเข้าถึงระบบ จำกัดการเข้าถึงเฉพาะผู้ใช้และเครือข่ายที่จำเป็น ปิดบริการที่ไม่ได้ใช้งาน และประสานผู้ดูแลหรือผู้ผลิตเพื่อกำหนดกรอบเวลาการแก้ไข พร้อมพิจารณามาตรการตั้งค่า PHP ตามประกาศทางการ โดยทดสอบผลกระทบก่อนใช้งาน มาตรการสำหรับ CVE-2026-109618

การกำหนด memory_limit=-1 ในระดับผู้ดูแลช่วยลดเส้นทางโจมตีที่อาศัยขีดจำกัดหน่วยความจำของ PHP โดยต้องตรวจสอบว่าไม่มีการตั้งค่าใน Pool, Directory หรือแอปพลิเคชันเปลี่ยนกลับไปใช้ค่าจำกัดหน่วยความจำ และเริ่ม PHP workers ใหม่ทั้งหมด [2] ข้อควรระวัง: การตั้งค่านี้เป็นการยกเลิกขีดจำกัดหน่วยความจำต่อคำขอ จึงต้องจำกัดขนาดคำขอที่เว็บเซิร์ฟเวอร์หรือ Reverse Proxy และพิจารณาควบคุมหน่วยความจำด้วย Container หรือ cgroup ตามความเหมาะสม ไม่ควรใช้ RLIMIT_AS หรือ RLIMIT_DATA ทดแทน เนื่องจากอาจกระตุ้นเงื่อนไขที่มีช่องโหว่ ทั้งนี้ มาตรการดังกล่าวยังไม่ป้องกันทุกกรณี [2] มาตรการสำหรับ CVE-2026-109619 กำหนด session.upload_progress.enabled=0 และสำหรับ PHP 8.5 ให้กำหนด fatal_error_backtraces=0 เพิ่มเติม โดยใช้ไฟล์ตั้งค่าที่มีผลก่อนประมวลผลคำขอ และเริ่ม PHP workers ใหม่ทั้งหมด ไม่ควรอาศัยการตั้งค่าผ่าน ini_set() ภายในแอป [3] มาตรการชั่วคราวลดความเสี่ยงได้เฉพาะบางเส้นทางการโจมตี ไม่สามารถทดแทนการอัปเดตได้อย่างสมบูรณ์

5. ข้อควรทราบเพิ่มเติมหลังอัปเดต คำแนะนำเพิ่มเติมสำหรับช่องโหว่ CVE-2026-115560 ประกาศ PHP วันที่ 23 ตุลาคม 2569 แนะนำให้ปิด session.upload_progress.enabled = 0 เพื่อป้องกันเส้นทาง RCE อีกกรณีหนึ่งที่เกี่ยวข้องกับ CVE-2026-115560 ซึ่งเกิดภายใต้เงื่อนไขเฉพาะของการตั้งค่าและการเปลี่ยนวิธีจัดการข้อมูล Session ระหว่างการทำงานของแอปพลิเคชัน [1]

หน่วยงานที่ปิดค่านี้ไว้แล้วควรคงค่าไว้ และติดตามประกาศ PHP ก่อนเปิดกลับ โดยประเด็นนี้เป็นข้อมูลเพิ่มเติมแยกจากสอง CVE หลักข้างต้น

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

แหล่งอ้างอิง [1] https://dg.th/pj91vekmw0 [2] https://dg.th/b41ya7tsqp [3] https://dg.th/bejakg93lh [4] https://dg.th/gshnfzpewr [5] https://dg.th/nvcs0i4kdo [6] https://dg.th/mdoear7nh3 [7] https://dg.th/vdyjgxk72e 2 [8] https://dg.th/sr1k6hji0a

由于 PHP2Shell 漏洞存在于 PHP 中，而 PHP 是 Web 和信息系统处理中广泛使用的基础组件，因此该漏洞会影响多种类型的系统，并允许攻击者在未经身份验证的情况下远程执行代码。攻击的成功与否取决于每个系统的安装方法、配置和运行状况。为了帮助各机构全面检查和解决此问题，泰国国家计算机安全事件响应中心 (ThaiCERT) 已编制了针对各类系统的 PHP 检查和更新指南。各机构应检查网站、内部系统以及由外部服务提供商管理的系统，尤其要检查安装了多个版本或作为组件集成在多种软件和设备型号中的 PHP。仅更新应用程序、主机或管理系统可能无法覆盖作为平台组件的 PHP。因此，各机构应检查每个服务实际调用的 PHP 版本，并在根据以下指南 [1][2][3] 更新所有系统后确认结果。

1. 组织应立即采取的行动：1.1 调查 PHP 使用情况。验证每个网站和服务（包括内部和外部管理系统）使用的 PHP 版本。1.2 通过制造商或软件包提供商支持的渠道准备并实施更新、备份、兼容性测试和 PHP 更新。1.3 重启服务并验证结果。启动服务重启流程，并确认所有机器都使用更新后的 PHP。1.4 维护证据并改进备份系统。记录补丁结果，并在恢复备份系统或旧映像之前执行补丁检查。仅仅更新网站、应用程序、主机或控制面板并不能保证所有 PHP 版本都已更新。

2. 探索 8 个系统组中的 PHP 使用情况。以下列表仅供参考；每个系统可能属于多个组，但这并不意味着所有产品都会受到影响。请验证版本、补丁状态和供应商公告。网站、Web 应用程序和本地系统：检查使用 PHP 的公共网站、CMS 系统、内网、人力资源系统、ERP 系统、CRM 系统、服务台系统、采购系统和员工门户，即使这些系统无法直接在线访问。明确标识每个服务使用的 PHP 版本、安装位置和配置文件。如果服务运行在多台机器上，请检查并更新所有机器。后端系统、移动应用程序和 API：检查使用 PHP 处理数据的 API 服务器和后端服务。移动应用程序的更新并不能保证服务器端的 PHP 问题已得到修复。如果多台机器位于负载均衡器或多个服务集之后，请更新并验证所有服务集。管理系统和主机控制面板：检查管理系统使用的 PHP 版本（如果适用）以及分配给每个网站的 PHP 版本，这些版本可能不同。对于 cPanel，请通过 MultiPHP 管理器检查特定域名的 PHP 配置，并通过 EasyApache 4 软件包管理系统安装或更新软件包。或者，根据软件包类型，通过供应商渠道进行操作。对于 Plesk，请通过 PHP 设置 [4][5] 检查每个站点的 PHP 版本和 PHP 处理程序。更改机器的默认 PHP 配置可能不会更改所有现有站点的 PHP 配置，因此请逐个站点检查所有仍在使用的版本。对于供应商提供的软件或现成设备，请检查具有 Web 管理页面或可能包含 PHP 组件的产品。请将产品名称、版本和发行版告知制造商，以确认影响并请求任何相关的补丁或固件。请使用制造商支持的更新方法。未经制造商指导，请勿将内部产品文件替换为新的 PHP 版本。对于容器和 Docker 镜像，请检查正在运行的容器和准备重用的镜像中的 PHP 配置，然后更新基础镜像或软件包，构建新镜像，进行测试，并从修改后的镜像部署容器 [6]。仅更新主机或下载新镜像并不能覆盖现有容器。如果配置了图像摘要，则它还必须指向修改后的图像。

在已安装 PHP 或 PHP 已捆绑到其他软件中的 Windows 机器上，检查诸如 php.exe、php-cgi.exe 和 PHP 模块等文件，并确定它们在 Web 服务器上的安装位置、版本以及所使用的服务，包括标准安装路径之外的文件。仅存在 PHP 文件并不能确定它们是否用于 Web 服务。如果 PHP 是现成软件的组件，请使用制造商提供的更新包。

测试系统、遗留系统和备份系统：验证开发环境、用户验收测试环境、预发布环境和灾难恢复环境，包括虚拟机、原型镜像和已恢复的安装。在恢复遗留系统之前，更新可立即投入使用的软件包并定义补丁程序。如果从旧的备份或快照恢复，请在重新连接到服务器网络之前，检查并修复隔离网络上的 PHP 问题。

对于由外部服务提供商管理的系统，应与共享主机、托管主机和系统维护承包商协调，索取实际使用各自服务的网站或服务的 PHP 审计结果。证据应包括系统名称、版本或软件包编号、修改后的 CVE 编号、操作日期、更新后的审计结果以及相关的供应商文档。仅说明“网站已更新”是不够的。

3. PHP 验证和更新流程 验证 PHP 版本是否与实际服务匹配。使用 `php -v` 检查版本，使用 `php --ini` 检查配置文件，但结果显示的是命令调用的 PHP 版本，这可能与网站或 PHP-FPM 的 PHP 版本不同，因此您还需要检查 Web 服务器、服务和控制面板的设置。[7][8] 如果需要通过 Web 创建 PHP 验证页面，请仅显示必要信息，限制管理员访问权限，并在验证完成后将其删除。选择一个包含针对这两个 CVE 漏洞的补丁的版本或软件包。修复了 CVE-2026-109618 和 CVE-2026-109619 的 PHP 版本包括 8.2.35、8.3.36、8.4.27 和 8.5.12 或更高版本，这些版本包含补丁且仍在支持中。 [1] 如果使用操作系统供应商或长期支持提供商提供的软件包，请检查版本号和软件包编号，因为补丁程序可能会在不更改 PHP 主版本号的情况下重新应用。对于 PHP 8.1 或更低版本，请咨询供应商以确认补丁覆盖范围，并计划迁移到受支持的版本。即使旧版本缺少更新，也不应认为它是安全的。[1] 备份测试和更新数据。备份数据库、应用程序文件和配置文件，并制定恢复计划。测试关键功能和扩展程序，尤其是在跨版本迁移时，并通过供应商或软件包维护者的支持渠道进行更新。重启服务并验证 PHP 更新结果。根据安装模型重启 PHP 服务或相关 Web 服务器，确保之前的进程已被完全替换。对于容器，请从修改后的镜像部署软件包。在所有网站、机器和容器上通过实时服务进行验证，测试登录、数据库连接和关键功能。记录补丁状态、执行日期和负责人，以备将来参考。如果检测到任何异常迹象，请进一步调查是否存在入侵，因为更新不会删除攻击者先前可能安装的恶意软件或漏洞。

4. 暂时无法进行更新时的临时措施：以下措施可降低特定途径的风险，但不能替代补丁安装。管理员应评估影响、进行测试并制定明确的修复时间表。限制系统访问，仅允许必要的用户和网络访问，关闭未使用的服务，并与管理员或制造商协调确定修复时间表。考虑实施官方发布的 PHP 配置措施，并在实施前测试其影响。针对 CVE-2026-109618 的措施。

在管理员级别将 `memory_limit` 设置为 -1 可以缓解依赖 PHP 内存限制的攻击路径。这需要确保池、目录或应用程序中的任何设置都不会恢复到内存限制状态并重启所有 PHP 工作进程。[2] 注意：此设置会移除每个请求的内存限制，因此必须在 Web 服务器或反向代理上限制请求大小，并且应考虑使用容器或 cgroup 进行内存控制。不应使用 `RLIMIT_AS` 或 `RLIMIT_DATA` 作为替代方案，因为它们可能会触发漏洞。但是，此措施并不能防止所有情况。[2] 针对 CVE-2026-109619 的措施是将 `session.upload_progress.enabled` 设置为 0，并且对于 PHP 8.5，还需要将 `fatal_error_backtraces` 设置为 0。这需要使用一个配置文件，该文件会在处理请求和重启所有 PHP 工作进程之前生效。不应在应用程序中通过 `ini_set()` 函数依赖此设置。 [3] 此临时措施可以缓解一些攻击途径，但不能完全取代更新。

5. 更新后的补充说明 针对漏洞 CVE-2026-115560 的补充指导：PHP 于 2026 年 10 月 23 日发布的公告建议禁用 session.upload_progress.enabled = 0 以防止远程代码执行 (RCE)。另一个与 CVE-2026-115560 相关的案例发生在应用程序执行期间会话数据处理配置和更改的特定条件下 [1]。

已禁用此设置的组织应保持禁用状态，并在重新启用前密切关注 PHP 公告。此信息与上述两个主要 CVE 无关。

ThaiCERT 要求各机构在其真实环境中对 PHP 进行调查，以所有八个系统组为指导，验证所有服务的补丁，并更新备份安装，以防止重复使用易受攻击的版本。

参考文献 [1] https://dg.th/pj91vekmw0 [2] https://dg.th/b41ya7tsqp [3] https://dg.th/bejakg93lh [4] https://dg.th/gshnfzpewr [5] https://dg.th/nvcs0i4kdo [6] https://dg.th/mdoear7nh3 [7] https://dg.th/vdyjgxk72e 2 [8] https://dg.th/sr1k6hji0a