這週 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/m.aspx?n=bbs/Soft_Job/M.1792709592.A.CA3.html