CVE-2026-27192: Verified Repro With Script Download

GHSA-9m9c-vpv5-9g85: Feathers exposes internal headers via unencrypted session cookie

Summary

The @feathersjs/authentication-oauth package versions 5.0.39 and earlier store ALL incoming HTTP request headers in the session cookie. The session is persisted using cookie-session middleware which base64-encodes the data. While the cookie is cryptographically signed to prevent tampering, the contents are NOT encrypted and can be decoded by anyone with access to the cookie value. This exposes sensitive internal proxy/gateway headers (such as x-forwarded-for, x-internal-api-key, x-real-ip, authorization, etc.) that may contain API keys, service tokens, and internal infrastructure details.

Impact

• Package: @feathersjs/authentication-oauth (npm)
• Affected Versions: <= 5.0.39
• Patched Version: 5.0.40
• Severity: HIGH
• CWE: CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor)

Risk Consequences:

• Internal API keys and service tokens stored in headers by reverse proxies or API gateways are exposed to clients
• Internal IP addresses and network topology information can be leaked
• Authorization tokens (Authorization header) may be exposed if stored
• Session cookies (Cookie header) could be captured

This vulnerability is particularly dangerous for deployments behind reverse proxies or API gateways that inject sensitive headers.

Root Cause

Technical Explanation:

The vulnerability exists in the OAuth service handler at packages/authentication-oauth/src/service.ts:

// Line 173 in vulnerable versions (v5.0.39)
session.headers = headers;

This single line stores the entire headers object (containing ALL HTTP request headers) into the session. The session is then serialized and stored in a cookie by cookie-session middleware.

The cookie-session middleware works by:

1. Taking the session object and serializing it to JSON
2. Base64-encoding the JSON string
3. Storing the result in a cookie (e.g., feathers.oauth=<base64-encoded-data>)
4. Cryptographically signing the cookie to detect tampering

The critical flaw: The signature only prevents modification - it does NOT encrypt the contents. Anyone can base64-decode the cookie value to reveal all stored headers.

Fix Commit: https://github.com/feathersjs/feathers/commit/ee19a0ae9bc2ebf23b1fe598a1f7361981b65401

The fix changes the code to only store the specific header needed for functionality:

// Fixed version (v5.0.40+)
// Only store the referer header needed for origin validation
session.headers = {
  referer: headers?.referer
}

Reproduction Steps

The reproduction is performed by the script repro/reproduction_steps.sh:

1. Clones the feathers repository at the vulnerable version (v5.0.39)
2. Navigates to the packages/authentication-oauth package
3. Analyzes the source code in src/service.ts for the vulnerable pattern
4. Detects the presence of session.headers = headers which stores all headers
5. Demonstrates how sensitive headers would be exposed by simulating the session encoding

What the script does:

• Locates the vulnerable code pattern in the source
• Verifies that ALL headers are stored, not just necessary ones
• Demonstrates the exposure by simulating base64 encoding of a session with sensitive headers
• Shows that internal proxy headers like x-forwarded-for, x-internal-api-key, x-real-ip would be exposed

Expected Evidence:

• Exit code 0 if vulnerability is confirmed
• Exit code 1 if code appears patched
• Log output showing the vulnerable code section at line 173
• Demonstration of how base64 encoding exposes header data

Evidence

Log Files:

• logs/repro_output.log - Contains the full reproduction output
• logs/npm_install.log - Contains npm install output (if dependencies needed installation)

Key Evidence from Reproduction:

=== VULNERABILITY ANALYSIS ===

✅ VULNERABILITY CONFIRMED - Vulnerable code pattern detected

   The code contains: `session.headers = headers`
   This stores ALL HTTP headers in the session cookie.

   Code section:
   ---
    171:     session.redirect = redirect
    172:     session.query = restQuery
>>> 173:     session.headers = headers
    174: 
    175:     return this.handler('GET', handlerParams, {})
    176:   }
   ---

Base64 Exposure Demonstration: When headers like:

{
    "x-forwarded-for": "10.0.0.1",
    "x-internal-api-key": "sk_live_secret123",
    "x-real-ip": "192.168.1.1"
}

Are stored in the session, the cookie contains:

eyJoZWFkZXJzIjp7IngtZm9yd2FyZGVkLWZvciI6IjEwLjAuMC4xIiwieC1pbnRlcm5hbC1hcGkta2V5...

Which can be trivially decoded to reveal the sensitive data.

Environment Details:

• Tested against feathers v5.0.39 (vulnerable)
• Node.js environment
• Package: @feathersjs/authentication-oauth

Recommendations / Next Steps

Immediate Action:

1. Upgrade to @feathersjs/authentication-oauth version 5.0.40 or later
2. Regenerate any API keys, tokens, or credentials that may have been exposed via HTTP headers
3. Review access logs for any suspicious activity

Testing Recommendations:

1. Verify that after upgrading, only the referer header (if needed) is stored in session
2. Ensure OAuth authentication flows continue to work correctly
3. Test with common proxy headers (x-forwarded-for, x-real-ip) to confirm they are no longer stored

Fix Verification: After upgrading, the code at packages/authentication-oauth/src/service.ts should show:

session.headers = {
  referer: headers?.referer
}

Instead of:

session.headers = headers;

Additional Security Considerations:

1. Consider implementing additional header filtering at the reverse proxy level
2. Review other applications that may have similar session storage patterns
3. Educate development teams about the difference between "signed" and "encrypted" cookies

Additional Notes

Idempotency Confirmation: The reproduction script has been run twice consecutively and produced identical results, confirming:

• The vulnerability exists in v5.0.39
• The detection is deterministic and reliable
• The script is idempotent and safe to re-run

Edge Cases:

• If the code has already been patched (v5.0.40+), the script will detect the fixed pattern and exit with code 1
• The script correctly handles the case where the vulnerable pattern has been replaced with the selective header storage

Limitations:

• This reproduction demonstrates the code vulnerability through static analysis
• A full runtime reproduction would require setting up an OAuth provider and complete authentication flow
• The exposure risk depends on the deployment configuration (presence of reverse proxies/API gateways that add sensitive headers)

Report generated by reproduction agent for GHSA-9m9c-vpv5-9g85