แจ้งเตือน พบช่องโหว่ PHP2Shell เสี่ยงถูกควบคุมเซิร์ฟเวอร์จากภายนอก - Thailand Computer Emergency Response Team (ThaiCERT)

ศูนย์ประสานการรักษาความมั่นคงปลอดภัยระบบคอมพิวเตอร์แห่งชาติ (ThaiCERT) ได้ติดตามสถานการณ์ภัยคุกคามทางไซเบอร์ พบรายงานช่องโหว่ใน PHP จำนวน 2 รายการ ได้แก่ CVE-2026-109618 และ CVE-2026-109619 หรือที่เรียกว่า PHP2Shell ซึ่งอาจเปิดโอกาสให้ผู้โจมตีที่ไม่มีบัญชีผู้ใช้ส่งคำขอที่สร้างขึ้นเป็นพิเศษ เพื่อรันคำสั่งบนเซิร์ฟเวอร์ด้วยสิทธิ์ของบัญชี Web Server และควบคุมระบบจากภายนอกได้ ช่องโหว่ส่งผลกระทบต่อระบบที่ใช้ PHP ให้บริการเว็บไซต์และ Web Application รวมถึง PHP-FPM, Apache mod_php, php-cgi, FrankenPHP และ LiteSpeed ปัจจุบันมีการเผยแพร่ Proof of Concept (PoC) สู่สาธารณะแล้ว และ PHP ได้เผยแพร่เวอร์ชันที่แก้ไขแล้ว [1]

1. รายละเอียดช่องโหว่ 1.1 CVE-2026-109618 (CVSS v4.0: 9.2)[2] – Out-of-Memory State Corruption เป็นช่องโหว่จากการจัดการหน่วยความจำเมื่อระบบเกิดภาวะหน่วยความจำไม่เพียงพอ หรือ Out-of-Memory (OOM) ไม่เหมาะสม ในบางช่วง PHP อาจยุติการประมวลผลขณะที่ข้อมูลภายในของคำขอยังถูกเตรียมไม่สมบูรณ์ ทำให้ขั้นตอนปิดคำขอนำข้อมูลที่ไม่ถูกต้องไปประมวลผลต่อ ผู้โจมตีอาจส่งคำขอแบบ Multipart ที่ใช้หน่วยความจำจำนวนมาก เพื่อกระตุ้นเงื่อนไขดังกล่าวและรันคำสั่งบนเซิร์ฟเวอร์ด้วยสิทธิ์ของบัญชี Web Server ได้ โดย PHP ยืนยันผลกระทบกับ Apache mod_php แล้ว ส่วน PHP-FPM อาจได้รับผลกระทบภายใต้เงื่อนไขของ Web Application [3] 1.2 CVE-2026-109619 (CVSS v4.0: 9.2)[4] – Use-After-Free / Stale Global State เป็นช่องโหว่ที่เกิดจากสถานะส่วนกลางของ PHP ยังคงอ้างอิงข้อมูลของคำขอก่อนหน้า แม้ว่าหน่วยความจำดังกล่าวจะถูกคืนให้ระบบแล้ว เมื่อ Worker เดิมรับคำขอถัดไป อาจนำข้อมูลที่ค้างอยู่กลับมาใช้งานก่อนขั้นตอนเริ่มต้นตามปกติ ผู้โจมตีอาจจัดเตรียมคำขอหลายรายการให้ถูกประมวลผลโดย Worker เดียวกัน เพื่อนำไปสู่การรันคำสั่งบนระบบและควบคุมเซิร์ฟเวอร์จากภายนอก โดยพบช่องทางที่เกี่ยวข้องกับ Session Upload Progress, Fatal Error และสถานะภายในอื่นของ PHP และมีการยืนยันผลกระทบกับทั้ง Apache mod_php และ PHP-FPM ภายใต้เงื่อนไขที่เกี่ยวข้อง [5]

2. ผลิตภัณฑ์ที่ได้รับผลกระทบ [6] – PHP 8.2 ที่ต่ำกว่า version 8.2.35 – PHP 8.3 ที่ต่ำกว่า version 8.3.36 – PHP 8.4 ที่ต่ำกว่า version 8.4.27 – PHP 8.5 ที่ต่ำกว่า version 8.5.12 – PHP 8.1 และเวอร์ชันเก่ากว่าที่สิ้นสุดการสนับสนุนและยังไม่ได้รับแพตช์จาก Linux Distribution หรือผู้ให้บริการ Extended Support รูปแบบการติดตั้งที่ต้องตรวจสอบประกอบด้วย PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed หรือ LSAPI รวมถึง PHP ภายใน Container, Docker Image, Hosting Control Panel และผลิตภัณฑ์สำเร็จรูปที่มี PHP เป็นส่วนประกอบ

