自己部署的服务器，谁来打补丁？——从 PHP2Shell 说起

2026 年 10 月 21 日，PHP 官方公开了两个漏洞：CVE-2026-109618 和 CVE-2026-109619，行业里统称 PHP2Shell。两个漏洞都在 PHP 解释器本身，而不在 WordPress、Laravel 这类上层框架里；攻击者不需要登录，通过 HTTP 请求就可能在服务器上执行任意代码。PHP 官方给的评分是 9.2（CVSS v4，严重）。根据 W3Techs 的统计，能识别出服务端语言的网站里，69.3% 用的是 PHP。

时间线如下（北京时间）：

这张表里有一件事值得注意：以安全为业务的厂商，在 PHP 官方发布修复之前就已经在保护自己的客户了——Cloudflare 的防护规则在官方修复发布前好几个小时就已上线，Linux 发行版也提前拿到了补丁。而一个自己维护服务器的创始人，最早也要等到新闻出来才知道这件事——那时利用尝试早已开始。

所有软件都有尚未被发现的漏洞，升级首先是为了拿到安全补丁，而不是为了新功能。自己部署服务，就等于自己承担了这份长期的安全维护工作。如果你没有能力、信心或者精力做这件事，那你应该选择一个可靠的替你持续升级基建的平台。

升级不是为了新功能

很多非技术创始人对“升级”的理解是：新版本有新功能，我不需要新功能，所以不用升级。这个推理的前提是错的。

所有软件都有尚未被发现的漏洞。你今天用的版本没有已知漏洞，只说明还没人发现，不说明没有。

看两个例子：

2012 年部署 PHP 5.4 的人，当天拿到的就是一个有漏洞的版本，只是这个漏洞 14 年后才被找到。

而且这个间隔在缩短。AI 让阅读和分析代码的成本大幅下降，找漏洞的成本也随之下降。找漏洞越便宜，被找到的漏洞就越多，需要打的补丁也就越多。这对防守方是好事，前提是有人及时把补丁装上。

这里还要区分两种升级：

补丁更新，比如 8.3.35 升到 8.3.36。只修漏洞，不改功能。下一个 PHP2Shell 出现时，你需要的就是它。

大版本升级，比如 PHP 8.1 升到 8.2。之所以必须做，是因为一个版本到了停止维护（EOL）的日期之后，官方就不再为它发补丁更新了。

第二点是最容易被忽略的。即使你一个新功能都不想要，也躲不开大版本升级——因为只有升级到仍在维护的版本，你才能继续收到补丁。以这次为例，PHP 官方只为 8.2 到 8.5 发布了正式修复版本；而 8.2 本身会在 2026 年 12 月 31 日停止维护。今天“还在维护期内”，两个月后就不是了。

打补丁需要你做什么

对于自己部署服务的非技术创始人，风险来自两件事：不知道有维护这件事，和知道了也没有办法去做。下面三种情况，我认为危险程度是一样的。

情况一：宝塔 + WordPress（或织梦、帝国 CMS），跑在 CentOS 7 上。 几年前找人搭好，之后就没再动过。CentOS 7 自带的 PHP 是 5.4.16，而 CentOS 7 本身已经在 2024 年 6 月停止维护。这次 PHP2Shell，CentOS 7 上的 PHP 没有免费的修复途径：主流的第三方源没有发布修复版本，能拿到修复的只有付费的延长支持服务（例如 TuxCare，起价约 5,000 美元一年）或未经审核的社区补丁。阿里云 Linux 2（兼容 CentOS 7）倒是在 10 月 22 日发布了修复——前提是你知道自己用的是哪个系统。

情况二：用 Trae、Cursor 或 Claude Code 写出来的应用，部署在一台 ECS 或轻量服务器上。 AI 帮你写了代码，也帮你写了 Dockerfile，里面固定了某个版本的基础镜像。你可能并不知道镜像里有什么。这次出问题的是 PHP，下一次可能是 Node.js、Python，或者某个依赖包。AI 可以帮你写升级命令，但它不会在漏洞公开的那天提醒你。

情况三：外包团队做的后端。 项目交付了，合同结束了，服务器的登录方式在某封邮件里。漏洞出来的时候，你不知道该找谁，也不知道该检查什么。

无论哪种情况，PHP2Shell 这一周，你需要完成的是下面这些步骤：

知道这件事。 不是在漏洞公开的一周后，而是在当天。利用尝试在公开之前就已经出现了。

分辨真假信息。 头两天流传的说法里，有“一个请求就能接管全球 70% 的网站”。实际情况是：目前没有人展示过能对任意服务器生效的单个请求，公开的利用代码在默认安装的 PHP 上也无法直接使用；70% 是 PHP 在网站中的占比，不是受影响网站的数量。这两个漏洞的评分，在不同来源里分别是 9.2、9.8、8.1 和 10。中文圈的视频和文章里也有不少类似的说法。你需要有能力判断哪些是真的。

确认你实际运行的版本。 命令行里 php -v 显示的版本，可能和 Web 服务实际加载的不是同一个。更麻烦的是，Ubuntu 24.04 上已经打过补丁的 PHP，版本号仍然显示 8.3.6——发行版是把补丁移植到旧版本上，版本号不变。判断是否已修复，要去查软件包的更新日志里有没有这两个 CVE 编号。

升级。 用的是哪个发行版、哪个面板、哪个 PHP 分支，决定了你从哪里拿补丁、有没有补丁。宝塔团队连夜把修复做到了 7.0，并提示要先在测试环境验证；但按下按钮、测试、重启的，仍然是你。

重启。 升级软件包之后，必须重启 PHP-FPM 或 Web 服务器。否则内存里常驻的进程仍然在运行旧代码。

