CVE-2026-27959

What it actually does

Koa versions before 3.1.2 and 2.16.4 improperly parse the HTTP Host header in the ctx.hostname API. Instead of strictly validating the Host value against RFC 3986 hostname syntax, Koa naively derives a hostname from malformed input containing an @ character, allowing an attacker to influence the hostname value returned to application code. If an application uses ctx.hostname to construct absolute URLs, password reset links, email verification links, redirects, canonical links, tenant routing, or security decisions, the attacker can cause the application to generate attacker-controlled links or make incorrect routing decisions. The impact is primarily integrity compromise; the flaw does not directly provide code execution, data disclosure, or denial of service by itself.

Why it matters to the business

Applications built on affected Koa versions may send users links that appear to come from the legitimate service but actually point to an attacker-controlled domain. This can enable account takeover through poisoned password reset or email verification links, phishing, brand abuse, and incorrect application routing. The risk is highest for internet-facing applications that generate links from incoming request hostnames, especially authentication, onboarding, invitation, and account recovery workflows. Although this issue is not listed in CISA KEV, has no known ransomware association, and currently has low EPSS probability, it has a high integrity impact and is straightforward to trigger remotely without authentication.

How an attack unfolds

An attacker sends a crafted HTTP request to a Koa-based application using a malformed Host header that includes an @ character and an attacker-controlled domain. In vulnerable Koa versions, ctx.hostname may resolve to the attacker-controlled portion rather than rejecting the malformed host. If the application uses ctx.hostname when building absolute URLs, the attacker can trigger the application to create links using the malicious hostname. In a common password-reset scenario, the attacker submits a victim email address while controlling the Host header; the application sends the victim a password reset email containing a link whose domain is controlled by the attacker. If the victim clicks the link, the reset token or verification token may be sent to the attacker-controlled site, enabling token theft and potential account takeover. Similar abuse is possible for email verification, invitation links, callback URLs, generated redirects, and host-based routing logic.

How to fix it

Upgrade Koa to a fixed version: Koa 3.x users should upgrade to 3.1.2 or later, and Koa 2.x users should upgrade to 2.16.4 or later. If consuming directly from source, ensure the fix commit c5a52e056d61afa012a08d3aa89a59bce5ccbf1b or a later commit is present. After upgrading, rebuild and redeploy all applications and containers that bundle the vulnerable dependency. As a defense-in-depth measure, avoid deriving security-sensitive absolute URLs from user-controlled Host headers. Configure a canonical public base URL through trusted configuration, enforce an allowlist of valid hostnames at the reverse proxy or application layer, reject Host and X-Forwarded-Host values containing userinfo-style syntax such as @, and only trust forwarded host headers from known proxies. Review password reset, email verification, invitation, redirect, OAuth callback, and tenant routing code for use of ctx.hostname.

How to confirm the fix worked

Confirm dependency versions with package manager and software composition tooling, such as npm ls koa, yarn why koa, pnpm why koa, lockfile inspection, container image SBOMs, and deployed artifact manifests. Verify that all deployed applications use Koa 3.1.2 or later, Koa 2.16.4 or later, or include commit c5a52e056d61afa012a08d3aa89a59bce5ccbf1b. Perform an application test against non-production or authorized environments by sending malformed Host headers containing @ and confirming the request is rejected, normalized safely, or does not influence generated URLs. Exercise password reset, verification, invitation, and redirect flows and confirm generated links always use the configured canonical domain, not the incoming Host header. Check reverse proxy configuration to ensure invalid Host headers are blocked before reaching the application and that forwarded host headers are only accepted from trusted infrastructure.

Typical attack path

1. Identify an internet-facing Node.js application using Koa versions prior to 3.1.2 or 2.16.4.
2. Find functionality that generates absolute URLs or makes routing/security decisions using ctx.hostname, such as password reset, email verification, account invitation, or redirect flows.
3. Send a request with a malformed Host header containing an @ character and an attacker-controlled hostname.
4. Cause the vulnerable application to derive the attacker-controlled hostname from ctx.hostname.
5. Trigger generation of an email, redirect, link, or route based on the poisoned hostname.
6. Capture tokens, direct users to a phishing site, or influence application behavior using the attacker-controlled URL.

How to detect it

Look for evidence of malformed host header probing and abuse in web server, reverse proxy, CDN, WAF, API gateway, and application logs. Prioritize endpoints that generate emails or absolute links, such as password reset, email verification, registration, invitations, account recovery, login, logout, OAuth, SSO, and redirect endpoints. Search raw request headers for Host or X-Forwarded-Host values containing @, percent-encoded @ (%40), unexpected external domains, or userinfo-like syntax. Correlate suspicious requests with outbound email logs to determine whether reset, verification, or invitation emails were generated immediately afterward. Review email templates and delivery logs for links whose domains do not match approved application domains. Inspect application telemetry for redirects, canonical URL generation, or tenant resolution using unrecognized hostnames. If tokens may have been exposed, review account activity following those emails for password changes, logins from unusual IP addresses, session creation, MFA changes, email changes, or other account recovery events. Because exploitation can leave limited server-side artifacts if raw headers are not logged, absence of evidence in normalized logs is not proof of no exploitation.

• Host: .*@
• X-Forwarded-Host: .*@
• Forwarded: .*host=.*@
• %40
• @evil.com
• ctx.hostname
• password reset link domain mismatch
• email verification link domain mismatch
• invitation link domain mismatch
• unexpected Host header
• malformed Host header
• invalid host header
• userinfo in Host header

What your security team should do

• Inventory all Node.js services using Koa and prioritize internet-facing authentication, account recovery, onboarding, and multi-tenant routing applications.
• Upgrade affected services to Koa 3.1.2 or later, or 2.16.4 or later, and redeploy all images and serverless bundles that include the vulnerable dependency.
• Search application code for ctx.hostname usage and replace security-sensitive URL generation with a trusted configured base URL.
• Add host allowlisting and malformed Host header rejection at the edge proxy, load balancer, API gateway, or application middleware.
• Review recent password reset, verification, and invitation activity for links generated with unexpected domains.
• Add SIEM detections for Host and X-Forwarded-Host headers containing @, especially on authentication and account recovery endpoints.
• Ensure access logs capture raw Host and X-Forwarded-Host values where legally and operationally appropriate.
• Treat any confirmed token leakage through attacker-controlled reset or verification links as a credential compromise event and rotate affected tokens or sessions.