plaincve:~$

// 威脅簡報

CVE-2026-45758

guardrails-ai 0.10.1 遭植入惡意程式:AI 安全函式庫的 PyPI 供應鏈入侵

CVSS
9.6 CRITICAL
CISA KEV
未列入
弱點類型
CWE-506
主題
供應鏈 · AI 安全

PlainCVE 團隊 · 發布 2026-09-24 · AI 輔助 · 媒體簡報 ↓

人工審稿 2026-09-24指令測試:未提供漏洞重現:未進行驗證紀錄 ↓

攻擊者用偷來的上傳權杖把惡意的 guardrails-ai 0.10.1 發佈到 PyPI;在 Linux 上一 import 就會下載並執行遠端程式。

誰會中在 2026-05-11 約兩小時的時間窗內,從 PyPI 安裝了 guardrails-ai 0.10.1 的電腦、CI 環境或容器映像檔。0.10.0 與 0.10.2 不受影響。
後果研究人員指出,惡意程式會下載並執行一個竊取憑證的工具。裝過又 import 過 0.10.1 的機器,上面能取得的 GitHub 權杖、雲端金鑰、套件庫權杖與 API 金鑰都應視為可能外洩。
現在該做什麼確認環境與 lockfile 中有沒有出現過 0.10.1。有的話就改用 0.10.0 或 0.10.2 以上,把該機器視為可能遭入侵,並輪替那台機器能存取的所有憑證。
查看依據(4)
  • 廠商 / 維護者廠商建議:裝過 0.10.1 就把機器視為可能遭入侵,輪替那台機器能存取的憑證,並稽核 GitHub 帳號If you installed 0.10.1, treat the host as potentially compromised.github.com
  • 廠商 / 維護者廠商建議:機器上有敏感憑證時考慮整台重灌Consider a full machine reimage if the host handles sensitive credentialsgithub.com
  • 研究團隊The Hacker News 針對同一波攻擊的 npm 惡意程式建議:先隔離機器、做映像保存,再撤銷權杖It's therefore essential that developers do not revoke the npm tokens before isolating and imaging the system.thehackernews.com
  • 本站判斷guardrails 的 Python 惡意程式有沒有「權杖被撤銷就刪檔」的機制未經證實;本站仍建議先隔離再輪替,因為成本很低
受影響版本僅 0.10.1
查看依據(4)
  • 廠商 / 維護者Guardrails AI 安全公告:2026-05-11 從 PyPI 安裝了 0.10.1 的使用者受影響any user who installed guardrails-ai==0.10.1 from PyPI on May 11, 2026.github.com
  • CVE 紀錄CVE 紀錄的結構化欄位只列 0.10.1 受影響"version":"= 0.10.1"cveawg.mitre.org
  • 漏洞資料庫OSV 只列 0.10.1 受影響osv.dev
  • 研究團隊Socket 研究人員:惡意程式碼在 Linux 上、套件被 import 時下載並執行遠端程式The compromised version contains malicious code that downloads and executes a remote payload on Linux systems upon import.github.com
修好的版本0.10.0(廠商公告)或 0.10.2 以上(CVE 紀錄與 NVD)
查看依據:來源說法不一(4)
  • 廠商 / 維護者說法不一Guardrails AI 安全公告只把 0.10.0 列為安全版本,發布時還沒有高於 0.10.1 的修補版No patched version above 0.10.1 is available yet.github.com
  • 廠商 / 維護者說法不一廠商 SECURITY_ADVISORY.md:0.10.0 及更早是安全版本,沒有提到 0.10.2github.com
  • CVE 紀錄說法不一CVE 紀錄:升級到 0.10.2 或降回 0.10.0,兩者都不受影響Users should upgrade to version 0.10.2 or downgrade to version 0.10.0, both of which are unaffected.cveawg.mitre.org
  • 廠商 / 維護者廠商發布說明:0.10.2 改用 PyPI trusted publishing 發佈release workflow for trusted publishinggithub.com