处理停止维护的版本。 如果你在 8.1 或更早的版本上，要么迁移到 8.2 以上（而 8.2 两个月后也会停止维护），要么确认发行版有没有提供移植的修复包。临时关闭 session.upload_progress 只能缓解其中一个漏洞，而且必须改在 php.ini 或 FPM 配置里，并重启所有进程。

检查是否已经被入侵。 看 Web 根目录下有没有来历不明的 PHP 文件，PHP 进程有没有启动 curl、wget 之类的下载程序，服务器有没有异常的对外连接。

为什么不直接升级？ 大多数自己部署的网站都卡在第 6 步，因为离开旧版本的 PHP 很少是点一个按钮的事。很多时候要先换操作系统：CentOS 7 没有平滑的升级路径，要么做一次耗时数小时、需要多次重启、风险不低的原地转换，要么新开一台服务器，把所有网站、数据库、邮箱都迁过去。然后是代码本身会出问题。PHP 7.0 删除了 mysql_* 系列函数，而很多老代码的每一次数据库查询都用它；PHP 7.2 删除了 mcrypt，用它加密过的数据要连同代码一起迁移；PHP 8.0 把很多警告改成了致命错误，还改变了字符串和数字的比较规则，有些逻辑会在不报任何错的情况下悄悄变掉。用 Zend Guard 加密的商业程序在 PHP 7 及以上根本无法运行，用 ionCube 加密的程序一般要等原厂商为 PHP 8 重新加密。老旧的插件、主题和框架版本，也常常限制了能用的 PHP 版本。这些工作没有带来任何新功能，但只要你还想收到补丁，就一项也躲不掉。这也是为什么即使面板允许每个网站单独选择 PHP 版本，大量网站依然停在停止维护的版本上。

这不是一个极端的例子。按对外显示的版本号统计，10 月 21 日中国境内可识别版本的 PHP 服务约 19.6 万个，其中 88% 是已经停止维护、PHP 官方不再发布修复版本的 8.1 或更早版本；阿里云上这个比例是 95%。

选平台时应该问什么

如果上面七步里有你做不了的，就不应该自己运维服务器。但“选一个托管平台”本身并不够：一个托管平台如果自己也停在停止维护的组件上，对你来说和自己部署没有区别，只是出问题的服务器挂着别人的名字。

所以选平台时，我建议问这六个问题：

能不能问到它用的语言、框架、数据库分别是什么版本？ 答不上来，或者不愿意答，本身就是一个信号。

这些组件是否都还在官方维护期内？

它有没有真正做过大版本迁移？ 不只是小版本补丁。请对方举出具体的例子和时间。

面对公开的高危漏洞，它的响应时间是多少？ 比如 2021 年的 Log4Shell，它是哪天处理的。

补丁是否不需要你做任何操作就能生效？ 如果每次修复都要你“重新发布一下”，你就又回到了“需要知道这件事”的问题上。

如果平台不再维护，你的数据能不能带走？

这六个问题对任何平台都适用，包括 Zion。

我们在 Zion 是怎么做的

Zion 从一开始要做的，就是替非技术创始人把基建接过去：服务器、数据库、运行环境、安全补丁，这些原本需要一个后端团队长期维护的东西，由我们来维护。创始人只需要关心自己的产品和用户。

Zion 的技术栈里没有 PHP，所以这次 PHP2Shell 本身与我们无关。顺便一提，Zion 托管的应用对任何 .php 路径的请求都直接返回 403——这类请求基本都来自扫描器。

但 PHP2Shell 说明的问题，我们一直在处理。后端和数据库的升级，由我们统一完成，项目方不需要做任何操作。过去六年，二十来位工程师为 Zion 提交了七十多次技术栈升级。下面是其中四次：

这四次升级没有给用户带来任何新功能，这正是上文说的意思：它们的目的是让平台一直留在能收到补丁的版本上。

两次数据库升级用的是同一套做法：逻辑复制、迁移期间锁定部署、准备好回滚脚本。2026 年那次的迁移文档里，专门对照了 2023 年那次的过程。也就是说，这不是一次性的抢救，而是一套可以重复执行的流程。

Spring Boot 那次值得多说一句。近 900 个文件的改动，没有带来一个新功能，只是为了让后端框架回到官方维护的版本上。如果你自己维护一个 Java 后端，这就是你某一天要面对的工作量；换成 PHP、Node.js 或 Python，规模不同，性质一样。

你放弃了什么

托管平台不是没有代价的，我不想回避这一点。

你依赖平台方。 平台的维护做得好，你受益；做得不好，你也跟着受影响。所以上面那六个问题，要真的去问。

你失去一部分控制权。 你不能自己选择运行环境的版本，也不能在服务器上装任意软件。

迁移成本。 换平台是有成本的，选之前要问清楚数据能不能导出、以什么格式导出。

谁应该自己部署？有技术合伙人，或者有人能在漏洞公开后 48 小时内完成上面七个步骤的团队。对这样的团队，自己部署带来的控制权是值得的。

对于没有这样的人的非技术创始人，我的建议是：把安全维护交给以此为工作的人，然后去检查他们是否真的在做。

结论

PHP2Shell 不会是最后一个。找漏洞正在变得更便宜，会有更多的漏洞被找到，也会有更多的补丁要打。自己部署服务，意味着每一个补丁都是你的事；选择托管平台，意味着这些事由平台去做，但前提是平台方确实在做，而且你检查过。

这些事，Zion 从 2020 年做到现在，快七年了：跟进公开的安全漏洞、对数据库和后端服务持续升级版本，把迁移做成可以重复执行的流程，并且以后我们也会一直做下去。这也是 Zion 存在的原因：让非技术创始人不需要组建自己的技术团队，也能拥有一套一直有人维护的基建。

了解 Zion：https://www.functorz.com/