2026年10月21日PHP官方紧急发布安全更新修复了两项严重的远程代码执行漏洞CVE-2026-109618OOM异常处理中的内存破坏漏洞。CVE-2026-109619请求间遗留失效状态导致的内存安全漏洞。这两项漏洞被统称为PHP2ShellCVSS v4.0 评分均达到9.2分。值得注意的是这次的问题不在具体的PHP业务代码而在PHP解释器本身。研究人员已经验证部分攻击路径可以在业务代码执行之前触发。因此传统的上传文件大小限制、业务层参数校验都不能作为可靠的完整防护方案。本文不讨论漏洞利用方法只讲生产环境如何应急处置。一、先确认你的PHP版本修复了吗PHP官方在10月21日发布的修复版本如下PHP分支修复版本PHP 8.28.2.35PHP 8.38.3.36PHP 8.48.4.27PHP 8.58.5.12PHP 8.1及更早版本已经停止上游常规维护需要检查发行版提供的回移补丁或升级至受支持的版本。注意发行版中的PHP版本号较老不一定代表没有修复。Debian、Ubuntu、RHEL等系统可能将安全补丁回移到原有软件包。因此不能只比较PHP版本号还需要核对发行商的安全公告和软件包修复记录。首先查看当前PHP环境php -v php --ini如果使用PHP-FPM还应检查php-fpm -v部分系统中命令带有版本后缀例如php-fpm8.3。但这里存在一个容易忽略的问题命令行PHP版本不一定就是网站实际使用的PHP版本。服务器可能同时安装了多个PHP版本不同网站也可能对应不同的PHP-FPM进程池。需要进一步检查Nginx的fastcgi_pass配置、PHP-FPM监听地址和对应的服务进程。对于使用虚拟主机的站点应直接联系主机商确认修复情况。二、升级之前先阻断已经确认的攻击路径如果暂时不能升级可以采用分层防护措施降低风险。但要明确临时配置不是漏洞修复不能承诺阻断全部RCE攻击。1. 关闭Session上传进度功能PHP官方明确建议session.upload_progress.enabled Off这个配置用于跟踪文件上传进度。很多普通网站并不需要它。关闭该功能可以阻断CVE-2026-109619已确认的部分Session攻击路径。2026年10月23日PHP官方又发布了CVE-2026-115560相关提示。该问题需要一种不常见的Session序列化配置组合并且上传进度功能仍然开启。官方建议在后续修复发布之前继续关闭该功能。需要注意配置位置。如果使用PHP-FPM应该在请求解析前生效的服务端配置中设置在业务代码里调用ini_set(session.upload_progress.enabled, 0); // 在代码中设置为无效行为业务代码执行时请求解析过程可能早已完成。修改之后需要重启所有相关PHP工作进程。PHP 8.5环境还应检查fatal_error_backtraces 0这项设置用于降低CVE-2026-109619的另一条已确认攻击路径风险。2. 不要简单降低memory_limit这是此次漏洞最容易被误解的地方。(使用docker运行的伙伴, 需要反直觉思考)很多管理员遇到内存风险第一反应是把配置改小memory_limit 64M但对于CVE-2026-109618这个思路可能适得其反。攻击者可以利用PHP内存分配失败后的异常处理缺陷触发内存破坏。PHP官方给出的临时缓解建议反而是memory_limit -1即取消PHP自身的内存上限减少通过人为设置的PHP内存限额触发已知漏洞路径的机会。如果使用PHP-FPM可以在对应进程池配置中采用管理员级设置php_admin_value[memory_limit] -1例如配置在相应PHP-FPM Pool文件中。这样可以避免业务程序通过普通配置方式重新设置有限内存上限。但是这项操作有重要前提必须先建立可靠的系统级资源隔离。memory_limit-1并不意味着内存永远不会分配失败。底层内存耗尽仍可能触发异常而且无限制的PHP进程可能拖垮整台服务器。(也就说此修复方式的前提是通过docker运行限制内存)因此应配合容器或Linux cgroup资源隔离PHP-FPM工作进程数量控制内存监控与OOM处置策略对异常请求的前置拦截。尤其不要用RLIMIT_AS、RLIMIT_DATA代替cgroup因为它们也可能制造漏洞涉及的内存分配失败条件。没有完成资源隔离和业务验证之前不建议在生产环境直接照抄memory_limit-1。3. 在Nginx、WAF等前置层限制请求此次攻击的重要特点是攻击者不需要上传巨大的文件也可能使PHP在请求解析阶段产生较大的内存开销。因此client_max_body_size 1m;这样的设置仍有价值但不能单独阻断攻击。对于完全不需要multipart上传的业务可以在WAF或前置代理层拦截不必要的multipart/form-data请求。如果必须保留上传功能应进一步限制上传入口请求体大小multipart分段数量和字段数量请求头数量、字段长度和嵌套复杂度后台入口的来源IP。需要注意普通Nginx配置并不能自动完整解析和限制multipart内部所有字段结构复杂限制可能需要专用WAF或额外的请求解析模块。不要把client_max_body_size当成完整解决方案。4. 修改配置后必须验证生效这也是生产环境经常遗漏的一步。先确认PHP-FPM配置无语法问题再按实际服务名称执行重启。例如sudo systemctl restart php8.3-fpm具体服务名应以实际部署环境为准。随后从受控的Web请求上下文检查?php header(Content-Type: text/plain); echo PHP: , PHP_VERSION, PHP_EOL; echo memory_limit: , ini_get(memory_limit), PHP_EOL; echo upload_progress: , ini_get(session.upload_progress.enabled), PHP_EOL;这个临时检查文件只应通过本机或受限管理入口访问验证后立即删除不要长期暴露公网。重点确认网站实际使用的PHP版本和软件包修复状态所有相关PHP-FPM Pool是否加载了正确配置旧Worker是否已全部退出业务是否出现兼容性异常。三、修复漏洞不等于完成安全处置PHP升级完成后还需要考虑另一个问题在修复之前系统是否已经遭到入侵建议结合正常运维基线检查Web目录是否出现未知PHP文件或异常修改是否存在异常进程、计划任务或启动项Web访问日志是否有明显异常请求PHP-FPM、Nginx、Apache日志是否出现异常崩溃是否出现陌生登录、未知SSH密钥或异常外联数据库凭据、应用密钥是否可能已经泄露。如果发现明确的入侵迹象应进入正式的事件响应流程保留证据、隔离受影响环境并考虑从可信镜像恢复和轮换凭据。仅删除一个可疑文件不能说明攻击者已经被清除。四、最后的建议防止RCE优先于维持服务在线这次漏洞真正值得警惕的不是PHP可能被打崩而是攻击者可能获得远程代码执行权限。因此在无法确认防护是否有效时暂时隔离高风险服务也是合理的应急选择。可以接受短时间业务中断但不能把可能已经遭到入侵的服务当成正常业务继续运行。需要再强调一次升级或安装供应商安全回移补丁是修复对应漏洞的根本办法。临时配置、WAF和请求限制只能帮助管理员争取修复时间。PHP2Shell也再次说明生产环境安全不是改几行配置就能解决的问题。真正困难的是理解系统底层的故障机制并在安全风险和业务连续性之间作出正确取舍。参考资料PHP官方2026年10月21日、23日安全公告PHPAWS Security BlogUsing AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619) | AWS Security BlogRed Hat安全公告RHSB-2026-013 Request handling memory corruption - php (CVE-2026-109618, CVE-2026-109619, CVE-2026-115560) - php2shell | Red Hat Customer Portal本文根据截至2026年10月24日公开的安全公告整理。实际操作前请确认环境、备份配置并制定回滚方案。