本周先做这件事：普通用户留意常用网站的官方通知，不必因为 PHP2Shell 恐慌；负责 PHP 网站的你应立即核对运行版本、软件包来源和部署方式，并按维护方公告更新。PHP 被许多网站使用，不代表这个 PHP 漏洞会自动影响全球大部分网站；实际风险取决于漏洞条件是否与你的环境相符。
你担心个人账户或常用网站，可以先看清自己需要采取的措施。
你负责 PHP 网站或运维工作，可以按文中的核查清单确认修复状态。
你需要解释事件影响范围，可以用后文的数据口径区分潜在暴露、攻击尝试和已确认受害。
最后更新于 2026 年 10 月 23 日；信息核对自 PHP 项目公告、CERT-EU、AWS Threat Intelligence、Wiz Research 与 W3Techs。
PHP2Shell：PHP 使用广泛，不等于全球大部分网站都受影响
结论先说：这个事件值得网站运营者尽快核查，但“全球大部分网站已受影响”并不是现有证据能支持的结论。普通用户通常无需采取紧急设备处置；关注常用服务的官方通知即可。
PHP 项目在 2026 年 10 月 21 日发布针对两项 PHP 核心漏洞的安全更新，编号为 CVE-2026-109618 和 CVE-2026-109619。官方说明，漏洞可能导致远程代码执行，风险涉及对外处理网络请求的 PHP 部署；项目同时提供了修复版本，并建议用户更新。详细信息可查阅PHP 官方安全公告及两项核心漏洞安全通告、第二项漏洞通告。
PHP 确实很常见。W3Techs 于 2026 年 10 月 23 日给出的统计是：在其能够识别服务器端编程语言的网站中，69.3% 使用 PHP。这个数字是技术使用率，不是漏洞命中率，也不是受害者比例；统计的分母、技术识别方式与漏洞扫描结果都不同。(W3Techs 的 PHP 使用率统计)
为什么会有人说“影响面很广”？因为漏洞在 PHP 核心，而不是某个特定网站应用的代码；如果某项服务运行在受影响的 PHP 构建上，应用本身写得是否安全并不能单独排除风险。研究人员报告称，他们在测试环境中对 WordPress、Drupal 和 Joomla 等应用演示了利用。这能说明多个应用栈可能涉及，不能证明所有使用这些程序的网站都处于可利用状态。(Wiz Research 的 PHP2Shell 技术分析)
⚠️ “某技术被很多网站使用”只能提示潜在覆盖面，不能替代对具体版本、部署和补丁状态的核查。
漏洞普遍存在与实际可利用，差在版本和部署条件
判断 PHP2Shell 风险，至少要把三件事分开：网站是否运行 PHP、运行的 PHP 构建是否有修复、漏洞触发条件是否能在该部署中实现。少核对其中一项，就容易把潜在风险说成已确认入侵。
官方安全公告涉及的两条维护分支修复版本为 PHP 8.2.35、8.3.36、8.4.27 和 8.5.12。对这些上游分支，低于对应修复版本的构建需要进一步核实。PHP 项目也提醒，8.1 及更早版本不再由上游常规维护；部分操作系统或长期支持供应商可能提供回补，旧分支的具体处理不能只照抄上游版本号。
漏洞机制也有边界。PHP 公告描述了内存分配异常、请求处理状态未正确复位等问题；研究分析则指出，利用的可靠性会受 PHP 构建、运行方式、扩展和内存布局等因素影响。Red Hat 也说明，其特定标准部署中的 PHP-FPM 与使用 mod_php 的环境，实际利用难度并不相同。利用更难不等于漏洞已修复，不能把某种运行方式当成免疫证明。
因此，“PHP 网站”只是筛查起点，不是最终结论。常见误判包括：把使用 PHP 的比例当作受影响比例；把扫到的旧版本号直接当作可攻陷证据；以及把供应商已回补的包误认成未修复。核对时要看具体发行版公告和实际运行的软件包，而非仅看网站页面或应用后台显示。
普通用户的风险与站长的修复责任并不相同
对普通用户而言，漏洞存在不等于你的手机或电脑感染。PHP2Shell 描述的是服务器端 PHP 的安全问题；可能的后续影响包括服务中断、网站内容被篡改，或网站所持有的数据面临风险，但是否发生以及影响谁，必须由针对具体服务的证据确认。
目前有一项值得认真看待、但不应夸大的攻击线索：AWS Threat Intelligence 报告称，其 MadPot 蜜罐遥测中出现了一次可疑 PHP2Shell 利用尝试，时间为 2026 年 10 月 17 日，早于公开披露；公开发布补丁后，也观察到针对传感器的更多尝试。AWS 同时指出，这些尝试是否能在真实系统上成功尚不清楚。它证明有攻击活动或尝试的迹象，不等于确认有相应数量的真实网站被攻陷。(AWS Threat Intelligence 的观察报告)
你可以先按这份清单处理：
- ✅ 查看常用服务的官方公告；没有具体通知时，不必因为它使用 PHP 就自行认定账户泄露。
- ✅ 对确有异常的账户，从服务官方应用或书签进入，检查登录记录；如果密码在多个服务重复使用，优先更换重复密码。
- ✅ 开启服务提供的多因素验证，并留意官方对密码重置、数据泄露或服务中断的说明。
- ❌ 不要打开来源不明的“受影响网站名单”，也不要转发未经核实的受害者数量。
- ❌ 不要把访问 PHP 网站等同于本机感染；设备防护、浏览器更新等常规安全措施继续保持即可。
如果你使用 Hashvps 的服务，可先查看 Hashvps 帮助中心中的相关服务说明；如需确认 Hashvps 服务相关信息，也可通过 Hashvps 联系渠道咨询。这些渠道不能代替其他网站或平台发布的安全公告。
站长从公告核对到修复复核，按顺序推进
如果你负责网站，先确认“实际运行在哪里”，再对照公告。容器、面板托管、共享主机和自行编译环境的补丁来源可能不同；网页上显示的版本号也不一定能说明供应商有没有回补。
本周核查清单：
- 盘点入口。 列出对外处理 PHP 请求的站点、容器、后台任务和测试环境，确认哪些接收不可信的网络请求。
- 确认运行时。 在服务器、容器或托管商控制面板确认实际 PHP 版本、运行模式及安装包来源。不要只看开发机版本。
- 对照两项漏洞公告。 核对 CVE-2026-109618 与 CVE-2026-109619 的受影响条件，并查看所用发行版或托管平台的独立公告。
- 应用维护方修复。 上游维护分支按公告升级到对应修复版本；旧分支则确认供应商是否提供明确回补。不要凭猜测套用别的发行版补丁。
- 复核进程和实例。 更新后确认实际服务进程已加载新包；若有多个容器、节点或 PHP-FPM 工作进程，逐一核实，而不是只检查一个入口。
- 按公告检查线索。 结合服务日志、异常进程与文件变更进行排查。AWS 提到可留意上传请求中的
PHP_SESSION_UPLOAD_PROGRESS字样，但单一日志特征不能独立证明遭到攻击或排除入侵。
版本决策对照：
| 你的环境 | 判断依据 | 下一步 |
|---|---|---|
| 使用 PHP 8.2、8.3、8.4 或 8.5 上游版本 | 与 PHP 公告列出的分支修复版本对照 | 更新到相应修复版本或更新的安全版本 |
| 使用 PHP 8.1 或更早分支 | 上游不再常规维护；发行版或长期支持供应商可能另有回补 | 查供应商对两项 CVE 的明确公告；无法确认时升级到受支持分支 |
| 使用容器或托管环境 | 镜像、宿主机软件包和实际运行进程可能不一致 | 同时核实镜像更新、实例重建和服务进程状态 |
| 暂时无法更新 | 官方说明临时缓解措施不能替代完整修复 | 尽快按 PHP 及供应商公告缩小暴露面，并安排修复和复核 |
项目公告列出的维护版本之外，旧分支与第三方软件包的修复状态可能不同。PHP 官方说明部分发行版和长期支持供应商会提供回补；因此，版本字符串看起来旧，不足以独自判定未修复；看起来新，也不替代包来源和进程核验。
用三种统计口径拆解“全球大部分网站”
“全球大部分网站”需要有覆盖完整、口径清楚的统计才能成立。当前公开资料能确认 PHP 的使用广度、漏洞的存在和修复信息，也能确认部分攻击尝试；这些并不是同一类数据。
| 说法 | 实际衡量的对象 | 能否直接证明网站受害 |
|---|---|---|
| PHP 使用率 | 某项技术在特定样本网站中的使用比例 | 不能；不说明 PHP 版本和补丁状态 |
| 潜在受影响实例 | 符合公告所列版本、配置与部署条件的服务 | 不能；还需评估利用前提与实际暴露情况 |
| 已确认遭利用或入侵 | 有证据表明攻击尝试成功、造成未授权影响的实例 | 可以说明具体事件，但不能推算全球总比例 |
目前没有可靠公开统计能把全球网站逐一对应到其 PHP 构建、补丁状态、运行配置和入侵情况。W3Techs 的 PHP 使用数据可以解释为什么漏洞受到广泛关注，但其调查本身并不是漏洞扫描或受害者清点。Wiz 的复现展示了特定环境下的利用可能性；AWS 的蜜罐观察则报告了尝试，并明确指出真实系统上的成功情况不明。
因此，“PHP 被大量网站使用”有统计依据；“PHP2Shell 已影响全球大部分网站”则缺少同等口径的证据。把后一句当成已证实结论，会混淆技术普及率、漏洞实例数与确认受害数。
对比结论与行动优先级：能确认什么，仍不能确认什么
截至 2026 年 10 月 23 日，可确认的是：PHP 项目发布了两项核心漏洞公告与修复版本；多个安全机构和研究团队分析了影响条件；AWS 报告了攻击尝试和蜜罐观察。仍不能据此确认全球受影响网站比例、真实受害者总数，或某个具体网站已经被入侵。
| 对象 | 已有证据支持的判断 | 现在最合适的动作 |
|---|---|---|
| 普通用户 | 漏洞在服务器侧；不能仅凭访问 PHP 网站判定设备感染 | 关注常用服务通知，只有出现账户异常时再按服务指引处置 |
| PHP 网站运营者 | 影响范围由 PHP 构建、补丁来源与部署条件决定 | 核对公告、更新包和实际进程，无法确认时向托管或系统供应商求证 |
| 需要传播事件信息的人 | PHP 使用率与受害者统计不是同一数据 | 引用原始公告，明确标出攻击尝试与确认入侵的差别 |
常见疑问也可以归结为一个判断：风险值得处理，影响规模不能靠标题推算。 对普通用户，最实用的动作是查常用服务公告，而不是猜测自己访问过的网站有没有中招；对站长，则是按官方公告核实运行环境并完成修复。后续若出现可靠的全球统计或具体受害证据，应按其样本与统计口径重新评估，不把推测提前写成结论。
关于 PHP2Shell 的常见问题
PHP2Shell 为什么可能波及很多网站？
漏洞位于 PHP 核心，因此使用符合受影响条件的 PHP 运行时，不同应用程序也可能面对风险。但使用 PHP 的网站总数不等于存在漏洞的实例数；版本、补丁、配置与暴露方式都需要分别核对。
PHP2Shell 已经影响全球大部分网站了吗？
没有可靠的全球受影响网站总数或受害者统计支持这一说法。公开报告中的 PHP 使用率是技术普及数据，蜜罐里的攻击请求是尝试记录；两者都不能直接当作成功入侵的网站数量。
普通用户遇到 PHP2Shell 应该做什么？
留意你常用网站或服务的官方通知，不要因为访问过 PHP 网站就认定设备感染。若收到可信的账户异常通知，再从官方入口检查登录活动，并按服务方建议更换密码或启用账户保护。
PHP 网站怎么确认是否受到 PHP2Shell 影响？
核实实际运行的 PHP 构建、包来源和服务进程，再分别对照 PHP 项目及操作系统或托管商的公告。旧分支可能有供应商回补，版本号本身不足以判定修复状态；仍不确定时应请维护方确认。
等后续公告更新时，请以 PHP 项目、操作系统供应商以及你实际使用的服务所发布的安全通知为准。普通用户按官方通知关注账户即可；网站运营者应尽快完成环境核查、补丁确认与必要的日志复核，不要把尚未证实的全球影响比例当成处置依据。
先核实影响范围，再按步骤排查
先对照官方安全公告确认受影响的 PHP 版本、配置条件与修复版本，别只凭 PHP 的普及率判断风险。
如果你维护网站，先查清线上实际运行的 PHP 版本和部署配置，再按公告逐项确认是否命中漏洞条件。