Skip to main content

CVE-2026-33525

LOW
Cross-site Scripting (XSS) (CWE-79)
2026-03-24 https://github.com/authelia/authelia
0.5
CVSS 4.0 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY
0.5 LOW
CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N/E:U/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

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N/E:U/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
Attack Vector
Adjacent
Attack Complexity
High
Privileges Required
None
User Interaction
P
Scope
X

Lifecycle Timeline

3
Patch released
Mar 31, 2026 - 21:13 nvd
Patch available
Analysis Generated
Mar 24, 2026 - 16:45 vuln.today
CVE Published
Mar 24, 2026 - 16:33 nvd
LOW 0.5

DescriptionGitHub Advisory

Impact

Official Weighted Severity Rating: Low

This exploit is very unlikely to be the case for most users as it requires configuration of the Content Security Policy template value. Below represents a safe value, _any other value_ other than unconfigured should be _very carefully evaluated_ regardless of the fix.

yaml
server:
  headers:
    csp_template: ''
env
AUTHELIA_SERVER_HEADERS_CSP_TEMPLATE=

Provided the following conditions are met:

  1. The Content Security Policy:
  2. Has been disabled or modified from the entirely safe default value; and
  3. Has been completely disabled by the Administrator by omitting the header explicitly at the proxy (worst practice); or
  4. Has been effectively disabled by modifying script-src allowing unsafe inline scripts rather than using hashes AND effectively disabled by modifying connect-src allowing connections to arbitrary websites.
  5. Authelia is being hosted on a domain that has other applications that can write to the cookie for the Authelia domain.
  6. One of the other applications noted in 2 has an vulnerability that can be exploited to execute malicious javascript with similar requirements to 1.
  7. The attacker can exploit the javascript in 3 to delete the existing language cookie scoped to the fully qualified domain name of Authelia with the same site value of strict (which is not possible in most scenarios unless the application in 3 has the exact same domain or a subdomain of the Authelia domain).
  8. The attacker can exploit the javascript in 3 to write a new language cookie scoped for a domain that Authelia is sent cookies for.
  9. The attacker can get a user to meet the conditions required to execute the javascript in 3.
  10. You are running Authelia 4.39.15.

An attacker may potentially be able to inject javascript into the Authelia login page. Unless both the script-src and connect-src directives have been modified it's almost impossible for this to have a meaningful impact. However if both of these are and they are done so without consideration to their potential impact; there is a are situations where this vulnerability could be exploited.

This is caused to the lack of neutralization of the langauge cookie value when rendering the HTML template.

This vulnerability is likely difficult to discover though fingerprinting due to the way Authelia is designed but it should not be considered impossible. The additional requirement to identify the secondary application is however likely to be significantly harder to identify along side this, but also likely easier to fingerprint.

Patches

Upgrade to 4.39.16 or Downgrade to 4.39.14.

Proof of Concept

No current proof of concept exists that does not require manual manipulation of the browser which is effectively a local attack where all privileges have been compromised without the need for this attack vector (i.e. installation of userscripts or a browser plugin which would be able to compromise any website or web app). There is a decent chance one will exist or certain conditions exist that could lead to the vulnerability being exploitable.

Discovery of this flaw has prompted an deliberate evaluation of any other potential flaws similar to this which did not yield any results, as well as a deliberate evaluation of best practices in this area which has resulted in a minor tweak to hardening measures. These additional hardening measures should not have any effect (explicit definition of the script-src and connect-src policies, which are the same value as default was previously), but it should theoretically prevent an accidental change in the future degrading the existing security layers we implement.

Workarounds

The overwhelming majority of installations will not be affected and no workarounds are necessary. The default value for the Content Security Policy makes exploiting this weakness completely impossible. It's only possible via the deliberate removal of the Content Security Policy or deliberate inclusion of clearly noted unsafe policies.

Use the default Content Security Policy

The default Content Security Policy is completely secure and prevents any third party javascript the browser evaluates against it.

yaml
server:
  headers:
    csp_template: ''

Using a custom Content Security Policy is a very advanced choice that requires specialist knowledge. The use of unsafe-inline, unsafe-eval, unsafe-hashes, etc. are particularly problematic as they effectively allow arbitrary script execution (if a security policy includes an option that says unsafe it's probably a good indication you should not use it).

Upgrade or Downgrade

Both the next version and previous version of Authelia do not have this bug.

AnalysisAI

A stored cross-site scripting (XSS) vulnerability exists in Authelia version 4.39.15 due to improper neutralization of the language cookie value when rendering HTML templates. This vulnerability only affects users who have deliberately disabled or modified the default Content Security Policy with unsafe directives (such as unsafe-inline scripts or arbitrary domain connections); default installations are completely protected. An attacker could potentially inject malicious JavaScript into the Authelia login page if multiple preconditions are met, including a secondary application vulnerability on the same domain, CSP misconfiguration, and the ability to manipulate cookies.

Technical ContextAI

The vulnerability stems from CWE-79 (Improper Neutralization of Input During Web Page Generation), a classic XSS flaw. Authelia (Go package github.com/authelia/authelia) fails to sanitize or escape the language cookie value before inserting it into HTML template output. This cookie is typically user-controlled or can be manipulated through other means. The attack only succeeds when Content Security Policy headers, which normally serve as the primary defense against XSS in modern applications, have been explicitly weakened by administrators through configuration of the csp_template field to include unsafe-inline or unsafe-eval directives in script-src, or overly permissive connect-src policies. The default empty csp_template value applies a strict CSP that prevents all inline script execution, making the vulnerability unexploitable in standard deployments.

RemediationAI

Immediately upgrade Authelia to version 4.39.16 or downgrade to 4.39.14 (see https://github.com/authelia/authelia/security/advisories/GHSA-gmfg-3v4q-9qr4). For all users, ensure the default Content Security Policy configuration is active by leaving the csp_template field empty or unconfigured in your configuration file (server.headers.csp_template should be unset or set to an empty string). If custom CSP policies have been implemented, audit them immediately to remove any unsafe directives such as unsafe-inline, unsafe-eval, unsafe-hashes, or overly permissive domain patterns in script-src and connect-src directives. The default CSP is completely secure and should only be modified by administrators with specialized security knowledge.

Share

CVE-2026-33525 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy