CVE-2026-66832

This CVE exposes session tokens passed through WebView URL query parameters during third-party redirect flows—a pattern that looks like developer negligence but is better understood as a structural platform failure. When a developer needs to maintain authentication across a WebView handoff to an external service, appending the token to the URL is the path of least resistance: it works, it persists across the web request, and it requires no deep knowledge of Android's WebView API nuances. The secure alternatives—CookieManager with HttpOnly flags, WebView.loadDataWithBaseURL() with controlled cookie scope, or migrating to Chrome Custom Tabs—require more code, more platform-specific knowledge, and sacrifice the debuggability that URL parameters provide. The blast radius extends beyond the immediate session hijack risk. The persistent user identifier present in WebView User-Agent headers compounds the token exposure into potential cross-site correlation. Any intermediary in the redirect chain—ad networks, analytics providers, affiliate systems—logging referrer URLs now holds a session-equivalent identifier paired with a persistent user fingerprint. This transforms a single token leak into a broader identity exposure across third-party infrastructure the developer doesn't control. Google has effectively acknowledged WebView's security limitations by directing developers toward Custom Tabs for redirect flows, yet the platform has not provided a first-class secure session-handoff API for WebViews themselves. The recommended secure alternatives depend on APIs that have shown instability across Android version churn, leaving developers who invest in proper implementations with code that may subtly break on future updates without clear migration paths. For defenders: prioritize migrating affected WebView redirect flows to Chrome Custom Tabs, which provide a more secure container with proper referrer handling. If migration isn't feasible immediately, implement token invalidation and rotation on the backend to limit the exposure window. Audit the redirect chain for third-party intermediaries that may be logging referrer URLs—the vulnerability's impact is bounded by who receives the leaked URL. Document this as a class of issue in your secure coding standards, not a one-off fix.

Reviewed through automated stages and approved by a human before publication.