PHP2Shell.help
简体中文
菜单
PHP 8.2–8.5 修复版本已发布 独立社区资源 · 事实核实于 2026年10月22日
PHP 8.2–8.5 修复版本已发布

PHP2Shell 检测：你网站的 PHP 受影响吗？

我在运营网站：检测我的 PHP → 我只是普通上网用户

PHP2Shell 是 PHP 运行时本身的两个严重漏洞，可能让攻击者不登录就在服务器上执行代码。官方已发布修复版本：8.2 分支升级到 8.2.35、8.3 到 8.3.36、8.4 到 8.4.27、8.5 到 8.5.12 或更高。先确认网站实际在用的 PHP，再按环境升级并重启 PHP。只更新 WordPress 或插件修不了它。

PHP2Shell.help 编辑部核实日期 官方来源 ↓

检测你的 PHP 是否受 PHP2Shell 影响

你填写的内容只在浏览器里判定，不会发送。 访问统计说明

在主机控制面板里能看到，或 WordPress 后台「工具 → 站点健康 → 信息 → 服务器」。
我们不会访问你的服务器。

输入网站使用的 PHP 版本，我们会和该分支的首个修复版本比较，并告诉你下一步怎么做。

关于 PHP2Shell，需要先了解什么？

先看 PHP2Shell 是什么、谁发出了提醒，以及哪些已经确认、哪些还没有确认。

PHP2Shell 是什么？到底有多严重？

PHP2Shell 是研究人员给两个 PHP 漏洞起的统称，官方编号是 CVE-2026-109618 和 CVE-2026-109619。一个出在 PHP 内存不足时的清理过程，一个出在请求结束后残留的全局状态被下一个请求误用。两个问题都在 PHP 运行时里，不在 WordPress、Laravel 或任何具体程序里。

严重程度很高：远程代码执行意味着攻击者可能以网站进程的身份运行命令，改网站文件、读取配置里的数据库密码、留下后门。PHP 官方在 GitHub 发布的两份安全公告给出的 CVSS 4.0 评分都是 9.2（严重）。原始研究报告称在 WordPress、Drupal、Joomla 的部署上演示了无需登录的代码执行，并有单独的内存泄露问题。腾讯云的官方风险通告也把它定为“高风险”。但是否真的能被攻破，取决于 PHP 版本、运行方式和配置，所以第一步是查清楚自己的环境。详细解释见 PHP2Shell 漏洞说明。

我只是上网、没有自己的网站，需要做什么吗？

不需要动手。PHP2Shell 是网站服务器上的漏洞，修复责任在网站和服务器的运营方。普通网民不需要关机、断网、卸载 App，也不需要更新手机或电脑上的什么东西——这些设备一般不跑会受影响的 PHP 网站服务。

真正需要注意的有两件事：

  • 如果某个网站或服务正式通知你改密码，再去改。不要因为新闻就把所有密码都换一遍，也不要在通知以外的地方输入密码。
  • 借热点诈骗的邮件、短信会变多。凡是“你的账号受 PHP 漏洞影响，请点击链接验证”“请下载补丁”之类的消息，一律当钓鱼处理。

各国政府和官方机构怎么说？

十几个国家和地区的政府与网络安全机构已经就 PHP2Shell 发出公告或提醒。共同点是尽快升级到修复版本；日本、美国、英国等多家机构还建议，来不及升级就考虑先让网站或服务下线。

中文地区里，香港政府电脑保安事故协调中心（GovCERT.HK）发布了高危保安警报，新加坡网络安全局（CSA）也发了公告。中国大陆和台湾地区的国家级机构是否发布过公告，本站暂未核实到。企业方面，腾讯云 发布了风险通告；阿里云漏洞库 的首页列表收录了 CVE-2026-109618，定级高危，详情页本站未能打开，细节未核实。

国家/地区机构公告
中国香港特别行政区GovCERT.HK「PHP 多个漏洞」高危保安警报，涵盖两个 CVE。
新加坡CSA / SingCERT可被利用实现未经认证的远程代码执行，请立即打补丁。
日本国家サイバー統括室（NCO）尽快应用 PHP 修复；无法及时修复时，暂停网站也是有效选择。
日本内閣総理大臣紧急呼吁：确认是否使用 PHP、应用修复、无法修复时考虑暂停网站，并关注 NCO 的信息。
日本警視庁サイバーセキュリティ対策本部呼吁做好应用 PHP 修复的准备。
日本IPA（情報処理推進機構）盘点 PHP 的使用情况（含产品和设备内置），停止使用已停止维护的版本，修复发布后尽快应用。
美国NSA Cybersecurity使用 PHP 的组织应立即更新；无法更新时考虑将受影响服务下线。
英国NCSC8 项优先行动：盘点 PHP、升级、加固；无法缓解时下线服务并排查后门。
欧盟CERT-EU立即打补丁；无法打补丁则隔离对外应用。临时措施只能降低暴露，只有升级才是完整修复。
德国BSI补丁发布前预警：可能存在无需认证的远程代码执行；当时未确认有利用。
法国CERT-FR (ANSSI)警报公告：隔离受影响系统并迁移到受支持版本；临时绕过措施未经 CERT-FR 验证。
西班牙INCIBE-CERT「严重」：列出修复版本和 7.4/8.0/8.1 源码补丁；临时措施不是完整方案。
瑞士BACS / NCSC.ch立即更新，并检查内置 PHP 的内部系统、管理界面和设备。
荷兰NCSC-NL发布公告并维护内置 PHP 的受影响产品清单，被 CERT-EU 和英国 NCSC 引用。
波兰CERT PolskaPHP 存在可远程执行代码的严重漏洞，请立即更新。
美国FBI Cyber Division无法立即更新就下线；盘点 PHP，监控 PHP 进程异常拉起 shell，失陷后向 IC3 报告。
加拿大Canadian Centre for Cyber Security（原文未核实）建议升级到修复版本。

均于2026年10月21日发布。

现在已经有人在攻击了吗？“补丁后 15 分钟沦陷”是真的吗？

已经有人在尝试攻击。Cloudflare 表示在补丁发布前就观察到了针对这两个漏洞的攻击流量，攻击者还在不断变换请求内容。但截至本站核实时，还没有核实到成功入侵的公开案例。

“补丁发布后 15 分钟就会大规模沦陷”这个说法，本站核对的来源里找不到依据：Sansec 只是预计会出现大规模利用，没有给出时间。“几点几分起全网被接管”之类的说法同样未经证实。

网上自称“PoC 已放出”的代码仓库，本站没有验证，也不会链接；这类仓库夹带恶意程序的情况并不少见。不要下载运行来路不明的“检测脚本”或“利用代码”。

“没核实到成功入侵”不等于“没有人被入侵”。补丁已经公开，攻击者可以对比补丁找出漏洞位置，所以不要等。

最近的数据泄露和 PHP2Shell 有关吗？

目前没有公开证据。网上有人把近期的数据泄露事件归到 PHP2Shell 头上，本站没有找到当事公司或调查方的确认。日本不少网站和服务这两天进入维护，XServer、Lolipop 等租赁服务器商在公告里写明是预防性措施，维护不等于被黑。

判断某次泄露的原因，只看当事公司或调查机构的正式说明。

日本为什么这么紧张？

PHP 修复版本在日本时间深夜发布。前后几个小时里，日本首相在 X 上发出紧急呼吁：确认是否在用 PHP、尽快应用修复、来不及就考虑暂停网站；国家网络统括室（NCO）、警视厅也接连发帖提醒。XServer、Lolipop 等租赁服务器商也预防性地暂停了控制面板或部分服务。很多网站同时进入维护，看起来像“日本网站全瘫了”，但服务商公告写的是预防措施；维护本身不等于被攻破。