CVSS 向量
顯示完整向量CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
時間點
  • 漏洞出現 2026-05-11 · 惡意版本 0.10.1 上架 PyPI（太平洋時間） 來源
  • 首次公開 2026-05-11
CISA KEV未列入(未列入 KEV 不代表沒有被利用)
查看依據(4)
  • 本站判斷本站 2026-09-24 的 CISA KEV 快照沒有這個 CVE;未列入不代表沒有被利用
  • CERT / 政府CISA 在 CVE 紀錄中的 SSVC 評估為「實際利用:無」;惡意版本本身就是攻擊,這項評估不代表裝過的機器安全"Exploitation":"none"cveawg.mitre.org
  • 廠商 / 維護者廠商公告:攻擊者發佈了惡意的 0.10.1,約兩小時內被研究人員發現、遭 PyPI 隔離Security researchers identified the malicious package within approximately 2 hours of publication, and PyPI quarantined the repository.github.com
  • 廠商 / 維護者廠商檢查自家系統與存取紀錄後,沒有發現使用者資料經由廠商系統外流的證據;這只涵蓋廠商自己的系統,不能證明安裝過的機器沒有被偷走資料a review of system and access logs has produced no evidence of user data exfiltration through our systems.github.com

藍隊應對手冊

確認、修補 / 緩解、應變、強化。版本符合受影響條件不等於已被入侵;檢查沒有結果也不等於安全,每一項都有能證明與不能證明的範圍。標記的步驟對應下方攻擊流程裡可以擋下攻擊的那一步。

DETECT確認我受影響嗎?有沒有入侵跡象?
  1. 01找出是否裝過 0.10.1

    廠商建議:檢查開發機、虛擬環境、lockfile(記錄確切依賴版本的檔案)和 CI 映像檔。只要在 2026-05-11 從 PyPI 裝過 0.10.1,就算受影響。poetry.lock、uv.lock、Pipfile.lock 的套件名稱和版本在不同行,所以要分開比對;最後一行直接找安裝紀錄資料夾。不要用 pip 或 python 檢查可能已被感染的環境。

    唯讀查詢
    grep -rnE 'guardrails-ai==0\.10\.1' --include='*.txt' --include='*.in' . 2>/dev/null
grep -rn -A2 '^name = "guardrails-ai"' --include=poetry.lock --include=uv.lock . 2>/dev/null | grep 'version = "0.10.1"'
grep -rn -A6 '"guardrails-ai": {' --include=Pipfile.lock . 2>/dev/null | grep '"==0.10.1"'
find / -type d -name 'guardrails_ai-0.10.1.dist-info' 2>/dev/null
    步驟 4
  2. 02檢查研究人員公布的檔案路徑

    Socket 表示下載的程式會寫到 /tmp/transformers.pyz。這個路徑來自研究人員,不是廠商公布的入侵指標(IoC)。重開機後 /tmp 可能已被清空,所以找不到也不代表安全。

    唯讀查詢
    ls -l /tmp/transformers.pyz 2>/dev/null
    步驟 5
  3. 03稽核 GitHub 帳號活動

    廠商建議:檢查有沒有未經授權的工作流程執行、新建的 repo 或出乎意料的 commit。

    唯讀查詢
    gh run list --repo OWNER/REPO --limit 100
    步驟 1步驟 2步驟 6
MITIGATE修補 / 緩解先修補;還不能修補時先擋住
  1. 01移除 0.10.1,改用安全版本

    廠商公告建議 0.10.0,也可以從 v0.10.0 的 git tag 安裝。CVE 紀錄與 NVD 則也把 0.10.2 以上列為安全版本。

    會變更環境
    pip install "guardrails-ai==0.10.0"   # or "guardrails-ai>=0.10.2" per CVE record / NVD
    步驟 5
  2. 02Snowglobe / Guardrails Hub 使用者重新申請 API 金鑰

    廠商已在 2026-05-13 強制作廢所有 Snowglobe 與 Hub 的 API 金鑰,需要重新申請。

