CVE-2025-32379

What it actually does

This is a cross-site scripting issue in Koa applications that pass user-controlled values into ctx.redirect(). In affected Koa versions before 2.16.1 and before 3.0.0-alpha.5, redirect handling can allow dangerous URL schemes such as javascript: to survive application-side sanitization and be emitted in a redirect response. If a victim follows an attacker-crafted link or is otherwise sent through a vulnerable redirect route, script can execute in the victim’s browser in the security context of the affected application. The impact is client-side code execution, not server-side code execution.

Why it matters to the business

Successful exploitation can lead to account takeover, session theft, unauthorized actions performed as the victim, phishing inside a trusted application, or exposure of sensitive data visible to the user. The CVSS score is moderate and current EPSS is low, and it is not listed in CISA KEV or associated with ransomware activity, so widespread exploitation pressure appears limited; however, internet-facing login flows, SSO callback flows, invite links, and redirect endpoints can materially increase risk because exploitation requires only a crafted URL and victim interaction.

How an attack unfolds

An attacker first identifies an application route that accepts a user-controlled destination, return URL, next URL, callback URL, or similar parameter and passes it to Koa’s ctx.redirect(). The attacker crafts a URL containing a JavaScript URL scheme or an encoded variant intended to bypass application validation. When the vulnerable application processes the request, it emits a redirect that causes the victim’s browser to execute attacker-controlled JavaScript rather than navigate to a safe destination. The attacker then delivers the crafted link through phishing, chat, email, comments, support tickets, or another user-facing channel. If a victim opens the link while authenticated to the affected application, the attacker’s script may read accessible page data, perform actions using the victim’s session, redirect the user to a phishing page, or attempt to exfiltrate tokens or other sensitive browser-accessible information.

How to fix it

Upgrade Koa to a fixed release: use Koa 2.16.1 or later for the 2.x branch, or 3.0.0-alpha.5 or later for the 3.x alpha branch. For source-based deployments, ensure the Koa dependency includes the upstream fix at commit 16b6e08059b46c5b2d08debcc3cb26a90eca8ed0 or a later trusted version. Rebuild and redeploy applications after dependency updates, including containers and serverless bundles that vendor node_modules. Where Red Hat Enterprise Linux package advisories are applicable, update affected xmlrpc-c packages to 0:1.51.0-5.el8_5.1 or later as listed by the vendor. As a defense-in-depth measure, do not pass raw user input to ctx.redirect(); implement a strict allowlist of relative paths or approved destination origins, reject javascript:, data:, vbscript:, file:, and other non-HTTP(S) schemes, normalize and decode input before validation, and prefer server-side mapping of redirect targets over arbitrary user-supplied URLs. Add a Content Security Policy to reduce the impact of XSS, but do not treat CSP as a substitute for patching and validation.

How to confirm the fix worked

Confirm dependency versions using package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, software composition analysis, or runtime package inventory; Koa should resolve to 2.16.1 or later, or 3.0.0-alpha.5 or later. For source builds, verify the deployed Koa code contains the fix from commit 16b6e08059b46c5b2d08debcc3cb26a90eca8ed0 or a later upstream revision. Identify routes that call ctx.redirect() and verify they do not accept arbitrary user-controlled destinations. Test redirect endpoints with benign payloads such as javascript:alert(1), mixed-case variants, URL-encoded variants, and leading whitespace or control-character variants; a fixed and correctly validated application should reject them or redirect only to an approved safe path or origin. Inspect HTTP responses and browser behavior to ensure no Location header is emitted with a dangerous scheme. For Red Hat package exposure, validate installed package versions with the system package manager and confirm xmlrpc-c packages are at 0:1.51.0-5.el8_5.1 or later where applicable.

Typical attack path

1. Find a Koa-based application endpoint that redirects users based on a request parameter or user-controlled input.
2. Test whether values such as javascript: URLs, encoded javascript: schemes, mixed-case schemes, or whitespace-obfuscated schemes are accepted by the redirect flow.
3. Craft a malicious link that routes through the vulnerable application and triggers ctx.redirect() with attacker-controlled script content.
4. Deliver the link to a targeted user through phishing, messaging, embedded content, or another social-engineering channel.
5. When the victim opens the link, the browser follows the unsafe redirect and executes attacker-controlled JavaScript in the application’s origin context.
6. Use the executed script to steal browser-accessible data, perform actions as the victim, alter page content, or redirect the victim to a credential-harvesting site.

How to detect it

To determine whether this was already exploited, review HTTP access logs from web servers, reverse proxies, load balancers, CDNs, WAFs, and application logs for requests to redirect-like endpoints containing javascript:, encoded JavaScript schemes, script tags, event handlers, or outbound exfiltration URLs. Focus on parameters commonly used for redirects such as redirect, return, returnUrl, next, continue, callback, url, target, destination, and goto. Inspect response logs or sampled traffic for 3xx responses whose Location header begins with javascript: or an obfuscated equivalent. Correlate suspicious requests with user-agent, referrer, source IP, authenticated user session, and follow-on activity such as unusual account changes, new API tokens, password changes, MFA changes, or suspicious outbound browser requests. If browser telemetry, CSP violation reports, EDR browser events, or RUM telemetry are available, look for script execution, blocked inline scripts, or connections to unfamiliar external domains immediately after visits to redirect endpoints. Because this is client-side exploitation, server compromise artifacts are not expected solely from this vulnerability; evidence is more likely in web request logs, WAF alerts, CSP reports, and user-account activity logs.

• Location: javascript:
• Location: JavaScript:
• Location: JAVASCRIPT:
• javascript:alert(
• javascript:confirm(
• javascript:prompt(
• javascript:fetch(
• javascript:eval(
• javascript:document.cookie
• javascript:localStorage
• javascript:sessionStorage
• java%73cript:
• javas%63ript:
• %6a%61%76%61%73%63%72%69%70%74%3a
• %0Ajavascript:
• %0Djavascript:
• %09javascript:
• redirect=javascript:
• returnUrl=javascript:
• return=javascript:
• next=javascript:
• continue=javascript:
• callback=javascript:
• url=javascript:
• target=javascript:
• destination=javascript:
• goto=javascript:
• <script>
• %3Cscript%3E
• onerror=
• onload=
• document.cookie
• localStorage.getItem
• sessionStorage.getItem

What your security team should do

• Inventory applications using Koa and prioritize internet-facing applications, authentication flows, callback handlers, and any endpoints with returnUrl, redirect, next, continue, callback, url, or destination parameters.
• Upgrade Koa to 2.16.1 or later, or 3.0.0-alpha.5 or later, and redeploy all affected application artifacts.
• Review all ctx.redirect() usage and replace arbitrary user-controlled redirects with allowlisted relative paths or server-side destination identifiers.
• Add automated tests for unsafe redirect payloads, including encoded and mixed-case javascript: scheme variants.
• Search recent web access logs, reverse proxy logs, WAF logs, CDN logs, and application logs for suspicious redirect parameters and XSS payloads.
• Tune WAF/SIEM detections for redirect parameters containing dangerous schemes, encoded JavaScript schemes, or script exfiltration patterns.
• Ensure cookies use HttpOnly, Secure, and SameSite attributes where possible to reduce the impact of browser-side script execution.
• Deploy or strengthen Content Security Policy to limit inline script execution and outbound exfiltration destinations.
• Patch applicable Red Hat packages to vendor-fixed versions if those packages are present and in scope for the advisory.
• Treat confirmed exploitation as a potential user-session compromise and rotate affected sessions or tokens where browser-accessible credentials may have been exposed.