{"id":"CVE-2026-62314","aliases":["GHSA-6wcg-mqvh-fcvg"],"title":"Anubis: Policy bypass via client controlled X-Original-URI header","summary":"Anubis: Policy bypass via client controlled X-Original-URI header","severity":"medium","cvss":5.8,"cwe":["CWE-284"],"vendor":"TecharoHQ","product":"github.com/TecharoHQ/anubis","ecosystem":"go","affected":["github.com/TecharoHQ/anubis >= 1.22.0, < 1.26.0"],"patched":["github.com/TecharoHQ/anubis 1.26.0"],"published":"2026-10-02","updated":"2026-10-02","sourceUpdated":"2026-10-02T18:22:09Z","source":"GHSA","sourceUrl":"https://github.com/advisories/GHSA-6wcg-mqvh-fcvg","references":[{"url":"https://github.com/TecharoHQ/anubis/security/advisories/GHSA-6wcg-mqvh-fcvg"},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-62314"},{"url":"https://github.com/TecharoHQ/anubis/pull/1630"},{"url":"https://github.com/TecharoHQ/anubis/commit/276b537776b281b1c4e01421435bc03ade3d8fc4"},{"url":"https://github.com/TecharoHQ/anubis/releases/tag/v1.26.0-pre1"},{"url":"https://github.com/advisories/GHSA-6wcg-mqvh-fcvg"}],"tags":["ghsa","go"],"epss":0.00464,"epssPercentile":0.37933,"ingestedAt":"2026-10-02T18:25:05.832Z","slug":"CVE-2026-62314","body":"## Overview\n\nAny HTTP client can bypass Anubis bot protection on the default configuration by adding a single request header. No challenge needs to be solved.\nAffected versions: v1.22.0 through v1.25.0 (introduced in commit d1d631a, PR #1015)\n\nThe root cause is in `lib/policy/checker.go`, `PathChecker.Check()`:\n```go\nfunc (pc *PathChecker) Check(r *http.Request) (bool, error) {\n    originalUrl := r.Header.Get(\"X-Original-URI\")\n    if originalUrl != \"\" {\n        if pc.regexp.MatchString(originalUrl) {\n            return true, nil\n        }\n    }\n    if pc.regexp.MatchString(r.URL.Path) {\n        return true, nil\n    }\n    return false, nil\n}\n```\n\nThe header value comes directly from the client request. The middleware chain never strips it. In reverse proxy mode an attacker fully controls it.\nThe default policy imports `data/common/keep-internet-working.yaml`, which contains path-only ALLOW rules with no other conditions:\n\n```yaml\n- name: well-known\n  path_regex: ^/\\.well-known/.*$\n  action: ALLOW\n```\n\nWhen `X-Original-URI` matches one of those regexes, the rule fires as ALLOW and the request is forwarded upstream without any challenge or JWT check.\n\n\n# Proof of concept\n\nNormal request, gets challenged:\n```\ncurl -s https://anubis.techaro.lol/ | grep -o \"<title>.*</title>\"\n```\n\nBypass, gets upstream content:\n```\ncurl -s -H \"X-Original-URI: /.well-known/x\" https://anubis.techaro.lol/ | grep -o \"<title>.*</title>\"\n```\n\nThe first command returns the Anubis challenge page title. The second returns the real site title directly, with no cookie set and no challenge issued. Verified live against anubis.techaro.lol.\n\n# Suggested fix\nThe fix should probably be to strip the header from incoming client requests in the middleware chain before policy evaluation. In `auth_request` mode the header is set by the proxy after Anubis processes the middleware, so stripping it at ingress does not break that deployment mode.\n\n## Affected packages\n\n- `github.com/TecharoHQ/anubis >= 1.22.0, < 1.26.0`\n\n## Remediation\n\nUpgrade to a patched release:\n\n- `github.com/TecharoHQ/anubis 1.26.0`","depth":"sunlit","depthScore":32,"depthScoreParts":{"impact":31.9,"likelihood":0.1,"exploitation":0,"ransomware":0},"changes":[]}