EUVD-2026-38083
GHSA-j748-h363-wqj8
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network vector; AC:H for eight simultaneous preconditions; PR:L for authenticated access; scope change as bypass affects the downstream protected application; no integrity or availability impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
3DescriptionCVE.org
Authelia is an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for applications via a web portal. In versions 4.36.0 through 4.39.19, due to lack of canonicalization of domains in very specific edge cases, an access control rule may be skipped when it should match a request. The specific conditions that could lead to a security issue for vulnerability are: 1. The specific target resource of the attack must be using the forwarded authorization integration; 2. The requested domain must have two additional segments compared to a session domain i.e. a.b.example.com is requested, but the session domain is example.com; 3. There access control rules must specify two separate rules which both contain inexact domain matches such as *.b.example.com and *.example.com i.e. wildcards, username matches, group matches; 4. The rules must be in order of most specific domain to least specific domain; 5. The second rule must be more permissive than the first rule; 6. The attacker must specifically request a URL for the more specific domain, with the second part containing one or more capitalized letters i.e. https://a.B.example.com and no other segment with capitalized letters; 7. The integration used must not be the Envoy ExtAuthz integration; and 8. The proxy must not canonicalize the requested host name in the relevant header before sending it to the relevant authorization endpoint. The kind of configuration used to produce this issue and result in a bypass rule being matched has long been highly discouraged. Essentially hosts which should be bypassed entirely should not be secured by having the proxy check them with the authorization handlers. Upgrade to 4.39.20 to receive a patch.
AnalysisAI
Authorization bypass in Authelia 4.36.0-4.39.19 allows an attacker to circumvent access control rules under an extremely narrow set of eight simultaneous conditions involving mixed-case domain requests, wildcard rule ordering, and a non-canonicalizing proxy. The flaw occurs because Go's case-sensitive strings.HasSuffix was used for wildcard domain matching: a crafted URL such as https://a.B.example.com causes the suffix check against *.b.example.com to fail silently, causing the authorization engine to fall through to a more permissive rule (e.g., *.example.com → bypass). No confirmed active exploitation has been identified and no CISA KEV listing exists; the CVSS 4.0 score of 1.3 with E:P reflects that proof-of-concept exploitation is plausible in theory but real-world exposure is extremely limited by the configuration prerequisites.
Technical ContextAI
The root cause is CWE-178 (Improper Handling of Case Sensitivity). Authelia's access control engine in internal/authorization/access_control_domain.go used Go's built-in strings.HasSuffix for suffix-matching wildcard domain rules. Because this function is case-sensitive, a domain segment containing uppercase letters (e.g., B in a.B.example.com) does not match the lowercase pattern b.example.com, causing the first ACL rule to silently fail to match and evaluation to fall through to the next, potentially less restrictive rule. The fix in commit b6d1d60 introduces utils.StringHasSuffixFold, a new utility wrapping strings.EqualFold(s[len(s)-len(suffix):], suffix), and replaces all three case-sensitive strings.HasSuffix calls in the domain matcher (covering wildcard, user-wildcard, and group-wildcard branches). The affected CPE is cpe:2.3:a:authelia:authelia:*:*:*:*:*:*:*:*, versions 4.36.0 through 4.39.19, using the forwarded authorization proxy integration (excluding Envoy ExtAuthz).
RemediationAI
Upgrade to Authelia 4.39.20, which is the vendor-released patch resolving this issue via commit b6d1d60baa02f216fdb19f5dfeaf2e805829508a (replacing case-sensitive strings.HasSuffix with the case-insensitive StringHasSuffixFold utility across all domain-matching branches). See the advisory at https://github.com/authelia/authelia/security/advisories/GHSA-j748-h363-wqj8. If immediate upgrade is not feasible, three specific compensating controls can reduce exposure: (1) configure the upstream proxy to lowercase the Host header before forwarding to Authelia's authorization endpoint - this eliminates the mixed-case domain condition entirely, though it may affect logging fidelity; (2) restructure ACL rules to avoid the discouraged pattern of ordering a more specific restrictive wildcard rule before a less specific bypass rule - eliminate bypass as a fallback to a restrictive rule, since Authelia's own documentation has long flagged this as insecure regardless of this CVE; or (3) replace wildcard domain rules with explicit exact-match domain entries where operationally feasible, which removes the inexact match condition entirely. Rule reordering and restructuring carry the risk of unintended access changes and must be tested thoroughly before deployment.
Authelia is a a single sign-on multi-factor portal for web apps. Rated critical severity (CVSS 10.0), this vulnerability
Authelia is an open-source authentication and authorization server providing 2-factor authentication and single sign-on
Same weakness CWE-178 – Improper Handling of Case Sensitivity
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today