CVE-2026-33131: H3 Framework Auth Bypass Vulnerability

CVE-2026-33131 Overview

CVE-2026-33131 is a Host Header Spoofing vulnerability affecting H3, a minimal HTTP framework for Node.js. The vulnerability exists in the NodeRequestUrl class (which extends FastURL) and allows attackers to bypass authentication and authorization middleware through crafted Host headers. When event.url, event.url.hostname, or event.url._url properties are accessed in middleware—such as logging middleware—the _url getter constructs a URL from untrusted data, including the user-controlled Host header.

Due to H3's router resolving the route handler before middleware execution, an attacker can supply a specially crafted Host header (e.g., Host: localhost:3000/abchehe?) to cause middleware path checks to fail while the route handler still matches, effectively bypassing security controls.

Critical Impact

This vulnerability enables authentication and authorization bypass in any application built on H3 (including Nitro/Nuxt) that relies on middleware to guard sensitive routes using event.url properties.

Affected Products

• H3 version 2.0.0
• H3 versions 2.0.1-rc.2 through 2.0.1-rc.14
• Applications built on Nitro/Nuxt using affected H3 versions

Discovery Timeline

• 2026-03-20 - CVE-2026-33131 published to NVD
• 2026-03-20 - Last updated in NVD database

Technical Details for CVE-2026-33131

Vulnerability Analysis

This Host Header Spoofing vulnerability (CWE-290: Authentication Bypass by Spoofing) exploits a fundamental flaw in how H3 processes URL construction. The issue stems from the framework's use of unsanitized, attacker-controlled input when constructing the FastURL.href property. The vulnerability is particularly dangerous because H3's routing architecture resolves route handlers before middleware runs, creating a race condition where security middleware can be bypassed while the actual route still processes the request.

The attack is network-accessible and requires no authentication or user interaction to exploit, making it highly accessible to remote attackers. Successful exploitation can lead to unauthorized access to protected endpoints and potential data compromise.

Root Cause

The root cause lies in the NodeRequestUrl class's _url getter, which constructs URLs using untrusted data from the HTTP Host header without proper validation or sanitization. When middleware accesses event.url properties for path-based authorization checks, the manipulated Host header causes path matching to fail, even though the underlying route handler correctly matches the request.

This design flaw violates the principle of never trusting client-controlled input for security-critical decisions. The middleware receives a different URL path interpretation than the router, creating a security boundary mismatch.

Attack Vector

The attack exploits the discrepancy between how middleware interprets the URL path and how the router resolves handlers. An attacker sends a request with a crafted Host header containing path components and query string terminators:

The vulnerability is exploited by manipulating the Host header to include path-like components. For example, an attacker targeting a protected /admin endpoint might send a request with Host: localhost:3000/public? header. The middleware's path check sees the manipulated URL and may interpret the path as /public, allowing the request to pass authorization checks. Meanwhile, the router (which resolved before middleware) correctly routes to the actual /admin handler.

This attack requires no special privileges and can be executed with standard HTTP request tools. For detailed technical information, see the H3 Security Advisory.

Detection Methods for CVE-2026-33131

Indicators of Compromise

• HTTP requests with Host headers containing path separators (/) or query string characters (?)
• Unusual Host header values that don't match expected domain patterns
• Access logs showing requests to protected endpoints without corresponding authentication logs
• Host headers containing localhost references with appended path components

Detection Strategies

• Implement WAF rules to detect and block Host headers containing path traversal characters or query strings
• Monitor for requests where the Host header contains characters outside typical hostname patterns (e.g., /, ?, #)
• Create alerts for access to sensitive routes from Host headers that don't match configured virtual hosts
• Review middleware logs for authentication/authorization decisions that contradict route access patterns

Monitoring Recommendations

• Enable detailed logging for all middleware authentication decisions, including the raw Host header value
• Set up anomaly detection for Host headers that deviate from expected patterns
• Monitor for increased 401/403 errors followed by successful access to the same endpoints
• Implement request correlation to identify discrepancies between middleware path interpretation and actual route accessed

How to Mitigate CVE-2026-33131

Immediate Actions Required

• Upgrade H3 to version 2.0.1-rc.15 or later immediately
• Audit all middleware that uses event.url, event.url.hostname, or event.url._url for path-based security decisions
• Implement Host header validation at the reverse proxy or load balancer level
• Review access logs for evidence of exploitation attempts using malformed Host headers

Patch Information

The H3 team has addressed this vulnerability in version 2.0.1-rc.15. The fix ensures that FastURL.href is no longer constructed with unsanitized, attacker-controlled input from the Host header. Users should update their H3 dependency immediately by running the appropriate package manager command for their environment.

For additional details, refer to the GitHub Security Advisory GHSA-3vj8-jmxq-cgj5.

Workarounds

• Deploy a reverse proxy (nginx, Caddy, HAProxy) that validates and normalizes Host headers before passing requests to H3
• Implement explicit Host header validation middleware that runs before any path-based security checks
• Configure your infrastructure to reject requests with Host headers not matching allowed domains
• Use route-level authentication decorators instead of relying solely on path-matching middleware

# Example nginx configuration to validate Host headers
# Add to your server block
if ($http_host ~ "[/?#]") {
    return 400;
}

# Alternatively, explicitly whitelist allowed Host values
map $http_host $valid_host {
    default 0;
    "example.com" 1;
    "www.example.com" 1;
}

server {
    if ($valid_host = 0) {
        return 400;
    }
    # ... rest of configuration
}