昨天到今天，互联网过了一个“惊魂48小时”。
荷兰政府把 DigiD、MijnOverheid 这些政务系统直接关了，连国家网络安全中心自己的网站都挂了；日本那边 pixiv、Niconico 集体紧急维护，寿司郎的小程序也暂停运行；法国的政府官网直接贴上“部分服务暂时不可用”。
全世界的网站像在集体“拔网线”。
把这么多网站掀翻的，是 PHP 刚公开的两个漏洞：CVE-2026-109618 和 CVE-2026-109619。安全圈给它们起了个直白的名字——PHP2Shell。
翻译成大白话：攻击者往你网站发一个精心构造的请求，连账号密码都不用，就能在你服务器上拿到一个 shell（命令行入口），想干什么干什么。
而这两颗雷，在 PHP 内部埋了十几年。
更让人后背发凉的是：国内大量跑在宝塔面板、老版本 PHP 上的站长，这次很可能就站在雷区正中央。
01 先搞懂这颗雷到底有多凶
先说影响面。
按 W3Techs 的统计，目前能被识别出服务端语言的网站里，69.3% 跑的是 PHP——第二名 JavaScript 才 8.1%。换句话说，PHP 不是某个网站的某个插件，它是整个互联网的“后厨”。登录、搜商品、下订单、发评论，背后几乎都是它在处理。
过去我们常听说“某某 PHP 网站被黑了”，多半是某个主题、某个插件出了幺蛾子，换个主题就好。但这次不一样。
这两个漏洞出在 PHP 解释器内核，跟你的程序、插件一点关系都没有。用发现方之一 Wiz 的话说：哪怕你网站上只挂着一个 Hello World，照样中招。
官方给两个漏洞的 CVSS 评分都是 9.2（满分 10），风险等级“严重”，不需要任何认证就能远程触发。
最要命的是 Apache 下的 mod_php 模式——PHP 最经典的部署方式——攻击在你的网站代码开始运行之前就已经发生。就是说，你写的防注入、过滤、鉴权，全部形同虚设，根本来不及出手。
02 为什么一颗雷能埋十几年
这两个漏洞的技术原理，说穿了都不算新鲜，就是内存管理的老毛病。
第一个（CVE-2026-109618）出在“内存耗尽”处理上。PHP 处理内存不够时，用的是最粗暴的方式：急刹车（longjmp），直接跳走。问题在于，如果这个刹车刚好踩在一个微妙的时间点，内部数据只初始化了一半，后续的清理流程却把这堆“半成品”当成正常数据来处理，攻击者就能利用这个缝隙，让服务器执行自己的代码。官方已经验证：默认配置下，构造一个特制的 multipart 请求，把内存“刚刚好”耗尽，就能在应用代码跑起来之前完成攻击。
第二个（CVE-2026-109619）更经典，是“释放后使用”。一个请求处理完、内存释放了，但某些全局状态没清干净；同一个进程去处理下一个请求时，又去摸这些已经失效的内存。攻击者不光能把它堆叠成代码执行，还能顺带把别的用户留在内存里的密码、令牌、API 密钥读出来。其中一个已证实的利用路径，走的是 session.upload_progress（会话上传进度）这个默认开启的功能，你的程序甚至都不用调 session_start。
这两个问题不是今天才有的。
追根溯源，能一路追溯到 2004 年，安全研究员 Stefan Esser 发现的第一个 PHP 内存限制漏洞；2020 年有一份被忽视的 bug 报告；2024 年 PHP 做了多年来第一次外部安全审计，核心开发者其实已经注意到内存耗尽处理的隐患——但当时没人能证明它真的能被人利用，几种修复方案又各有代价，可能破坏兼容，可能引入新的拒绝服务风险，团队迟迟不敢拍板，问题就这么被搁下了。
PHP 基金会事后把这段历史，称作一次“结构性失败”。
那为什么 2026 年就爆了？因为 AI 把它从“理论上的缺陷”变成了“能用的刀”。
8 月 1 日，安全公司 Calif 的研究员在 GPT-5.6 Sol 帮助下发现了第一个漏洞；8 月 11 日，Calif 和 OpenAI 同一天独立上报了同一根因；8 月 19 日，谷歌旗下的 Wiz 又用自家平台和 AI 模型独立挖了出来，随后两天就在 Drupal、WordPress 的官方镜像上，验证了无需登录的远程代码执行。
过去这种“把理论缺陷打磨成可用攻击代码”的活，是世界级团队几个月的量；现在一个研究员加一个前沿模型，一周就搞定。Wiz 的联合创始人把它称作“迄今由 AI 协助发现的最严重漏洞”，和当年深埋在地基里、潜伏多年才爆发的 Heartbleed、Log4Shell 归为一类。
03 你的宝塔面板在不在雷区
先说个让人稍微喘口气的消息：宝塔面板默认的部署方式，不是上面说的那种高危 CGI 直连模式，所以并不是所有宝塔服务器都挨刀。这跟 2024 年那次 CVE-2024-4577 的结论有点像——面板默认配置相对安全。
但是，重点来了。
影响环境包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed 这些常见跑法。你只要装了宝塔，服务器上就挂着 PHP-FPM 或 Apache，到底受不受影响，取决于你的 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
也就是说，8.1 及更早的版本，官方已经停止维护，这次拿不到官方补丁。
W3Techs 的同日数据显示：现在还有 27% 的 PHP 网站跑在 7.x，7.7% 跑在 5.x——这些停更的老版本，一个补丁都等不到。而国内跑在宝塔面板、ThinkPHP、Discuz 上的大量长尾站点，用的正是这些老版本。
别觉得“我的站小，没人看得上”。这次漏洞的利用门槛低到发指，扫描器分分钟就能全网扫一遍，谁裸奔谁倒霉，跟站大小没关系。
这里还要纠正一个很常见的侥幸心理：“我装了安全插件，能挡住。”安全插件、WAF、防火墙确实有用，但这次漏洞的触发点在内核层、在代码运行之前，很多基于应用层的过滤根本拦不到。打补丁、升级版本，才是唯一靠谱的出路。别把“上了防护”当成“安全了”。
顺便提醒一句：如果你连自己服务器上装了哪些 PHP 版本、哪些站点在跑、跑在哪个版本上都不清楚，那今天就是整理资产的最好时机。宝塔面板“软件商店-已安装”里能看到所有 PHP，挨个点开核对，心里才有数。
先说原则：优先升级，临时配置只是兜底。只有补丁能真正堵住漏洞，临时缓解只是降低风险，不是根治。
【第一步：备份】
升级前先把网站文件和数据库完整备份一份。宝塔面板左侧“网站”里，每个站都有备份入口，顺手也能用“计划任务”加个自动备份。这是所有操作的地基，出问题能一键回滚。
【第二步：8.x 版本直接面板升级】
如果你是 PHP7.4-PHP8.2 及以上，最简单。
登录宝塔面板 → 软件商店 → 已安装 → 找到正在用的 PHP 版本 → 点管理 → 检查更新，直接升到对应安全版本。
PHP7.4以上版本，8.1以下的版本，宝塔出了安全修复版本，PHP8.1->PHP8.1.35、PHP8.0->PHP8.0.31、PHP7.4->PHP7.4.34。上面用的是宝塔PHP修复版本。
升完在“软件商店-已安装”里核对版本号，确认是 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 其中之一。上面用的是官方的补丁升级。
然后重点测一遍：网站能不能开、上传功能正不正常、数据库连不连得上、后台登录顺不顺。
【第三步：老版本用宝塔修复版】
如果你还跑在 PHP 7.0～7.3，官方不提供补丁了，但宝塔已经出了修复版，是从 7.4 官方补丁逐行比对回移出来的四个版本：7.0.34、7.1.34、7.2.35、7.3.34（宝塔修复版）。
按你的版本，在服务器终端（SSH）里选一条执行：
PHP 7.0：curl -o php7_cve.sh download.bt.cn/install/php7_cve.sh && bash php7_cve.sh install 70
PHP 7.1：curl -o php7_cve.sh download.bt.cn/install/php7_cve.sh && bash php7_cve.sh install 71
PHP 7.2：curl -o php7_cve.sh download.bt.cn/install/php7_cve.sh && bash php7_cve.sh install 72
PHP 7.3：curl -o php7_cve.sh download.bt.cn/install/php7_cve.sh && bash php7_cve.sh install 73
几点提醒：
执行前务必先备份；升级会重启 PHP，站点会有短暂不可用，选低峰期操作；这是宝塔自建补丁，强烈建议先在测试环境把业务跑一遍，确认没问题再上生产；一台服务器往往装了多个 PHP 版本，逐一核查，别漏掉还在偷偷跑着的旧版。
【临时缓解方案：只能降低风险，不能替代升级】
如果一时半会儿升不了，先做这些止血。
针对 CVE-2026-109619，改 php.ini，把 session.upload_progress.enabled 设为 0；PHP 8.5 额外加一条 fatal_error_backtraces = 0。改完重启 PHP。
针对 CVE-2026-109618，调整 POST 大小限制：没有大文件上传就设 post_max_size = 8M，需要传文件就 32M，同时保证 upload_max_filesize 小于 post_max_size。别乱用 memory_limit = -1，它确实能降低利用条件，但等于关掉了 PHP 内存限制，小白千万别碰。
另外可以在 Nginx/Apache 代理层限制请求体大小、参数数量，多一道防线。
05 修完就完事了？还差得远
升级打完补丁，只是把眼前的火扑了。下面这几件事，同样要命。
第一，临时配置不是保险。等你空下来，还是得走正式的升级或迁移流程，别让“临时方案”变成“永久裸奔”。
第二，把日志盯起来。接下来一段时间，重点看 web 访问日志、PHP 错误日志、有没有异常进程和异常请求。Cloudflare 在补丁生效当天就观测到了针对客户的攻击流量，攻击者还在不停变形载荷绕过规则——说明真有人在下手，不能掉以轻心。
第三，老版本该规划迁移了。PHP 7.0～7.3 官方早就停止维护，宝塔的修复版也只是“缓兵之计”，能撑一时，撑不了一世。趁这次机会，把那些古董项目往受支持的版本上搬，一劳永逸。别等下次再爆雷的时候，又拿“项目太老没法升级”当借口——这次暴露的，恰恰是“项目老”本身就是最大的风险。
写在最后：
干这行的都知道，没有哪套软件是绝对安全的，补丁永远是打不完的。但这次不一样的地方在于：它不是某个插件的问题，而是 PHP 这个“地基”本身的问题；它不是“可能被利用”，而是“已经有人在利用”。
对普通站长来说，现在最该做的不是刷新闻吃瓜，而是立刻打开宝塔面板，看看自己跑的是哪个版本，动手升级。
这次是 PHP，下次可能是别的什么。把“定期升级、及时打补丁、老版本尽快迁移”这几个习惯立起来，才是一个服务器真正“安全”的底层逻辑。
