chore(deps): update dependency koa to v2.16.4 [security] by renovate[bot] · Pull Request #100 · un-ts/koa

renovate · 2026-05-01T08:21:30Z

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
koa (source)	`2.11.0` → `2.16.4`

Inefficient Regular Expression Complexity in koa

CVE-2025-25200 / GHSA-593f-38f6-jp5m

More information

Details

Summary

Koa uses an evil regex to parse the X-Forwarded-Proto and X-Forwarded-Host HTTP headers. This can be exploited to carry out a Denial-of-Service attack.

PoC

Coming soon.

Impact

This is a Regex Denial-of-Service attack and causes memory exhaustion. The regex should be improved and empty values should not be allowed.

Severity

CVSS Score: 9.2 / 10 (Critical)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Koajs vulnerable to Cross-Site Scripting (XSS) at ctx.redirect() function

CVE-2025-32379 / GHSA-x2rg-q646-7m2v

More information

Details

Summary

In koa < 2.16.1 and < 3.0.0-alpha.5, passing untrusted user input to ctx.redirect() even after sanitizing it, may execute javascript code on the user who use the app.

Patches

This issue is patched in 2.16.1 and 3.0.0-alpha.5.

PoC

Coming soon...

Impact

Redirect user to another phishing site
Make request to another endpoint of the application based on user's cookie
Steal user's cookie

Severity

CVSS Score: 5.0 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Koa Open Redirect via Referrer Header (User-Controlled)

CVE-2025-8129 / GHSA-jgmv-j7ww-jx2x

More information

Details

Summary

In the latest version of Koa, the back method used for redirect operations adopts an insecure implementation, which uses the user-controllable referrer header as the redirect target.

Details

on the API document https://www.koajs.net/api/response#responseredirecturl-alt, we can see:

response.redirect(url, [alt])

Performs a [302] redirect to url.
The string "back" is specially provided for Referrer support, using alt or "/" when Referrer does not exist.

ctx.redirect('back');
ctx.redirect('back', '/index.html');
ctx.redirect('/login');
ctx.redirect('http://google.com');

however, the "back" method is insecure:

https://github.com/koajs/koa/blob/master/lib/response.js#L322

  back (alt) {
    const url = this.ctx.get('Referrer') || alt || '/'
    this.redirect(url)
  },

Referrer Header is User-Controlled.

PoC

there is a demo for POC:

const Koa = require('koa')
const serve = require('koa-static')
const Router = require('@koa/router')
const path = require('path')

const app = new Koa()
const router = new Router()

// Serve static files from the public directory
app.use(serve(path.join(__dirname, 'public')))

// Define routes
router.get('/test', ctx => {
  ctx.redirect('back', '/index1.html')
})

router.get('/test2', ctx => {
  ctx.redirect('back')
})

router.get('/', ctx => {
  ctx.body = 'Welcome to the home page! Try accessing /test, /test2'
})

app.use(router.routes())
app.use(router.allowedMethods())

const port = 3000
app.listen(port, () => {
  console.log(`Server running at http://localhost:${port}`)
})

Proof Of Concept

GET /test HTTP/1.1
Host: 127.0.0.1:3000
Referer: http://www.baidu.com
Connection: close

GET /test2 HTTP/1.1
Host: 127.0.0.1:3000
Referer: http://www.baidu.com
Connection: close

Impact

https://learn.snyk.io/lesson/open-redirect/

Severity

CVSS Score: 2.0 / 10 (Low)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Koa has Host Header Injection via ctx.hostname

CVE-2026-27959 / GHSA-7gcc-r8m5-44qm

More information

Details

Summary

Koa's ctx.hostname API performs naive parsing of the HTTP Host header, extracting everything before the first colon without validating the input conforms to RFC 3986 hostname syntax. When a malformed Host header containing a @ symbol (e.g., evil.com:fake@legitimate.com) is received, ctx.hostname returns evil.com - an attacker-controlled value. Applications using ctx.hostname for URL generation, password reset links, email verification URLs, or routing decisions are vulnerable to Host header injection attacks.

Details

The vulnerability exists in Koa's hostname getter in lib/request.js:

// Koa 2.16.1 - lib/request.js
get hostname() {
  const host = this.host;
  if (!host) return '';
  if ('[' === host[0]) return this.URL.hostname || ''; // IPv6 literal
  return host.split(':', 1)[0];
}

The host getter retrieves the raw header value with HTTP/2 and proxy support:

// Koa 2.16.1 - lib/request.js
get host() {
  const proxy = this.app.proxy;
  let host = proxy && this.get('X-Forwarded-Host');
  if (!host) {
    if (this.req.httpVersionMajor >= 2) host = this.get(':authority');
    if (!host) host = this.get('Host');
  }
  if (!host) return '';
  return host.split(',')[0].trim();
}

The Problem

The parsing logic simply splits on the first : and returns the first segment. There is no validation that the resulting string is a valid hostname per RFC 3986 Section 3.2.2.

RFC 3986 Section 3.2.2 defines the host component as:

host = IP-literal / IPv4address / reg-name
reg-name = *( unreserved / pct-encoded / sub-delims )
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

The @ character is explicitly NOT permitted in the host component - it is the delimiter separating userinfo from host in the authority component.

Attack Vector

When an attacker sends:

Host: evil.com:fake@legitimate.com:3000

Koa parses this as:

API	Returns	Notes
`ctx.get('Host')`	`"evil.com:fake@legitimate.com:3000"`	Raw header
`ctx.hostname`	`"evil.com"`	Attacker-controlled
`ctx.host`	`"evil.com:fake@legitimate.com:3000"`	Raw header value
`ctx.origin`	`"http://evil.com:fake@legitimate.com:3000"`	Protocol + malformed host

