CVE-2026-48794 — authelia
Fix: authelia/authelia@b6d1d60CVE-2026-48794 is a CWE-178 vulnerability in github.com/authelia/authelia/v4. A fix is available for github.com/authelia/authelia/v4 — see the affected versions and patch details below.
Authelia has an Edge Case Access Control Rule Mismatch
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-48794.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
github.com/authelia/authelia/v4Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Impact
CVSSv4 Baseline Score: Low 2.4
CVSSv4 Weighted Score: Low 1.3
The full CVSSv4 Vector for this vulnerability is:
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:H/IR:L/AR:L/MAV:N/MAC:H/MAT:P/MPR:L/MVC:L/MVI:N/MVA:N/MSC:L/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Amber
CVSSv3.1 Baseline Score: Low 3.1
CVSSv3.1 Overall Score: Low 3.4
The full CVSSv3.1 Vector equivalent for this vulnerability is:
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:C/CR:H/IR:L/AR:L/MAV:N/MAC:H/MPR:L/MUI:X/MS:U/MC:L/MI:N/MA:N
The weighted severity rating is a result of no indication this is currently being exploited being available at the time of the publish date, in addition to the fact it's unlikely that it is being exploited currently. The vectors have been picked based on the scenario most likely to exist in real configurations.
In addition to the weighting our assessment considers the fact the configuration scenario required for this vulnerability to be exploited is highly unlikely and an attacker is unlikely in most scenarios to be able to determine if the exploit is available and if it was successful except in rare situations. Though the visibility to the attacker was not reflected in our assessment.
Summary
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.
Details
This attack vector must be executed in a highly specific scenario which we do not believe any user would find themselves in. In an abundance of caution we are issuing this advisory and would appreciate any users who find this configuration report it to us with both the access control section, and sessions section so that we can best advise the community of the actual impact.
The specific conditions that could lead to a security issue for vulnerability are as follows:
- The specific target resource of the attack must be using the forwarded authorization integration.
- The requested domain must have two additional segments compared to a session domain i.e.
a.b.example.comis requested, but the session domain isexample.com. - There access control rules must specify two separate rules which both contain inexact domain matches such as
*.b.example.comand*.example.comi.e. wildcards, username matches, group matches. - The rules must be in order of most specific domain to least specific domain.
- The second rule must be more permissive than the first rule.
- The second rule must also match all criteria of the given request.
- 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.comand no other segment with capitalized letters. - The integration used must not be the Envoy ExtAuthz integration.
- 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.
It should also be noted this has been heavily mitigated due to another bug where the session domain would not match if any part of the configured session domain was capitalized (fixed in https://github.com/authelia/authelia/commit/368631ecc5a9c6bcf2ff5f892ad443b890dd945e, it should be expressly noted this commit does not contain a fix for a CVE). This bug would prevent the request from succeeding in any way. This bug will also be fixed after this vulnerability is fixed, and the bug where session domains would not match has no security impact other than heavily mitigating the access control vulnerability.
Patches
Upgrade to 4.39.20.
Commit: https://github.com/authelia/authelia/commit/b6d1d60baa02f216fdb19f5dfeaf2e805829508a
Workarounds
See the below examples for configurations to avoid.
Examples
1FA Downgrade
The following example could result in a 1FA downgrade.
Request URL: https://a.B.example.com
Configuration:
session:
cookies:
- domain: 'example.com'
authelia_url: 'https://example.com'
access_control:
rules:
- domain: '*.b.example.com'
policy: 'two_factor'
- domain: '*.example.com'
policy: 'one_factor'
Bypass Downgrade
The following example could result in a bypass downgrade. It should be noted that configurations like this have long been discouraged. The domains matching the pattern *.example.com should not be configured to forward authorization requests to Authelia in most situations.
Request URL: https://a.B.example.com
Configuration:
session:
cookies:
- domain: 'example.com'
authelia_url: 'https://example.com'
access_control:
rules:
- domain: '*.b.example.com'
policy: 'two_factor'
- domain: '*.example.com'
policy: 'bypass'
Unaffected Scenario
The following configuration is unaffected regardless of the request.
session:
cookies:
- domain: 'example.com'
authelia_url: 'https://example.com'
access_control:
rules:
- domain: 'b.example.com'
policy: 'two_factor'
- domain: '*.example.com'
policy: 'one_factor'
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/authelia/authelia/v4 | ≥ 4.36.0&&< 4.39.20 | 4.39.20go get github.com/authelia/authelia/v4@v4.39.20 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/authelia/authelia/v4, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/authelia/authelia/v4 to 4.39.20 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-48794 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is CVE-2026-48794 in your dependencies?
Find it across Go, including transitive dependencies.