AI供應鏈攻擊：供應鏈本身就是攻擊面

2026年3月19日，一個名為TeamPCP的威脅組織對Aqua Security的trivy-action GitHub儲存庫中的77個版本標籤強行推送了其中的76個。Trivy是業界部署最廣泛的開源漏洞掃描器。新標籤指向了包含憑證竊取程式的惡意提交。由於大多數CI/CD流程透過可變版本標籤而非固定的提交SHA來參照GitHub Actions，每個在建置流程中執行Trivy的組織都立即開始執行這些惡意程式碼。掃描看似仍然成功。掃描器仍然回報漏洞。同時，它也悄悄地收割了執行環境中的每一個機密。¹

供應鏈攻擊利用已授權操作的組合來產生未授權行為。攻擊者透過GitHub Actions標籤劫持入侵Trivy後，使用竊取的CI憑證在PyPI上植入LiteLLM後門，在46分鐘內達到46,996次安裝。每個元件都在其被授予的權限範圍內運作。結構性的防禦方式是將相依套件固定到不可變的參照，並將套件安裝視為程式碼執行。

五天後，也就是3月24日，TeamPCP使用從其中一個CI環境竊取的PyPI發布權杖，發布了LiteLLM（一個在36%雲端環境中存在的熱門AI代理函式庫）的兩個帶有後門的版本。²版本1.82.8包含一個.pth檔案，會在任何Python啟動時自動執行，時機在任何匯入之前，在任何應用層沙箱之前。載荷收集SSH金鑰、雲端憑證、資料庫密碼、加密貨幣錢包和CI/CD機密，使用硬編碼的RSA公鑰加密這些資料，然後將封存檔滲漏到前一天註冊的攻擊者控制網域。³

PyPI在46分鐘後將兩個版本隔離。在這段時間內，發生了46,996次安裝。⁴ LiteLLM的維護者刪除了他的GitHub帳戶，輪換了所有金鑰，並聘請了Mandiant。⁵

安全掃描器進行了掃描。建置流程完成了建置。套件管理器安裝了套件。每個元件都完全按照其被信任的方式運作。

TL;DR

• 攻擊鏈：TeamPCP於3月19日透過GitHub Actions標籤劫持入侵Trivy（安全掃描器），然後於3月24日使用從受Trivy感染的CI環境中竊取的PyPI權杖入侵LiteLLM（AI代理）。46分鐘內46,996次下載。⁴
• 技術手法：版本1.82.8濫用Python的.pth機制，在受感染系統上每次執行python3時執行憑證竊取程式，無需匯入LiteLLM。³
• 影響範圍：2,337個PyPI套件依賴LiteLLM。88%的版本規範允許安裝遭入侵的版本。已確認對Google ADK、Stanford DSPy、MLflow、Guardrails AI和Cisco AI Defense SDK的下游影響。⁴
• 攻擊行動：TeamPCP在一週內攻擊了五個生態系統：GitHub Actions、Docker Hub、npm（CanisterWorm，28+套件）、Open VSX（Checkmarx KICS）和PyPI（LiteLLM）。⁶
• 結構性教訓：鏈中的每個環節都在其授予的範圍內運作。組合這些已授權的操作產生了未授權的行為。此模式與在代理層級啟用靜默外傳及在CI/CD層級啟用Clinejection的組合缺口相呼應。供應鏈攻擊就是組合攻擊。
• 您可以採取的行動：將相依套件固定到不可變的參照。將發布憑證與CI執行器隔離。在作業系統層級監控對外網路請求。將pip install視為程式碼執行，因為它本就是如此。

一台安全掃描器走進您的建置流程

攻擊始於2026年2月下旬Trivy的GitHub Actions環境中的一項錯誤配置。攻擊者利用存在漏洞的pull_request_target工作流程，滲漏了Aqua Security的aqua-bot個人存取權杖。Aqua於3月1日輪換了部分憑證，但遺漏了其他憑證。TeamPCP保留了有效的權杖。¹

3月19日，他們使用這些權杖在trivy-action儲存庫中強行推送了77個版本標籤中的76個，以及setup-trivy中的全部7個標籤，將每個可變標籤參照重新導向到惡意提交。他們也觸發了發布自動化，將惡意Trivy二進位檔發布為v0.69.4。¹

載荷是一個憑證竊取程式，會傾印Runner.Worker行程的記憶體，收集SSH金鑰、雲端憑證、Kubernetes機密、Docker配置、Git憑證和.env檔案。它使用AES-256和4096位元的RSA金鑰加密收集到的資料，然後將封存檔滲漏到攻擊者控制的伺服器。惡意程式碼與合法的Trivy功能並行執行。掃描成功了。掃描器仍然回報漏洞。竊取程式在背景執行。⁷

3月19日至23日間，攻擊者也在trivy:0.69.4、trivy:0.69.5、trivy:0.69.6和trivy:latest標籤下毒化了Docker Hub映像檔。CrowdStrike、Microsoft、Wiz和Palo Alto都在數天內發布了技術分析。⁷⁸⁹

諷刺之處在於其結構性：最重視安全的組織反而受害最深。如果您在CI中執行Trivy是因為您關心漏洞掃描，那麼您的建置流程就是那個正在收割憑證的流程。

從掃描器到竊取程式再到AI代理

LiteLLM的CI流程執行了Trivy。具體來說，ci_cd/security_scans.sh透過apt從Aqua的儲存庫拉取Trivy，沒有進行版本固定。¹⁰在入侵期間，一次CI執行拉取了被毒化的Trivy二進位檔，該檔案從GitHub Actions環境中收割了PYPI_PUBLISH_PASSWORD。

3月23日，攻擊者註冊了litellm.cloud。3月24日UTC時間10:39，他們使用竊取的憑證將litellm==1.82.7發布到PyPI。版本1.82.8隨後在UTC 10:52發布。⁴

這兩個版本使用了不同的攻擊技術。版本1.82.7將載荷嵌入proxy_server.py中，在import litellm.proxy時觸發。版本1.82.8將一個.pth檔案放入site-packages/中，在任何Python解譯器啟動時觸發。.pth機制是Python用於路徑配置的合法功能。Python的site.py會在直譯器初始化期間自動執行在site-packages/中找到的任何以.pth結尾的檔案。大多數Python開發者並不知道此功能的存在。³

兩個版本中的載荷都收集了環境變數、SSH金鑰、AWS/GCP/Azure憑證、Kubernetes配置、資料庫密碼、加密貨幣錢包和CI/CD機密。它使用隨機工作階段金鑰以AES-256-CBC加密這些收集內容，並以硬編碼的4096位元RSA公鑰包裝工作階段金鑰，然後透過HTTPS POST滲漏封存檔。只有攻擊者才能解密竊取的資料。³

1.82.8惡意程式中的一個錯誤洩漏了蹤跡。.pth檔案產生了一個子Python行程，該行程重新觸發.pth檔案，形成了指數型的分叉炸彈。Andrej Karpathy在X上標記了這個錯誤。若非此分叉炸彈，竊取程式本會在每個受感染系統上每次Python呼叫時悄悄執行，可能在數週內都沒有人注意到。⁴

PyPI於UTC 11:25隔離了兩個版本——46分鐘的曝光時間，46,996次下載。⁴

影響範圍

開發者每天大約下載LiteLLM 340萬次。Wiz回報它在36%的雲端環境中執行。² 46分鐘的曝光窗口已綽綽有餘。

FutureSearch分析了PyPI的BigQuery下載記錄，發現在攻擊期間，pip拉取版本1.82.8的速率是任何安全版本的6倍。下載量嚴重偏向pip（解析到最新版本），而非uv（使用鎖定檔案）。在46,996次下載中，有23,142次是v1.82.8的pip安裝，每次都在安裝過程中就執行了載荷，因為.pth檔案在pip自身的Python行程期間就已觸發。⁴

PyPI上有2,337個套件依賴LiteLLM。88%（2,054個套件）的版本規範允許安裝遭入侵的版本。下游曝險包括：⁴

LiteLLM Cloud和Docker代理使用者未受影響，因為其相依套件已在requirements.txt中固定。「已固定」與「未固定」之間的區別，就是遭入侵與安全之間的區別。⁵

一週內五個生態系統

TeamPCP並未止於PyPI。此攻擊行動在短時間內襲擊了五個套件生態系統：⁶

GitHub Actions（3月19日）：76個trivy-action標籤和全部7個setup-trivy標籤遭劫持。發布了惡意Trivy二進位檔v0.69.4至v0.69.6。

Docker Hub（3月19日至22日）：惡意Trivy映像檔以aquasec/trivy:latest和版本特定標籤推送。傳播到mirror.gcr.io。

Open VSX（3月23日）：TeamPCP入侵了Checkmarx KICS GitHub Action，在UTC 12:58至16:50間劫持了35個標籤。²

npm（3月23日至24日）：CanisterWorm（一種自我傳播的蠕蟲）部署到28+個npm套件中。

PyPI（3月24日）：LiteLLM版本1.82.7和1.82.8發布，內含憑證竊取載荷。

每次生態系統入侵都使用了從前一次入侵中收割的憑證。此攻擊行動是一個信任利用的有向圖，每個被入侵的節點產出了通往下一個節點的金鑰。

供應鏈攻擊就是組合攻擊

TeamPCP攻擊行動的結構模式與我在代理安全和靜默外傳脈絡中描述的模式相同：個別已授權的元件組合成未授權的行為。