The ctx.hostname API returns evil.com because the parser splits on the first : without understanding that evil.com:fake@legitimate.com is a malformed authority component where evil.com:fake would be interpreted as userinfo by a proper URI parser.

Additional Concern: `ctx.origin`

Koa's ctx.origin property concatenates protocol and host without validation:

// lib/request.js
get origin() {
  return `${this.protocol}://${this.host}`;
}

Applications using ctx.origin for URL generation receive the full malformed Host header value, creating URLs with embedded credentials that browsers may interpret as userinfo.

HTTP/2 Consideration

Koa explicitly checks httpVersionMajor >= 2 to read the :authority pseudo-header:

if (this.req.httpVersionMajor >= 2) host = this.get(':authority');

The same vulnerability applies - malformed :authority values containing userinfo would be accepted and parsed identically.

PoC

Setup

// server.js
const Koa = require('koa'); 
const app = new Koa();

// Simulates password reset URL generation (common vulnerable pattern)
app.use(async ctx => {
  if (ctx.path === '/forgot-password') {
    const resetToken = 'abc123securtoken';
    const resetUrl = `${ctx.protocol}://${ctx.hostname}/reset?token=${resetToken}`;
    
    ctx.body = {
      message: 'Password reset link generated',
      resetUrl: resetUrl,
      debug: {
        rawHost: ctx.get('Host'),
        parsedHostname: ctx.hostname,
        origin: ctx.origin,
        protocol: ctx.protocol
      }
    };
  }
});

app.listen(3000, () => console.log('Server on http://localhost:3000'));

Exploit

curl -H "Host: evil.com:fake@localhost:3000" http://localhost:3000/forgot-password

Result

{
  "message": "Password reset link generated",
  "resetUrl": "http://evil.com/reset?token=abc123securtoken",
  "debug": {
    "rawHost": "evil.com:fake@localhost:3000",
    "parsedHostname": "evil.com",
    "origin": "http://evil.com:fake@localhost:3000",
    "protocol": "http"
  }
}

The password reset URL points to evil.com instead of the legitimate server. In a real attack:

Attacker requests password reset for victim's email with malicious Host header
Server generates reset link using ctx.hostname → https://evil.com/reset?token=SECRET
Victim receives email with poisoned link
Victim clicks link, token is sent to attacker's server
Attacker uses token to reset victim's password

Additional Test Cases

##### Basic injection
curl -H "Host: evil.com:x@legitimate.com" http://localhost:3000/forgot-password

##### Result: hostname = "evil.com"

##### With port preservation attempt
curl -H "Host: evil.com:443@legitimate.com:3000" http://localhost:3000/forgot-password  

##### Result: hostname = "evil.com"

##### Unicode/encoded variations
curl -H "Host: evil.com:x%40legitimate.com" http://localhost:3000/forgot-password

##### Result: hostname = "evil.com"

Deployment Consideration

For this attack to succeed in production, the malicious Host header must reach the Koa application. This occurs when:

No reverse proxy - Application directly exposed to internet
Misconfigured proxy - Proxy doesn't override/validate Host header
Proxy trust enabled (app.proxy = true) - X-Forwarded-Host can be injected
Default virtual host - Server is the catch-all for unrecognized Host headers

Impact

Vulnerability Type

CWE-20: Improper Input Validation
CWE-644: Improper Neutralization of HTTP Headers for Scripting Syntax

Attack Scenarios

1. Password Reset Poisoning (High Severity)

Attacker hijacks password reset tokens by poisoning reset URLs
Requires victim to click link in email
Results in account takeover

2. Email Verification Bypass

Attacker poisons email verification links
Can verify attacker-controlled email on victim accounts

3. OAuth/SSO Callback Manipulation

Applications using ctx.hostname for OAuth redirect URIs
Attacker redirects OAuth callbacks to malicious server
Results in token theft

4. Web Cache Poisoning

If responses are cached without Host in cache key
Poisoned URLs served to all users
Persistent XSS/phishing via cached responses

5. Server-Side Request Forgery (SSRF)

Internal routing decisions based on ctx.hostname
Attacker manipulates which backend receives requests

Who Is Impacted

Direct impact: Any Koa application using ctx.hostname or ctx.origin for URL generation without additional validation
Common patterns: Password reset, email verification, webhook URL generation, multi-tenant routing, OAuth implementations

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

koajs/koa (koa)

Uh oh!

Uh oh!

Conversation

renovate Bot commented May 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Inefficient Regular Expression Complexity in koa

Details

Summary

PoC

Impact

Severity

References

Koajs vulnerable to Cross-Site Scripting (XSS) at ctx.redirect() function

Details

Summary

Patches

PoC

Impact

Severity

References

Koa Open Redirect via Referrer Header (User-Controlled)

Details

Summary

Details

PoC

Impact

Severity

References

Koa has Host Header Injection via ctx.hostname

Details

Summary

Details

The Problem

Attack Vector

Additional Concern: ctx.origin

HTTP/2 Consideration

PoC

Setup

Exploit

Result

Additional Test Cases

Deployment Consideration

Impact

Vulnerability Type

Attack Scenarios

Who Is Impacted

Severity

References

Release Notes

What's Changed

What's Changed

What's Changed

Configuration

Uh oh!

changeset-bot Bot commented May 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ No Changeset found

Uh oh!

socket-security Bot commented May 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

socket-security Bot commented May 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

renovate Bot commented May 1, 2026 •

edited

Loading

Additional Concern: `ctx.origin`

changeset-bot Bot commented May 1, 2026 •

edited

Loading

socket-security Bot commented May 1, 2026 •

edited

Loading