CVE-2026-34083: 
JavaScript vulnerability analysis and mitigation

CVE-2026-34083 is an OAuth Authorization Code Theft vulnerability in Signal K Server, a marine data hub application, caused by the use of an unvalidated HTTP Host header to construct the OAuth2 redirect_uri in its OIDC login and logout handlers. Affected versions are >= 2.20.0 and < 2.24.0 of the signalk-server npm package. The vulnerability was published on April 2, 2026, with a patch released in version 2.24.0. It carries a CVSS v3.1 base score of 6.1 (Medium/Moderate) (Github Advisory, RedHat CVE).

The root cause is twofold and maps to CWE-346 (Origin Validation Error) and CWE-601 (Open Redirect). First, the redirectUri field in OIDCConfig (defined in types.ts) is optional with no safe default, meaning a valid OIDC configuration can exist without it, silently activating a vulnerable fallback. Second, in oidc-auth.ts, both the login handler (lines 278–282) and logout handler (lines 513–515) call req.get('host') — an attacker-controlled value — to dynamically construct the redirect_uri or post_logout_redirect_uri sent to the OIDC provider. The risk is compounded by SignalK's own official Nginx documentation, which instructs administrators to use proxy_set_header Host $host;, forwarding the client-supplied Host header unmodified to the backend and directly enabling the injection in production deployments. A proof-of-concept using a simple PowerShell Invoke-WebRequest with a spoofed Host header is publicly documented in the advisory (Github Advisory).

Successful exploitation allows an unauthenticated attacker to redirect OAuth authorization codes to an attacker-controlled domain, enabling full account takeover of any user who initiates an OIDC login flow. The attacker can exchange the stolen authorization code for access tokens and establish a session as the victim user. Additionally, the logout handler's identical flaw allows post-logout redirection to an attacker-controlled domain, creating a phishing opportunity. Availability is not impacted, but confidentiality and integrity are both affected through unauthorized account access (Github Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, consisting of a concrete PowerShell command that demonstrates the Host header injection against a live SignalK Server instance. No privileges are required, but user interaction (a victim initiating login) is needed for the authorization code to be stolen. There is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.026% (0.000140 per Feedly), placing it in the 8th percentile for exploitation likelihood. The vulnerability is not listed in the CISA KEV catalog (Github Advisory).

1. Reconnaissance: Identify internet-facing Signal K Server instances (versions >= 2.20.0, < 2.24.0) with OIDC/SSO login enabled, particularly those deployed behind Nginx using the official recommended configuration (proxy_set_header Host $host;).
2. Craft malicious login request: Send an HTTP GET request to the OIDC login endpoint with a spoofed Host header pointing to an attacker-controlled domain:

$response = Invoke-WebRequest -Uri "http://<target>:3000/signalk/v1/auth/oidc/login" -Headers @{"Host"="evil.com"} -MaximumRedirection 0 -ErrorAction SilentlyContinue -UseBasicParsing

3. Verify injected redirect URI: Decode the Location header in the response to confirm the redirect_uri parameter now points to evil.com:

[uri]::UnescapeDataString($response.Headers.Location)

4. Deliver link to victim: Trick a legitimate user into clicking the crafted login URL (e.g., via phishing), causing their browser to initiate the OIDC flow with the injected redirect_uri.
5. Capture authorization code: The OIDC provider, trusting the redirect_uri in the request, sends the OAuth authorization code to evil.com (the attacker's server) instead of the legitimate SignalK callback.
6. Exchange code for tokens: Use the captured authorization code to request access/ID tokens from the OIDC provider, then create an authenticated session as the victim user on the SignalK Server (Github Advisory).

• Network: HTTP requests to /signalk/v1/auth/oidc/login or /signalk/v1/auth/oidc/logout with a Host header value that does not match the server's legitimate hostname or IP address; OAuth authorization code callbacks arriving at unexpected external domains.
• Logs: SignalK access logs showing OIDC login/logout requests with anomalous Host header values (e.g., external domains instead of localhost or the configured server hostname); OIDC provider logs showing redirect_uri values pointing to unregistered or unexpected domains.
• Application Behavior: Unexpected new user sessions created via OIDC for accounts that did not initiate a login; users reporting being redirected to unknown domains after logout.

Upgrade Signal K Server to version 2.24.0 or later, which patches the vulnerable Host header usage in both the login and logout OIDC handlers (SignalK Release). As an immediate workaround for those unable to upgrade, explicitly set the redirectUri field in the OIDC configuration — this bypasses the vulnerable dynamic fallback and uses the configured static value instead. Additionally, modify the Nginx reverse proxy configuration to replace proxy_set_header Host $host; with proxy_set_header Host $host; → a hardcoded server hostname, preventing the client-supplied Host header from reaching the backend (Github Advisory).

The vulnerability was reported by researcher VashuVats and published by SignalK maintainer tkurki on April 1, 2026. The advisory notably highlights that SignalK's own official documentation actively enabled the attack by recommending an Nginx configuration that forwards the client Host header unmodified, a detail that drew attention to the compounding risk of insecure-by-default documentation. No significant broader media coverage or social media discussion has been identified beyond the GitHub advisory and vulnerability database entries (Github Advisory).