RESPOND應變發現入侵跡象時
  1. 01把機器視為可能遭入侵

    廠商建議:如果機器上有敏感憑證,考慮重灌。同一波攻擊的 npm 惡意程式有「權杖被撤銷就刪檔」的機制,因此 The Hacker News 建議先隔離、做映像保存,再撤銷權杖。guardrails 的 Python 惡意程式有沒有這個機制,目前未經證實。

    步驟 5步驟 6
  2. 02輪替那台機器能存取的所有憑證

    廠商列出的範圍包括 GitHub PAT、雲端金鑰、套件庫權杖和各種 API 金鑰。TanStack 對同一波攻擊的建議還包括 AWS、GCP、Kubernetes、Vault 與 SSH 憑證。

    步驟 6
HARDEN強化長期避免同類問題
  1. 01發佈套件改用 trusted publishing

    guardrails-ai 從 0.10.2 起改用 PyPI trusted publishing,不再保存長期有效的上傳權杖。你自己維護套件時也可以比照辦理。

    步驟 2步驟 3
  2. 02縮小 CI 權杖權限,並檢查開發工具設定資料夾

    Socket 針對這波攻擊建議:限制 GitHub Actions OIDC(CI 向雲端換取短期憑證的機制)的權限範圍,並檢查 .claude/ 與 .vscode/ 資料夾有沒有被植入持續存在的程式。

    步驟 1步驟 2
完整修復步驟與說明

處理順序很重要。 同一波攻擊的 npm 惡意程式會在偵測到權杖被撤銷時刪除家目錄,因此 The Hacker News 建議先隔離機器、做映像保存,再撤銷權杖。guardrails 的 Python 惡意程式有沒有這個機制,目前未經證實,但先隔離的成本很低。

  1. 找出所有裝過 0.10.1 的地方。 開發機、虛擬環境、requirements*.txt、poetry.lock、uv.lock、CI 快取和容器映像檔都要查。映像檔即使已重建,舊的建置紀錄也可能顯示當時裝了哪一版。
  2. 換成安全版本。 廠商建議 pip install "guardrails-ai==0.10.0",或從 v0.10.0 的 git tag 安裝;CVE 紀錄與 NVD 也接受 0.10.2 以上。
  3. 隔離後再輪替憑證。 範圍包括那台機器(或那個 CI 工作)能取得的所有權杖與金鑰,不只是 guardrails 相關的。
  4. 廠商的資料外洩說法有其範圍。 廠商說,檢查自家系統與存取紀錄後,沒有發現使用者資料經由廠商系統外流的證據。「沒找到證據」不等於「確定沒有外流」,而且這只涵蓋廠商自己的系統。研究人員指出,惡意程式是從攻擊者的伺服器下載竊取工具,因此你自己的機器是否安全,這項說法無法證明。

攻擊流程

從左到右是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

