CVE-2026-25651: 
JavaScript vulnerability analysis and mitigation

CVE-2026-25651 is an open redirect vulnerability (CWE-601) in the client-certificate-auth Node.js middleware package, caused by Host header injection in the HTTP-to-HTTPS redirect logic. Versions 0.2.1 and 0.3.0 are affected; the issue was disclosed and patched on February 6, 2026. The vulnerability carries a CVSS v3.1 base score of 6.1 (Medium) (Github Advisory, Security Advisory).

The root cause is the middleware's unconditional use of the unvalidated HTTP Host header when constructing HTTPS redirect URLs (CWE-601). The vulnerable code in lib/clientCertificateAuth.js reads: if (!req.secure && req.header('x-forwarded-proto') != 'https') { return res.redirect('https://' + req.header('host') + req.url); } — allowing an attacker who can manipulate the Host header to redirect victims to an arbitrary domain. Exploitation requires that HTTP traffic reaches the Node.js application directly without a reverse proxy or load balancer that sets x-forwarded-proto: https, a condition that is uncommon in modern production deployments (Security Advisory, Github Advisory).

Successful exploitation enables phishing attacks where victims following legitimate-looking links are silently redirected to attacker-controlled credential-harvesting pages. In OAuth/SSO authentication flows, authorization codes or tokens may leak to the attacker's domain via the redirect URL. Additionally, sensitive URL parameters can be exposed to attacker domains through the Referer header, and in deployments using shared caches, poisoned redirect responses may be served to multiple users (Security Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.019% (0.000280), indicating a very low probability of exploitation in the near term. Real-world exploitability is further constrained by the requirement that HTTP traffic reach the Node.js application without a proxy setting x-forwarded-proto: https, which is uncommon in modern infrastructure. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (Github Advisory, Security Advisory).

1. Identify a vulnerable target: Locate a Node.js application using client-certificate-auth versions 0.2.1 or 0.3.0 that accepts direct HTTP connections without a reverse proxy enforcing x-forwarded-proto: https.
2. Craft a malicious link: Construct a URL pointing to the legitimate application over HTTP (e.g., http://vulnerable-app.example.com/login) to share with the victim via phishing email or message.
3. Intercept and inject the Host header: Position yourself as a man-in-the-middle or use a tool (e.g., Burp Suite) to intercept the victim's HTTP request and replace the Host header with an attacker-controlled domain (e.g., Host: attacker.com).
4. Trigger the redirect: The middleware evaluates the request as non-HTTPS and issues a 302 Found response redirecting to https://attacker.com/login.
5. Harvest credentials or tokens: The victim lands on the attacker-controlled site, where credentials, OAuth tokens, or other sensitive data can be captured (Security Advisory).

• Network: Unexpected 302 redirect responses from the application server pointing to external or unfamiliar domains; HTTP requests to the application with a Host header value that does not match the application's configured hostname.
• Logs: Web server or Node.js access logs showing 302 responses where the Location header contains a domain other than the application's own domain; requests arriving over plain HTTP (port 80) that should normally be HTTPS-only.
• Application Behavior: Users reporting being redirected to unexpected external sites after clicking application links; OAuth/SSO flows completing on unexpected domains (Security Advisory).

Upgrade client-certificate-auth to version 1.0.0 or later, which completely removes the vulnerable HTTP-to-HTTPS redirect behavior (npm install client-certificate-auth@^1.0.0). If immediate upgrading is not possible, block all HTTP traffic at the network or load balancer level, ensure your reverse proxy always sets the x-forwarded-proto: https header, or add middleware before clientCertificateAuth to validate the Host header against an allowlist of trusted domains. Implementing a strict Content-Security-Policy header can also help limit the impact of any redirect-based attacks (Security Advisory, v1.0.0 Release).