一个 PHP 高危漏洞，揭示 Web3 链下基础设施不容忽视的安全风险。
文章作者、来源：慢雾科技
发生了什么
10 月 21 日，PHP 项目发布紧急安全更新，修复 CVE-2026-109618 和 CVE-2026-109619 两个可导致未认证远程代码执行（RCE）的严重漏洞；二者均被评为 CVSS v4.0 9.2 分。PHP 官方明确表示，修复前，所有对外提供 Web 服务的 PHP 安装都可能受到影响。
(https://www.php.net/index.php#2026-10-20-1)
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 这些大家熟悉的系统，底下都是它。
各国的反应也说明了问题——荷兰国家网络安全中心曾预防性关闭网站；韩国总统办公室召开紧急网络安全会议，政府上调了网络安全警报级别。
(https://x.com/ncsc_nl/status/2112874187719385243)
另外，据报道，朝鲜几乎所有官方网站，包括官方媒体和政府门户网站，已离线超过 24 小时，目前尚未得知是否与该漏洞事件有关。
对 Web3 的影响
这不是一个只关乎传统网站运维的问题。对 Web3 而言，链上合约即使没有漏洞，但围绕合约运转的大量"链下环节"，包括前端页面、API、托管钱包、签名服务、空投领取页、运营后台和数据服务，很多是用 PHP 搭的（WordPress、WooCommerce、Magento 等）。合约本身没有漏洞，也不代表这些环节安全。
据慢雾(SlowMist) 旗下威胁情报系统 MistEye 统计，其扫描的 1488 个加密行业相关域名中，793 个具有直接 PHP 指纹，约为 53.3%。需要强调，这只说明用了 PHP，不代表这些网站有漏洞或已被攻破。
1. 平台方：几条典型的风险路径
前端被篡改，用户被诱导签名。如果 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，要看具体产品的技术栈。
但需要注意的是，服务器被攻陷，不等于链上资产一定被盗。 从 Web 服务被入侵到真正损失资金，中间还要看攻击者能不能接触到敏感凭证、签名流程、管理权限或用户交互环节。热钱包是否与 Web 层隔离、密钥是否放在 HSM/KMS 里、权限是否最小化，直接决定损失的上限。
2. 普通用户：要不要把币提走？
不需要。 原因很简单：
这次漏洞影响的是满足特定条件的服务器环境，不意味着所有用户的钱包都有风险。
浏览网站、连接钱包，与私钥泄露不是一回事。漏洞本身并不能直接破解用户的钱包或签名。
某个项目可能用了 PHP，不代表它已经出事。没有理由假设每个交易所都已被入侵，更不必因此提走全部资产。
用户真正要警惕的，是自己访问的网站是否已被攻陷。用户没办法判断一个网站有没有打补丁，所以这轮事件是个提醒：不要盲目信任网站界面。攻击者还可能借舆论热度传播假登录页、假补偿入口、恶意的钱包连接请求。
如果项目官方确认网站或后台遭入侵，就按公告披露的实际影响判断是否暂停交互、检查异常交易、撤销可疑授权。如果确认签名私钥或助记词已泄露，要按密钥泄露事件处理，光改密码或断开网站连接是不够的。用交易机器人、自动化执行工具或云部署服务的用户，也要留意相关服务是否发布了受影响版本或凭证轮换通知。
如何应对
1. 平台与项目方：
第一步：摸清家底，尽快升级
- 盘点所有公网和内网的 PHP 资产：主机、容器镜像、Kubernetes 工作负载、遗留 CMS、管理后台、合作方托管环境、第三方插件和托管服务。技术指纹只能当线索，不能直接当作"确认有漏洞"的结论。
- 升级到 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12，或采用发行版、云厂商、托管服务商提供的等效补丁。使用 8.1 及更早版本的，要向供应商要 backport 或尽快迁移。"旧环境稳定"”应用不常更新"都不能降低这个漏洞的风险。
- 升级后重建容器镜像、滚动重启或替换所有 PHP 工作进程，并核对线上实际处理请求的运行时版本，而不只是构建机或命令行里的版本。
第二步：暂时没法升级怎么办
先把暴露面缩小，争取时间，但这不能替代补丁：
- 隔离公网暴露的 PHP 应用，或在入口层加网络认证与访问控制。
- 关闭不必要的文件上传，在 WAF 或 Web 服务器层拒绝不需要的 multipart/form-data 请求。
- 部分安全建议还包括：设置 memory_limit=-1、关闭 session.upload_progress.enabled，PHP 8.5 上再关闭 fatal_error_backtraces。这些配置有业务和可用性上的副作用，要先测试，每次改动后重启所有 PHP worker。
第三步：查有没有被入侵，并清理凭证
- 对曾暴露在公网的受影响服务，结合日志、终端监测和异常网络连接排查，比如 PHP 进程突然去启动系统命令。发现疑似入侵，先保留证据，再按事件响应流程处置。
- 假设最坏情况：对未及时修补的服务器，轮换 API 密钥、会话密钥、TLS 证书、数据库密码、云访问令牌、CI/CD 凭据、RPC/API Key、Webhook 密钥和第三方 Token，并核查是否有异常使用记录。
- 如果环境里装过或运行过已确认被污染的软件版本，光升级或重装不能说明风险已消除，还要排查凭证泄露和持久化后门，必要时重建一个干净的环境。
第四步：守住资产控制面
补 PHP 不应该是唯一的动作。更要保证"一台 Web 机被攻陷，不会连累资金系统"：
- 把热钱包、归集钱包和关键签名服务的私钥，从 Web 节点上彻底隔离。使用 HSM、MPC、专用签名网络或最小权限的 KMS 策略。
- 把 Web 服务、签名服务、链上节点、数据库和构建系统放进不同的网络分段与身份边界。
- 事件期间临时收紧高风险操作，如提现、地址白名单变更、管理员提权、API Key 创建、风控规则修改，必要时启用人工复核或延迟生效。
- 链上自动执行的服务，可根据业务采用独立签名、多签审批、交易额度限制和紧急停用机制。
- 检查网站静态资源、JavaScript 包、反向代理配置、DNS/CDN 规则和交易构造服务，确认没有被插入恶意脚本或被替换。
2. 普通用户：
- 走正规入口：近期尽量通过书签或官方渠道访问平台，警惕任何借"安全事件"名义发来的链接。
- 别只看域名和界面：就算是熟悉的 dApp 域名，页面脚本、交易参数、RPC 配置也可能被服务器端的入侵者替换。
- 签名前逐项核对：接收地址、所在链、授权额度、调用的合约和交易模拟结果。尤其小心 approve 和 setApprovalForAll，对无限额度授权更要谨慎。
- 警惕"补偿"”迁移"”重新验证"：事件期间可能冒出"重新登录"”重新验证钱包"”迁移资产"”领取补偿"之类的提示。不要只凭站内弹窗操作，要从项目官方的多个渠道交叉核实。
- 给资产分层：用硬件钱包保管大额资产，日常交互用单独的、限额的钱包，并定期清理授权。这样即使某个前端或平台出事，单次损失也有上限。
- 有异常先停手：遇到异常的签名请求、没预料到的授权提示，或网站行为不对劲，先暂停，再通过官方渠道核实。
最后想说
PHP2Shell 这类免登录的远程代码执行漏洞，一旦突破 Web 层，传统的服务器入侵就可能演变成前端投毒、身份冒用、签名权限滥用、热钱包风险，甚至供应链层面的横向渗透。
对平台来说，最优先的事有三件：升级到已修复版本，隔离暂时无法修补的老旧环境，审计密钥与资产控制面。升级之后，还要把排查入侵迹象当作事件响应的一部分。对用户来说，这段时间要少一点对页面界面的盲目信任，签每一笔之前多看一眼。
但也别过度恐慌：漏洞存在，不等于资产一定受威胁；服务器失陷，也不一定导致链上资金损失。真正决定风险大小的，是攻击者能拿到哪些凭证、这些凭证有多大权限，以及项目能多快隔离并撤销这些权限。对 Web3 项目来说，安全建设不仅要想办法阻止攻击发生，更要考虑：某个组件真被攻陷时，能不能把影响限制在局部，不让风险蔓延到核心业务和资产环节。