一項新發表的安全研究報告揭露，Android作業系統中一項長期存在的漏洞可使一般應用程式繞過使用者啟用的VPN鎖定機制，將真實IP位址等敏感資訊洩漏至外部網路。這項漏洞影響絕大多數執行Android 12以上版本的裝置，估計涵蓋全球約九成以上的Android衍生裝置出貨量。
漏洞運作機制
Android的「Always-on VPN」與「封鎖未經VPN的連線（Block connections without VPN）」設定，旨在確保受保護應用程式的網路流量不會透過非VPN路徑外洩。然而，研究人員發現，一般應用程式可透過Android公開的IpSecManager.UdpEncapsulationSocket API，要求ConnectivityManager建立NAT-T keepalive連線。該請求會進入名為startNattKeepaliveWithFd的Binder方法，將重複的檔案描述符與資源ID傳遞至框架，但框架並未驗證呼叫者是否擁有對應的IpSec資源，亦未檢查呼叫者UID的有效VPN鎖定政策，便將keepalive封包交由Wi-Fi硬體卸載路徑發送。
一旦進入Wi-Fi卸載路徑，UDP/4500封包的發送將繞過一般應用程式socket寫入路徑中原本由VPN鎖定機制控管的環節。攻擊者可控制目的地IP位址，接收端則可觀察到裝置的真實實體網路來源IP與發包時序，而封包格式則由平台固定為NAT-T keepalive格式，無法承載任意應用程式內容。
實測驗證結果
研究團隊在Pixel 8 Pro（執行Android 16）上透過獨立的OpenWrt路由器進行封包擷取，證實在VPN鎖定啟用狀態下，受保護的一般應用程式仍能以每10秒一次的頻率，從實體Wi-Fi介面發送UDP/4500封包至外部測試端點。Samsung SM-F966B（搭載Qualcomm晶片）則獨立驗證了同一公共路徑，在長達24小時32分鐘的持續租約期間內維持一個作用中的實體閘道Wi-Fi槽位。Nothing A059（執行Android 16）亦確認公共路徑准入與作用中回呼，但未進行獨立的封包擷取或持續時間量測。
此外，研究團隊亦在Pixel裝置上測試了完整生命週期行為，包括背景執行、螢幕鎖定、Doze模式、電池省電模式、限制待機桶、Binder凍結器等情境，證實keepalive在這些狀態下仍持續運作，直到手動強制停止、解除安裝、網路斷線或重新開機等邊界事件發生才會中止。
根本原因分析
漏洞的根源在於Android框架中一個被稱為「信任模型崩塌（Collapsed Trust Model）」的設計缺陷。原始的fd-based NAT-T keepalive API屬於特權API，但在2019年的API審查過程中，公共的UdpEncapsulationSocket keepalive功能被引入至同一Binder方法，原本的無條件權限檢查隨之移除。為維持安全性，曾於2019年4月新增一套驗證機制，用以確認呼叫者是否擁有有效的IpSec封裝socket資源、驗證資源ID的有效性、拒絕重複使用，並在keepalive生命週期內鎖定資源。然而，該驗證機制在2019年5月因服務相依性與死結問題遭到還原，僅以每UID、每網路的配額限制取代。配額機制雖能限制資源耗用，卻無法驗證檔案描述符與資源的真實對應關係，也無法執行VPN政策。
研究人員批評，這項出於技術考量的還原決定本身並非失敗所在，但其在尚未完成替代安全控管的情況下，便將一般應用程式路徑釋出，屬於審查與發布治理的缺失。
裝置影響範圍
根據Android相容性定義文件，Android 10（2019年）起即要求支援Wi-Fi keepalive卸載的裝置提供至少三個並行keepalive槽位。經韌體與原始碼普查，七大Android WLAN晶片家族均提供keepalive或卸載封包支援介面，包括Qualcomm QCA/CLD3/FastConnect、Qualcomm WLAN/QDSP6 WCNSS、Broadcom/Cypress bcmdhd/DHD、MediaTek CONSYS/Connac、Unisoc/Spreadtrum SPRDWL、Samsung S.LSI/Exynos Wi-Fi，以及Huawei/HiSilicon Hi11xx。實測橫跨三個OEM與兩個確認的WLAN家族，估計覆蓋2021年第四季至2026年第一季期間91.24%的Android衍生裝置出貨量，其餘8.76%仍未釐清。
生態系調查
研究團隊針對F-Droid與IzzyOnDroid的4,679個獨立git來源進行靜態掃描，未發現任何Android框架IPsec、IKE或NAT-T API的使用案例，手動稽核則辨識出73款使用Android VpnService的應用程式。在Google Play的調查中，於26款現行上架的相關應用程式中取得9款APK，其中僅FortiClient VPN與SmartVPN兩款包含47處平台SDK呼叫點，累計Google Play安裝次數約413萬次，相對於Google公布的逾30億台活躍Android裝置，使用這些平台API的使用者比例估計僅約0.01%。
修補建議與回歸測試
研究團隊建議，修復方案應在startNattKeepaliveWithFd的准入階段分離特權fd呼叫者與公共UdpEncapsulationSocket呼叫者：前者需具備PACKET_KEEPALIVE_OFFLOAD權限並接受基本的fd格式驗證；後者則須證明擁有即時的呼叫者IpSec封裝socket資源、證明重複的fd與儲存的資源相符，且單一資源不得同時支援並行NAT-T記錄。此外，ConnectivityService應擷取呼叫者的完整UID，檢查目標網路與底層網路關係，並在使用者UID的VPN或鎖定政策禁止直接發送時，拒絕實體底層卸載。
研究團隊亦建議Android應考慮將面向一般應用程式的IPsec、IKE與NAT-T介面全面標記為棄用，並將相關框架功能限為系統特權使用；對於無法承受手機端VPN外洩風險的威脅模型，則建議採用外部路由器強制執行VPN的方案，使手機將路由器作為唯一的網際網路路徑，並在隧道失效時自動中斷連線。
通報與揭露時程
該發現於2026年5月15日通報Android漏洞獎勵計畫（VRP），Google當天完成分流並要求協調揭露。後續Google將其標記為與既有問題386376240重複，研究人員於2026年6月12日通知Google預計進行公開揭露，最終於2026年7月29日正式公開。該研究的作者為Arin Šupuk，同時也是商業應用程式VPN Leak Guard的開發者，該應用程式亦為部分實測觀察的來源。