Skip to content

← Public intelligence

PyPI package

jinja2

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 5.4PyPIAmendedPublished

    Jinja2 vulnerable to sandbox breakout through attr filter selecting format method

    CVE-2025-27516 · GHSA-cpwx-vrp4-4pq7

    Affected
    • PyPI jinja2 <= 3.1.5
    Fixed in
    3.1.6· Vendor fix available
    Issue
    An oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup.

    Recommended action: Upgrade to 3.1.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  2. Medium, CVSS 5.4PyPIAmendedPublished

    Jinja has a sandbox breakout through indirect reference to format method

    CVE-2024-56326 · GHSA-q2x7-8rv6-6q7h

    Affected
    • PyPI jinja2 <= 3.1.4
    Fixed in
    3.1.5· Vendor fix available
    Issue
    An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

    Recommended action: Upgrade to 3.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  3. Medium, CVSS 5.4PyPIAmendedPublished

    Jinja has a sandbox breakout through malicious filenames

    CVE-2024-56201 · GHSA-gmj6-6f8f-6699

    Affected
    • PyPI jinja2 >= 3.0.0, <= 3.1.4
    Fixed in
    3.1.5· Vendor fix available
    Issue
    A bug in the Jinja compiler allows an attacker that controls both the content and filename of a template to execute arbitrary Python code, regardless of if Jinja's sandbox is used. To exploit the vulnerability, an attacker needs to control both the filename and the contents of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates where the template author can also choose the template filename.

    Recommended action: Upgrade to 3.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  4. Medium, CVSS 5.4PyPIAmendedPublished

    Jinja vulnerable to HTML attribute injection when passing user input as keys to xmlattr filter

    CVE-2024-34064 · GHSA-h75v-3vvj-5mfj

    Affected
    • PyPI jinja2 < 3.1.4
    Fixed in
    3.1.4· Vendor fix available
    Issue
    The xmlattr filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, /, , or =, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for the previous GHSA-h5c8-rqwp-cp95 CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the xmlattr filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting values as user input continues to be safe.

    Recommended action: Upgrade to 3.1.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  5. Medium, CVSS 5.4PyPIAmendedPublished

    Jinja vulnerable to HTML attribute injection when passing user input as keys to xmlattr filter

    CVE-2024-22195 · GHSA-h5c8-rqwp-cp95

    Affected
    • PyPI jinja2 < 3.1.3
    Fixed in
    3.1.3· Vendor fix available
    Issue
    The xmlattr filter in affected versions of Jinja accepts keys containing spaces. XML/HTML attributes cannot contain spaces, as each would then be interpreted as a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. Note that accepting keys as user input is not common or a particularly intended use case of the xmlattr filter, and an application doing so should already be verifying what keys are provided regardless of this fix.

    Recommended action: Upgrade to 3.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  6. Medium, CVSS 6.9PyPIAmendedPublished

    Insecure Temporary File in Jinja2

    CVE-2014-0012 · GHSA-fqh9-2qgg-h84h

    Affected
    • PyPI jinja2 < 2.7.2
    Fixed in
    2.7.2· Vendor fix available
    Issue
    FileSystemBytecodeCache in Jinja2 prior to version 2.7.2 does not properly create temporary directories, which allows local users to gain privileges by pre-creating a temporary directory with a user's uid. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-1402.

    Recommended action: Upgrade to 2.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  7. High, CVSS 8.6PyPIAmendedPublished

    Incorrect Privilege Assignment in Jinja2

    CVE-2014-1402 · GHSA-8r7q-cvjq-x353

    Affected
    • PyPI jinja2 < 2.7.2
    Fixed in
    2.7.2· Vendor fix available
    Issue
    The default configuration for bccache.FileSystemBytecodeCache in Jinja2 before 2.7.2 does not properly create temporary files, which allows local users to gain privileges via a crafted .cache file with a name starting with jinja2 in /tmp.

    Recommended action: Upgrade to 2.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  8. Medium, CVSS 6.9PyPIAmendedPublished

    Regular Expression Denial of Service (ReDoS) in Jinja2

    CVE-2020-28493 · GHSA-g3rq-g295-4j3m

    Affected
    • PyPI jinja2 < 2.11.3
    Fixed in
    2.11.3· Vendor fix available
    Issue
    This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDOS vulnerability of the regex is mainly due to the sub-pattern [a-zA-Z0-9.-]+.[a-zA-Z0-9.-]+ This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

    Recommended action: Upgrade to 2.11.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  9. High, CVSS 7.7PyPIAmendedPublished

    Jinja2 sandbox escape via string formatting

    CVE-2019-10906 · GHSA-462w-v97r-4m45

    Affected
    • PyPI jinja2 < 2.10.1
    Fixed in
    2.10.1· Vendor fix available
    Issue
    In Pallets Jinja before 2.10.1, str.formatmap allows a sandbox escape. The sandbox is used to restrict what code can be evaluated when rendering untrusted, user-provided templates. Due to the way string formatting works in Python, the str.formatmap method could be used to escape the sandbox. This issue was previously addressed for the str.format method in Jinja 2.8.1, which discusses the issue in detail. However, the less-common str.formatmap method was overlooked. This release applies the same sandboxing to both methods. If you cannot upgrade Jinja, you can override the issafeattribute method on the sandbox and explicitly disallow the formatmap method on string objects.

    Recommended action: Upgrade to 2.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  10. High, CVSS 7.7PyPIAmendedPublished

    Jinja2 sandbox escape vulnerability

    CVE-2016-10745 · GHSA-hj2j-77xm-mc5v

    Affected
    • PyPI jinja2 < 2.8.1
    Fixed in
    2.8.1· Vendor fix available
    Issue
    In Pallets Jinja before 2.8.1, str.format allows a sandbox escape.

    Recommended action: Upgrade to 2.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →