PHP2Shell将在企业环境残留数年，资产可见性不足加大修复难度
PHP2Shell高危漏洞已遭在野利用，因资产可见性不足、补丁落地难，将在企业环境残留数年，危害或超Log4Shell。
PHP被打包集成在第三方产品、长期支持（LTS）Linux发行版、预构建容器、虚拟机与固件镜像中，这意味着企业面临的真正挑战不止漏洞本身，更在于资产可见性不足，以及上游补丁是否可用。
图片来源：James Hammond / Unsplash
上周，全球应用最广泛的Web应用运行时PHP曝出两个高危漏洞，官方照例发布通告要求用户立即打补丁。但PHP已被广泛集成到各类第三方产品中，这些产品的补丁周期完全由厂商掌控，客户无法自行决定，因此CISO在未来数年内都要持续应对这些漏洞带来的长尾风险。
NAS设备、防火墙、VPN网关、打印机、楼宇管理面板、工业IoT设备，以及运营技术（OT）网络内的人机界面（HMI），都配有基于PHP运行时的Web管理面板。这些运行时大多无法直接打补丁，不少还属于已停止支持的版本，根本没有上游补丁可用。
广泛使用的技术中存在的漏洞往往会残留数年，部分部署场景永远无法打补丁——这些部署位于已停止支持但仍在服役的产品中。2021年12月Log4Shell漏洞披露后一年，仍有近四分之三的企业资产存在这一高危Log4j Java库漏洞风险，整个2023年，该漏洞都是真实攻击中最常用的攻击向量。
对于无法识别并修复所有受影响资产的企业而言，PHP2Shell（CVE-2026-109618、CVE-2026-109619）的危害可能比Log4Shell更严重，目前相关攻击已经启动。周一，CISA将这两个漏洞列入其已知被利用漏洞目录，证实漏洞已遭在野利用。此前研究人员曾观测到大规模扫描和漏洞利用尝试，但当时尚未确认有生产系统被攻破。
Forescout威胁狩猎高级经理Sai Molige通过邮件向CSO表示：“PHP2Shell有可能成为Log4Shell级别的安全事件，但原因有所不同。Log4j的核心问题是企业找不到自己都不知道存在的依赖库；PHP的问题则是，很多被遗忘的基础设施能被找到，但根本没有对应的上游补丁。”
第三方设备和软件产品的补丁往往需要数周时间才能由厂商推送，在此之前，安全团队必须在互联网边界和内部网络层面通过其他方式降低暴露面。而所有防护工作的前提是梳理出所有受影响资产，这对这两个漏洞而言并非易事。
官方修复版本已发布，实际补丁落地阻碍重重
PHP项目已发布PHP 8.5.12、8.4.27、8.3.36、8.2.35作为官方修复版本，但由于PHP的分发机制特殊，仅靠版本号判断是否修复远远不够。大多数服务器运行的Linux发行版通过自带包管理器推送应用更新，其中LTS发行版往往会打包较旧的PHP版本。很多情况下，这些发行版的包维护者需要手动将补丁反向移植到对应版本中。
举例来说，PHP 7.4、8.0、8.1虽然仍被广泛使用，但官方已停止支持。PHP开发者为这些版本发布了最基础的源代码反向移植包，帮助包维护者完成适配，但PHP 7.3及更早版本完全没有覆盖。漏洞情报公司VulnCheck扫描了260万台面向互联网的PHP主机，发现42%的主机运行已停止支持的PHP分支，其中27%运行PHP 3.x到7.3版本，15%运行PHP 7.4、8.0或8.1版本。
LTS发行版获取补丁的方式取决于其打包的PHP版本。Ubuntu 22.04用户可免费获取PHP 8.1的更新补丁；Ubuntu 20.04的PHP 7.4补丁需要用户订阅Pro服务才能获取；Debian 11内置PHP 7.4的补丁需要用户购买Freexian扩展支持合约才能获取；AlmaLinux 8则为已停止支持的PHP 7.2、7.3、8.0提供了反向移植补丁。Red Hat Enterprise Linux、SUSE、Alpine、Amazon Linux各自划定了支持边界，直接决定不同发行版版本是否能获取对应补丁。
反向移植补丁的版本号可能与上游版本不一致，进一步增加了资产梳理的难度。例如AlmaLinux修复后的版本号为php-8.3.33-1.el10_2.alma.1，低于上游对应分支的修复版本号8.3.36。如果扫描工具仅读取PHP版本标识，就会误将已经打了补丁的主机判定为存在漏洞。除此之外，各类第三方企业产品的预构建容器、虚拟机、固件镜像都内置了独立的PHP运行时，这类资产很难通过自动化扫描工具排查。
软件供应链安全公司Echo联合创始人兼CTO Eylam Milner表示：“PHP团队在极其棘手的情况下已经做得很好。大多数企业的问题在于根本不知道自己在哪里运行了PHP。它存在于基础镜像、内置独立运行时的组件中，很多还运行着8.2以前的版本，这些版本早就过了支持周期。”
目前尚无公开数据统计有多少企业设备、IoT或OT设备运行存在漏洞的PHP版本，但这类设备确实存在，部分还可直接从互联网访问。安全公司Flare整合了多来源的互联网扫描数据，覆盖224个国家的2220231条PHP主机服务记录。研究人员对美国某一个州的区域样本分析后，识别出了存在漏洞的NAS设备、VPN网关、远程访问门户、楼宇自动化系统和物理访问控制器。
TrendAI AI安全与威胁研究副总裁Tom Kellermann表示：“企业仍将PHP视为普通的应用依赖，但它往往深度嵌入在设备、托管平台和上游容器镜像中，根本无法在漏洞披露首日完成补丁修复。真正的战斗不只是针对漏洞本身，更是资产可见性的问题。”
工业设备中也存在PHP运行时，这类设备的服役周期可达十年甚至更久，固件补丁的开发和部署都需要很长时间。部分这类设备必须在补丁发布前做隔离处理。
漏洞管理公司Cogent Security在PHP2Shell披露当天扫描了数十家财富500强客户的环境，发现平均每家企业有2266台受影响资产，其中926台正在运行PHP服务，122台直接暴露在互联网上。
本次扫描的范围仅覆盖服务器和虚拟机，不包括硬件设备和OT设备。这意味着企业面临的核心问题不是缺少扫描工具，而是无法实现全类型资产的可见性。因此，企业需要结合多种策略排查环境中所有的PHP安装实例：从基于主机的包管理器上报的版本信息，到网络扫描工具，再到可用的软件物料清单（SBOM）。
补丁到位前需降低暴露面，落实分层防护措施
梳理最新的资产清单固然重要，但即使完整掌握所有PHP安装位置，也无法解决第三方产品内置运行时的补丁问题——这类产品各自有独立的补丁排期和缓解方案，从禁用Web管理界面到完全网络隔离不等。
仅举几个例子：派拓网络（Palo Alto Networks）计划本周为部分PAN-OS设备推送更新；西门子告知客户，其工业网络使用的RUGGEDCOM APE1808设备同样运行PAN-OS，需遵循派拓网络的安全公告执行操作。Delta Controls已经修复了其企业楼宇管理平台enteliWEB，但受影响的暖通空调（HVAC）和房间控制器仍在等待固件补丁。Belden旗下部分NetModule IIoT和工业路由器已确认存在漏洞，但补丁仍在开发中。
部分产品的补丁可能需要数周才能推送，在此之前，企业必须持续关注所用第三方产品的安全公告，针对每个产品落实对应的临时缓解措施。还有部分产品已经停止支持，永远不会收到补丁，尤其是那些支撑企业仍需运行的遗留应用的设备。
对于无法更新的系统，缓解措施分为三类：
- 将存在漏洞的Web应用移出不安全的网络区域
- 在系统前端部署防火墙访问控制
- 评估系统是否已经遭入侵
部分场景下，用户可能不需要通过HTTP或HTTPS进行管理，相同的管理功能可以通过SSH或其他协议实现。例如，Belden和Delta均建议客户在补丁发布前禁用设备内置的HTTP服务器。NetScaler建议客户仅允许受信任的管理网络访问管理GUI和API。
防火墙检测规则存在一定局限性。在应用层，Web应用防火墙（WAF）可以起到一定防护作用，但无法拦截所有滥用multipart数据上传机制的PHP2Shell攻击——WAF通常不会像PHP引擎那样检查Web请求的完整报文主体。WAF可以扫描已知攻击特征，但无法深度解析这类表单上传的内部结构，难以拦截所有变种攻击，攻击者只要调整请求格式就有可能绕过规则。例如，如果WAF仅检查请求的前几KB内容，攻击者就可以在载荷开头填充大量无效数据，将恶意攻击代码推到检测范围之外。
此外，如果攻击者找到后端系统的直接IP地址，就可以完全绕过WAF控制。这并不意味着WAF规则毫无作用，但它不是防御漏洞利用的银弹。云服务方面，AWS、Cloudflare、Microsoft Azure均已推出PHP2Shell的WAF防护规则，很多本地部署的企业级WAF也已添加相关检测能力。
另一类防火墙防护是网络层的入侵防御系统（IPS）。这类防火墙的问题在于，如果未配置HTTPS流量解密，就可能被攻击者绕过。目前各IPS厂商已经发布了检测规则：派拓网络的Threat ID为543004；Check Point的IPS防护规则编号为CPAI-2026-15172；思科Talos发布了Snort规则67359和67360，Suricata规则3000650至3000652也已公开可用。
但部署补丁和其他缓解措施对已经被入侵的系统毫无作用。这些防护措施落地的时间越晚，攻击者入侵服务器的概率就越高。
Exabeam AI战略与安全研究副总裁Steve Povolny表示：“10月21日补丁发布后仅几天，PHP2Shell相关活动就从扫描探测演变为蜜罐上确认的远程代码执行，绝大多数真实损失都发生在这个窗口期。很多站点没有在首日打补丁，部分服务器可能在管理员察觉前就已被入侵，现在安装补丁对上周就已经潜入的攻击者毫无作用。打补丁只是关上了门，没法告诉你谁已经进到了屋里。”
所有检测和防护工作都必须配合日志排查开展，排查范围包括Web服务器访问日志与错误日志、PHP-FPM日志、WAF与反向代理日志、CDN日志、EDR与进程遥测数据、DNS与出网流量日志、认证日志、文件完整性监控数据，以及云审计日志。
全面排查日志与进程，识别已入侵系统痕迹
日志中需要重点关注的指标包括：PHP_SESSION_UPLOAD_PROGRESS标记与PHPSESSID cookie、向不支持上传功能的端点发送multipart/form-data请求、异常偏大或格式错误的multipart请求体、深度嵌套的字段名、单一来源的重复POST请求，以及HTTP 500错误峰值。
管理员还需排查是否存在PHP-FPM、Apache或httpd工作进程衍生sh、bash、curl、wget、base64或各类代码解释器的行为，Web服务账号下是否出现异常子进程、反向Shell、Web工作进程发起的出站连接，以及Web根目录、上传目录、插件目录下是否存在新增或被篡改的.php文件。
安全公司Xint.io的研究人员指出，异常的PHPSESSID cookie长度或损坏情况、异常偏大的会话文件、不明原因的工作进程重启或段错误，也可能是漏洞被利用的迹象。
参考来源：
# web安全 # 企业安全
本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf 客服小蜜蜂（微信：freebee1024）
被以下专辑收录，发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
- 0 文章数
- 0 关注者