guardrails-ai 0.10.1 遭植入惡意程式:AI 安全函式庫的 PyPI 供應鏈入侵: 1. 偷到一名員工的 GitHub 個人存取權杖 → 2. 觸發約 30 個 repo 的 GitHub Actions,從建置產物中取出機密 → 3. 用偷來的上傳權杖把惡意 0.10.1 發佈到 PyPI → 4. 使用者或 CI 安裝了 guardrails-ai 0.10.1 → 5. 在 Linux 上 import 套件時,下載並執行遠端程式 → 6. 竊取憑證的工具蒐集機器上的機密CVE-2026-45758 · guardrails-ai 0.10.1 遭植入惡意程式:AI 安全函式庫的 PyPI 供應鏈入侵攻擊者你的系統外部偷到一名員工的 GitHub 個人存取權杖 — 個人存取權杖(PAT)是一串可以代替密碼操作 GitHub 的字串。廠商表示入侵就從這裡開始,但沒有說明權杖是怎麼外洩的。 1偷到一名員工的GitHub 個人存取權杖觸發約 30 個 repo 的 GitHub Actions,從建置產物中取出機密 — GitHub Actions 是自動建置與發佈的 CI/CD 流程。攻擊者從執行結果裡取得 repo 的機密設定,其中包括 PyPI 的上傳權杖。廠商也說攻擊者試圖進入其 Ray 推論叢集和其他套件系統,但沒有成功。 2觸發約 30 個 repo 的GitHub Actions,從建置產物中取出機密用偷來的上傳權杖把惡意 0.10.1 發佈到 PyPI — 發佈時間是 2026-05-11 太平洋時間下午 6 點左右。研究人員約兩小時後發現,PyPI 隨即把整個專案隔離。 3用偷來的上傳權杖把惡意0.10.1 發佈到 PyPI使用者或 CI 安裝了 guardrails-ai 0.10.1 — 只要在那段時間窗內安裝,而且沒有鎖定版本,就可能拿到 0.10.1。 4使用者或 CI 安裝了guardrails-ai0.10.1在 Linux 上 import 套件時,下載並執行遠端程式 — Socket 表示惡意程式碼加在 __init__.py 裡,會把檔案寫到 /tmp/transformers.pyz,再直接用 python3 執行,完全不檢查完整性。只安裝、不 import 會不會執行,目前沒有來源說明。 5在 Linux 上 import套件時,下載並執行遠端程式竊取憑證的工具蒐集機器上的機密 — 根據 Wiz 的報告,下載的是一個模組化的憑證竊取工具,從攻擊者的指揮伺服器(C2)取得。廠商沒有公布它做了什麼。 6竊取憑證的工具蒐集機器上的機密攻擊路徑可在此擋下PlainCVE · plaincve.date/vulns/cve-2026-45758-guardrails-ai-pypi-compromise · CC BY 4.0
圖片可自由用於報導與教學,採 CC BY 4.0,圖上已附出處。
  1. 攻擊者

    偷到一名員工的 GitHub 個人存取權杖

    個人存取權杖(PAT)是一串可以代替密碼操作 GitHub 的字串。廠商表示入侵就從這裡開始,但沒有說明權杖是怎麼外洩的。

    防禦: 使用權限範圍小、有效期短的權杖,並定期檢查哪些權杖還有效。

  2. 攻擊者

    觸發約 30 個 repo 的 GitHub Actions,從建置產物中取出機密

    GitHub Actions 是自動建置與發佈的 CI/CD 流程。攻擊者從執行結果裡取得 repo 的機密設定,其中包括 PyPI 的上傳權杖。廠商也說攻擊者試圖進入其 Ray 推論叢集和其他套件系統,但沒有成功。

    防禦: 不要讓建置產物帶出機密,並限制誰能觸發工作流程。

  3. 攻擊者

    用偷來的上傳權杖把惡意 0.10.1 發佈到 PyPI

    發佈時間是 2026-05-11 太平洋時間下午 6 點左右。研究人員約兩小時後發現,PyPI 隨即把整個專案隔離。

    防禦: 改用 PyPI 的 trusted publishing,不再保存長期有效的上傳權杖。0.10.2 已經這樣做。

  4. 你的系統

    使用者或 CI 安裝了 guardrails-ai 0.10.1

    只要在那段時間窗內安裝,而且沒有鎖定版本,就可能拿到 0.10.1。

    防禦: 用 lockfile 鎖定確切版本,新版本就不會在不知不覺中被裝進來。

  5. 你的系統

    在 Linux 上 import 套件時,下載並執行遠端程式

    Socket 表示惡意程式碼加在 __init__.py 裡,會把檔案寫到 /tmp/transformers.pyz,再直接用 python3 執行,完全不檢查完整性。只安裝、不 import 會不會執行,目前沒有來源說明。

    防禦: 改用 0.10.0 或 0.10.2 以上,並移除 0.10.1。

  6. 外部

    竊取憑證的工具蒐集機器上的機密

    根據 Wiz 的報告,下載的是一個模組化的憑證竊取工具,從攻擊者的指揮伺服器(C2)取得。廠商沒有公布它做了什麼。

    防禦: 輪替那台機器能存取的所有憑證,並稽核 GitHub 活動。

