CVE-2026-62314: Anubis Web AI Firewall Auth Bypass Flaw

CVE-2026-62314 Overview

CVE-2026-62314 is an access control weakness in Anubis, a Web AI Firewall utility that challenges client connections to protect upstream resources from scraper bots. The flaw resides in lib/policy/checker.go within the PathChecker.Check() function. The checker trusted the client-controlled X-Original-URI header before matching against r.URL.Path. An attacker can send this header to match default ALLOW rules such as ^/\.well-known/.*$ shipped in data/common/keep-internet-working.yaml and bypass the Anubis challenge entirely. The issue affects versions from 1.22.0 up to but not including 1.26.0-pre1. The weakness is classified under [CWE-284] Improper Access Control.

Critical Impact
Remote unauthenticated clients can bypass the Anubis bot challenge by supplying a crafted X-Original-URI header, exposing upstream resources intended to be protected from scraper traffic.

Affected Products

Anubis Web AI Firewall versions 1.22.0 through 1.25.x
Deployments using the default data/common/keep-internet-working.yaml ALLOW rules
Reverse-proxy topologies that pass or accept X-Original-URI from clients

Discovery Timeline

2026-07-15 - CVE-2026-62314 published to NVD
2026-07-16 - Last updated in NVD database
v1.26.0-pre1 - Patch released by the TecharoHQ Anubis project

Technical Details for CVE-2026-62314

Vulnerability Analysis

Anubis performs policy decisions per request by evaluating configured path rules. The PathChecker.Check() function determined the effective request path before comparing it to policy expressions. In the vulnerable code, the checker preferred the X-Original-URI header, a value that reverse proxies such as NGINX may set for subrequest routing. Because Anubis accepted this header without verifying it originated from a trusted proxy, any HTTP client could set it directly.

By sending X-Original-URI: /.well-known/anything, a client caused the path checker to match the default ALLOW rule ^/\.well-known/.*$. The request then bypassed the JavaScript proof-of-work challenge and reached the upstream service, defeating the anti-scraper protection.

Root Cause

The root cause is misplaced trust in a client-controlled HTTP header for security-relevant path decisions. Policy checkers must derive request paths from r.URL.Path unless the header source is authenticated as an internal subrequest. The patch introduces a subRequestMode flag that is threaded through the CEL and path checkers, ensuring the header is honored only in subrequest contexts.

Attack Vector

Exploitation requires network access to the Anubis-fronted endpoint. No authentication or user interaction is needed. The attacker crafts a standard HTTP request with an added X-Original-URI header pointing at an allow-listed path. Anubis returns the upstream content directly, allowing automated scrapers or bots to harvest data intended to be gated.

// Patch excerpt: subRequestMode is now explicitly wired through the checker
type CELChecker struct {
	program        cel.Program
	src            string
	subRequestMode bool
}

func NewCELChecker(cfg *config.ExpressionOrList, dnsObj *dns.Dns, subRequestMode bool) (*CELChecker, error) {
	env, err := expressions.BotEnvironment(dnsObj)
	if err != nil {
		return nil, err
	}
	// ...
}
// Source: https://github.com/TecharoHQ/anubis/commit/276b537776b281b1c4e01421435bc03ade3d8fc4

Detection Methods for CVE-2026-62314

Indicators of Compromise

Inbound HTTP requests containing an X-Original-URI header from external client IP addresses rather than trusted reverse-proxy hops.
Requests where the header value references allow-listed prefixes such as /.well-known/ while the actual request path is unrelated.
Elevated upstream traffic volume from user agents typical of scrapers with no corresponding Anubis challenge-completion events.

Detection Strategies

Parse Anubis and upstream access logs for X-Original-URI values that diverge from r.URL.Path on the same request.
Alert on requests that bypass the Anubis challenge cookie yet still hit protected upstream endpoints.
Correlate proxy logs to confirm whether X-Original-URI was injected by a trusted internal component or arrived from the client edge.

Monitoring Recommendations

Track the ratio of challenge-solved sessions to total upstream requests and investigate sudden increases in unauthenticated flow-through.
Capture full HTTP request headers at the ingress tier so that header spoofing attempts remain forensically available.
Baseline scraper-detection metrics before and after upgrading to 1.26.0-pre1 to confirm the bypass is closed.

How to Mitigate CVE-2026-62314

Immediate Actions Required

Upgrade Anubis to version 1.26.0-pre1 or later, which correctly wires subrequest mode through the CEL and path checkers.
Strip or normalize the X-Original-URI header at the outermost reverse proxy before traffic reaches Anubis.
Audit deployed policy files, particularly data/common/keep-internet-working.yaml, and tighten any overly broad ALLOW rules such as ^/\.well-known/.*$.

Patch Information

The fix is delivered in the GitHub Release v1.26.0-pre1 via Pull Request #1630 and commit 276b5377. Full remediation guidance is documented in GitHub Security Advisory GHSA-6wcg-mqvh-fcvg.

Workarounds

Configure the upstream reverse proxy to unset X-Original-URI on client-facing requests until the upgrade is applied.
Restrict the default ALLOW ruleset to explicit, minimally-scoped paths rather than broad regular expressions.
Place Anubis behind an ingress layer that only forwards headers from an allow-list of trusted internal hops.

bash

# Example NGINX snippet to strip the untrusted header before it reaches Anubis
location / {
    proxy_set_header X-Original-URI "";
    proxy_pass http://anubis_upstream;
}