PHP2Shell 和 wp2shell 是一回事吗？

不是。wp2shell 是 WordPress 核心的另一组漏洞（CVE-2026-63030 等），靠升级 WordPress 修复。PHP2Shell 在 PHP 里，靠升级 PHP 修复。用 WordPress 的网站两样都要保持最新。

我的网站受 PHP2Shell 影响吗？

先查清网站实际使用的 PHP，再和修复版本对照。

我的 WordPress 网站受 PHP2Shell 影响吗？更新插件够不够？

要看 WordPress 下面跑的是哪个 PHP，而不是看 WordPress 版本。只要那个 PHP 低于所在分支的修复版本，网站就在受影响范围内。

更新 WordPress 核心、主题和插件修不了 PHP2Shell，因为漏洞在 PHP 里。WordPress 后台的“工具 → 站点健康 → 信息 → 服务器”能看到当前 PHP 版本。具体步骤见 WordPress PHP 版本。

WordPress 站长的完整自查步骤见 PHP2Shell 与 WordPress。

怎么查我的网站用的是哪个 PHP 版本？

最可靠的是看网站实际在用的 PHP 版本：

  • WordPress：工具 → 站点健康 → 信息 → 服务器。
  • 宝塔、1Panel、cPanel 等面板：看该网站绑定的 PHP 版本，而不是面板默认值。
  • 服务器上：在网站所在的主机或容器里运行 php -v。它显示的是命令行 PHP，可能和网站用的不是同一个，只作参考。

一台服务器装好几个 PHP 很常见，命令行显示新版本不代表网站已经换过去。各种环境的查看方法见 查看 PHP 版本，查到后填进 PHP 版本检测 直接判断，判断只在你的浏览器里进行。

能不能输入网址在线扫描我的网站？

本站不提供输入网址的扫描，原因有两个：网站对外暴露的版本号经常被隐藏或伪造，凭它判断不可靠；我们也不向别人的服务器发送任何探测请求。

可靠的办法是看网站实际运行的 PHP：WordPress 站点健康、面板里该网站绑定的 PHP，或在网站所在的主机、容器里运行 php -v（命令行可能和网站不同，只作参考），然后填进 PHP 版本检测。判断在你的浏览器里完成，填写的内容不会发送。

我的网站是不是已经被黑了？

升级 PHP 只能保证以后，不能证明以前没被入侵。本漏洞目前没有官方公布的、能确定归因的入侵特征。建议先升级，再花点时间检查：有没有陌生的管理员账号、上传目录里有没有 .php 文件、最近有没有自己没改过却被改动的文件、有没有陌生的计划任务。

发现异常先保全日志和现场，再联系主机商或专业人员，不要急着删文件。步骤见 网站被黑检测。

PHP2Shell 怎么修复？

把 PHP 升级到修复版本或发行版的修复包，然后重启 PHP。

PHP2Shell 修复版本是多少？怎么修？

PHP 官方为 8.2 到 8.5 四个分支发布了修复版本，升级到对应版本或更高即可：

分支首个修复版本
PHP 8.28.2.35
PHP 8.38.3.36
PHP 8.48.4.27
PHP 8.58.5.12
8.1 及更早无新发行版（7.4、8.0、8.1 有官方源码补丁）

修的步骤可以概括为三步：确认网站实际用的 PHP → 升级到修复版本或安装发行版的修复包 → 重启 PHP-FPM 或 Apache，再回到网站复查版本。注意 Ubuntu、Debian 这类发行版会把补丁回移到旧版本号里，php -v 数字没变也可能已经修好，要看完整的包版本。各环境的做法见 PHP2Shell 修复。

用宝塔、1Panel 或虚拟主机，没法自己升级怎么办？

