Summary

Reflected XSS in the local OAuth callback server. The handler in packages/ai/src/utils/oauth/callback-server.ts reflects the error and error_description query params into a <script id="server-state" type="application/json"> block in oauth.html via JSON.stringify(resultState). JSON.stringify does not escape </, so a </script> sequence in either field closes the embedding block and lets attacker HTML/JS execute on the http://localhost:<oauth-port> origin.

Impact

The OAuth callback port is known per provider:

• Anthropic: 54545
• OpenAI Codex: 1455
• GitLab Duo: 8080

(Other providers can fall back to a random port, but the well-known ports above account for the bulk of real OAuth logins.)

During the ~5-minute OAuth login window (DEFAULT_TIMEOUT in callback-server.ts), a page open in another browser tab can navigate the victim to a URL such as:

http://localhost:54545/callback?error=x&error_description=%3C%2Fscript%3E%3Cimg+src%3Dx+onerror%3Dalert(1)%3E

The server responds with the rendered oauth.html template. The injected </script> closes the JSON block, the following HTML is parsed, and the attacker JS runs in the http://localhost:54545 origin. The login attempt is rejected on the server side at the same time (DoS of the in-progress OAuth flow), and the user sees an attacker-controlled error page in their browser.

The blast radius is bounded by the loopback-only localhost bind and the short OAuth window, but the bug is real: a </script> in error_description is enough to inject HTML, and the user has no way to tell the spoofed page from the legitimate "Authentication Failed" page.

Location

packages/ai/src/utils/oauth/callback-server.ts (the response builder in #handleCallback) substituting into:

packages/ai/src/utils/oauth/oauth.html:167-169

<script id="server-state" type="application/json">
    __OAUTH_STATE__
</script>

Fix

Escape < to its JSON unicode form (<) before substitution, and use the function form of replaceAll so any attacker-controlled $& / `$`` patterns in the JSON string cannot influence the substitution semantics:

const stateJson = JSON.stringify(resultState).replace(/</g, "\\u003c");
return new Response(
    (templateHtml as unknown as string).replaceAll("__OAUTH_STATE__", () => stateJson),
    ...
);

< is a valid JSON escape, so JSON.parse(document.getElementById("server-state").textContent) in oauth.html continues to round-trip the original error string to the client without modification.

No behavior change for the success path or for non-malicious error strings — only the < byte is rewritten on the way into the script block.

Detected by

Aeon + manual review.

• Severity: medium
• CWE-79 (Improper Neutralization of Input During Web Page Generation)

The triage axis was "reflected query param into HTML script block via stringify-only encoding" — the same shape that has bitten several other localhost helper servers in the past quarter.

Verification

• Added packages/ai/test/oauth-callback-html-escape.test.ts — two regression cases:
  1. </script> in error_description is unicode-escaped, the JSON parses, and parsed.error round-trips the original payload.
  2. </script> in the bare error param is unicode-escaped on the no-error_description path.
• Test drives the real OAuthCallbackFlow.login() flow against an ephemeral port, sends the malicious request via fetch(), and asserts on the rendered HTML body.
• Manually verified the escape against a faithful replica of the substitution pipeline (Node script, all four cases pass: malicious error_description, malicious bare error, success-path round-trip, plain-text round-trip).

Bun was not available in the scanner sandbox; the regression test runs under bun test from packages/ai locally.

Filed by Aeon.