最近 Threat actors use agentic AI tooling to find and abuse exposed secrets | Microsoft Security Blog 微軟資安報告文章提到，名為 ARTEX 的代理式 AI 攻擊框架被用來翻找 GitHub 公開儲存庫中不慎外洩的憑證與金鑰。之所以值得關注，在於它把一個老問題推向新階段，過去靠人工翻找程式碼的慢工細活，如今由 AI 代理接手，掃描、判讀到後續利用可以一氣呵成，影響面涵蓋雲端服務、應用程式憑證與 AI 推論相關的 API 金鑰。
技術成因：代理式工具把人工瓶頸整段拿掉
根據微軟安全部落格的說明，攻擊者長期以來就會在公開程式碼儲存庫中搜尋外洩的憑證、密鑰與其他驗證素材，這項技巧本身並不新鮮，真正的限制在於人力，操作者必須逐一找到儲存庫、閱讀內容、再拿驗證素材去發動後續行動。
ARTEX 這類代理式工具改變的是節奏與深度，它能在多個儲存庫之間以更快速度掃描，並由代理自行分析掃描結果、直接發動後續攻擊，讓攻擊鏈中需要人手介入的環節大幅減少。微軟指出，至少有一例中，AI 代理從掃描 GitHub 找尋密鑰，進展到從 Azure Key Vault 外洩資料，全程只花五分鐘。
受影響範圍：從原始碼一路燒到雲端租戶
微軟威脅情報指出，外洩的素材包含憑證、應用程式憑證，以及跨多個應用與雲端服務的 AI 推論相關 API 金鑰，攻擊者取得後可對受害組織發動進一步的惡意活動。微軟自 2026 年 10 月 28 日起觀察到來自 IP 位址 199.19.77[.]84 的服務主體登入成功紀錄，涉及多家受影響客戶的多個應用程式 ID，其中包含多租戶應用程式憑證在來源端，也就是廠商自有的應用程式，遭到竊取後被用來存取多個下遊租戶的情況。
CyberQ 分析，攻擊者利用這些竊得的憑證進行雲端資源探索、憑證與資料外洩，範圍涵蓋 Azure Key Vault 與儲存體帳戶，也包含對 Azure AI 服務的濫用。微軟另外從 65.87.223.26 觀察到惡意操作，包括在使用者代理程式內嵌 shell 指令所透露的漏洞利用跡象，以及嘗試取得 App Service 驗證權杖，並提到 Todyl 也回報了涉及相同 IP 的類似行動。另有來自 157.22.126.128 的偵察行動，目標是受害者在 Azure AI 服務上部署的 AI 工作負載。
修補與緩解：先找出密鑰，再立刻輪替
微軟建議組織掃描自己在 GitHub 上的程式碼，確認哪些位置存在密鑰，除了把密鑰從程式碼庫中移除，受影響的組織應立即輪替任何已外洩的金鑰或憑證。GitHub 本身會自動掃描公開儲存庫以偵測密鑰，組織除了掃描自家儲存庫，也可以啟用 GitHub 的公開監控功能。社群中有網友提到，這波事件讓人意識到安全態勢上的怠惰或草率，會被 AI 加持的攻擊迅速且嚴厲地懲罰。
也有網友指出，過去不在意憑證外洩從來就不是好事，但現在確實得留意資安稅了。另一位網友的看法更長線，認為再過幾年，每一套軟體都會被大量代理程式每分每秒逆向工程、掃描與測試，等於要補繳數十年的資安欠稅。
至於 NVD 上與此元件相關的近期紀錄，包括 CVE-2026-105941、CVE-2026-88132 與 CVE-2026-85922，屬於 Azure Key Vault 與 GitHub 這類元件的關聯漏洞，讀者可對照文末表格查看細節，但並非這起 ARTEX 事件本身被引用的編號，請當參考並做應對處理。
CyberQ 觀點
企業應把 GitHub 公開儲存庫視為對外暴露面的一部分，啟用密鑰掃描並定期清查，任何曾出現在公開程式碼中的金鑰都應視為已外洩並立即輪替。
CyberQ 建議，同時盤點多租戶應用程式與服務主體的權限範圍，縮小單一憑證外洩可觸及的雲端資源，並針對異常來源 IP 與非預期登入建立告警。使用者端則要養成不把金鑰寫進程式碼的習慣。
CVE 漏洞資料核實
以下為撰文時以 NVD 2.0 API 依元件關鍵字（azure key vault、github）查得的近期公告紀錄，屬同一元件的關聯漏洞，並非本文事件本身所對應的編號，僅供參考 NVD：CVE-2026-105941、NVD：CVE-2026-88132、NVD：CVE-2026-85922：
| CVE 編號 | CVSS 分數／嚴重度 | 公佈時間（UTC） | 受影響廠商／產品 | 弱點類型 | 官方摘要（原文節錄） | 參考連結 |
|---|---|---|---|---|---|---|
| CVE-2026-105941 | 8.1（HIGH） | 2026-10-20T13:16:39 | ， | CWE-918 | The Azure Key Vault KMS provider in Kroxylicious accepts an untrusted vaultName from wire-deserialized EDEK bytes without format validation, enabling SSRF that exfiltrates the proxy’s Azure bearer token to an attacker-controlled host. Token replay against the real Key Vault defeats the entire record-encryption trust model. | https://access.redhat.com/security/cve/CVE-2026-105941 https://bugzilla.redhat.com/show_bug.cgi?id=2510876 https://github.com/kroxylicious/kroxylicious/commit/aa1b02a5f8e5bb5003 |
| CVE-2026-88132 | 5.9（MEDIUM） | 2026-10-13T19:21:32 | ， | CWE-346 | Origin validation error in Azure Key Vault allows an unauthorized attacker to disclose information over a network. | https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-88132 |
| CVE-2026-85922 | 7.4（HIGH） | 2026-10-13T19:21:18 | microsoft / azure-keyvault-administration、microsoft / azure-keyvault-certificates、microsoft / azure-keyvault-keys、microsoft / azure-keyvault-secrets、microsoft / azure-keyvault-securitydomain | CWE-1390 | Weak authentication in Azure Key Vault allows an unauthorized attacker to bypass a security feature over a network. | https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-85922 |