先分清 PHP 归谁管：

  • 宝塔、1Panel：PHP 由面板自己安装或用面板的镜像，系统 apt、yum 升级的 PHP 通常不是网站在用的那个。本站还没有核实到宝塔的修复构建和面板内更新步骤；1Panel 官方的 1panel/php 镜像在本站核实时也还没有修复版本的标签。见 宝塔 PHP。
  • 虚拟主机、托管主机：PHP 由主机商安装，你最多能在面板里切换分支。如果面板里没有修复版本，就要找主机商。PHP2Shell 修复 里有可以直接复制的工单。
  • 自己的 VPS：按系统走 Ubuntu/Debian 升级 或 Docker 镜像。

暂时升级不了，至少先做 临时缓解，并认真考虑先暂停网站。

PHP 7.4、8.0、8.1 这些老版本怎么办？祖传项目不敢升级怎么办？

PHP 官方没有给这些停止维护的分支发新的发行版，但为 7.4、8.0、8.1 提供了最小源码回移补丁——需要自己打补丁重新编译，或者等发行版、长期支持厂商出修复包。中文社区流传的“8.1 及以下完全没有补丁”并不准确，但“没有现成可直接安装的官方新版本”是对的。

祖传项目的现实做法：

  1. 先评估能不能暂停对外服务，或只允许内网、固定 IP 访问。
  2. 同分支能升就先升；跨分支（比如 7.4 到 8.3）一定先备份，在副本上测试。
  3. 实在动不了的，用源码回移补丁重新编译，或找提供长期支持的发行版。

完整说明见 PHP 停止维护版本。

怎么跟老板、客户、主机商说明？

说清四件事：查了哪些网站和服务器、各自的 PHP 版本和是否已修复、还有什么没查清楚、谁在什么时候处理下一步。修复进度和“有没有被入侵”分开说，不要承诺“所有网站绝对安全”。

找主机商时，直接问：我的网站用的是哪个 PHP、有没有更新到修复版本或包含修复的软件包、没更新的话什么时候更新。PHP2Shell 修复 里有完整的工单模板。

可以让 AI 登录服务器帮我修吗？

不要把服务器、面板、数据库的账号密码交给聊天工具、陌生人或“帮你修漏洞”的私信。社交平台上流传的“把 CVE 编号丢给 AI、再提供账号密码就能修好”，和钓鱼没有区别。AI 可以解释步骤，登录和执行要自己或可信的运维来做。

暂时没法升级 PHP 怎么办？

临时缓解只能减少特定攻击路径的暴露，都不是修复。

用了 Cloudflare 或云厂商 WAF 就安全了吗？

不算修好。Cloudflare 表示已为启用 WAF 的免费和付费套餐默认部署防护；腾讯云也称其 Web 应用防火墙、云防火墙支持防护。这能挡住一部分已知的攻击请求，但服务器上的 PHP 仍然是有漏洞的版本——绕过 CDN 直接访问源站、或者攻击请求换了花样，防护就可能失效。

WAF 是为你争取时间，不是替代升级。

关掉 session.upload_progress 够不够？

不够。PHP 官方给了几项临时设置，每一项都只能挡住一部分已确认的攻击路径，没有一项能代替升级：

  • 针对 CVE-2026-109619：关闭 session.upload_progress.enabled。必须写进主配置、在请求解析前生效，并重启所有 PHP worker，用 ini_set() 或 FPM 的 .user.ini 改没用。PHP 8.5 还可以关闭 fatal_error_backtraces，同样只针对一条已确认的路径。
  • 针对 CVE-2026-109618：把 memory_limit 设为 -1，并把 post_max_size 调低（不需要上传的网站设 8M，需要上传的设 32M）。前者要留意服务器内存，后者会让大文件上传失败。

全部都只是过渡，详见 临时缓解措施。

PHP 官方公告写得很明确：“only an update is a complete solution”（只有升级才是完整的解决办法）。—— PHP 安全公告

依据哪些来源？

来源

本页的核心事实（修复版本、CVE 详情、发行版软件包、官方机构的提醒）都来自官方来源；研究报告、新闻和社区讨论已分别标注。