上傳一張圖就能偷走金鑰：Rails Active Storage 爆出 9.5 分嚴重漏洞
Rails GitHub Security Advisory GHSA-xr9x-r78c-5hrm · 2026-07-29
Ruby on Rails 團隊於 2026 年 7 月 29 日發布安全公告，揭露 Active Storage 圖片變體處理流程中的 CVE-2026-66066，CVSS v4 評分達 9.5 分（Critical）。攻擊者只需上傳一張精心構造的圖片並觸發變體產生，就能在未授權情況下讀取伺服器任意檔案，甚至可能達成遠端程式碼執行。這起漏洞最早在 oss-security 郵件列表擴散討論。
漏洞機制
Active Storage 透過 libvips 處理圖片變體時，libvips 內部有一批標記為「unfuzzed」、僅適用於受信任內容的檔案格式操作，理應在處理外部上傳內容時停用。Active Storage 卻沒有停用這些不安全的載入器，只要應用程式設定 config.active_storage.variant_processor = :vips 並接受使用者上傳圖片，觸發變體產生本身不需要其他前置條件。攻擊者藉此讀取的檔案範圍涵蓋 Rails 處理程序的環境變數，其中可能包含 secret_key_base、Rails master key、資料庫密碼與雲端儲存服務的存取金鑰。
受影響版本
activestorage < 7.2.3.2activestorage >= 8.0, < 8.0.5.1activestorage >= 8.1, < 8.1.3.1
此漏洞由 0xacb、s3np41k1r1t0、Ethiack 的 castilho，以及 GMO Flatt Security 的 RyotaK 各自獨立回報。
修補與緩解
官方已釋出 7.2.3.2、8.0.5.1、8.1.3.1 三個修補版本，建議同時將 libvips 升級到 8.13 以上。若暫時無法升級，可設定環境變數 VIPS_BLOCK_UNTRUSTED，或在 ruby-vips 2.2.1 以上版本的初始化程式中呼叫 Vips.block_untrusted(true)；若專案只用 ruby-vips 做檔案分析，也可以直接移除該依賴。官方公告特別提醒，升級後仍應輪替 secret_key_base、master key 與所有資料庫及第三方服務憑證，因為若攻擊者已在修補前得手，僅升級版本並不會讓外洩的金鑰失效。
原始來源：Rails GitHub Security Advisory GHSA-xr9x-r78c-5hrm、oss-security 郵件列表討論
一個判斷寫反：macOS 螢幕分享的 SRP 驗證形同虛設
warez.sl0p.foo 技術寫作 · 2026-08-01
獨立研究團隊在 2026 年 8 月 1 日公開一份針對 macOS screensharingd 的預先驗證遠端程式碼執行寫作，指出蘋果螢幕分享服務所用的 SRP（Secure Remote Password）驗證流程存在判斷錯誤。攻擊者只需知道目標主機的 IP，不需任何帳密，就能繞過整套金鑰交換與加密協商，直接讀寫受害機器上的任意檔案。蘋果已在 2026 年 7 月 27 日發布的 macOS 26.6（Tahoe）中修補此問題。
漏洞機制
screensharingd 在解析 SRP 封包長度欄位時，使用大端序 32 位元數值表示長度。當長度欄位第 15 位以上任一位元被設為 1（即長度 ≥ 32768）時，原本應回傳錯誤碼的例外路徑卻回傳了殘留的成功狀態碼 0。呼叫端把這個 0 解讀成「驗證已完成」，於是略過金鑰產生、session proof 驗證，以及 ChaCha20-Poly1305 加密協商與安裝，直接進入後驗證的訊息處理迴圈，整條連線完全沒有加密與身分確認。研究團隊同時指出第二個弱點：伺服器未拒絕 A ≡ 0 (mod N) 的公鑰值，違反 RFC 5054 的規範要求。
受影響版本
所有實作 security type 36（即螢幕分享所用驗證機制）的 macOS 26.5 及更早版本皆受影響。同一時期另一位研究者 fG! 在部落格 reverse.put.as 也證實了同一顆漏洞的存在，但刻意不公開技術細節。
修補與緩解
蘋果在 macOS Tahoe 26.6 安全公告中修補了此問題，截至目前尚未見獨立 CVE 編號被公開索引。研究團隊釋出的 exploit.py 展示了檔案讀取、檔案寫入，以及透過寫入 crontab 觸發、排程執行時自動連回互動式 PTY shell 的完整攻擊鏈。唯一有效的緩解方式是儘速升級到 26.6，因為漏洞出在驗證流程本身，升級前僅能靠關閉螢幕分享服務或以防火牆封鎖來臨時止血。
原始來源：Apple Screen Sharing Pre-Auth RCE 技術寫作、macOS Tahoe 26.6 安全公告
掃遍 7.6PB HuggingFace 訓練資料：22 萬組活跳跳憑證藏在公開資料集裡
Truffle Security 部落格 · 2026-08-02
Truffle Security 團隊完整複製了 HuggingFace 資料集 Hub 上所有公開儲存庫、分支與大檔案物件，動用自家工具 TruffleHog 開啟驗證模式全面掃描。這是該團隊有史以來規模最大的一次掃描，資料量達到 7.6PB，是先前最大規模掃描（400TB）的約 19 倍。
背景
掃描前團隊先把 Parquet、Arrow、JSONL、壓縮檔與各種二進位格式攤平成可被文字掃描工具解析的內容，再逐一比對已知的憑證格式並向對應服務商發出驗證請求，確認金鑰是否仍然有效。過程中只做中繼資料層級的驗證，不讀取或修改任何實際資料。
核心發現
團隊總共處理了約 1.869 億個獨立檔案，涵蓋約 81.5 萬個資料集儲存庫（其中 67 萬個順利掃描完畢），最終找到 221,303 組活躍且獨一無二、通過驗證的憑證，分散在 6,003 個資料集當中。其中包含：
- 349 組有效 GitHub 個人存取權杖（223 組具完整 repo 寫入權限、130 組可竄改 CI workflow、112 組具 admin:org 權限）
- 318 組可推送映像檔的 Docker Hub 權杖
- 237 組具寫入權限的 HuggingFace 權杖
- 11,496 組 AI 服務商金鑰（OpenAI、Anthropic、Gemini、Groq、Azure OpenAI）
- 8,557 組橫跨 3,811 個專案的 GCP 服務帳號金鑰
- 8,594 組驗證有效的資料庫憑證，合計可存取 3.5TB 資料
- 5,885 組 Slack 與 Mailgun 權杖
影響範圍
其中一組外洩憑證直接暴露了 393GB 的個資，規模相當於全球人口約 3.7% 的資料量；另外還發現 51.7TB 存放在非公開 AWS S3 儲存桶中的資料，以及單一資料庫外洩量達 617.7GB 的極端案例。44% 的獨立憑證重複出現在多個資料集裡，最誇張的一組同一憑證出現在 1,131 個不同資料集中。團隊估算，光是被盜用的 AI 推論額度，保守估計就可能造成每年 92 萬美元的損失。
原始來源：Truffle Security：Scanning 7.6 Petabytes of HuggingFace Training Data for Secrets