我们webman是否受影响,公司已经通报该漏洞了

按目前公开的信息判断，这条攻击链打不到这套 webman
应用——不是因为它安全做得严，而是因为它的运行方式根本不会走到漏洞所
在的代码路径。但有一个更要紧的事：你们跑的 PHP 8.1 是
EOL，这次没有 8.1 的补丁，同机如果还有 php-fpm
服务，那些才需要紧急处理。

为什么 webman 不受这条链影响

漏洞在 ext/session 的 php_session_rfc1867_callback()——它挂在 SAPI
解析 multipart 请求体的钩子上。这套项目：

1. 不用 php-fpm：Webman 是 Workerman 常驻 CLI
   进程（config/server.php 直接 listen http://0.0.0.0:2），PHP
   以 CLI SAPI 运行。CLI 下 PHP 根本不做 multipart
   解析，$_POST/$_FILES 是空的。
2. multipart 是 Workerman 自己解析的：vendor/workerman/workerman/P
   rotocols/Http/Request.php:484 的 parseUploadFiles()
   手工切分边界、tempnam() 落临时文件。PHP_SESSION_UPLOAD_PROGRESS
   在这里只是一个普通表单字段，不会触发 ext/session 的任何逻辑。

3. session 完全不走 PHP 原生扩展：support/bootstrap/Session.php
   用的是 Workerman\Protocols\Http\Session（纯 PHP 实现，存
   Redis，config/session.php），全项目没有任何
   session_start()，也没有 $_SESSION。所以连"上传进度写 session
   文件 + 应用 include 落地"那条链的落点都没有。

   顺带一提，这个 CVE 本身还有争议：有审计仓库称该 UAF 在已发布 PHP
   中无法复现；但 PHP 官方是按 CVSS 9.2
   发的安全版本，在官方详细通告出来之前按"真实且严重"对待是对的。

Workerman/webman 服务通过 PHP命令行运行的，常驻进程独立处理 HTTP 请求，文件上传与 Session 管理由框架自身实现，不受影响。

更新
Workerman/webman 使用 CLI 常驻进程，自行处理 HTTP 上传，并不在每次 HTTP 请求之间执行 PHP 原生请求的销毁与重新初始化，因此不具备目前已披露的原生上传及跨请求利用链条件。
但是不排除有其他未知攻击链条，所以该升级就升级，不要等新的利用链条被发现导致被攻击。

🧬 漏洞的根源在PHP解释器，不在框架层
PHP2Shell（CVE-2026-109618 / CVE-2026-109619）是 PHP 解释器内核的漏洞，根源位于 ext/session/session.c 等底层代码中。安全分析明确指出，漏洞“位于解释器内核，与运行方式无关”，Apache mod_php 和 PHP-FPM 两种主流部署方式均受影响。

Workerman/Webman 虽然不依赖 FPM，但它仍然需要用 PHP 解释器来解析和执行代码，无法绕开解释器自身的缺陷。

⚙️ “常驻进程”恰恰是漏洞利用的理想温床
作者声明中“常驻进程独立处理HTTP请求”这一点，非但不是免疫的理由，反而精准地描述了漏洞利用所需的前提条件。

PHP2Shell 中的 CVE-2026-109619 是一个跨请求的释放后重用（UAF） 漏洞。它的触发路径是：一个常驻的 worker 进程在处理完请求 A 后，在全局状态中留下了指向已释放内存的指针；当同一个 worker 接着处理请求 B 时，如果它在初始化前读到了这个“脏”指针，漏洞就被触发了。

Workerman 的常驻内存模型意味着一个 PHP 进程会连续处理成千上万个请求。这为漏洞所要求的“跨请求状态污染”创造了比传统“一个请求一个进程”的 FPM 模式多得多的触发机会。

🛡️ “框架自实现Session管理”并非安全屏障
声明中提到“Session 管理由框架自身实现”，但这同样不能构成防护。

漏洞利用并不完全依赖 PHP 原生的 session_start()。根据 PoC 分析，攻击者可以通过在 multipart/form-data 请求中构造特定的 PHP_SESSION_UPLOAD_PROGRESS 字段，利用 PHP 内置的上传进度处理机制（默认开启）来投毒 session 数据。这个处理过程发生在应用代码（包括框架的 Session 中间件）运行之前。

此外，Workerman 官方页面本身也引述了漏洞性质：“multipart/form-data 上传时，PHP_SESSION_UPLOAD_PROGRESS 字段的内容会被 PHP 作为 session 数据解析（反序列化），恶意 payload 触发 PHP 内置类魔术方法 → RCE”。这正说明了风险是内在于 PHP 解释器处理上传的环节，而非框架的 Session 管理逻辑。

💎 总结与判断
综合来看，Workerman/Webman 框架作者的声明，在技术上很可能站不住脚。该声明似乎将“不经过 FPM 的请求生命周期”等同于“不经过 PHP 解释器的漏洞触发点”，这是一个误解。实际上，Workerman 的常驻进程架构，可能使它比传统 FPM 模式面临更集中的跨请求攻击面。

因此，最稳妥的判断是：Workerman/Webman 项目同样需要将 PHP 升级到已修复的版本（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35），不能依赖框架层特性来规避解释器内核的漏洞。

DEEPSEEK 深度思考的结果。大佬们可以分析一下。

🐮

虽然现有的条件，webman可能不受影响，但是线上的业务，建议大家还是升级处理，现在8.0 8.1都已经出了最小更新了，需要自己编译一下就行。

可以使用AI，让他使用https://github.com/crazywhalecc/static-php-cli 重新对修复的版本进行静态打包替换即可。

目前看下来就5.x的版本php最难受了，7.x还有8.x基本都有可以通过升级或者ubuntu这些系统上的php补丁的方案解决。
关于8.0版本当时用的第一版的webman如果升级了php8.2以后会出现一个问题是，PHP 8.2 将动态创建类属性的行为标记为弃用了，而老版本的 Webman 项目会把这个弃用警告转换成 ErrorException，所以请求过程中出现了异常。
可以适当加入下面第二个if这一段，在support/bootstrap中来放行
set_error_handler(function ($level, $message, $file = '', $line = 0) {
if (error_reporting() & $level) {
if ($level === E_DEPRECATED || $level === E_USER_DEPRECATED) {
return true;
}
throw new ErrorException($message, 0, $level, $file, $line);
}
});

PS：这个方式适合不想一个个控制器改过来的人