CVE-2026-100390 is a High (CVSS 7.4) authentication bypass by spoofing in Zoraxy 3.2.3 through 3.3.4. IPv6 clients can supply their own X-Forwarded-For value and defeat IP based access rules. Upgrade to a release newer than 3.3.4 and review any rule that trusts client IP addresses.
What's affected
Zoraxy versions 3.2.3 through 3.3.4 are affected, per the record and the VulnCheck advisory. The weakness is CWE-290 (authentication bypass by spoofing).
The cause, as described in the record, is that Zoraxy does not parse IPv6 addresses in the RemoteAddr field correctly when it sets forwarded headers. An unauthenticated attacker who connects over IPv6 can supply an arbitrary X-Forwarded-For value, spoof their source IP and get around IP based access controls in the authorization provider.
Severity differs by source. The record carries CVSS 3.1 7.4 (High). The VulnCheck advisory lists a CVSS score of 9.1 with a CVSS 4.0 vector. Treat the higher number as the worst case if your access rules depend on client IP addresses.
We could not confirm a fixed release number. The references point to a pull request (1264) and a commit in the Zoraxy repository, and the advisory's affected range ends at 3.3.4, so a later release should carry the change. Check the Zoraxy release notes to confirm that the version you pick includes pull request 1264.
How to check if you're exposed
First, find your Zoraxy version. The version is shown in the management interface, and the binary or container tag will also tell you. If it is between 3.2.3 and 3.3.4 inclusive, you are in range.
Second, check whether you use the feature at risk. The record says the problem affects IP based access controls in the authorization provider. If you have no rule that allows or blocks by source IP address, the bypass gains the attacker little. If you do, those rules are the ones to review.
Third, check whether IPv6 is reachable. The attacker must connect over IPv6. If your listener only accepts IPv4, the stated condition does not apply, though that is a poor long term control.
The free in-browser dependency scan at gold.safeguard.sh/scan can match a lockfile or manifest against known CVEs without installing anything. The Gold directory page for each CVE lists affected packages and fixes as they are published.
What to do now
- Check the Zoraxy version and note whether it is in the 3.2.3 to 3.3.4 range.
- Upgrade to a release newer than 3.3.4 that includes pull request 1264. Confirm in the release notes.
- Until then, do not rely on source IP alone for access decisions. Add real authentication in front of anything sensitive.
- If IPv6 is not needed on the listener, consider disabling it as a stopgap.
- Review access logs for requests that arrived over IPv6 with unusual forwarded header values.
Why it matters
An X-Forwarded-For header is only as honest as the system that sets it. A reverse proxy is supposed to write the real client address into that header and discard whatever the client sent. When the proxy fails to parse the connection address correctly, which can happen with IPv6 formats, it may pass the client's own claim through.
IP allow lists then fail open. Anyone who can reach the proxy over IPv6 can claim to be an internal address. The record does not mark the CVE as known exploited, and the sources we reviewed report no exploitation.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which Zoraxy versions are affected?
Versions 3.2.3 through 3.3.4, per the record and VulnCheck. We could not confirm the exact fixed version number, so check the release notes for a release newer than 3.3.4.
Why do the scores differ?
The record shows CVSS 3.1 7.4. VulnCheck lists 9.1 on CVSS 4.0. Different scoring versions and assumptions explain the gap.
Sources
Last reviewed: 18 October 2026.