影響範圍

條件是否受影響
2026-05-11 從 PyPI 安裝了 guardrails-ai 0.10.1,並在 Linux 上 import 過受影響,應視為可能遭入侵
裝過 0.10.1,但只在非 Linux 系統上使用,或從未 import研究人員說惡意程式只在 Linux 上、import 時執行;只安裝不 import 是否安全,未經證實。仍建議輪替憑證
0.10.0 或更早版本不受影響
0.10.2 以上不受影響(依 CVE 紀錄與 NVD)

各來源對「安全版本」的說法不完全一致:

來源受影響安全版本
廠商 GHSA 公告0.10.1只列 0.10.0
廠商 SECURITY_ADVISORY.md0.10.10.10.0 及更早;沒有提到 0.10.2
CVE 紀錄(CNA:GitHub)僅 0.10.10.10.0 或 0.10.2 以上
NVD0.10.1升級到 0.10.2 或降回 0.10.0
OSV僅 0.10.1未列

PyPI 上已經看不到 0.10.1,版本紀錄直接從 0.10.0 跳到 0.10.2(2026-06-04 釋出)。

原理

這不是程式寫錯的漏洞,而是發佈流程被入侵,惡意程式碼被人刻意放進正式版本。這類情況歸類為 CWE-506(內嵌惡意程式碼)。

廠商說明的入侵經過:

  1. 一名員工的 GitHub 個人存取權杖(PAT,可以代替密碼操作 GitHub 的一串字串)外洩。
  2. 攻擊者用這個權杖,在 guardrails-ai 組織底下約 30 個 repo 觸發 GitHub Actions(自動建置與發佈的 CI/CD 流程),再從建置產物中取出 repo 的機密設定。
  3. 攻擊者拿其中一個 PyPI 上傳權杖,發佈了惡意的 0.10.1。廠商也提到,攻擊者試圖進入其 Ray 推論叢集和其他套件系統,但沒有成功。

研究人員觀察到的惡意行為(廠商沒有公布):

  • Socket 表示,惡意程式碼加在套件的 __init__.py,也就是套件被 import 時一定會跑的檔案。在 Linux 上,它會下載一個遠端檔案寫到 /tmp/transformers.pyz,再直接執行,完全不做完整性檢查。
  • Wiz 表示新增的程式只有 13 行,作用是從攻擊者的指揮伺服器(C2)下載並執行一個模組化的憑證竊取工具。Socket 公布的下載網域是 git-tanstack[.]com(已做防誤點處理)。
  • The Hacker News 指出,同一波攻擊的 npm 套件是在「安裝時」執行,這個 Python 套件則是在「import 時」執行。

概念示意(不是 Guardrails 的實際設定): 問題的根源是 CI 裡存著長期有效的上傳權杖,一旦 repo 機密外流,任何人都能用它發佈新版本。

