EUVD-2026-87327Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessConnect to Zoraxy over IPv6
-
DeliverySend request with forged X-Forwarded-For header
-
ExploitIPv6 RemoteAddr mis-parse leaves spoofed header intact
-
ExecutionBypass IP-based access control
-
ImpactReach IP-restricted protected resource
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Anti-spoofing controls
MITRE ATT&CK
1 technique across 1 tactic: Defense Evasion The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires: (1) a vulnerable Zoraxy instance in the 3.2.3-3.3.4 range; (2) the deployment must use Zoraxy's SSO forward-auth provider with IP-based access controls, since the bug lives in the forward-auth util that sets X-Forwarded-For/X-Original-IP; and (3) the attacker must connect over IPv6, because the flawed strings.Cut on the first ':' only breaks for bracketed IPv6 RemoteAddr (e.g. '[2a01:4f8::1]:54321'), causing net.ParseIP to fail so the client-supplied header is not overwritten. Under these conditions no authentication is required (PR:N). The limiting factors - mandatory IPv6 reachability and reliance on IP-based access control as the security boundary - mean IPv4-only or non-IP-gated deployments are not exploitable. |
| Impact | This is a genuine access-control bypass but its real-world risk is narrower than the 9.1 CVSS 4.0 score suggests. The vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H confirms remote, unauthenticated, low-complexity exploitation, but the AT:P (attack requirement) correctly captures that exploitation is conditional: the attacker must reach Zoraxy over IPv6 AND the deployment must use the SSO forward-auth provider with IP-based access controls. EPSS is not provided, this CVE is NOT in CISA KEV (no confirmed active exploitation), and no weaponized POC is published - the VulnCheck advisory and the merged fix (PR #1264, commit 56bb3e5a) describe the flaw and include a regression test but do not constitute exploit code. The VC:H/VI:H impact rating is arguably generous: the flaw itself only spoofs a source IP; the downstream confidentiality/integrity impact depends entirely on what the IP allowlist is protecting. Signals are consistent (network vector matches the X-Forwarded-For spoofing mechanism), but the config-dependency and IPv6 requirement mean this is a targeted, deployment-specific issue rather than a broadly wormable one. Patch availability is confirmed by the vendor GitHub repo. |
| Exploit ScenarioDerived | An attacker connects to an internet-facing Zoraxy (3.2.3-3.3.4) instance over IPv6 where an application behind it relies on Zoraxy's SSO forward-auth IP-based access controls. Because Zoraxy mis-parses the bracketed IPv6 RemoteAddr and fails to overwrite the client-supplied X-Forwarded-For, the attacker sets X-Forwarded-For to a trusted/whitelisted IP and is granted access to a resource that should be IP-restricted. No public exploit code is identified, though a vendor/VulnCheck advisory and a fix commit with a regression test exist. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 25, 2026
Source-IP spoofing in Zoraxy 3.2.3 through 3.3.4 lets unauthenticated attackers who reach the service over IPv6 forge X-Forwarded-For and X-Original-IP values, so IP-based access controls enforced by Zoraxy's SSO forward-auth provider see a trusted client address and grant access (CWE-290). The 9.1 CVSS 4.0 severity reflects fully unauthenticated remote exploitation (PR:N), but our independent assessment (CVSS:3.1/AV:N/AC:H/PR:N/UI:N) rates the real-world risk lower because exploitation requires IPv6 connectivity and a deployment that actually relies on forward-auth IP allowlisting as a security boundary, so IPv4-only or non-IP-gated instances are not exploitable. No public exploit code was identified at time of analysis and there is no KEV entry, though a vendor patch is available.
RemediationAI
Apply the upstream fix: PR #1264 / commit 56bb3e5abb83eae42a64203028d73a001d6096c4 (patch available from the vendor; a formally tagged patched release was not independently confirmed, so verify the deployed build contains the net.SplitHostPort change and the header-deletion branch in src/mod/auth/sso/forward/util.go). If patching must be deferred, block or disable IPv6 access to the Zoraxy forward-auth endpoints via firewall or listener configuration, accepting that this breaks legitimate IPv6 clients and hides rather than fixes the trust issue; or stop treating X-Forwarded-For/X-Original-IP as a security boundary in the authorization provider and enforce access through SSO session or token validation instead of source-IP allowlists, which removes the bypass but discards IP allowlisting as a defense layer; and/or front Zoraxy with a reverse proxy that unconditionally strips client-supplied X-Forwarded-For and X-Original-IP and re-injects the true peer address, which is reliable only if that proxy is the single ingress path and invalidates legitimate forwarding/logging use cases. Consult the VulnCheck advisory and the upstream PR for updated release guidance.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in Zoraxy's SSO forward-auth utility (src/mod/auth/sso/forward/util.go, function rSetIPHeader, roughly lines 127-142 in v3.3.4), which rewrites the X-Forwarded-For and X-Original-IP headers from Go's http.Request.RemoteAddr before the request is evaluated against an authorization provider's IP allowlist. The vulnerable code used strings.Cut(r.RemoteAddr, ":") to strip the port, which behaves correctly for IPv4 ("10.0.0.1:54321") but mangles bracketed IPv6 ("[2a01:4f8::1]:54321" becomes "[2a01:4f8"), causing net.ParseIP to fail; when the address cannot be parsed the client-supplied header value is left in place instead of being overwritten with the real peer address. CWE-290 (Authentication Bypass by Spoofing) is the correct root-cause class: implicit trust in a client-controllable header combined with a parsing error. The upstream fix replaces the manual cut with net.SplitHostPort and, when the address still cannot be parsed or RemoteAddr is empty, explicitly deletes the forwarded headers so a client-supplied value is never retained (PR #1264, commit 56bb3e5abb83eae42a64203028d73a001d6096c4), backed by new unit tests covering IPv4, bracketed IPv6, IPv6 without a port, and unparsable/empty addresses.
Know when Zoraxy gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Remote unauthenticated (AV:N/PR:N), but AC:H reflects the required IPv6 path plus dependence on IP-based access controls being the security gate; C:H/I:H assume the bypassed control fronts sensitive resources.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
Zoraxy versions 3.2.3 through 3.3.4 fail to properly parse IPv6 addresses in the RemoteAddr field when setting forwarded headers. Unauthenticated attackers connecting over IPv6 can supply arbitrary X-Forwarded-For values to spoof their source IP and bypass authorization provider IP-based access controls.
Executive ViewAI
Zoraxy versions 3.2.3 through 3.3.4 contain a critical authentication bypass that allows unauthenticated attackers with IPv6 access to forge client IP headers and evade IP-based access controls protecting SSO-gated applications. Organizations using Zoraxy as a reverse proxy with forward-auth IP allowlisting as a security boundary are at risk of unauthorized access to internal or sensitive services, though IPv4-only and non-IP-gated deployments are not affected. Leadership should prioritize patching because this flaw directly undermines a network security control, but immediate exploitation risk is limited by the specific IPv6 and configuration preconditions and the absence of public exploit code.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB