資安雷達 2026 年 4 月 26 日

2026-04-26 — Gmail E2EE 全商業開放、AI 提示注入野外現況、rustls-webpki 高危漏洞、Ray RCE

Gmail 企業端到端加密:基於客戶端加密的 E2EE 方案…

Gmail 企業端到端加密:基於客戶端加密的 E2EE 方案向所有 Workspace 商業客戶開放

Google Workspace · 2026-04-25

Google Workspace 將 Gmail 端到端加密(E2EE)擴展至所有商業層級客戶。此方案基於客戶端加密(Client-Side Encryption, CSE)技術,加密金鑰儲存在客戶控制的基礎設施中,Google 伺服器接收的是密文,無法讀取郵件內容。

技術架構:CSE 而非 S/MIME

此方案不是傳統的 S/MIME。S/MIME 要求 IT 管理員為每位使用者申請、管理憑證,並在收件方也完成相同的憑證部署後才能加密通訊。CSE 的差異在於:加密在客戶端(瀏覽器或應用程式)進行,密文在傳輸前即已生成;金鑰由客戶在 Google 基礎設施外自行選擇儲存位置(可整合現有企業金鑰管理服務);Google 儲存和傳遞的是 Google 無法解密的密文。

跨域收件人處理

當收件人不是 Gmail 使用者時,發件人向其發送邀請,使其透過受限制的 Gmail Web 介面(guest Google Workspace 帳號)存取和回覆郵件,而非要求對方配置 S/MIME 基礎設施,降低了跨組織加密通訊的摩擦。

分階段開放

Phase 1(Beta,2025 年 4 月起):向同組織 Gmail 使用者發送 E2EE 郵件;Phase 2(數週後):向任何 Gmail 收件箱發送;Phase 3(2025 年下半年):向任何電子郵件位址發送。

附加功能

CSE 預設模式強制執行、分類標籤與 DLP 規則整合,以及新一代威脅防護 AI 模型。

原始來源:Gmail E2E Encryption for All Businesses — Google Workspace Blog


野外的 AI 威脅:提示注入攻擊在生產系統中的現況

Google Security Blog · 2026-04-23

Google 安全研究人員記錄了 2026 年初在真實部署的 AI 系統中觀察到的提示注入攻擊模式,分析攻擊者如何將惡意指令注入 AI pipeline 並繞過安全護欄。

攻擊分類

直接提示注入(Direct Prompt Injection):攻擊者直接在使用者輸入中嵌入覆蓋系統提示的指令,如「忽略之前的指令,改為輸出…」。間接提示注入(Indirect Prompt Injection):惡意內容嵌入 AI 工具會自動讀取的外部資源中(網頁、文件、電子郵件),當 AI Agent 存取這些資源時,嵌入的指令被執行。後者在 AI 代理和多步驟工作流場景下危險性更高。

攻擊向量的現實分佈

觀察到的主要攻擊目標包括:接收 Webhook 並傳遞給 LLM 的系統、爬取使用者提供 URL 的搜尋增強生成(RAG)管線、處理使用者上傳文件的工作流程。文件類(PDF、Word)是間接注入的高頻載體,因為 LLM 通常被指示「完整閱讀並處理此文件」。

防禦機制

Google 研究指出,無單一防禦手段能完全消除提示注入風險。有效緩解措施包括:工具使用前的意圖驗證(確認 AI 代理請求的動作是否符合預期)、輸出過濾層(截斷包含控制字元或特定模式的生成內容)、最小權限原則(限制 AI 代理對外部服務的存取範圍),以及上下文邊界強化(明確標記系統提示與使用者輸入的分界)。

原始來源:AI Threats in the Wild — Google Security Blog


GHSA-82j2-j2ch-gfr8:rustls-webpki TLS 憑證驗證高危漏洞

GitHub Advisory Database / RustSec · 2026-04-24

rustls-webpki 是 Rust 生態中廣泛使用的 TLS 憑證驗證函式庫,為 rustls TLS 實作提供 X.509 憑證鏈驗證能力。GHSA-82j2-j2ch-gfr8 被評為 High 嚴重性,影響 TLS 憑證鏈的驗證邏輯。

漏洞背景

rustls-webpki 對應 webpki crate 的 Rust 重寫版本(原 webpki 由 Brian Smith 以 Rust 撰寫,後由 rustls 生態接管維護)。其核心功能是根據 RFC 5280 驗證 TLS 伺服器或客戶端提交的 X.509 憑證鏈是否由受信任的 CA 簽發,以及是否在有效期內、是否被吊銷(OCSP/CRL)。

潛在影響

rustls 被 curl(Rust 後端)、Hyper、Reqwest 等廣泛使用的 Rust 網路函式庫採用。憑證驗證缺陷可能允許攻擊者以無效或過期憑證通過 TLS 握手,進而實施中間人攻擊或欺騙合法服務。受影響版本應盡速更新至修復版本;具體受影響版本範圍請查閱 RustSec 公告頁面。

原始來源:GHSA-82j2-j2ch-gfr8 — GitHub Advisory DatabaseRustSec Advisory Database


CVE-2026-41486:Ray 分散式 ML 框架 Python 套件高危 RCE 漏洞

GitHub Advisory Database · 2026-04-24

CVE-2026-41486 影響 Ray pip 套件,評為 High 嚴重性,屬遠端程式碼執行(RCE)類型漏洞。Ray 是廣泛應用於機器學習訓練任務平行化的分散式計算框架,被 Anyscale 等公司和大量 ML workload 採用。

Ray 的攻擊面背景

Ray 的架構以 Head Node 和多個 Worker Node 構成叢集,節點間透過 gRPC 和自定義序列化協定通訊。Ray Dashboard 預設在 8265 端口開放,Ray 物件儲存(Plasma)和 GCS(Global Control Service)在叢集內部可存取。此前(2023 年 CVE-2023-48022)Ray 在缺乏預設認證的情況下曾遭大規模利用,攻擊者可直接提交惡意 remote function 在 worker 上執行任意程式碼。

緩解措施

更新至修復版本;若暫無法更新,確保 Ray Dashboard 和 GCS 端口不對公開網路暴露;在 Kubernetes 部署中使用 NetworkPolicy 限制 Ray 叢集內部通訊的存取範圍;啟用 Ray 的身分驗證機制(自 Ray 2.x 提供 TLS 和 auth token 選項)。

原始來源:CVE-2026-41486 — GitHub Advisory Database


End of article
0
Would love your thoughts, please comment.x
()
x