Meta Ads MCP 嚴重漏洞：未經驗證即可竊取操作者 Meta 存取金鑰
GitHub Security Advisory (GHSA-9gw6-46qc-99vr) · 2026-05-20 發布，2026-06-11 加入資料庫
GHSA-9gw6-46qc-99vr（CVE-2026-48039）於 2026 年 5 月 20 日披露，影響 pip 套件 meta-ads-mcp，CVSS v3.1 評分為 9.1（Critical）。漏洞允許任何網路可達的未經驗證攻擊者執行 MCP 工具，並從錯誤回應中取得操作者的 Meta Graph API 長效存取金鑰。自行架設此服務並將端口暴露於不受信任網路的使用者面臨最高風險。
漏洞機制
問題源自兩個相互疊加的設計缺陷。認證中介層繞過發生在 AuthInjectionMiddleware.dispatch() 函數中：當請求標頭中既無 Authorization: Bearer 也無 X-PIPEBOARD-API-TOKEN 時，中介層僅記錄「No authentication tokens found in headers」卻仍呼叫 call_next(request)，實際上讓請求在無驗證的情況下繼續傳遞，而非回傳 HTTP 401。
第二個缺陷是憑證洩露：工具處理器在缺少每請求憑證時，自動回退使用環境變數 META_ACCESS_TOKEN。make_api_request() 函數透過 URL 查詢參數傳遞此金鑰（形如 ?access_token=EAAG...），而非使用請求標頭。當 Graph API 呼叫失敗時，錯誤處理器將完整請求 URL——含明文金鑰——序列化進 JSON-RPC 回應的 request_url 欄位，以 HTTP 200 OK 回傳給攻擊者。
完整攻擊鏈僅需四步驟：
- 攻擊者向
/mcp端點送出未帶任何認證的 HTTP POST - 中介層未驗證即轉發請求
- 工具處理器以
META_ACCESS_TOKEN呼叫 Meta Graph API - API 失敗後，回應體中出現含明文金鑰的完整 URL
成功利用後，攻擊者可在 MCP 介面外直接使用該長效金鑰，對被連結的廣告帳號執行讀寫操作、消耗 API 配額，甚至接管整個 Meta 廣告帳戶。CVE 評分向量 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N 反映此漏洞無需任何預設條件即可利用。
受影響版本
所有 meta-ads-mcp ≤ 1.0.108 版本均受影響。由於 1.0.102 至 1.0.105 缺少對應的 git tag，尚無法確認這些特定版本的確切狀態，但保守估計應一同視為受影響。CWE 分類涵蓋三項弱點：CWE-287（不當認證）、CWE-209（錯誤訊息包含敏感資訊）、CWE-522（憑證保護不足）。
修補與緩解
版本 1.0.109（2026-05-20 發布）修正了上述兩項根本問題：HTTP 中介層現在要求明確的 Authorization: Bearer 或 X-PIPEBOARD-API-TOKEN 標頭，缺少時直接回傳 401；Graph API 錯誤回應也已遮蔽 URL 中的敏感憑證，防止金鑰出現在日誌與回應體中。
已安裝舊版的操作者應立即升級至 1.0.109 或更新版本，同時輪換現有的 Meta 存取金鑰，並審查 Graph API 存取日誌以確認是否已遭利用。使用 stdio 傳輸（非 HTTP）的本地部署不受此漏洞影響。
原始來源：GitHub Security Advisory GHSA-9gw6-46qc-99vr、meta-ads-mcp 1.0.109 Release Notes
數百個 AUR 套件遭資訊竊取程式污染，Arch Linux 社群緊急清除惡意提交
Arch Linux aur-general 郵件列表 · 2026-06-11
2026 年 6 月 11 日，Arch Linux 使用者倉庫（AUR）發生大規模供應鏈攻擊事件：數百個套件的 Git 提交遭到竄改，植入資訊竊取程式（infostealer）。AUR 維護團隊成員 Jonathan Grotelüschen 在官方郵件列表確認事件，表示正全力重置或刪除所有惡意提交，並封禁相關帳號。
攻擊手法與影響範圍
AUR 是 Arch Linux 社群維護的非官方套件倉庫，任何使用者均可貢獻 PKGBUILD 腳本，安全性高度依賴社群審查與帳號安全。此次事件中，攻擊者取得多個套件維護者帳號的存取權，直接推送含惡意程式碼的提交至 AUR Git 倉庫。受影響套件之一為 gnome-randr-rust，惡意提交在 PKGBUILD 建置流程中注入資訊竊取程式邏輯，使任何透過 AUR helper（如 yay、paru）安裝或更新這些套件的使用者，在建置階段即遭惡意程式碼執行。
資訊竊取程式（infostealer）屬於一類專門收集本機憑證、瀏覽器儲存的密碼、加密貨幣錢包及 Session Cookie 的惡意軟體。與勒索軟體不同，infostealer 通常靜默運作，不阻斷系統服務，使被入侵的使用者難以即時察覺。此類攻擊若成功，可能導致帳號接管、財務損失或進一步的橫向滲透。
由於 AUR 採用分散式貢獻模型，精確的受影響套件清單難以即時公告。AUR 維護團隊開放社群透過回覆郵件列表舉報其他疑似遭污染的套件，以集中追蹤。此次攻擊僅影響 AUR 套件，Arch Linux 官方倉庫（core、extra、multilib）並未受到牽連。
受影響版本
受影響套件的範圍尚在調查中。使用者若在 2026 年 6 月初透過 AUR helper 安裝或更新套件，均應保持警惕。AUR 採取滾動更新模型，受影響套件的「版本號」並非辨別感染的有效指標，應以各套件的 Git 提交歷史作為判斷依據。以下情形的使用者風險最高：
- 事發期間執行過
yay -Syu、paru -Syu或手動從 AUR 安裝套件 - 安裝了維護者帳號已被識別為遭盜用的套件
- 未在安裝前手動審查 PKGBUILD 內容
修補與緩解
AUR 維護團隊持續重置惡意提交並封禁被盜用帳號。使用者應立即審查近期從 AUR 安裝或更新的套件清單，可使用 pacman -Qm 列出所有來自 AUR 的套件，並比對各套件 PKGBUILD 的 Git 提交歷史，確認是否存在非預期的修改。
若懷疑系統已遭感染，應立即採取以下措施：
- 變更所有本機儲存的帳號密碼及瀏覽器 Saved Passwords
- 撤銷並重新生成 SSH 金鑰、API Token 及加密貨幣錢包
- 審查
~/.bash_history、~/.zsh_history及系統日誌中的異常命令 - 考慮從已知乾淨的備份重建系統
此事件再次凸顯社群驅動套件倉庫的固有信任風險。使用 AUR 前手動檢閱 PKGBUILD 及其近期提交歷史是防範此類供應鏈攻擊的基本措施；進階使用者亦可考慮在隔離的 chroot 或容器環境中執行 AUR 建置流程，以限制惡意程式碼的影響範圍。
CodeIgniter4 檔案上傳驗證繞過漏洞：ext_in 規則讓 PHP Shell 偽裝成圖片通過
GitHub Security Advisory (GHSA-2gr4-ppc7-7mhx) · 2026-05-20 發布，2026-06-11 加入資料庫
GHSA-2gr4-ppc7-7mhx（CVE-2026-48062）於 2026 年 5 月 20 日揭露，影響 Composer 套件 codeigniter4/framework 所有 4.7.2 以前版本，CVSS v3 評分 9.8（Critical）。此漏洞允許攻擊者上傳含有惡意程式碼的 PHP 檔案，繞過 ext_in 驗證規則的限制，在特定部署條件下實現任意程式碼執行（RCE）。漏洞由研究員 @z3moo 與 @teebow1e 回報，已於 v4.7.3 修復。
漏洞機制
CodeIgniter4 的 ext_in 上傳驗證規則原意是限制使用者只能上傳特定副檔名的檔案（例如僅允許 .gif、.jpg）。然而修復前的實作只比對 MIME 型別推導出的「猜測副檔名」（guessed extension），而非用戶端實際提供的檔案名稱副檔名。MIME 型別檢測依賴檔案內容的魔術位元組（magic bytes），攻擊者可構造一個名為 shell.php、但開頭包含 GIF 魔術位元組（GIF89a）的檔案。
驗證流程中，系統讀取檔案內容後判斷其 MIME 型別為 image/gif，推導副檔名為 gif，符合 ext_in[gif,jpg,png] 規則而通過驗證。實際上檔案名稱仍為 shell.php，若應用程式保留原始檔名並將其儲存至 Web 伺服器可直接存取且允許 PHP 執行的目錄，攻擊者隨後即可透過 HTTP 請求觸發該 PHP 指令碼，取得伺服器端程式碼執行能力。弱點類型為 CWE-434（危險型別檔案的無限制上傳）。
下表比較修復前後的驗證行為：
| 情境 | 修復前（≤ 4.7.2） | 修復後（≥ 4.7.3） |
|---|---|---|
上傳 image.gif（真實 GIF） | 通過 | 通過 |
上傳 shell.php（含 GIF magic bytes） | 通過（漏洞） | 拒絕（副檔名不符） |
上傳 evil.php.gif（真實 GIF 內容） | 通過 | 拒絕（須同時比對兩者） |
受影響版本
codeigniter4/framework < 4.7.3 的所有版本均受影響（注意：修補版本為 v4.7.3，4.7.2 本身仍受影響）。實際遭利用需同時滿足以下條件：
- 應用程式使用
ext_in規則驗證上傳檔案副檔名 - 保留用戶端提供的原始檔案名稱（未重新命名）
- 上傳目標目錄位於 Web 根目錄（Web root）內
- Web 伺服器對該目錄啟用 PHP 腳本執行
不符合上述所有條件的應用程式仍應升級，因為 ext_in 的驗證邏輯本身存在根本性缺陷，無法保證副檔名與內容一致。
修補與緩解
CodeIgniter4 v4.7.3（2026-05-22 發布）修改了 ext_in 規則：驗證時同時比對用戶端提供的檔案名稱副檔名與MIME 型別偵測結果，兩者皆須符合允許清單才能通過。此修正確保 shell.php 即使內含 GIF 魔術位元組，也因其副檔名 .php 不在允許清單中而被拒絕。
建議所有 CodeIgniter4 開發者立即升級至 v4.7.3。除升級外，亦建議採取縱深防禦措施：
- 使用
$file->store()方法儲存上傳檔案，自動產生隨機化檔名 - 將上傳目錄移至 Web root 之外，透過應用程式層提供下載
- 在上傳目錄的
.htaccess或 Nginx 設定中明確禁用腳本執行 - 對於已部署且使用者可能已上傳檔案的系統，審查上傳目錄中是否存在
.php、.phtml等可執行副檔名的檔案
原始來源：GitHub Security Advisory GHSA-2gr4-ppc7-7mhx、CodeIgniter4 CHANGELOG.md