展開程式碼範例(yaml)
# 有風險的做法:長期有效的上傳權杖存在 repo 機密裡
- run: twine upload dist/*
  env:
    TWINE_PASSWORD: ${{ secrets.PYPI_TOKEN }}
展開程式碼範例(yaml)
# 較安全的做法:trusted publishing,發佈時才臨時換取短期憑證
permissions:
  id-token: write
- uses: pypa/gh-action-pypi-publish@release/v1

0.10.2 的發佈說明表示,專案已經改用 PyPI trusted publishing。

時間軸

日期事件
2026-05-11 約 18:00(太平洋時間)惡意 0.10.1 發佈到 PyPI
2026-05-11 約 20:00(太平洋時間)被發現,PyPI 隔離整個專案
2026-05-12Socket 在 GitHub 開 issue #1473;廠商發佈 GHSA 公告
2026-05-13CVE 編號保留;廠商於太平洋時間 14:00 作廢所有 Snowglobe/Hub API 金鑰
2026-05-19OSV 收錄
2026-06-04釋出 0.10.2
2026-06-05CVE 公開
2026-06-08CISA 加上 SSVC 評估
2026-07-23NVD 最後更新(狀態 Analyzed)

延伸閱讀

  • 評分: CVSS 3.1 9.6(嚴重),由 GitHub(CNA)評定。NVD 把它列為次要評分,沒有另外給自己的分數。
  • 是否「遭利用」: 這個 CVE 不在 CISA KEV,CISA 的 SSVC 評估寫的是 Exploitation: none。但惡意套件本身就是攻擊:只要裝了並 import 過 0.10.1,就應該假設惡意程式已經執行。
  • 與 Mini Shai-Hulud 的關係: Socket、Wiz、The Hacker News 和 SecurityWeek 都把這起事件歸入 2026-05-11 的 Mini Shai-Hulud 攻擊波,Socket 並點名 TeamPCP。廠商只說是更大規模攻擊的一部分,沒有提到這些名字。另外,TanStack 的入侵路徑是 pull_request_target 工作流程加上快取汙染,Guardrails 則是員工 PAT 外洩。這個套件是被蠕蟲自動擴散感染,還是另外遭到人為入侵,未經證實。
  • 未經證實的說法: SecurityWeek 稱惡意程式會鎖定 1Password、Bitwarden 等密碼管理工具,並在以色列或伊朗語系設定的系統上把音量開到最大播放音訊、刪除檔案。目前只有這一個來源這麼說。
  • 別名: GHSA-xmpw-2vmm-p4p6、PYSEC-2026-206。
  • 同一天受害的還有 Mistral AI 的 PyPI 套件(mistralai 2.4.6);TanStack 的事件另有編號 CVE-2026-45321。

驗證紀錄 已人工審稿、核對來源;尚未在我們的環境重現

人工審稿2026-09-24

驗證紀錄只寫環境與結果,不公開重現步驟或可攻擊他人系統的程式。詳見 政策.

來源

  1. 安全公告Malicious code in guardrails-ai 0.10.1 (supply chain compromise) — GHSA-xmpw-2vmm-p4p6 · Guardrails AI (GitHub), 2026-05-12 · 查閱 2026-09-23
  2. 廠商說明SECURITY_ADVISORY.md · Guardrails AI · 查閱 2026-09-23
  3. 安全公告CVE-2026-45758 record · CVE Program / GitHub_M, 2026-06-05 · 查閱 2026-09-23
  4. CVE / NVD / OSVNVD - CVE-2026-45758 · NIST NVD, 2026-06-05 · 查閱 2026-09-23
  5. 安全公告GHSA-xmpw-2vmm-p4p6 · OSV, 2026-05-19 · 查閱 2026-09-23
  6. 安全公告Advisories for Pypi/Guardrails-Ai package · GitLab · 查閱 2026-09-23
  7. 修補 commit / 版本Releases · guardrails-ai/guardrails · Guardrails AI, 2026-06-04 · 查閱 2026-09-23
  8. 其他guardrails-ai release history · PyPI · 查閱 2026-09-23
  9. 研究文章[SECURITY] Supply Chain Compromise in guardrails-ai v0.10.1 on PyPI (issue #1473) · Socket Threat Research (GitHub issue), 2026-05-12 · 查閱 2026-09-23
  10. 研究文章TanStack npm Packages Compromised in Ongoing Mini Shai-Hulud Supply-Chain Attack · Socket, 2026-05-11 · 查閱 2026-09-23
  11. 研究文章Mini Shai-Hulud Strikes Again: TanStack + more npm Packages Compromised · Wiz, 2026-05-12 · 查閱 2026-09-23
  12. 廠商說明Postmortem: TanStack npm supply-chain compromise · TanStack, 2026-05-15 · 查閱 2026-09-23
  13. 研究文章A Mini Shai-Hulud Has Appeared · StepSecurity, 2026-04-29 · 查閱 2026-09-23
  14. 新聞報導Mini Shai-Hulud Worm Compromises TanStack, Mistral AI, Guardrails AI & More Packages · The Hacker News, 2026-05-12 · 查閱 2026-09-23
  15. 新聞報導TanStack, Mistral AI, UiPath Hit in Fresh Supply Chain Attack · SecurityWeek, 2026-05-12 · 查閱 2026-09-23

媒體簡報

一句話

Guardrails AI 是一個幫 AI 應用程式檢查與過濾輸出的開源安全函式庫。2026 年 5 月 11 日,攻擊者用從公司 CI 流程偷來的上傳權杖,把一個惡意的 0.10.1 版發佈到 Python 套件庫 PyPI,約兩小時後被發現並隔離。研究人員表示,在 Linux 上載入這個版本時,會下載並執行一個竊取憑證的工具。多家資安公司認為這起事件屬於同一天的 Mini Shai-Hulud 供應鏈攻擊,但廠商本身沒有這樣表述。

關鍵數字

受影響版本
僅 0.10.1(2026-05-11 發佈) github.com
嚴重度
CVSS 3.1 9.6 嚴重(CNA:GitHub) nvd.nist.gov
CVE 公開
2026-06-05 nvd.nist.gov
乾淨的新版本
0.10.2(2026-06-04 釋出) pypi.org
研究人員歸因
Mini Shai-Hulud 攻擊波/TeamPCP(非廠商確認) github.com

已確認

  • 惡意的 guardrails-ai 0.10.1 在 2026-05-11 被發佈到 PyPI,約兩小時後遭隔離(廠商公告)。
  • 起因是一名員工的 GitHub PAT 外洩,攻擊者藉此濫用 CI 取得 PyPI 上傳權杖(廠商說明)。
  • 廠商表示,檢查自家系統與存取紀錄後,沒有發現使用者資料經由廠商系統外流的證據;這只涵蓋廠商自己的系統,不能證明安裝過的機器沒有被偷走資料。

尚未確認 / 說法不一

  • 與 Mini Shai-Hulud/TeamPCP 的關聯只來自研究人員與媒體;廠商只說是「更大規模攻擊的一部分」。
  • SecurityWeek 稱惡意程式會針對密碼管理工具,並在以色列或伊朗語系設定的系統上播放音訊、刪除檔案;其他來源沒有證實。
  • 只安裝、不 import 會不會執行惡意程式,沒有來源明確說明。
  • 廠商公告只把 0.10.0 列為安全版本;CVE 紀錄與 NVD 另外把 0.10.2 以上也列為安全。

可引用的一句話

這次沒有任何一行程式寫錯;攻擊者只是拿到了發佈的鑰匙,連 AI 的安全護欄本身都能被換掉。

圖片

下載分享圖(PNG) · 攻擊流程圖(可下載)

引用時請標示「PlainCVE」並附上本頁連結。 完整引用格式見下方「如何引用本頁」。有事實錯誤請回報.

如何引用本頁

本文採 CC BY 4.0,轉載請保留署名與連結。

PlainCVE 團隊(2026)。《guardrails-ai 0.10.1 遭植入惡意程式:AI 安全函式庫的 PyPI 供應鏈入侵》。PlainCVE。https://plaincve.date/vulns/cve-2026-45758-guardrails-ai-pypi-compromise(查閱日期:YYYY-MM-DD)
BibTeX
@misc{cve202645758guardrailsaipypicompromise2026,
  title  = {guardrails-ai 0.10.1 遭植入惡意程式:AI 安全函式庫的 PyPI 供應鏈入侵},
  author = {PlainCVE 團隊},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/vulns/cve-2026-45758-guardrails-ai-pypi-compromise},
  note   = {更新於 2026-09-24}
}