CVE-2026-46529：Evince/Atril 十年 RCE——PDF 觸發 GTK 模組載入執行任意程式碼
medeiros.zip · 2026-05-22
安全研究員於 2026 年 5 月 22 日揭露 CVE-2026-46529，影響 Linux 上最普遍的 PDF 檢視器 Evince、Atril 與 XReader（三者共用同一基礎程式碼）。漏洞存在超過十年，允許攻擊者透過精心製作的 PDF 檔案達成遠端程式碼執行（RCE），無需使用者做任何操作，僅需點擊開啟即可觸發。
漏洞機制
漏洞根源在 shell/ev-application.c 的 ev_spawn 函式，負責處理 PDF 內的 /GoToR（Go to Remote）動作——這個 PDF 標準功能允許開啟另一份文件並跳至指定頁面或命名目標。ev_spawn 在組裝命令列參數時，對三個參數未套用 g_shell_quote() 進行 shell 跳脫：
--page-label=%s
--named-dest=%s
--find=%s未跳脫的空白字元使攻擊者控制的字串被 shell 拆分為多個獨立參數，等效於向子程序注入任意命令列旗標。
利用鏈：--gtk-module 與 dlopen
攻擊者注入 --gtk-module=%f 旗標。GTK3 在處理 --gtk-module 時呼叫 g_module_open()，後者底層使用 dlopen() 載入指定路徑的共享函式庫。標記為 __attribute__((constructor)) 的函式會在載入時自動執行。
完整利用使用多用途（polyglot）檔案——一個既是合法 PDF 又是可載入 ELF 共享庫的檔案。使用者點擊此 PDF 時，ev_spawn 開啟子程序，注入的 --gtk-module 旗標指向 PDF 自身路徑，GTK3 透過 dlopen() 載入它並執行 constructor，完成 RCE。
受影響版本與修補狀態
研究員已向 Evince 與 Atril 維護者報告，修補狀態尚未公開確認。建議臨時緩解措施：
- 避免在 Evince/Atril 中開啟來源不明的 PDF 檔案
- 使用沙箱環境（如 Flatpak 版本）限制子程序能存取的路徑
- 考慮切換至具有更嚴格程序隔離的 PDF 檢視器（如 Okular 的沙箱模式）
Megalodon：六小時內 5,718 個惡意 commit 污染 5,561 座 GitHub 倉庫
safedep.io · 2026-05-22
資安公司 SafeDep 於 2026 年 5 月 22 日揭露代號 Megalodon 的供應鏈攻擊事件。攻擊者在 2026 年 5 月 18 日的六小時窗口內，透過注入惡意 GitHub Actions workflow，對 5,561 個倉庫送出 5,718 個惡意 commit，以 base64 編碼的 bash payload 竊取 CI 環境中的雲端憑證。
攻擊向量與 workflow 注入手法
攻擊者取得目標倉庫的存取權（推測透過被盜的 Personal Access Token 或 deploy key），以偽造的 git 身分（如 build-bot、auto-ci）提交惡意 workflow 檔案。兩種 workflow 變體分別利用不同的自動化觸發點：
- SysDiag 大量版：新增觸發條件
push（所有分支）+pull_request_target，確保每次 commit 或 PR 都執行惡意 payload - Optimize-Build 目標版：替換合法 workflow 為使用
workflow_dispatch觸發的版本，建立可遠端啟動的休眠後門
兩種變體均申請 id-token: write（OIDC token 生成）與 actions: read 權限，啟用雲端身分冒用。
Payload 竊取範圍
解碼後的 bash payload 收集：
- 所有 CI 環境變數與程序環境（含 secrets）
- AWS credentials、GCP access token、Azure IMDS token
- SSH keys、Docker config、
.npmrc、Kubernetes config - GitHub Actions OIDC token，可用於冒充合法雲端身分
- 透過 30+ 個 regex pattern 掃描原始碼中的 secrets
供應鏈放大效應在 Tiledesk 案例中體現：被污染倉庫的維護者從受損來源發佈了惡意 npm 版本，讓污染向下游傳播至 npm 使用者。
緩解措施
- 限制 workflow 權限至最小必要範圍（明確指定
permissions） - 監控未連結帳號的 unsigned commit 與異常身分
- 實施分支保護規則，要求 PR review 才能合併 workflow 變更
- 稽核 PAT/deploy key 存取並輪換可能已洩漏的憑證
原始來源：SafeDep — Megalodon
Google GCP API 金鑰刪除後最長 23 分鐘仍有效：最終一致性的安全隱患
aikido.dev · 2026-05-22
Aikido Security 研究員於 2026 年 5 月 22 日揭露 Google Cloud Platform API 金鑰的撤銷延遲問題：刪除 API 金鑰後，認證仍可成功持續 8 至 23 分鐘，中位數約 16 分鐘。相比之下，Service Account 金鑰約 5 秒完成撤銷，新版 Gemini API 金鑰（AQ. 前綴）約 1 分鐘。Google 最初拒絕修復，後於 2026 年 5 月 22 日重新將此問題標記為 P0。
測試方法與數據
研究員在 10 次測試中系統性地於金鑰刪除後持續發送認證請求，記錄成功率與地區差異：
| 地區 | 刪除後認證成功率 |
|---|---|
| US-East1、Europe-West1 | 約 49% |
| Asia-Southeast1 | 約 22% |
同一分鐘內的成功率在 5% 至 79% 之間高度變動，反映 GCP 全球認證基礎設施的最終一致性（eventual consistency）架構——不同認證伺服器的金鑰快取失效時間不同步。
受影響服務與攻擊場景
所有可對應到 GCP API 金鑰的服務均受影響，包括 Gemini（對話記錄與上傳檔案存取）、BigQuery（資料查詢）、Google Maps（API 請求繼續計費）。GCP 控制台在這段窗口期內無法顯示金鑰是否仍在運作，且已刪除金鑰的請求以 apikey:UNKNOWN 分類，難以在日誌中追蹤。
臨時緩解措施
在 Google 完成修復前，建議將 API 金鑰刪除視為需要 30 分鐘才完成的操作：
- 刪除後繼續監控「Enabled APIs and services」的 Traffic by Credential 圖表
- 若金鑰可能已洩漏，立即撤銷所有 API 服務的對應權限（而不只是刪除金鑰）
- 對敏感服務考慮改用 Service Account 憑證（撤銷更快速）
原始來源：Aikido Security Blog