3. แนวทางการแก้ไข [4] 3.1 ตรวจสอบเวอร์ชัน PHP ทุกระบบภายในหน่วยงาน รวมถึง Web Server, Application Server, Container, Hosting Control Panel ระบบสำรอง และผลิตภัณฑ์ที่มี PHP รวมอยู่ภายใน โดยสามารถใช้คำสั่ง php -v เพื่อตรวจสอบเวอร์ชัน 3.2 เร่งอัปเดตเป็นเวอร์ชันที่ได้รับการแก้ไข ดังนี้ – สำหรับ PHP 8.2 ให้อัปเดตเป็น version 8.2.35 หรือใหม่กว่า – สำหรับ PHP 8.3 ให้อัปเดตเป็น version 8.3.36 หรือใหม่กว่า – สำหรับ PHP 8.4 ให้อัปเดตเป็น version 8.4.27 หรือใหม่กว่า – สำหรับ PHP 8.5 ให้อัปเดตเป็น version 8.5.12 หรือใหม่กว่า 3.3 สำหรับระบบที่ติดตั้ง PHP ผ่าน Linux Distribution, Hosting Provider หรือ Control Panel ให้ตรวจสอบและติดตั้งแพ็กเกจที่ผู้ให้บริการรับรอง เนื่องจากบางแพ็กเกจอาจใช้หมายเลขเวอร์ชันเดิม แต่มีการนำแพตช์ความปลอดภัยกลับมาติดตั้งแล้ว 3.4 ระบบที่ใช้ PHP 8.1 หรือต่ำกว่า ควรย้ายไปใช้ PHP เวอร์ชันที่ยังได้รับการสนับสนุน หากยังไม่สามารถย้ายได้ ให้ตรวจสอบแพตช์จาก Linux Distribution หรือผู้ให้บริการ Extended Support โดยตรง ทั้งนี้ PHP ได้จัดเตรียม Source Backport ขั้นต่ำสำหรับ PHP 7.4, 8.0 และ 8.1 สำหรับผู้ดูแลระบบที่คอมไพล์ PHP เอง 3.5 หลังอัปเดต ให้ Restart PHP Worker และ Web Server ที่เกี่ยวข้อง เช่น PHP-FPM, Apache หรือ LiteSpeed เพื่อให้ระบบโหลด Binary และ Library ที่ได้รับการแก้ไขแล้ว 3.6 สำหรับระบบที่ใช้ Container ให้สร้าง Image ใหม่จาก Base Image ที่ได้รับการแก้ไข จากนั้น Deploy Container ใหม่ และตรวจสอบว่า Container ที่กำลังให้บริการไม่ได้ใช้ PHP เวอร์ชันเดิม 3.7 ตรวจสอบ Apache, PHP-FPM, Reverse Proxy และ Application Log เพื่อค้นหาเหตุการณ์ผิดปกติ เช่น Out-of-Memory, Fatal Error, Parse Error, Uncaught Error, ข้อความ Maximum execution time exceeded และ Worker ที่หยุดทำงานหรือ Restart บ่อยผิดปกติ 3.8 ตรวจสอบคำขอแบบ Multipart/Form-Data ที่มีขนาดใหญ่ ไม่มีค่า Content-Length ที่ใช้งานได้ มี Header หรือ Input Field จำนวนมาก รวมถึงการอัปโหลดไฟล์และ Session Upload Progress ที่เกิดขึ้นต่อเนื่องจากแหล่งที่ไม่รู้จัก 3.9 ตรวจสอบ Process และ Network Connection ที่เกิดจากบัญชี Web Server เช่น www-data , apache หรือ nginx รวมถึงไฟล์ที่ถูกสร้างหรือแก้ไขใน Web Root, Temporary Directory และ Upload Directory โดยไม่ทราบที่มา 3.10 หากพบหลักฐานการเข้าถึงโดยไม่ได้รับอนุญาต ให้แยกระบบออกจากเครือข่ายส่วนที่ไม่จำเป็น เก็บรักษา Log และหลักฐานที่เกี่ยวข้อง และดำเนินการตามกระบวนการตอบสนองเหตุการณ์ทันที