Trivy有權限在CI中執行。CI依設計持有發布憑證。套件管理器依命令安裝套件。每個.pth檔案都按預期配置Python路徑。鏈中的每個環節都在其定義的範圍內運作。組合這些合法操作產生了大規模的憑證滲漏。

Clinejection攻擊在CI/CD層級展示了相同的模式：一個問題標題將對抗性文字注入Cline的自動化流程，該流程執行了npm preinstall腳本，該腳本毒化了建置快取，該快取污染了跨工作流程的構件。每個步驟都持有自己的授權。¹¹

MCPTox基準測試在代理層級展示了相同的模式：嵌入工具描述中的惡意指令重新導向代理，使用伺服器上已有的合法工具來滲漏憑證。代理從未自己執行被毒化的工具。它讀取被毒化的描述，並使用自己的合法工具來執行攻擊。¹²

靜默外傳在執行時層級展示了這一點：網頁metadata中的對抗性指令誘使代理透過代理已有權限發出的對外HTTP請求，滲漏執行時的脈絡。¹³

攻擊面並非單一的脆弱元件。攻擊面是受信任元件的組合。保護個別環節並不能保護整條鏈。Trivy本身並不是漏洞。LiteLLM本身並不是漏洞。透過可變版本標籤和未固定相依套件來中介的它們之間的信任關係——才是漏洞。

真正有效的做法

能阻止此次攻擊各階段的防禦措施都很平凡。它們也正是大多數組織忽略的措施。

固定到不可變的參照。 LiteLLM透過apt拉取Trivy時沒有固定版本。如果security_scans.sh已固定到特定版本或提交SHA，被毒化的v0.69.4二進位檔就永遠不會執行。GitHub Actions應該參照提交SHA，而非可變標籤。uses: aquasecurity/[email protected]（遭入侵）與uses: aquasecurity/trivy-action@57a97c7（安全）之間的區別，就是失去發布憑證與否的區別。¹

將發布憑證與CI執行器隔離。 PYPI_PUBLISH_PASSWORD作為環境變數暴露在Trivy執行的GitHub Actions執行器中。如果團隊將發布憑證隔離在沒有第三方action相依的獨立工作流程中，Trivy的入侵就不會導致PyPI存取權外洩。PyPI的Trusted Publishers（OIDC）完全消除了儲存的權杖。⁵

監控對外網路請求。 憑證竊取程式透過HTTPS POST將資料滲漏到models.litellm.cloud，這是攻擊者在攻擊前24小時註冊的網域。標記對新註冊網域請求的出口監控原本能捕捉到這一切。我自己的hook系統會阻擋對不在允許清單上的網域的對外請求，這正是能攔截此次滲漏的相同模式。¹⁴

我在生產環境中以艱難的方式學到了相同的教訓。一條受信任的Cloudflare快取清除路徑發出了完全授權的API呼叫，卻仍然產生了錯誤的結果，因為周圍的防護欄過於寬鬆。那次失敗促使我針對高影響力的操作加入了破壞性動作的核准機制和飛行前hook，不僅僅是網域允許清單。

將pip install視為程式碼執行。 site-packages/中的.pth檔案在每次Python啟動時執行。無法選擇退出。沒有沙箱。如果您在具有憑證存取權的CI環境中執行pip install，您就授予了該套件中每個傳遞相依項的任意程式碼執行權限。緩解方式：在沒有憑證存取權的環境中執行pip install，然後將已安裝的套件複製到需要它們的環境中。

使用鎖定檔案。 FutureSearch的分析顯示，uv使用者（依賴鎖定檔案）很少拉取遭入侵的版本，而pip使用者（解析到最新版本）則不斷拉取它。鎖定檔案並非完整的防禦，但它們可防止最常見的曝險：未固定的>=版本限制靜默地升級到遭入侵的發布版本。⁴

令人不安的含義

TeamPCP攻擊行動證明，供應鏈安全並非排在應用程式安全、網路安全和端點保護之後的次要考量。對於執行具有工具存取權AI代理的組織而言，供應鏈就是首要的攻擊面。

在CI環境中呼叫pip install、獲取URL或安裝MCP伺服器的AI代理會在執行時組合信任關係。每個操作都帶有自己的授權。組合則未必。部署與防禦悖論加速了這一點：組織部署代理的速度比審計這些代理所組合的信任鏈還要快。

LiteLLM 1.82.8中的分叉炸彈錯誤是唯一使人們能快速偵測到此攻擊的原因。若非該實作錯誤，憑證竊取程式本會在每個受感染系統上每次Python呼叫時悄悄執行。46分鐘內46,996次安裝。36%的雲端環境。2,337個下游套件。攻擊者犯了一個錯誤。下一次，他們可能不會再犯。

更新——2026年3月31日：不同的載體，相同的結果

