５月２２日，PHP 與 Laravel 圈出現一個很值得注意的供應鏈攻擊：Laravel-Lang 旗下多個 Composer 套件的歷史版本標籤被重寫。
這不是常見的「攻擊者發了一個新惡意版本」。更麻煩的是，攻擊者取得 Laravel-Lang GitHub organization 的推送權限後，把既有 release tags 指向惡意 fork 裡的 commit。也就是說，表面上看起來還是熟悉的套件、熟悉的版本號，但 Composer 拉到的內容已經不是原本那份程式碼。
這種攻擊對讀者真正重要的地方，不在於 Laravel-Lang 本身有多大，而是它把 ２０２６ 年開源供應鏈的一個現實講得很清楚：
版本號已經不等於信任。套件來源、tag 指向、lockfile、CI 權限與祕密管理，必須一起看。
這次事件發生了什麼？
根據 StepSecurity、Reptile Haus、Snyk、Socket 等資安研究整理，攻擊大致發生在 ５月２２日深夜 UTC 時段，目標集中在 Laravel-Lang 生態的 Composer 套件。
| 項目 | 內容 |
|---|---|
| 事件日期 | ２０２６ 年 ５ 月 ２２ 日 |
| 攻擊對象 | Laravel-Lang organization 下的多個 Composer 套件 |
| 受影響套件 | laravel-lang/lang、laravel-lang/http-statuses、laravel-lang/attributes、laravel-lang/actions |
| 攻擊方式 | 重寫 GitHub release tags，讓既有版本指向惡意 fork commit |
| payload 位置 | 惡意 helpers.php，並透過 composer.json 的 autoload.files 自動載入 |
| 主要風險 | 竊取 CI/CD token、雲端金鑰、SSH key、.env、瀏覽器與開發者環境資料 |
| 建議處置 | 檢查 composer.lock、暫停可疑部署、輪替祕密、稽核 CI 與 GitHub 活動紀錄 |
這個手法很陰：官方 repository 不一定看得到惡意碼進入主分支，因為攻擊者利用的是「tag 可以指到 fork commit」這類很少被日常開發者注意的邊界。
對一般團隊來說，最危險的瞬間不是「手動升級到新版」，而是 CI 或部署流程在攻擊窗口內跑了 composer install 或 composer update，把被污染的 tag 解析進來。
為什麼這比一般套件攻擊更麻煩？
一般套件供應鏈攻擊，多半是以下幾種：
１．攻擊者偷到 maintainer 帳號，發佈新版本。
２．攻擊者做 typo-squatting，讓使用者裝錯套件。
３．攻擊者污染 build pipeline，讓正式版本帶上惡意碼。
Laravel-Lang 這次更棘手，因為它攻擊的是「歷史版本」。
開發團隊常有一個直覺：只要不追最新版、只要 lock 住版本，就比較安全。但這次事件提醒我們，如果版本標籤本身可以被重寫，光看版本號是不夠的。你以為自己裝的是舊版，實際上解析到的 commit 可能已經被換掉。
這也是為什麼多家資安公司都把重點放在幾件事：
- 不只檢查
composer.json，也要檢查composer.lock裡實際解析到的 source reference。 - 不只重新安裝套件，還要確認當時跑過 CI 的環境有沒有暴露祕密。
- 不只更新到安全版本，還要輪替可能被讀取的 token、deploy key、cloud key。
- 不只信任 GitHub tag，還要建立 tag 簽章、commit hash 驗證與 egress control。
這件事的本質不是「Laravel 套件出包」，而是軟體供應鏈信任邊界出包。
和 AI 開發有什麼關係？
表面上，這是一個 PHP／Composer 事件，不是 AI 模型事件。但它其實很接近 AI 開發團隊接下來會遇到的風險。
原因很簡單：２０２６ 年的開發工作流正在變成「人類規劃，AI agent 執行」。Cursor、Claude Code、Codex、GitHub Copilot Workspace 這類工具會越來越常幫你改依賴、補測試、修漏洞、更新 lockfile。
這會帶來一個新問題：
當 agent 看到「套件有更新」時，它可能很會修語法，卻不一定知道這次更新是不是供應鏈攻擊。
Laravel-Lang 事件剛好提供一個很現實的測試題：
- agent 會不會只看版本號？
- agent 會不會檢查 tag 是否被重寫？
- agent 會不會比對 lockfile 裡的 source reference？
- agent 會不會提醒使用者輪替 CI secrets？
- agent 會不會把「安裝成功」誤判成「安全成功」？
這也是為什麼最近幾篇資安新聞可以連在一起看：Project Glasswing 說明 AI 找漏洞速度正在變快；Laravel-Lang 事件則提醒我們，攻擊者不需要等你寫出漏洞，他可以直接污染你信任的依賴入口。
企業與開發團隊現在該看哪幾件事？
如果你的團隊有 Laravel 或 Composer 專案，這次事件可以直接當成檢查清單。
１．先查有沒有用到受影響套件
檢查 composer.json 與 composer.lock 是否包含：
laravel-lang/langlaravel-lang/http-statuseslaravel-lang/attributeslaravel-lang/actions
如果在 ５月２２日之後有跑過 composer install、composer update、CI build、production deploy，就要把它當成高風險事件處理。
２．不要只重跑 install，要輪替祕密
這類 credential stealer 的麻煩點是：即使你把套件修回來，祕密可能已經被拿走。
需要優先輪替：
- GitHub token
- CI/CD deploy key
- cloud provider access key
- database password
- SSH key
- package registry token
.env裡的第三方 API key
如果 CI runner 有存取 production 權限，事件等級就不該只算「開發環境污染」。
３．把供應鏈驗證加入 agent 工作流
未來如果讓 AI agent 自動更新依賴，提示詞與流程不能只寫「幫我更新套件」。比較完整的做法應該要求：
- 檢查套件 maintainer 最近是否有異常版本大量發布。
- 檢查 lockfile source reference 是否出現非預期變化。
- 檢查 install script、autoload.files、postinstall、prepare、GitHub Actions 是否新增敏感行為。
- 對 CI secrets 做最小權限設計，避免 build job 拿到 production 等級金鑰。
- 對 outbound network 做白名單，阻止未知網域 exfiltration。
這些不是「資安潔癖」，而是 agentic coding 進入正式環境後的基本衛生。
這件事的產業訊號
Laravel-Lang 事件和前一週的 Mini Shai-Hulud、TanStack、OpenAI 員工裝置受影響等新聞放在一起看，趨勢非常清楚：攻擊者正在往開發者供應鏈移動。
原因也很直白。攻擊 production server 很難，打防火牆、WAF、EDR、SIEM 都要成本；但攻擊一個維護者帳號、一個 CI workflow、一個 package tag，有時可以一次進入幾百、幾千個下游專案。
對 AI 產業來說，這尤其敏感。因為 AI 新創與 AI 團隊通常依賴大量開源套件、快速部署、頻繁更新，還會把 API key、模型權限、資料庫、向量庫、雲端權限接在同一條 pipeline 裡。
未來真正高價值的安全能力，不只是「模型會找漏洞」，而是：
模型知道什麼時候不該相信供應鏈。