CVE-2025-8129

What it actually does

CVE-2025-8129 is an open redirect issue in KoaJS Koa up to 3.0.0 in the HTTP response header handling logic in lib/response.js. Code paths that redirect a user "back" can derive the redirect destination from the inbound Referrer/Referer header without sufficiently constraining it to trusted local destinations. An attacker who can influence that header, or lure a user through a crafted flow, can cause an affected application to return a 3xx response with a Location header pointing to an attacker-controlled external URL. This does not provide remote code execution or direct data access, but it can undermine trust in legitimate application URLs and assist phishing, credential theft, malware delivery, OAuth/login-flow abuse, or user redirection to fraudulent content.

Why it matters to the business

The primary business risk is user trust abuse: attackers can use a legitimate application domain as a stepping stone to redirect users to malicious sites. This can increase the success rate of phishing and fraud campaigns, especially where users are trained to trust the organization’s domain. The CVSS score is low and EPSS is currently low at 0.00228, it is not listed in CISA KEV, and it is not known to be used in ransomware campaigns; however, public disclosure means the behavior is easy to test and may be opportunistically abused in internet-facing applications that use Koa redirect-back behavior. Organizations with many Node.js/Koa services or downstream dependencies should still treat remediation as a hygiene and phishing-risk reduction priority.

How an attack unfolds

An attacker identifies an application built with an affected Koa version that uses the vulnerable redirect-back functionality, such as a route that sends users back to their previous page after login, logout, form submission, authorization failure, or error handling. The attacker then crafts a request or phishing link that causes the victim’s browser to access the legitimate application while supplying or preserving a malicious external Referrer/Referer value. When the vulnerable server-side code executes, it trusts that header as the destination and responds with a redirect to the attacker-controlled site. The victim sees a trusted domain first, but is then silently or visibly redirected to a malicious page that may imitate a login portal, request sensitive information, deliver malware, or continue an OAuth/social-engineering flow. Named threat actor exploitation has not been provided, but the technique is commonly used by opportunistic phishing operators because it requires little technical complexity and leaves limited host-level artifacts.

How to fix it

Upgrade Koa to a version or source revision that includes the fix. For source-based Koa consumers, the listed fixed revision is koajs/koa commit 3b1688692471c70cf356ae526227e98982f56b09. If consuming vendor-packaged builds, apply the relevant fixed package versions: linux-lts Alpaquita stream fixed in 6.6.58-r0 and 6.12.41-r0, linux-lts Alpaquita 23 fixed in 6.1.91-r0, and linux-lts Alpaquita 25 fixed in 6.12.41-r0. Where immediate upgrade is not possible, avoid using redirect-back behavior that trusts Referrer/Referer, replace it with a server-side allowlisted return path, and only permit relative URLs or explicitly approved same-origin destinations. Normalize and validate redirect targets before setting the Location header. Do not accept full external URLs in return, next, continue, redirect, or back parameters unless they are strictly allowlisted. Consider adding centralized middleware that blocks external redirects by default.

How to confirm the fix worked

Confirm exposure by inventorying Koa versions with package manifests and dependency tooling such as package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls koa, or software composition analysis. Identify whether application code calls redirect-back behavior, including patterns such as ctx.redirect('back'), response.redirect('back'), ctx.response.back, response.back, or wrappers that derive redirects from Referrer/Referer. Validate the fix dynamically in a non-production test by sending a request to a relevant redirecting route with an external Referer header such as Referer: https://attacker.example/ and confirming the response does not set Location to that external domain. A fixed or mitigated application should redirect only to a safe local path, a trusted same-origin URL, or a configured allowlisted destination. Also verify that dependency scans no longer report Koa up to 3.0.0 or unfixed vendor package versions.

Typical attack path

1. Find an internet-facing application or route using affected Koa redirect-back behavior.
2. Determine which route emits a redirect based on the Referrer/Referer header, commonly after login, logout, form submission, authorization checks, or error handling.
3. Craft a request, lure, or browser flow that causes the Referrer/Referer header to contain an attacker-controlled external URL.
4. Send the victim to the legitimate application URL so the application returns a 3xx response.
5. The affected application sets the Location response header to the attacker-controlled URL.
6. The victim’s browser follows the redirect to the malicious site.
7. The attacker uses the redirected landing page for phishing, credential capture, malware delivery, fraud, or further social engineering.

How to detect it

To determine whether this was already exploited, review HTTP access logs, reverse proxy logs, CDN/WAF logs, and application logs for redirects whose Location response header points to an external domain not owned or explicitly trusted by the application. Focus on 301, 302, 303, 307, and 308 responses from routes commonly used after login, logout, form submission, authorization failure, password reset, OAuth/SSO handoff, or error handling. Correlate those responses with inbound Referer or Referrer headers containing the same external host, URL shorteners, punycode domains, newly registered domains, credential-harvesting domains, or domains that resemble the organization’s brand. If response headers are not logged, enable temporary enhanced logging for redirect responses and compare requested routes, user agents, source IPs, and referrer values. Look for bursts of requests to redirecting routes from email clients, mobile browsers, or uncommon user agents followed by external navigation. Host forensics are usually not useful for this vulnerability because exploitation does not require code execution or file creation on the server; evidence is primarily in web, proxy, CDN, WAF, identity, and email-security telemetry. If phishing is suspected, correlate redirect events with reported emails, credential submission alerts, impossible-travel sign-ins, MFA fatigue events, and newly observed malicious domains.

• lib/response.js
• ctx.redirect('back')
• ctx.redirect("back")
• response.redirect('back')
• response.redirect("back")
• ctx.response.back
• response.back
• Referer: http://
• Referer: https://
• Referrer: http://
• Referrer: https://
• Location: http://
• Location: https://
• HTTP/1.1 301
• HTTP/1.1 302
• HTTP/1.1 303
• HTTP/1.1 307
• HTTP/1.1 308
• koa@3.0.0
• koajs/koa
• 3b1688692471c70cf356ae526227e98982f56b09

What your security team should do

• Inventory all applications and services using Koa, prioritizing internet-facing services and authentication-adjacent routes.
• Upgrade affected Koa deployments to a fixed release or to a build containing commit 3b1688692471c70cf356ae526227e98982f56b09; apply listed vendor package fixes where applicable.
• Search code for redirect-back patterns such as ctx.redirect('back'), response.redirect('back'), response.back, and logic that trusts Referrer or Referer for redirect destinations.
• Add tests or middleware that reject external redirect destinations unless they are explicitly allowlisted.
• Review web access logs for historical 3xx responses where the Location header points to an external domain, especially when the inbound Referer header also contains that domain.
• Prioritize remediation for login, logout, account recovery, SSO, OAuth, checkout, payment, and support workflows because phishing impact is higher in those paths.
• Add SIEM detections for unusual 3xx redirect activity from trusted application domains to newly observed or suspicious external domains.
• Because KEV and ransomware indicators are not present and EPSS is low, handle as a prioritized application-security fix rather than an emergency infrastructure incident unless evidence of abuse is found.