本文由查找币安全团队整理，原始来源：BlockBeats（律动），原文作者：慢雾安全团队。以下分析聚焦漏洞技术机理与 Web3 链下风险面，供项目方与用户参考。
一、事件概述：一次被提前的紧急更新
10 月 21 日，PHP 项目发布紧急安全更新，修复 CVE-2026-109618 和 CVE-2026-109619 两个可导致未认证远程代码执行（RCE）的严重漏洞，二者均被评为 CVSS v4.0 9.2 分。PHP 官方明确表示，修复前，所有对外提供 Web 服务的 PHP 安装都可能受到影响。
事态的紧迫性还体现在两个时间点上：
- 细节提前泄露：10 月 20 日，漏洞细节在官方披露前就已泄露，而补丁尚未发布。PHP 安全团队不得不把紧急版本从原定的 10 月 22 日提前到 10 月 21 日 14:00（UTC）发布。
- 攻击早于披露：Amazon 威胁情报团队报告称，他们在 10 月 17 日就在自家 MadPot 蜜罐网络中观察到了针对 php2shell 的利用尝试，比公开披露早了四天。
慢雾（SlowMist）也在 PHP 官方预告发布后第一时间发出了安全提醒和建议。
二、两个漏洞的技术机理
CVE-2026-109618（OOM 内存损坏）
PHP 内存耗尽时，处理流程会被打断，此时手上的数据只准备了一半。收尾清理阶段，PHP 却把这些半成品当成完整数据来使用，导致内存状态错乱。
CVE-2026-109619（陈旧全局状态）
一个请求处理完成后，内存已经释放，但相关状态仍「留在原地」。同一个工作进程接手下一个请求时，可能在正常初始化之前就复用了这份过期状态。官方已确认，可借此攻击 PHP-FPM 并实现远程代码执行。
攻击路径的关键特征
这类漏洞的危险之处在于：攻击者不需要先拿到站点账号，也不用突破业务层的登录、权限或 API Key 验证。只需向暴露在公网的 PHP 应用发送一个构造好的请求，就可能以 Web 服务进程的权限执行任意代码。
影响范围与修复版本
- 受影响版本：PHP 5.4 至 8.5.11
- 修复版本：8.5.12、8.4.27、8.3.36、8.2.35
- 特别提示：PHP 8.1 及更早版本已停止上游常规支持，不能指望常规渠道出补丁，应迁移到仍受支持的版本。
三、为何引发全球性紧张
PHP 的部署基数决定了漏洞的波及面。据 W3Techs 统计，在能识别服务器语言的网站中，69.3% 使用 PHP；WordPress、WooCommerce、Magento 等常见系统底层均依赖它。
各国监管与政府机构的反应也印证了风险等级：荷兰国家网络安全中心曾预防性关闭网站；韩国总统办公室召开紧急网络安全会议，政府上调了网络安全警报级别。另有报道称，朝鲜几乎所有官方网站（包括官方媒体和政府门户网站）已离线超过 24 小时，目前尚不清楚是否与该漏洞事件有关。
四、对 Web3 的真实影响：链上无恙，链下承压
这不是一个只关乎传统网站运维的问题。对 Web3 而言，链上合约即使没有漏洞，围绕合约运转的大量「链下环节」——前端页面、API、托管钱包、签名服务、空投领取页、运营后台和数据服务——很多是用 PHP 搭建的（如 WordPress、WooCommerce、Magento）。合约本身没有漏洞，并不代表这些环节安全。
据慢雾（SlowMist）旗下威胁情报系统 MistEye 统计，其扫描的 1488 个加密行业相关域名中，793 个具有直接 PHP 指纹，占比约 53.3%。需要强调：这只说明这些网站使用了 PHP，不代表它们存在漏洞或已被攻破。
平台方：几条典型风险路径
- 前端被篡改，用户被诱导签名：若 DeFi、钱包类网站或空投页服务器被控制，攻击者可替换页面中的 RPC 地址、授权对象、合约地址或签名提示，把正常交易变成恶意授权、恶意合约交互或假充值流程。攻击者不必攻破合约，只需让用户自己签下一笔恶意授权。
- 密钥与凭证泄露：服务器被控制后，攻击者可能读取配置文件、数据库密码、API Token、环境变量等。若后端用 PHP 对接节点 RPC 或热钱包服务，API Key、会话令牌一旦泄露，可能升级为热钱包资产被转移或签名权限被滥用。
- 后台与 API 被接管：交易平台、NFT 市场、跨链桥、支付网关和节点服务商通常有运营后台，以及 KYC/风控接口、充值地址分配、提现审核、工单系统等。攻击者获取权限后，可能篡改配置、盗取用户数据、创建高权限账号或绕过业务流程。
- 供应链横向移动：PHP 进程权限通常不等于服务器最高权限，但若它能读到 CI/CD 密钥、容器运行时 socket、数据库凭据或云访问令牌，攻击范围就可能从一台 Web 节点扩展到数据库、构建系统，甚至整个生产账号。
- 支付插件与第三方服务：据了解，Binance Pay、Crypto.com Pay、BitPay、CoinGate、CoinPayments 等加密支付方案均有 WooCommerce 集成，服务器未修补即存在严重暴露风险。RPC、区块浏览器、数据分析平台等第三方服务，若后台或运维系统运行在受影响的 PHP 环境上，也可能成为入口。当然，RPC 节点、智能合约、区块浏览器和钱包本身并不天然依赖 PHP，需视具体产品的技术栈而定。
五、用户侧防护建议
- 少问平台，警惕借「安全事件」名义发来的链接：不要只看域名和界面。即便是熟悉的 dApp 域名，页面脚本、交易参数、RPC 配置也可能被服务器端入侵者替换。
- 签名前逐项核对：接收地址、所在链、授权额度、调用的合约和交易模拟结果。尤其小心
approve和setApprovalForAll，对无限额度授权更要谨慎。 - 警惕「补偿」「迁移」「重新验证」话术：事件期间可能出现「重新登录」「重新验证钱包」「迁移资产」「领取补偿」等提示。不要只凭站内弹窗操作，应从项目官方多个渠道交叉核实。
- 给资产分层：用硬件钱包保管大额资产，日常交互使用单独的、限额的钱包，并定期清理授权。这样即使某个前端或平台出事，单次损失也有上限。
- 有异常先停手：遇到异常的签名请求、意料之外的授权提示，或网站行为不对劲，先暂停，再通过官方渠道核实。
六、查找币观察：风险大小取决于凭证与隔离能力
PHP2Shell 这类免登录的远程代码执行漏洞，一旦突破 Web 层，传统的服务器入侵就可能演变为前端投毒、身份冒用、签名权限滥用、热钱包风险，甚至供应链层面的横向渗透。
对平台而言，最优先的三件事是：升级到已修复版本、隔离暂时无法修补的老旧环境、审计密钥与资产控制面。升级之后，还应把排查入侵迹象作为事件响应的一部分。
对用户而言，这段时间要少一点对页面界面的盲目信任，签每一笔之前多看一眼。但也不必过度恐慌：漏洞存在，不等于资产一定受威胁；服务器失陷，也不一定导致链上资金损失。真正决定风险大小的，是攻击者能拿到哪些凭证、这些凭证有多大权限，以及项目能多快隔离并撤销这些权限。
对 Web3 项目来说，安全建设不仅要想办法阻止攻击发生，更要考虑：当某个组件真被攻陷时，能否把影响限制在局部，不让风险蔓延到核心业务和资产环节。
本文由查找币整理，原始来源：BlockBeats（律动）。
原文来源：BlockBeats（律动）。