GHSA-hjj4-hfjm-fmrj
Authelia Missing Username Canonicalization in Basic Auth (LDAP)
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
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: Moderate 6.3
CVSSv4 Weighted Score: Low 2.9
The full CVSSv4 Vector for this vulnerability is:
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/CR:L/IR:L/AR:L/MAV:N/MAC:H/MAT:N/MPR:N/MUI:N/MVC:L/MVI:N/MVA:N/MSC:N/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Green
CVSSv3.1 Baseline Score: Low 3.7
CVSSv3.1 Overall Score: Medium 4.0
The full CVSSv3.1 Vector equivalent for this vulnerability is:
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:X/CR:H/IR:L/AR:L/MAV:N/MAC:H/MPR:N/MUI:N/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.
Due to lack of canonicalization of the basic auth username, the effectiveness of the brute force mechanism when using basic auth is partially degraded.
Most passwords of reasonable length are unlikely to have a meaningful effect due to the fact there is no clear feedback to an attacker that is attempting to exploit this, thus their brute force attempts are significantly more likely to miss a valid password than they are identify a valid one.
Details
When a user authenticates via Basic Auth (i.e via the Authorization header with the Basic scheme) on the authz verification endpoint, Authelia takes the username directly from the Authorization header and passes it as is to the regulation system for ban checking and attempt recording.
LDAP treats usernames case insensitively : john, John, and JOHN all bind as the same user. But the regulation SQL queries treat the lookup of these values in certain scenarios as case sensitive. This allows each variation of a usernames case to have its own ban bucket.
Notable conditions or unaffected configurations:
- The first factor login endpoint (
/api/firstfactor) is not affected - The LDAP authentication backend must be in use.
- If the underlying database is case insensitive (as it should be with the collation we use for MySQL) it is not affected
- Administrators using the recently added IP regulation mode are not affected
- Administrators using a third-party tool such as CrowdSec or fail2ban are not affected
- Administrators that have disabled basic auth are not affected
Patches
Upgrade to 4.39.20.
Commit: https://github.com/authelia/authelia/commit/b8985b57b70acdff8f204ed426ff619e763461ad
Workarounds
Explicitly disable the basic auth mechanism.
Caddy, HAProxy, and Traefik
server:
endpoints:
authz:
forward-auth:
implementation: 'ForwardAuth'
authn_strategies:
- name: 'CookieSession'
nginx
server:
endpoints:
authz:
auth-request:
implementation: 'AuthRequest'
authn_strategies:
- name: 'CookieSession'
Envoy
server:
endpoints:
authz:
ext-authz:
implementation: 'ExtAuthz'
authn_strategies:
- name: 'CookieSession'
References
N/A
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/authelia/authelia/v4 | ≥ 4.38.0&&< 4.39.20 | 4.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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-hjj4-hfjm-fmrj is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-hjj4-hfjm-fmrj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-hjj4-hfjm-fmrj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-hjj4-hfjm-fmrj in your dependencies?
O3 detects GHSA-hjj4-hfjm-fmrj across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.