4. แนวทางปฏิบัติกรณีไม่สามารถอัปเดตได้ทันที 4.1 สำหรับ CVE-2026-109618 ให้กำหนด memory_limit=-1 ในระดับผู้ดูแลระบบ และตรวจสอบว่า PHP-FPM Pool, Directory หรือ Web Application ไม่สามารถเปลี่ยนกลับไปใช้ค่าจำกัดหน่วยความจำได้ จากนั้น Restart PHP Worker ทุก Process 4.2 กำหนดค่า post_max_size ให้อยู่ในระดับต่ำและเหมาะสมกับการใช้งาน โดย PHP แนะนำให้พิจารณากำหนดเป็น 8M สำหรับระบบที่ไม่ต้องอัปโหลดไฟล์ หรือ 32M สำหรับระบบที่จำเป็นต้องอัปโหลดไฟล์ พร้อมกำหนด upload_max_filesize ให้ต่ำกว่า post_max_size 4.3 จำกัดขนาดคำขอ จำนวน Input Field, Multipart Part, Header, ไฟล์อัปโหลด และระดับการซ้อนของข้อมูลที่ Web Server, Reverse Proxy หรือ Web Application Firewall หากระบบไม่ใช้งาน Multipart/Form-Data หรือการอัปโหลดไฟล์ ให้พิจารณาปิดกั้นคำขอดังกล่าวก่อนส่งต่อไปยัง PHP 4.4 สำหรับ CVE-2026-109619 ให้กำหนด session.upload_progress.enabled=0 ใน php.ini , PHP-FPM Pool หรือ Server Configuration และ Restart PHP Worker ทุก Process 4.5 สำหรับ PHP 8.5 ที่ยังไม่สามารถอัปเดต ให้กำหนด fatal_error_backtraces=0 เพิ่มเติมและ Restart PHP Worker ทุก Process 4.6 แก้ไข Fatal Error, Warning, Deprecated Setting และ Execution Timeout ที่ผู้โจมตีสามารถกระตุ้นผ่าน Web Request ได้ รวมถึงตรวจสอบขั้นตอนอัปโหลด การนำเข้าข้อมูล Serialization, Destructor, Callback และ Extension 4.7 หากไม่สามารถดำเนินการตามมาตรการข้างต้นได้ ให้พิจารณาแยกระบบที่ได้รับผลกระทบออกจากอินเทอร์เน็ต หรือจำกัดการเข้าถึงให้เฉพาะเครือข่ายและ IP Address ที่ได้รับอนุญาตจนกว่าจะติดตั้งแพตช์แล้วเสร็จ 4.8 เพิ่มการเฝ้าระวังเหตุการณ์ผิดปกติและจัดเก็บ Log ให้เพียงพอต่อการตรวจสอบย้อนหลัง โดยการไม่พบข้อผิดพลาดใน Log ไม่สามารถใช้ยืนยันได้ว่าระบบปลอดภัย เนื่องจากบางกรณีอาจเกิดขึ้นก่อนที่ PHP จะบันทึกเหตุการณ์

แหล่งอ้างอิง [1] https://dg.th/qg4bajux0v [2] https://dg.th/e3xsphalkz [3] https://dg.th/uqegc1tvk3 [4] https://dg.th/mce2x3v7as [5] https://dg.th/lozamxw5ch [6] https://dg.th/lc8az9qbue

泰国国家计算机安全事件响应中心 (ThaiCERT) 一直在监测网络威胁形势，并发现了 PHP 中的两个已报告漏洞，即 CVE-2026-109618 和 CVE-2026-109619（也称为 PHP2Shell）。这些漏洞可能允许没有账户的攻击者发送特制请求，以 Web 服务器账户权限在服务器上执行命令，从而获得对系统的外部控制权。这些漏洞会影响使用 PHP 提供网站和 Web 应用程序服务的系统，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed。目前，概念验证 (PoC) 已公开发布，PHP 也已发布了修复版本。[1]

1. 漏洞详情 1.1 CVE-2026-109618 (CVSS v4.0: 9.2)[2] – 内存溢出状态损坏是一种内存管理漏洞，当系统遇到内存不足 (OOM) 情况时会发生。在某些情况下，PHP 可能会在请求中的数据尚未完全准备就绪时终止处理，导致请求关闭步骤继续处理错误的数据。攻击者可以发送占用大量内存的多部分请求来触发这种情况，并使用 Web 服务器帐户权限在服务器上执行命令。PHP 已确认此漏洞对 Apache mod_php 的影响，而 PHP-FPM 在 Web 应用程序环境下也可能受到影响。[3] 1.2 CVE-2026-109619 (CVSS v4.0: 9.2)[4] – 释放后使用/过时全局状态漏洞是由 PHP 全局状态在内存释放后仍然引用先前请求的数据而导致的。当同一个 Worker 处理下一个请求时，它可能会在正常终止步骤之前重用待处理的数据。攻击者可以安排同一个 Worker 处理多个请求，从而在系统上执行命令，并从外部控制服务器。这是通过利用与会话上传进度、致命错误和其他内部 PHP 状态相关的漏洞来实现的，并且已证实，在相关条件下，Apache mod_php 和 PHP-FPM 都会受到影响。[5]

