Kanorio 营销团队 · 发布于 2026年10月22日
网站明明运行正常，也没有收到异常通知，为什么突然被要求紧急更新 PHP？2026 年 10 月 21 日，日本首相高市早苗通过公开贴文呼吁网站管理员准备应用 PHP 修补程序，令原本偏向技术性的信息安全议题受到更多关注。
如果您使用 WordPress 建站，这次最需要确认的是：网站实际使用的 PHP，是否已完成安全更新。只在 WordPress 后台更新插件，并不能代替主机端的 PHP 修补。
本文将整理本次漏洞、版本检查方式与不同主机环境的处理步骤，并说明暂时无法更新、更新后出错，以及疑似遭入侵时的应对方案。即使您不是工程师，也能知道该联系谁、该确认哪些事项。
参考资料：高市早苗公开贴文、PHP 官方安全公告
这次公告涉及两项 PHP 漏洞：CVE-2026-109618 与 CVE-2026-109619，可能让未登录的攻击者在受影响环境中执行代码。问题位于 PHP 执行环境，并非某一款 WordPress 插件的专属漏洞。
您可以将 WordPress 理解为网站的内容管理工具，而 PHP 则是支撑其运作的一部分。即使 WordPress 本身已更新，底层 PHP 仍可能需要另外处理。官方也提醒，风险不只存在于单一服务器部署方式。
然而，“网站存在漏洞”、“网站暂停服务”与“网站已遭入侵”是三件不同的事。例如日本财务省公告，为了紧急检查与应用修补，暂停部分内容及服务。这类预防性停站，不能直接解读成网站遭黑。
对网站经营者而言，现在应优先确认自身环境，不必等待网站出现异常才处理。
参考资料：PHP 官方安全公告、日本财务省｜因应 PHP 漏洞暂停部分服务公告
进入 WordPress 后台的“工具 → 网站状态”，切换至信息标签，查看服务器相关信息；界面名称可能因版本与语系略有不同。您也可以请主机商提供网站目前实际执行的 PHP 完整版本。
不要只记录“PHP 8”，应取得完整版本号。同一个主机账号下的不同网站，也可能使用不同版本，需要分别确认。
参考资料：WordPress｜网站状态信息
截至本文更新日期，PHP 官方发布的本次修补版本如下：
| PHP 分支 | 本次修补版本 | 处理方向 |
|---|---|---|
| PHP 8.2 | 8.2.35 | 更新至此版本，或含相同修补的后续版本 |
| PHP 8.3 | 8.3.36 | 更新至此版本，或含相同修补的后续版本 |
| PHP 8.4 | 8.4.27 | 更新至此版本，或含相同修补的后续版本 |
| PHP 8.5 | 8.5.12 | 更新至此版本，或含相同修补的后续版本 |
| PHP 8.1 及更旧分支 | 不适用上述一般更新路径 | 向供应商确认回补修正，并安排升级 |
部分 Linux 发行版或长期支持供应商会将修正回补到既有套件，因此不能只凭画面上的版本号判定。若主机商表示已修补，请取得对应公告、套件版本或修补记录，确认涵盖上述两项 CVE。
旧分支即使取得本次回补，也不代表恢复完整的长期安全支持。
| 网站环境 | 优先联系对象 | 需要确认的事项 |
|---|---|---|
| 共享主机／虚拟主机 | 主机商客服 | 是否已修补、是否需要自行切换 PHP、网站何时生效 |
| 托管 WordPress | 托管服务商 | PHP 更新是否包含在服务内、完成时间与验证结果 |
| 自管 VPS／云端主机 | 工程师或系统管理员 | 所有对外服务实例是否已更新，旧程序是否已替换 |
| 委外建站但维护分工不明 | 建站公司与主机商 | 由谁执行修补、由谁测试网站、由谁汇报完成 |
这张表是联系分工建议，实际责任仍须依您的服务合约确认。网站由别人制作，不代表后续 PHP 更新一定有人代为处理。
操作提醒与免责说明：本文依截至 2026 年 10 月 22 日的官方公告整理，供修补参考，不构成个别网站的信息安全诊断或安全保证。不同主机、主题与插件的兼容性可能不同，操作前请确认备份可还原，并由主机商或维护人员确认适用方式。若疑似已遭入侵，应另行调查，不能仅以更新完成判定安全。
更新前，确认网站文件与数据库都有备份，也确认由谁负责还原。只下载文章内容，通常不足以还原整个网站。
但不要因为备份或测试需要时间，就让尚未修补的网站持续暴露。若无法立即处理，应请维护人员评估先限制外部存取，再完成备份与更新。
若已出现疑似入侵迹象，请先保留记录与环境快照；这份快照应标示为待调查资料，不能直接当成干净备份使用。
参考资料：WordPress｜更新 PHP 前的准备、WordPress｜网站遭入侵时的处理、CERT-EU｜修补与隔离建议
共享主机使用者应依主机商公告或客服指示操作；若控制台只能选择“8.3”或“8.4”，仍要确认背后实际应用的修补版本。
自管主机则由系统管理员依操作系统、套件来源或容器部署方式更新。本文不提供一组通用指令，因为不同环境的套件名称与服务管理方式并不相同。
本次修补的重点是 PHP 执行环境。WordPress 核心、主题与插件仍应维持更新，但不能把这些更新当成 PHP 已完成修补。
参考资料：PHP 官方安全公告
请维护人员确认相关服务已依部署方式重启或重新部署，没有继续使用旧的 PHP 工作程序。若网站有多台主机或多个容器，应逐一确认。
不要只依命令行上的 PHP 版本结案。命令行与网站服务可能使用不同执行环境，验证对象应包含实际响应访客请求的服务。
这是更新验收的实务重点：套件已下载、控制台已切换与网站已使用修补版本，不能只看其中一项。
建议至少完成以下检查：
这份清单用来确认修补与基本功能，不等同于完整的入侵鉴识或信息安全审计。
例如，一间使用共享主机的设计工作室，收到漏洞消息后，可以先整理网站网址与 PHP 版本，请主机商确认修补，再由原建站人员测试作品页与询价表单。完成的依据应是修补记录与测试结果，而非单纯“首页打得开”。这是处理流程示例，并非实际客户事件。
不要将插件或防火墙视为完整修补。
Cloudflare 已公布针对本次漏洞的防护措施，但网站仍需更新 PHP。是否有流量经过防护、规则是否适用，以及来源主机是否还有其他可直接存取的路径，都需要管理员确认。
若短时间内无法修补，CERT-EU 建议评估将受影响服务与公开网络隔离，待修补并验证后再恢复。技术上的临时设置也有适用限制，应交由维护人员评估，不建议一般网站经营者照抄陌生设置。
尤其要注意：开启 WordPress 维护模式，不一定能阻止请求到达有漏洞的 PHP。部分攻击路径可能在网站应用程序执行前触发，因此维护页面不能直接视为完成隔离。
参考资料：Cloudflare｜本次 PHP 漏洞防护说明、CERT-EU｜PHP 重大漏洞处置
更新后的错误可能与主题、插件或自定义程序的兼容性有关，应请维护人员查看错误记录，再调整相关组件。
不要只为恢复画面，就把公开网站切回尚未修补的 PHP。若必须回复环境进行排查，应先限制外部存取，再安排能正常运作且已修补的版本。
这些都是需要调查的警讯，但不能仅凭其中一项，就判定一定由本次漏洞造成。
请联系主机商或信息安全维护人员，保留存取记录、错误记录与环境快照，依情况隔离网站、清理或重建环境，并处理可能外泄的账号凭证。不要急着删光异常文件，令后续无法追查。
更新 PHP 能处理漏洞，却不会自动移除已植入的后门。同样地，还原备份也需要确认备份时间、内容是否干净，以及恢复后的环境是否完成修补。
参考资料：WordPress｜网站遭入侵时的处理
这次事件也提醒小品牌，选择建站工具时，应确认日后由谁负责安全更新与异常处理。
以 Kanorio 为例，公开网站采用 Cloudflare 边缘网络，提供 DDoS 缓解与 WAF 防护，并自动管理 SSL 证书及 HTTPS 连接，减少品牌自行设置基础防护的工作。但这些措施不代表零风险；经营者仍需保护账号并留意异常。本文也不以这些功能推定平台对本次漏洞完全不受影响。
详情请见：Kanorio 网站信息安全保障
需要分开确认。WordPress 是网站应用程序，PHP 是底层执行环境；本次漏洞的修补重点在 PHP，请取得主机端的修补确认。
网站可正常开启，不能证明没有风险。应尽快确认修补状态；无法立即更新时，与维护人员讨论限制存取或暂停服务。
可能是供应商采用回补修正。请主机商提供套件或安全公告，确认涵盖 CVE-2026-109618 与 CVE-2026-109619，不能只靠口头表示“有防护”判定。
参考资料：PHP 官方安全公告
不能直接这样判断。备份可能已包含异常内容，恢复环境也可能仍使用未修补 PHP；疑似入侵时，需另外调查与验证。
参考资料：WordPress｜网站遭入侵时的处理
如果您现在不知道从哪里开始，先找出主机商或维护窗口，确认三件事：网站实际使用哪个 PHP 版本、这次两项漏洞是否已修补、由谁验证更新后的功能。
对没有工程人力的工作室与小品牌，往后评估建站服务，也应把安全更新与维护分工纳入考量。可从 Kanorio 信息安全保障说明了解平台提供的基础防护，再依网站需求安排适合的维护方式。