Anubis
CVE-2026-62314
MEDIUM
Severity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
Network exploitable via single HTTP header (AV:N/AC:L/PR:N/UI:N); scope changes because bypass exposes upstream systems beyond Anubis; confidentiality limited to indirect upstream access (C:L), no integrity or availability impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
Anubis is a Web AI Firewall Utility that challenges users' connections in order to protect upstream resources from scraper bots. From 1.22.0 until 1.26.0-pre1, lib/policy/checker.go PathChecker.Check() trusted the client-controlled X-Original-URI header before matching r.URL.Path, allowing an HTTP client to match default data/common/keep-internet-working.yaml ALLOW rules such as ^/\.well-known/.*$ and bypass the Anubis challenge. This issue is fixed in version 1.26.0-pre1.
AnalysisAI
Challenge bypass in Anubis Web AI Firewall (versions 1.22.0 through pre-1.26.0-pre1) allows unauthenticated remote HTTP clients to circumvent bot-challenge enforcement by supplying a crafted X-Original-URI header. PathChecker.Check() in lib/policy/checker.go unconditionally trusted this client-controlled header over the actual request path, enabling any client to match default ALLOW rules (e.g., ^/\.well-known/.*$) and reach upstream resources without completing the Anubis challenge. No active exploitation confirmed (not in CISA KEV) and no public exploit code identified at time of analysis, but the bypass is trivially reproducible with a single HTTP header manipulation.
Technical ContextAI
Anubis is an open-source Go-based reverse-proxy firewall (CPE: cpe:2.3:a:techarohq:anubis:*:*:*:*:*:*:*:*) designed to intercept and challenge HTTP clients suspected of being scrapers or bots before passing traffic to upstream services. It supports two deployment modes: direct proxy and subrequest mode (used by nginx auth_request and Traefik forwardAuth middleware). In subrequest mode, the actual user-requested path is communicated to Anubis via the X-Original-URI (nginx) or X-Forwarded-Uri (Traefik) headers. The root cause (CWE-284: Improper Access Control) is that PathChecker.Check() in lib/policy/checker.go read X-Original-URI unconditionally - regardless of whether Anubis was actually operating in subrequest mode - and used that header value to evaluate path-matching ALLOW rules defined in data/common/keep-internet-working.yaml. An attacker could therefore set X-Original-URI to a well-known path (e.g., /.well-known/acme-challenge/x) and have it matched against ALLOW rules, bypassing the challenge entirely. The fix introduced a subRequestMode flag that gates header trust, ensuring X-Original-URI and X-Forwarded-Uri are only consulted when subrequest mode is explicitly configured.
RemediationAI
Upgrade Anubis to version 1.26.0-pre1 or later, available at https://github.com/TecharoHQ/anubis/releases/tag/v1.26.0-pre1. The fix (commit 276b537776b281b1c4e01421435bc03ade3d8fc4, PR #1630) introduces a subRequestMode flag that restricts trust of X-Original-URI and X-Forwarded-Uri headers to explicitly configured subrequest deployments only. If immediate upgrade is not feasible, a compensating control is to configure the upstream proxy (nginx, Traefik) to strip or rewrite the X-Original-URI and X-Forwarded-Uri headers on inbound requests before they reach Anubis, preventing clients from injecting arbitrary values; note that this workaround will break legitimate subrequest-mode path matching until the patch is applied. Alternatively, operators can remove or narrow ALLOW rules in data/common/keep-internet-working.yaml to reduce the set of paths that can be targeted, though this may interfere with ACME certificate validation and other legitimate well-known path traffic.
Same weakness CWE-284 – Improper Access Control
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: ModerateShare
External POC / Exploit Code
Leaving vuln.today