PHP2Shell（CVE-2026-109618/CVE-2026-109619）是两个CVSS 4.0评分为9.2的高危远程代码执行漏洞，影响PHP 8.2至8.5未升级版本，需立即升级至8.2.35/8.3.36/8.4.27/8.5.12修复。
立刻确认你手上的 PHP 版本是否低于 8.2.35、8.3.36、8.4.27 或 8.5.12 ——只要任一版本不满足，就处于 PHP2Shell（CVE-2026-109618 / CVE-2026-109619）的直接攻击面内，无需登录即可被远程执行代码。
php -v 输出怎么看才不算漏掉旧版本
很多运维在查版本时只看主命令输出，却忽略了多版本共存、容器镜像、CLI 与 FPM 不一致等陷阱。PHP2Shell 是运行时级漏洞，只要某个 Worker 进程加载了未修复的 PHP SAPI，风险就存在。
- 执行
php -v后，再跑一遍php-fpm -v（或php-cgi -v），确认所有 SAPI 实例版本一致 - 检查
which php和which php-fpm是否指向同一安装路径；若不同，说明存在多版本混用，必须逐个验证 - 在容器环境里，不能只信 Dockerfile 的
FROM标签——有些基础镜像（如php:8.2-apache）在补丁发布前已停止更新，实际拉取的仍是8.2.34 - Windows 下通过 XAMPP、WampServer、宝塔 Windows 版部署的 PHP，要进对应控制面板查真实二进制路径并执行
php.exe -v
WordPress / Laravel 等 CMS 和框架不能帮你挡这个漏洞
PHP2Shell 不依赖业务逻辑，连 <?php echo=""><!--?php--><!--?php--><!--?php--><!--?php--><!--?php-->?php> 这样的单行脚本都可被利用。CMS 更新再及时，只要底层 PHP 没升级，攻击者就能绕过全部应用层防护直击内核。
- WordPress 插件扫描器、Laravel
artisan security:check类工具对 PHP2Shell 完全无效 - WP Super Cache、OPcache、APCu 等加速扩展不仅不缓解，反而可能因缓存未清理的异常状态加剧 UAF 触发概率
- 某些托管平台（如 SiteGround、WP Engine）声称“已自动加固”，需手动验证其后台是否真将 PHP 升级到了修复版本，而非仅加了 WAF 规则
- 老旧定制系统若基于 ThinkPHP 5.1 + PHP 7.4，哪怕代码十年没动过，也必须立即处理——PHP 7.4 已无官方补丁，只能换版本或上旁路防护
容器和 CI/CD 流水线里的隐藏风险点
很多团队以为“镜像重建一次就安全了”，但构建缓存、base 镜像源、CI runner 环境都可能让漏洞悄悄回流。
立即学习“PHP免费学习笔记（深入）”；
- Docker 构建时若用了
CACHE FROM且 base 镜像未刷新，新 Dockerfile 仍会复用旧 PHP 层 - GitHub Actions / GitLab CI 中的
setup-phpaction 默认不锁 minor 版本，php-version: '8.2'可能拉到8.2.34而非8.2.35 - Kubernetes 集群中，
php-fpmPod 的 readiness probe 若调用的是/status这类简单 endpoint，无法反映 PHP 内核是否已热更——必须重启所有 Pod 才能加载新二进制 - 使用 FrankenPHP 的团队要注意：它默认捆绑 PHP，但补丁发布后需手动拉取新版本镜像（如
frankenphp:1.2.3-php8.5.12），不能指望自动同步
无法立即升级的老系统怎么办
没有“完美缓解”，只有“有限压制”。临时措施仅封堵已知 PoC 路径，且部分配置在特定场景下会引发兼容性断裂。
- 全局禁用
session.upload_progress.enabled=0是最有效前置动作，但会破坏依赖该机制的上传进度条功能（如某些定制化大文件上传组件） - 设
memory_limit=-1可缓解 CVE-2026-109618，但若业务本身依赖内存限制做请求熔断，可能造成 OOM 波及整个 FPM pool - Nginx 层加
client_max_body_size 8m有用，但攻击者可改用极小 payload + 多次触发，所以必须配合limit_req控制 multipart 请求频次 - PHP 8.5 环境务必关掉
fatal_error_backtraces=0，否则错误堆栈可能泄露内存布局，辅助变种利用
真正难啃的不是技术动作，而是那些“没人记得谁配的”PHP-FPM pool、藏在测试机里的 Docker Compose 环境、外包团队留下的离线部署包——它们不会出现在资产台账里，却可能第一个被扫出 shell。
