### 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: 1. The first factor login endpoint (`/api/firstfactor`) is **not** affected 2. The LDAP authentication backend must be in use. 3. If the underlying database is case insensitive (as it should be with the collation we use for MySQL) it is **not** affected 4. Administrators using the recently added IP regulation mode are **not** affected 5. Administrators using a third-party tool such as CrowdSec or fail2ban are **not** affected 6. 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 ```yaml server: endpoints: authz: forward-auth: implementation: 'ForwardAuth' authn_strategies: - name: 'CookieSession' ``` #### nginx ```yaml server: endpoints: authz: auth-request: implementation: 'AuthRequest' authn_strategies: - name: 'CookieSession' ``` #### Envoy ```yaml server: endpoints: authz: ext-authz: implementation: 'ExtAuthz' authn_strategies: - name: 'CookieSession' ``` ### References N/A
### 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: 1. The first factor login endpoint (`/api/firstfactor`) is **not** affected 2. The LDAP authentication backend must be in use. 3. If the underlying database is case insensitive (as it should be with the collation we use for MySQL) it is **not** affected 4. Administrators using the recently added IP regulation mode are **not** affected 5. Administrators using a third-party tool such as CrowdSec or fail2ban are **not** affected 6. 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 ```yaml server: endpoints: authz: forward-auth: implementation: 'ForwardAuth' authn_strategies: - name: 'CookieSession' ``` #### nginx ```yaml server: endpoints: authz: auth-request: implementation: 'AuthRequest' authn_strategies: - name: 'CookieSession' ``` #### Envoy ```yaml server: endpoints: authz: ext-authz: implementation: 'ExtAuthz' authn_strategies: - name: 'CookieSession' ``` ### References N/A
Update github.com/authelia/authelia/v4 to 4.39.20 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanAuthelia Missing Username Canonicalization in Basic Auth (LDAP) affects github.com/authelia/authelia/v4 (go). Severity is low. ### 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: 1. The first factor login endpoint (`/api/firstfactor`) is **not** affected 2. The LDAP authentication backend must be in use. 3. If the underlying database is case insensitive (as it should be with the collation we use for MySQL) it is **not** affected 4. Administrators using the recently added IP regulation mode are **not** affected 5. Administrators using a third-party tool such as CrowdSec or fail2ban are **not** affected 6. 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 ```yaml server: endpoints: authz: forward-auth: implementation: 'ForwardAuth' authn_strategies: - name: 'CookieSession' ``` #### nginx ```yaml server: endpoints: authz: auth-request: implementation: 'AuthRequest' authn_strategies: - name: 'CookieSession' ``` #### Envoy ```yaml server: endpoints: authz: ext-authz: implementation: 'ExtAuthz' authn_strategies: - name: 'CookieSession' ``` ### References N/A
AI coding agents often install or upgrade packages automatically in go. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/authelia/authelia/v4go | >=4.38.0,<=4.39.19 | 4.39.20 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/authelia/authelia/v4 to 4.39.20 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanAuthelia Missing Username Canonicalization in Basic Auth (LDAP) affects github.com/authelia/authelia/v4 (go). Severity is low. ### 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: 1. The first factor login endpoint (`/api/firstfactor`) is **not** affected 2. The LDAP authentication backend must be in use. 3. If the underlying database is case insensitive (as it should be with the collation we use for MySQL) it is **not** affected 4. Administrators using the recently added IP regulation mode are **not** affected 5. Administrators using a third-party tool such as CrowdSec or fail2ban are **not** affected 6. 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 ```yaml server: endpoints: authz: forward-auth: implementation: 'ForwardAuth' authn_strategies: - name: 'CookieSession' ``` #### nginx ```yaml server: endpoints: authz: auth-request: implementation: 'AuthRequest' authn_strategies: - name: 'CookieSession' ``` #### Envoy ```yaml server: endpoints: authz: ext-authz: implementation: 'ExtAuthz' authn_strategies: - name: 'CookieSession' ``` ### References N/A
AI coding agents often install or upgrade packages automatically in go. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/authelia/authelia/v4go | >=4.38.0,<=4.39.19 | 4.39.20 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard