这周 PHP 圈最热闹的不是新版本，而是一个叫「PHP2Shell」的漏洞。 名字听起来很像加油站，实际上是把你的伺服器直接加满油、送给骇客开走。 CVE-2026-109618／109619，CVSS 9.2，不用登入就能远端执行程式。 最可怕的一句话是：「连只印 Hello World 的页面都会中」。 ━━━━━━━━━━━━━━━ ▍它到底怎麽打进来的？（技术一点点就好） ━━━━━━━━━━━━━━━ 简单说，攻击者丢一个特制的超大上传表单（multipart）， 在请求一开始就把记忆体灌爆。 PHP 脑袋当机的那一瞬间，留下一份「做到一半」的资料， 收尾时却把它当成真的拿来用，於是就能执行任意程式。 重点来了：这一切发生在 PHP「解析上传表单」的阶段。 你写得再漂亮的登入检查、签名验证、副档名过滤，通通还没轮到上场。 等於小偷不是从门进来，是在你盖房子打地基的时候就先躲进去了。 官方说「唯一可靠的解法是升级 PHP」，修补版本是 8.2.35／8.3.36／8.4.27／8.5.12。 然後我打开公司的主机一看：7.4、7.1…… 官方的回答是：8.1 以下，祝你好运。 ━━━━━━━━━━━━━━━ ▍这不是演习，是已经在发生的事 ━━━━━━━━━━━━━━━ 其实两周前就有一波大量攻击。 我们这边损失大约 24 万，朋友的公司更惨，一天实际损失百万。 漏洞公告出来之前，有人早就在用了。 我一个在骇客圈的朋友说得更直接：「这招我们用了十年以上了，一招打天下。」 官方公告是这礼拜才出来，但对某些人来说， 这只是把用了十年的祖传秘方正式公开而已。 ━━━━━━━━━━━━━━━ ▍「全部升级」听起来很正确，但…… ━━━━━━━━━━━━━━━ 我们一间公司 20 几个专案、100 多个站，很多还架在已经停止维护的旧框架上。 光是其中一套支付系统，评估升到 PHP 8.3 就要 6～8 人天。 而且原样换上去会整站回 500，因为旧框架会把 PHP 8 的一堆警告当成错误丢出来。 另外，原本用 error_reporting(0) 藏起来的型别问题， 在 PHP 8 全部会跳出来咬人。 100 多个站一个一个这样升？升完大概也过年了。 我在某大集团资讯部的朋友，现在就还在熬夜加班升版本。 但其实，按照下面的上策或中策，他可以早点下班。 ━━━━━━━━━━━━━━━ ▍框架老了？其实可以自己改（这段比较硬核一点） ━━━━━━━━━━━━━━━ 很多人把框架当成神主牌，官方不支援就只能整套重写。 但 PHP 框架说穿了，就是一堆跟着专案一起打包的 PHP 档。 它是你的程式码，不是黑盒子，坏了就打开来修。 这次的 ThinkPHP 5.0 就是例子。 换上 PHP 8.3 之後整站 500，追下去发现根因只有一个： 框架会把 PHP 8 新增的「提醒」当成「错误」丢出来，等於一张黄牌就直接判出场。 改框架里一行，告诉它「提醒就记下来，不要判出场」，整站就恢复正常。 全专案真正会死的地方只有 3 处，各改一两行。 PHP 本身也一样。 官方虽然不出 7.x 的修补版，但修补的原始码是公开的。 sury 做的事，就是把修补补进旧版 PHP 再重新打包。 CentOS 没有现成套件？自己编一份带修补的 PHP，也不是什麽黑魔法。 这件事我不是第一次做。 当年 PHP 7 刚推出，Laravel 4.2 官方不支援 PHP 7，很多团队只能整套重写成 Laravel 5。 我那时候选择直接改框架，把 4.2 改到能在 PHP 7 上稳定跑。 例如 PHP 7 把一部分错误改成新的 Error 类型，旧框架的错误处理只接得住旧的 Exception，一出错就是一整页空白。 把这些接缝一个一个补起来，比整套重写便宜太多。 不过升级最可怕的往往不是「会坏」，而是「默默变了」。 举个例子： "abc" <= 0 这行在 PHP 7 是 true，在 PHP 8 变成 false。 如果你的金额检查刚好这样写，升级後就可能把奇怪的金额放行。 程式不会报错，帐会错。 所以我们升级时，是让 7.4 和 8.3 同时跑同一份程式，把支付回调、 金额路径的结果逐一比对，确认两边一模一样才算数。 ━━━━━━━━━━━━━━━ ▍上中下三策 ━━━━━━━━━━━━━━━ 【上策】套社群回补套件，程式一行都不用改 Debian／Ubuntu 的 PHP 套件维护者 Ondrej Sury（sury.org）很佛心，替 PHP 5.6 到 8.5 每个版本都出了修补套件。 连 7.4、7.1 这种官方不管的版本都有。版本号不变，只多一个套件修订号。 apt 升级、重启 PHP-FPM，收工。 缺点：只限 Debian／Ubuntu。CentOS 的朋友请往下看。 【中策】把图片上传独立成一台新版 PHP（我最推） 既然漏洞的大门是「上传表单」，那就别让上传请求碰到旧 PHP。 ‧原站的 Nginx 只把「上传图片」那几条路径转到一台独立主机（PHP 8.4.27） ‧其他所有 multipart 请求一律 403，旧 PHP 根本收不到 ‧上传主机负责验签名、验档案内容、把图片重新编码（夹带的恶意程式码顺便洗掉） ‧存放目录不能执行程式，主机也没有任何资料库权限，被打也拿不到资料 ‧前端网址、栏位一个都不用改，出事拿掉 Nginx 一行转发就回到原状 100 多个站要改，升级是处理不来的，不如弄一台共用的图片上传服务。 远古产品切开就好，这应该是改动最小的方案。 【下策】全面升级 PHP 8，必要时连框架一起改 这是唯一的根治法，也是技术债的总清算。 就像上面说的，框架其实改得动，难的是 100 多个站每个都要改、每个都要测。 长期一定要做，但不适合在「骇客已经在门口」的时候当第一步。 顺带一提，「只把 session.upload_progress 关掉」不够。 它只挡住其中一条路，另一个 CVE 靠的是灌爆记忆体，跟上传进度无关。 ━━━━━━━━━━━━━━━ ▍其实 15 年前就有人这样干了 ━━━━━━━━━━━━━━━ 15 年前我在 Yahoo! 还是个菜比巴。那时 Yahoo! 跟 PHP 之父 Rasmus Lerdorf 有合作，就已经用类似的做法，把上传这种高风险的东西独立出去。 前辈特别跟我提过，说是 PHP 之父的建议。当时我听了还不懂，现在懂了， 而且懂得有点痛。 照 PHP 之父当年的说法：一堆框架架在 PHP 上，早就千疮百孔， 小漏洞他也管不了了。 （他当时还来台湾招志愿者帮忙翻译中文文件。） 外商那时还教了我另一件事：「最高权限只用一瞬间」。 伺服器启动的时候，确实需要 root（最高权限）来做几件事，例如占用 80／443 这种特殊的埠、读取 HTTPS 凭证。 但这些事一做完，真正负责接客、执行 PHP 的那些工作程序， 就全部换成权限很小的帐号（例如 nginx、www-data）。 打个比方： 店长早上用万能钥匙开完大门，就把钥匙收进保险箱； 整天在柜台收钱的是工读生，他手上只有收银机的钥匙。 小偷就算骗倒了工读生，也拿不到万能钥匙，开不了金库。 PHP2Shell 让骇客拿到的，就是「正在执行 PHP 的那个帐号」的权限。 如果你的 PHP 是用 root 在跑，那就等於工读生身上挂着万能钥匙， 一被骗就全盘皆输； 如果是权限很小的帐号，骇客进得来，也只能在一个很小的房间里打转。 这次我们的独立上传服务也是同一套思路：它用专属的受限帐号在跑， 只能写图片资料夹，连一个资料库帐号都没有。 漏洞不一定挡得住，但损害可以先算好上限。 有朋友吐槽：「其他语言也跟着爆啊，总不是同一个人吧？」 说得对，每个语言都有洞，只是 PHP 这次的比较严重，而且全世界跑 PHP 的老系统实在太多了。 ━━━━━━━━━━━━━━━ ▍结论 ━━━━━━━━━━━━━━━ 1. 今天就做：关掉 session.upload_progress、Nginx 挡掉不必要的上传 2. Debian／Ubuntu：套 sury 回补，当天收工 3. 套不了的：把上传独立出去，先把大门关上 4. 长期：该升级的还是要升，但可以从容地升 资安不一定要靠熬夜，有时候是靠「把对的那一刀切下去」。 祝大家今晚都能准时下班 XD -- 最喜欢的一句话是？ 世界和平 最尊敬的人是？ 德蕾莎修女 请说一句话。 大家都要幸福喔～ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 122.116.54.124 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1792709592.A.CA3.html