2. 受影响产品 [6] – PHP 8.2 版本低于 8.2.35 – PHP 8.3 版本低于 8.3.36 – PHP 8.4 版本低于 8.4.27 – PHP 8.5 版本低于 8.5.12 – PHP 8.1 及更早版本，这些版本已停止支持且未收到来自 Linux 发行版或扩展支持提供商的补丁。需要检查的安装包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed 或 LSAPI，以及容器、Docker 镜像、主机控制面板和包含 PHP 组件的现成产品中的 PHP。

3. 解决方案 [4] 3.1 检查组织内所有系统的 PHP 版本，包括 Web 服务器、应用服务器、容器、主机控制面板、备份系统以及集成了 PHP 的产品。您可以使用命令 `php -v` 检查版本。3.2 加快更新到最新版本，具体如下：– 对于 PHP 8.2，请更新到 8.2.35 或更高版本。– 对于 PHP 8.3，请更新到 8.3.36 或更高版本。– 对于 PHP 8.4，请更新到 8.4.27 或更高版本。– 对于 PHP 8.5，请更新到 8.5.12 或更高版本。3.3 对于通过 Linux 发行版、主机提供商或控制面板安装 PHP 的系统，请检查并安装提供商支持的软件包，因为某些软件包可能使用旧版本号，但已重新安装安全补丁。3.4 使用 PHP 8.1 或更低版本的系统应迁移到受支持的 PHP 版本。如果无法迁移，请直接从您的 Linux 发行版或扩展支持提供商处查找补丁。PHP 为自行编译 PHP 的系统管理员提供了 PHP 7.4、8.0 和 8.1 的最低源代码向后移植版本。3.5 更新后，重启 PHP 工作进程和相关 Web 服务器，例如 PHP-FPM、Apache 或 LiteSpeed，以便系统加载已打补丁的二进制文件和库。3.6 对于容器化系统，请从已打补丁的基础镜像创建一个新镜像，然后部署容器，并确保当前运行的容器未使用旧版本的 PHP。3.7 检查 Apache、PHP-FPM、反向代理和应用程序日志，查找异常情况，例如内存不足、致命错误、解析错误、未捕获的错误、超出最大执行时间等消息，以及工作进程异常频繁地停止或重启。3.8 检查 Multipart/Form-Data 请求。 3.9 调查源自 www-data、apache 或 nginx 等 Web 服务器帐户的进程和网络连接，包括从未知来源创建或修改的 Web 根目录、临时目录和上传目录中的文件。3.10 如果发现未经授权访问的证据，则将系统与不必要的网络区域隔离，维护相关日志和证据，并立即执行事件响应程序。

4. 无法立即更新情况下的行动计划 4.1 对于 CVE-2026-109618，请在管理员级别将 memory_limit 设置为 -1，并验证 PHP-FPM 池、目录或 Web 应用程序不会恢复到内存限制。然后重启所有 PHP 工作进程。4.2 将 post_max_size 设置为适合使用情况的较低值。PHP 建议对于不需要文件上传的系统，建议设置为 8M；对于需要文件上传的系统，建议设置为 32M。将 upload_max_filesize 设置为低于 post_max_size 的值。4.3 如果系统不使用 multipart/form-data 或文件上传，请在 Web 服务器、反向代理或 Web 应用程序防火墙上限制请求大小、输入字段数量、multipart 部分数量、标头数量、上传的文件数量以及数据嵌套级别。考虑在将此类请求转发给 PHP 之前将其阻止。4.4.对于 CVE-2026-109619，请在 php.ini、PHP-FPM 池或服务器配置中设置 session.upload_progress.enabled=0，并重启所有 PHP 工作进程。4.5 对于目前无法更新的 PHP 8.5，请添加 fatal_error_backtraces=0 并重启所有 PHP 工作进程。4.6 修复攻击者可通过 Web 请求触发的致命错误、警告、已弃用的设置和执行超时。此外，还要检查上传、数据导入、序列化、析构函数、回调和扩展进程。4.7 如果无法实施上述措施，请考虑将受影响的系统与互联网隔离，或限制访问，仅允许授权的网络和 IP 地址访问，直至补丁完全安装。4.8 加强对异常情况的监控，并存储足够的日志以供回顾性调查。日志中没有错误并不能确认系统安全，因为某些情况可能发生在 PHP 记录事件之前。

参考文献 [1] https://dg.th/qg4bajux0v [2] https://dg.th/e3xsphalkz [3] https://dg.th/uqegc1tvk3 [4] https://dg.th/mce2x3v7as [5] https://dg.th/lozamxw5ch [6] https://dg.th/lc8az9qbue