CVE-2026-27959: Koa Host Header Injection Vulnerability

CVE-2026-27959 Overview

CVE-2026-27959 is a Host Header Injection vulnerability affecting Koa, a popular middleware framework for Node.js using ES2017 async functions. The vulnerability exists in Koa's ctx.hostname API, which performs naive parsing of the HTTP Host header by extracting everything before the first colon without validating that the input conforms to RFC 3986 hostname syntax.

When a malformed Host header containing a @ symbol is received, ctx.hostname returns an attacker-controlled value. This enables attackers to manipulate applications that rely on ctx.hostname for URL generation, password reset links, email verification URLs, or routing decisions.

Critical Impact

Applications using ctx.hostname for security-sensitive operations such as password reset links and email verification URLs are vulnerable to Host header injection attacks, potentially allowing attackers to hijack user accounts or redirect sensitive traffic.

Affected Products

• Koa versions prior to 3.1.2
• Koa versions prior to 2.16.4

Discovery Timeline

• 2026-02-26 - CVE CVE-2026-27959 published to NVD
• 2026-02-26 - Last updated in NVD database

Technical Details for CVE-2026-27959

Vulnerability Analysis

This Input Validation Error (CWE-20) stems from insufficient validation of the HTTP Host header in Koa's ctx.hostname implementation. The vulnerable code extracts the hostname portion by simply returning everything before the first colon delimiter, without accounting for the userinfo component that can appear in URLs according to the URI specification.

In RFC 7230, the Host header should not contain userinfo (the user@ portion typically seen in URLs). However, when an attacker sends a Host header like attacker@evil.com:443, the vulnerable parsing logic fails to detect this malformed input and incorrectly returns attacker@evil.com as the hostname. More critically, if the URL parser interprets this as a URL with userinfo, the actual host portion becomes evil.com, which is entirely attacker-controlled.

This vulnerability enables Host header poisoning attacks where an attacker can manipulate any application logic that depends on ctx.hostname for constructing URLs, validating origins, or making routing decisions.

Root Cause

The root cause is the absence of input validation against RFC 7230 requirements for Host headers. The original implementation naively splits the Host header on commas (for handling multiple values) and colons (for port separation) without checking for the presence of userinfo components indicated by the @ symbol. This parsing approach assumes all Host header values are well-formed, which allows malicious input to bypass hostname validation.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by sending HTTP requests with crafted Host headers containing the @ symbol. For example:

1. Attacker sends a request with Host: user@evil.com header
2. Application calls ctx.hostname expecting the legitimate hostname
3. Vulnerable parsing returns evil.com as the hostname
4. If the application uses this value for password reset links, the reset URL points to evil.com
5. Victim clicks the link, sending their reset token to the attacker's server

// Vulnerable code pattern in lib/request.js (before fix)
     if (!host) host = this.get('Host')
   }
   if (!host) return ''
   return splitCommaSeparatedValues(host, 1)[0]

The security patch addresses this by detecting the @ symbol and using the URL parser to correctly extract the host portion:

// Security patch in lib/request.js
     if (!host) host = this.get('Host')
   }
   if (!host) return ''
   host = splitCommaSeparatedValues(host, 1)[0]
   // Host header may contain userinfo (e.g., "user@host") which is invalid per RFC 7230.
   // Use URL parser to correctly extract the host portion.
   if (host.includes('@')) {
     try {
       host = new URL(`http://${host}`).host
     } catch (e) {
       return ''
     }
   }
   return host

Source: GitHub Commit Update

Detection Methods for CVE-2026-27959

Indicators of Compromise

• HTTP requests containing @ symbols in the Host header
• Unusual password reset or verification emails pointing to unexpected domains
• Web server logs showing Host header values that don't match expected application hostnames
• Outbound connections to unexpected domains from URL generation functions

Detection Strategies

• Implement web application firewall (WAF) rules to detect and block Host headers containing the @ symbol
• Monitor server access logs for requests with malformed Host headers that deviate from RFC 7230
• Deploy runtime application self-protection (RASP) to detect hostname manipulation attempts
• Use SentinelOne's application security capabilities to identify vulnerable Koa versions in your environment

Monitoring Recommendations

• Enable detailed HTTP header logging on web servers and reverse proxies
• Set up alerts for Host header values that don't match your application's configured domains
• Monitor for anomalous patterns in password reset or email verification link generation
• Track dependency versions across your Node.js applications to identify vulnerable Koa installations

How to Mitigate CVE-2026-27959

Immediate Actions Required

• Upgrade Koa to version 3.1.2 or 2.16.4 immediately
• Audit all code paths that use ctx.hostname for security-sensitive operations
• Implement Host header validation at the reverse proxy or load balancer level
• Review recent password reset and verification link logs for suspicious domain redirections

Patch Information

The vulnerability has been fixed in Koa versions 3.1.2 and 2.16.4. The fix adds proper detection of the @ symbol in Host headers and uses the URL parser to correctly extract the host portion, returning an empty string for malformed inputs. The security patches are available through the following commits:

• GitHub Commit for 3.x branch
• GitHub Commit for 2.x branch

For additional details, refer to the GitHub Security Advisory GHSA-7gcc-r8m5-44qm.

Workarounds

• Configure reverse proxy to reject or sanitize Host headers containing @ symbols
• Implement application-level validation that checks ctx.hostname against an allowlist of expected domains
• Use a custom middleware to validate Host headers before they reach application code
• Avoid using ctx.hostname directly for security-sensitive URL generation; use hardcoded or environment-configured values instead

# Nginx configuration to reject malformed Host headers
# Add to server block or http block

# Reject requests with @ in Host header
if ($http_host ~* "@") {
    return 400;
}

# Alternative: Validate against allowed hostnames
set $valid_host 0;
if ($http_host = "example.com") {
    set $valid_host 1;
}
if ($http_host = "www.example.com") {
    set $valid_host 1;
}
if ($valid_host = 0) {
    return 400;
}