這篇文章上線六天後，npm出現了下一次事件。3月31日，axios維護者Jason Saayman披露，他的個人電腦透過有針對性的社交工程攻擊以及後續的遠端存取木馬惡意軟體遭到入侵。攻擊者使用他的npm憑證發布了axios 1.14.1和0.30.4，兩者都注入了一個名為[email protected]的新相依項，該相依項在macOS、Windows和Linux上安裝了跨平台的RAT。惡意版本上線約三個小時後，社群貢獻者分流了該事件，npm撤下了它們。¹⁶

axios的載體與TeamPCP不同。沒有遭入侵的CI執行器，沒有從第三方安全掃描器收割的憑證，沒有跨生態系統的蠕蟲。對Saayman的攻擊行動在發布前運作了大約兩週，入侵透過維護者的個人裝置直接傳到npm發布流程。補救工作需要徹底清除他所有的裝置，並輪換他曾使用過的每個平台（無論是個人還是其他用途）上的每一組憑證。C2基礎設施為142.11.206.73:8000上的sfrclak[.]com。¹⁶

結構性的教訓是相同的。信任鏈現在將維護者的專注力與警覺性也納入為環節，因為當對手操縱鏈中的人時，個別合法的操作會組合成未授權的行為。axios團隊正在採用的緩解措施（OIDC發布、不可變發布、裝置隔離）¹⁶解決的是與Trivy到LiteLLM所暴露的相同組合缺口：發布憑證被儲存在已經入侵其鄰近目標的對手可以觸及的位置。

三小時。46分鐘。這些就是現代供應鏈攻擊運作的時間窗口。固定與鎖定檔案仍然是主要的防禦措施：在3月31日UTC時間00:21至03:15窗口之外進行全新安裝的axios使用者並未受到影響。¹⁶

常見問題

我如何檢查自己是否受到影響？

搜尋您的CI記錄和本機環境，找出2026年3月24日UTC時間10:39至11:25之間安裝的LiteLLM版本1.82.7或1.82.8。如果您找到任一版本，請輪換系統可能存取的每一組憑證——環境變數、SSH金鑰、配置檔案。LiteLLM的官方指引：將執行過遭入侵版本的任何系統視為完全遭入侵。⁵

我應該追蹤哪個公告識別碼？

在OSV和PyPA公告資料庫中追蹤PYSEC-2026-2。OSV也將此事件別名為MAL-2026-2144。截至2026年3月25日，公開的OSV公告頁面並未列出惡意LiteLLM發布版本的CVE別名，因此事件回應團隊應優先以受影響的版本、安裝時間窗口和PYSEC-2026-2為依據。¹⁵

LiteLLM Cloud或Docker代理使用者受到影響了嗎？

沒有。LiteLLM Cloud和官方Docker代理映像檔在requirements.txt中固定了相依套件，防止自動解析到遭入侵的版本。只有在46分鐘窗口期間透過pip install litellm（未固定）安裝LiteLLM的使用者才受到影響。⁵

什麼是.pth檔案？為什麼它很危險？

.pth檔案是Python用於配置模組搜尋路徑的功能。Python的site.py模組會在直譯器初始化期間讀取並執行site-packages/目錄中任何以.pth結尾的檔案。執行發生在任何匯入陳述式之前、任何應用程式碼之前，以及任何Python層級沙箱之前。Python標準函式庫記錄了此機制，但鮮少有應用程式開發者知道它的存在。它是被重新利用為攻擊載體的合法功能。³

這與Trivy供應鏈攻擊有關嗎？

有關。LiteLLM的入侵是Trivy入侵的直接結果。TeamPCP於3月19日入侵Trivy的GitHub Actions，從在建置流程中執行Trivy的組織收割了CI/CD憑證。其中一組憑證是LiteLLM的PyPI發布權杖。攻擊者五天後使用該權杖發布了惡意的LiteLLM版本。¹⁰

什麼是TeamPCP？

TeamPCP（也被追蹤為DeadCatx3、PCPcat、ShellForce、CipherForce）是一個威脅組織，於2026年3月進行了跨多個生態系統的供應鏈攻擊行動，入侵了GitHub Actions、Docker Hub、npm、Open VSX和PyPI上的套件。該組織在大約一週內於五個套件生態系統中使用了憑證收割、標籤劫持和自我傳播蠕蟲技術。⁶

這與AI代理安全有何關係？

安裝套件、獲取URL或連接到MCP伺服器的AI代理會在執行時組合信任關係。每個操作都帶有自己的權限授予。這些操作的組合可能產生未授權的行為，正如靜默外傳（代理層級）、Clinejection（CI/CD層級）和此次攻擊（供應鏈層級）所展示的。執行時行為監控、網域允許清單和憑證隔離在堆疊的不同層級解決了組合缺口。¹⁴

來源