Vulnerability-Lookup

GHSA-WJV6-JCFJ-MF9R

Vulnerability from github – Published: 2026-07-28 21:50 – Updated: 2026-07-28 21:50

Summary

`datamodel-code-generator` vulnerable to code injection via unescaped carriage return in `--extra-template-data` `comment` field

Details

Summary

datamodel-code-generator is vulnerable to code injection when a developer passes an --extra-template-data file whose comment value contains a literal \r (carriage return). The comment variable is rendered into a Python # comment in six built-in templates with no line-terminator escaping. Python's tokenizer treats a bare CR as a physical-line terminator (see Python language reference — Physical lines), so the comment ends at the \r and the text after it is parsed as Python, including, when the CR is followed by suitable indentation, as a statement within the class body that follows on the next template line.

Details

The vulnerable templates each contain # {{ comment }} with no escaping:

src/datamodel_code_generator/model/template/TypeAliasAnnotation.jinja2:12 and :19
src/datamodel_code_generator/model/template/TypeAliasType.jinja2:12 and :19
src/datamodel_code_generator/model/template/TypeStatement.jinja2:12 and :19
src/datamodel_code_generator/model/template/pydantic_v2/BaseModel.jinja2:4
src/datamodel_code_generator/model/template/pydantic_v2/RootModel.jinja2:19
src/datamodel_code_generator/model/template/pydantic_v2/RootModelTypeAlias.jinja2:13

The pydantic_v2/BaseModel.jinja2:4 site is representative:

class {{ class_name }}({{ base_class }}):{% if comment is defined %}  # {{ comment }}{% endif %}

When the developer-supplied extras file populates comment for a model, the value reaches the template via DataModel.extra_template_data (set in src/datamodel_code_generator/model/base.py:736-742) and Jinja2 interpolates it raw. None of the templates use comment_safe, escape_docstring, or any other line-terminator filter.

PoC

Complete self contained POC is available at my secret gist: https://gist.github.com/thegr1ffyn/8ad6b8cb3cc2be9d3a0144aeb6896a3f

Impact

Who's affected: any developer or CI pipeline that runs datamodel-codegen --extra-template-data <file> where the extras file is influenced by attacker-controlled input. Realistic scenarios include:
Extras file generated from a third-party schema-annotation system.
Extras file vendored from an upstream repository.
Extras file produced by a script that merges multiple comment sources.
Build pipelines that template the extras file from environment variables, ticket descriptions, or commit metadata.
What it gains: arbitrary Python code execution in the importer's process at import time.
What it does NOT need: the schema itself can be entirely benign; only the extras file needs to contain the malicious comment.
What does block it: not passing --extra-template-data, or rejecting extras files whose comment values contain \r, \x0b, or \x0c before invocation.

Resolution

The fix normalizes comment values from built-in --extra-template-data before template rendering. Inline comments now convert CRLF, bare CR, vertical tab, and form feed into LF and prefix continuation lines with #, so attacker-controlled text stays inside the generated Python comment block.

Remediation

Upgrade to datamodel-code-generator 0.60.2 or later.

This issue affects datamodel-code-generator versions >= 0.14.1, <= 0.60.1 and is fixed in 0.60.2.

Submitted by: Hamza Haroon (thegr1ffyn)

Severity

7.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.60.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "datamodel-code-generator"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.14.1"
            },
            {
              "fixed": "0.60.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54654"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T21:50:09Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`datamodel-code-generator` is vulnerable to code injection when a developer passes an `--extra-template-data` file whose `comment` value contains a literal `\\r` (carriage return). The `comment` variable is rendered into a Python `#` comment in six built-in templates with **no** line-terminator escaping. Python\u0027s tokenizer treats a bare CR as a physical-line terminator (see [Python language reference \u2014 Physical lines](https://docs.python.org/3/reference/lexical_analysis.html#physical-lines)), so the comment ends at the `\\r` and the text after it is parsed as Python, including, when the CR is followed by suitable indentation, as a statement within the class body that follows on the next template line.\n\n### Details\n\nThe vulnerable templates each contain `# {{ comment }}` with no escaping:\n\n- `src/datamodel_code_generator/model/template/TypeAliasAnnotation.jinja2:12` and `:19`\n- `src/datamodel_code_generator/model/template/TypeAliasType.jinja2:12` and `:19`\n- `src/datamodel_code_generator/model/template/TypeStatement.jinja2:12` and `:19`\n- `src/datamodel_code_generator/model/template/pydantic_v2/BaseModel.jinja2:4`\n- `src/datamodel_code_generator/model/template/pydantic_v2/RootModel.jinja2:19`\n- `src/datamodel_code_generator/model/template/pydantic_v2/RootModelTypeAlias.jinja2:13`\n\nThe `pydantic_v2/BaseModel.jinja2:4` site is representative:\n\n```jinja2\nclass {{ class_name }}({{ base_class }}):{% if comment is defined %}  # {{ comment }}{% endif %}\n```\n\nWhen the developer-supplied extras file populates `comment` for a model, the value reaches the template via `DataModel.extra_template_data` (set in `src/datamodel_code_generator/model/base.py:736-742`) and Jinja2 interpolates it raw. None of the templates use `comment_safe`, `escape_docstring`, or any other line-terminator filter.\n\n### PoC\nComplete self contained POC is available at my secret gist: https://gist.github.com/thegr1ffyn/8ad6b8cb3cc2be9d3a0144aeb6896a3f\n\n### Impact\n\n- **Who\u0027s affected**: any developer or CI pipeline that runs `datamodel-codegen --extra-template-data \u003cfile\u003e` where the extras file is influenced by attacker-controlled input. Realistic scenarios include:\n  - Extras file generated from a third-party schema-annotation system.\n  - Extras file vendored from an upstream repository.\n  - Extras file produced by a script that merges multiple `comment` sources.\n  - Build pipelines that template the extras file from environment variables, ticket descriptions, or commit metadata.\n- **What it gains**: arbitrary Python code execution in the importer\u0027s process at `import` time.\n- **What it does NOT need**: the schema itself can be entirely benign; only the extras file needs to contain the malicious `comment`.\n- **What does block it**: not passing `--extra-template-data`, or rejecting extras files whose `comment` values contain `\\r`, `\\x0b`, or `\\x0c` before invocation.\n\n### Resolution\n\nThe fix normalizes `comment` values from built-in `--extra-template-data` before template rendering. Inline comments now convert CRLF, bare CR, vertical tab, and form feed into LF and prefix continuation lines with `# `, so attacker-controlled text stays inside the generated Python comment block.\n\n### Remediation\n\nUpgrade to `datamodel-code-generator` `0.60.2` or later.\n\nThis issue affects `datamodel-code-generator` versions `\u003e= 0.14.1, \u003c= 0.60.1` and is fixed in `0.60.2`.\n\nSubmitted by: Hamza Haroon (thegr1ffyn)",
  "id": "GHSA-wjv6-jcfj-mf9r",
  "modified": "2026-07-28T21:50:09Z",
  "published": "2026-07-28T21:50:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/security/advisories/GHSA-wjv6-jcfj-mf9r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/commit/b73abb5cd703a50471b8950bbd3bd0b82ad71de7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/koxudaxi/datamodel-code-generator"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/releases/tag/0.60.2"
    }
  ],
  "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": "`datamodel-code-generator` vulnerable to code injection via unescaped carriage return in `--extra-template-data` `comment` field"
}

GHSA-WJW6-95H5-4JPX

Vulnerability from github – Published: 2025-06-10 20:17 – Updated: 2026-06-08 20:18

Summary

Nautobot vulnerable to secrets exposure and data manipulation through Jinja2 templating

Details

Impact

What kind of vulnerability is it? Who is impacted?

All users of Nautobot versions prior to 2.4.10 or prior to 1.6.32 are potentially affected.

Due to insufficient security configuration of the Jinja2 templating feature used in computed fields, custom links, etc. in Nautobot:

A malicious user could configure this feature set in ways that could expose the value of Secrets defined in Nautobot when the templated content is rendered.
A malicious user could configure this feature set in ways that could call Python APIs to modify data within Nautobot when the templated content is rendered, bypassing the object permissions assigned to the viewing user.

Patches

Has the problem been patched? What versions should users upgrade to?

Nautobot versions 1.6.32 and 2.4.10 will include fixes for the vulnerability.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

The vulnerability can be partially mitigated by configuring object permissions appropriately to limit the below actions to only trusted users:

extras.add_secret
extras.change_secret
extras.view_secret
extras.add_computedfield
extras.change_computedfield
extras.add_customlink
extras.change_customlink
extras.add_jobbutton
extras.change_jobbutton

References

Are there any links users can visit to find out more?

https://jinja.palletsprojects.com/en/stable/sandbox/
https://docs.djangoproject.com/en/4.2/ref/templates/api/#alters-data-description
https://github.com/nautobot/nautobot/pull/7417
https://github.com/nautobot/nautobot/pull/7429

Severity

6.0 (Medium)


                  
                    CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:L/SI:L/SA:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nautobot"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.32"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nautobot"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-49142"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-06-10T20:17:15Z",
    "nvd_published_at": "2025-06-10T16:15:42Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nAll users of Nautobot versions prior to 2.4.10 or prior to 1.6.32 are potentially affected.\n\nDue to insufficient security configuration of the Jinja2 templating feature used in computed fields, custom links, etc. in Nautobot:\n\n1. A malicious user could configure this feature set in ways that could expose the value of Secrets defined in Nautobot when the templated content is rendered.\n2. A malicious user could configure this feature set in ways that could call Python APIs to modify data within Nautobot when the templated content is rendered, bypassing the object permissions assigned to the viewing user.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nNautobot versions 1.6.32 and 2.4.10 will include fixes for the vulnerability.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nThe vulnerability can be partially mitigated by configuring object permissions appropriately to limit the below actions to only trusted users:\n\n- `extras.add_secret`\n- `extras.change_secret`\n- `extras.view_secret`\n- `extras.add_computedfield`\n- `extras.change_computedfield`\n- `extras.add_customlink`\n- `extras.change_customlink`\n- `extras.add_jobbutton`\n- `extras.change_jobbutton`\n\n### References\n_Are there any links users can visit to find out more?_\n\n- https://jinja.palletsprojects.com/en/stable/sandbox/\n- https://docs.djangoproject.com/en/4.2/ref/templates/api/#alters-data-description\n- https://github.com/nautobot/nautobot/pull/7417\n- https://github.com/nautobot/nautobot/pull/7429",
  "id": "GHSA-wjw6-95h5-4jpx",
  "modified": "2026-06-08T20:18:22Z",
  "published": "2025-06-10T20:17:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nautobot/nautobot/security/advisories/GHSA-wjw6-95h5-4jpx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49142"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nautobot/nautobot/pull/7417"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nautobot/nautobot/pull/7429"
    },
    {
      "type": "WEB",
      "url": "https://docs.djangoproject.com/en/4.2/ref/templates/api/#alters-data-description"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nautobot/nautobot"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/jinja2/PYSEC-2025-74.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/nautobot/PYSEC-2025-79.yaml"
    },
    {
      "type": "WEB",
      "url": "https://jinja.palletsprojects.com/en/stable/sandbox"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:L/SI:L/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Nautobot vulnerable to secrets exposure and data manipulation through Jinja2 templating"
}

GHSA-WQC2-GWGP-9P7W

Vulnerability from github – Published: 2024-09-27 18:32 – Updated: 2024-09-27 21:31

Details

A Client-side Template Injection (CSTI) vulnerability in Webkul Krayin CRM 1.3.0 allows remote attackers to execute arbitrary client-side template code by injecting a malicious payload during the lead creation process. This can lead to privilege escalation when the payload is executed, granting the attacker elevated permissions within the CRM system.

Severity

8.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-46366"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-27T17:15:13Z",
    "severity": "HIGH"
  },
  "details": "A Client-side Template Injection (CSTI) vulnerability in Webkul Krayin CRM 1.3.0 allows remote attackers to execute arbitrary client-side template code by injecting a malicious payload during the lead creation process. This can lead to privilege escalation when the payload is executed, granting the attacker elevated permissions within the CRM system.",
  "id": "GHSA-wqc2-gwgp-9p7w",
  "modified": "2024-09-27T21:31:50Z",
  "published": "2024-09-27T18:32:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46366"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/Tommywarren/89cef7f876ee897a4ff40a8b71b6208e"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X238-V9F9-93G8

Vulnerability from github – Published: 2025-04-28 15:31 – Updated: 2025-04-28 15:31

Details

Dell PowerProtect Data Manager Reporting, version(s) 19.16, 19.17, 19.18, contain(s) an Improper Neutralization of Special Elements Used in a Template Engine vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to information disclosure.

Severity

2.3 (Low)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-23376"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-28T15:15:45Z",
    "severity": "LOW"
  },
  "details": "Dell PowerProtect Data Manager Reporting, version(s) 19.16, 19.17, 19.18, contain(s) an Improper Neutralization of Special Elements Used in a Template Engine vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to information disclosure.",
  "id": "GHSA-x238-v9f9-93g8",
  "modified": "2025-04-28T15:31:41Z",
  "published": "2025-04-28T15:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23376"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000311083/dsa-2025-062-security-update-for-dell-powerprotect-data-manager-multiple-security-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X7GR-MMJJ-HX3H

Vulnerability from github – Published: 2024-11-14 18:30 – Updated: 2026-04-01 18:32

Details

Improper Neutralization of Special Elements Used in a Template Engine vulnerability in Podlove Podlove Podcast Publisher.This issue affects Podlove Podcast Publisher: from n/a through 4.1.15.

Severity

9.1 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-52393"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-82",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-14T18:15:26Z",
    "severity": "CRITICAL"
  },
  "details": "Improper Neutralization of Special Elements Used in a Template Engine vulnerability in Podlove Podlove Podcast Publisher.This issue affects Podlove Podcast Publisher: from n/a through 4.1.15.",
  "id": "GHSA-x7gr-mmjj-hx3h",
  "modified": "2026-04-01T18:32:24Z",
  "published": "2024-11-14T18:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52393"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/podlove-podcasting-plugin-for-wordpress/vulnerability/wordpress-podlove-podcast-publisher-plugin-4-1-15-admin-remote-code-execution-rce-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/podlove-podcasting-plugin-for-wordpress/wordpress-podlove-podcast-publisher-plugin-4-1-15-admin-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-X7M9-MWC2-G6W2

Vulnerability from github – Published: 2026-05-18 17:23 – Updated: 2026-06-09 10:32

Summary

Formie: Pre-authenticated server-side template injection in Hidden fields

Details

Impact

Unauthenticated users could submit crafted values into Hidden fields (with Default value → Custom) that were evaluated as Twig during submission handling, which could lead to serious compromise of the Craft site (depending on template/sandbox behavior).
Sites with public Formie forms that include at least one Hidden field with that configuration.
No CP login for the reported chain.

Patches

2.2.20, 3.1.24

Workarounds

Temporarily remove Hidden fields from public forms or switch Hidden default away from Custom where feasible
Otherwise, upgrade to patched versions

Severity

9.8 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "verbb/formie"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-beta.1"
            },
            {
              "fixed": "3.1.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "verbb/formie"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45697"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-693",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T17:23:39Z",
    "nvd_published_at": "2026-05-29T20:16:27Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n- Unauthenticated users could submit crafted values into Hidden fields (with Default value \u2192 Custom) that were evaluated as Twig during submission handling, which could lead to serious compromise of the Craft site (depending on template/sandbox behavior).\n- Sites with public Formie forms that include at least one Hidden field with that configuration.\n- No CP login for the reported chain.\n\n### Patches\n- [2.2.20](https://github.com/verbb/formie/releases/tag/2.2.20), [3.1.24](https://github.com/verbb/formie/releases/tag/3.1.24)\n\n### Workarounds\n- Temporarily remove Hidden fields from public forms or switch Hidden default away from Custom where feasible\n- Otherwise, upgrade to patched versions",
  "id": "GHSA-x7m9-mwc2-g6w2",
  "modified": "2026-06-09T10:32:38Z",
  "published": "2026-05-18T17:23:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/verbb/formie/security/advisories/GHSA-x7m9-mwc2-g6w2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45697"
    },
    {
      "type": "WEB",
      "url": "https://github.com/verbb/formie/commit/f690d5623163ce2a95da305238d6367575486ee3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/verbb/formie"
    },
    {
      "type": "WEB",
      "url": "https://github.com/verbb/formie/releases/tag/2.2.20"
    },
    {
      "type": "WEB",
      "url": "https://github.com/verbb/formie/releases/tag/3.1.24"
    }
  ],
  "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": "Formie: Pre-authenticated server-side template injection in Hidden fields"
}

GHSA-XJW8-8C5C-9R79

Vulnerability from github – Published: 2026-04-15 19:46 – Updated: 2026-04-24 20:53

Summary

Improper neutralization of specific syntax patterns for unauthorized expressions in Thymeleaf

Details

Impact

A security bypass vulnerability exists in the expression execution mechanisms of Thymeleaf up to and including 3.1.3.RELEASE. Although the library provides mechanisms to prevent expression injection, it fails to properly neutralize specific syntax patterns that allow for the execution of unauthorized expressions. If an application developer passes unvalidated user input directly to the template engine, an unauthenticated remote attacker can bypass the library's protections to achieve Server-Side Template Injection (SSTI).

Patches

This has been fixed in Thymeleaf 3.1.4.RELEASE.

Workarounds

No workaround is available beyond ensuring applications do not pass unvalidated user input directly to the template engine. Upgrading to 3.1.4.RELEASE is strongly recommended in any case.

Credits

Thanks to Dawid Bakaj (VIPentest.com) for responsible disclosure.

Severity

9.0 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.3.RELEASE"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.thymeleaf:thymeleaf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.4.RELEASE"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.3.RELEASE"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.thymeleaf:thymeleaf-spring5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.4.RELEASE"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.3.RELEASE"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.thymeleaf:thymeleaf-spring6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.4.RELEASE"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40478"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-917"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-15T19:46:23Z",
    "nvd_published_at": "2026-04-17T22:16:33Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nA security bypass vulnerability exists in the expression execution mechanisms of Thymeleaf up to and including 3.1.3.RELEASE. Although the library provides mechanisms to prevent expression injection, it fails to properly neutralize specific syntax patterns that allow for the execution of unauthorized expressions. If an application developer passes unvalidated user input directly to the template engine, an unauthenticated remote attacker can bypass the library\u0027s protections to achieve Server-Side Template Injection (SSTI).\n\n### Patches\nThis has been fixed in Thymeleaf 3.1.4.RELEASE.\n\n### Workarounds\nNo workaround is available beyond ensuring applications do not pass unvalidated user input directly to the template engine. Upgrading to 3.1.4.RELEASE is strongly recommended in any case.\n\n### Credits\nThanks to Dawid Bakaj (VIPentest.com) for responsible disclosure.",
  "id": "GHSA-xjw8-8c5c-9r79",
  "modified": "2026-04-24T20:53:26Z",
  "published": "2026-04-15T19:46:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thymeleaf/thymeleaf/security/advisories/GHSA-xjw8-8c5c-9r79"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40478"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thymeleaf/thymeleaf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper neutralization of specific syntax patterns for unauthorized expressions in Thymeleaf"
}

GHSA-XQMJ-J6MV-4862

Vulnerability from github – Published: 2026-04-24 16:02 – Updated: 2026-05-12 13:27

Summary

LiteLLM: Server-Side Template Injection in /prompts/test endpoint

Details

Impact

The POST /prompts/test endpoint accepted user-supplied prompt templates and rendered them without sandboxing. A crafted template could run arbitrary code inside the LiteLLM Proxy process.

The endpoint only checks that the caller presents a valid proxy API key, so any authenticated user could reach it. Depending on how the proxy is deployed, this could expose secrets in the process environment (such as provider API keys or database credentials) and allow commands to be run on the host.

Proxy deployments running an affected version are in scope.

Patches

The issue is fixed in 1.83.7-stable. The fix switches the prompt template renderer to a sandboxed environment that blocks the attributes this attack relies on.

LiteLLM recommends upgrading to 1.83.7-stable or later.

Workarounds

If upgrading is not immediately possible:

Block POST /prompts/test at your reverse proxy or API gateway.
Review and rotate API keys that should not have access to prompt management routes.

Severity

8.6 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.80.5"
            },
            {
              "fixed": "1.83.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42203"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-24T16:02:42Z",
    "nvd_published_at": "2026-05-08T04:16:19Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nThe `POST /prompts/test` endpoint accepted user-supplied prompt templates and rendered them without sandboxing. A crafted template could run arbitrary code inside the LiteLLM Proxy process.\n\nThe endpoint only checks that the caller presents a valid proxy API key, so any authenticated user could reach it. Depending on how the proxy is deployed, this could expose secrets in the process environment (such as provider API keys or database credentials) and allow commands to be run on the host.\n\nProxy deployments running an affected version are in scope.\n\n### Patches\nThe issue is fixed in **`1.83.7-stable`**. The fix switches the prompt template renderer to a sandboxed environment that blocks the attributes this attack relies on.\n\nLiteLLM recommends upgrading to `1.83.7-stable` or later.\n\n### Workarounds\nIf upgrading is not immediately possible:\n\n1. Block `POST /prompts/test` at your reverse proxy or API gateway.\n2. Review and rotate API keys that should not have access to prompt management routes.",
  "id": "GHSA-xqmj-j6mv-4862",
  "modified": "2026-05-12T13:27:01Z",
  "published": "2026-04-24T16:02:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-xqmj-j6mv-4862"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42203"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BerriAI/litellm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "LiteLLM: Server-Side Template Injection in /prompts/test endpoint"
}

GHSA-XRH7-2GFQ-4RCQ

Vulnerability from github – Published: 2024-07-17 21:31 – Updated: 2024-12-18 22:03

Summary

openCart Server-Side Template Injection (SSTI) vulnerability

Details

A Server-Side Template Injection (SSTI) vulnerability in the Theme Editor Function of openCart project v4.0.2.3 allows attackers to execute arbitrary code via injecting a crafted payload.

Severity

8.0 (High)


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

5.5 (Medium)


                  
                    CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "opencart/opencart"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "4.0.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-36694"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-17T23:36:49Z",
    "nvd_published_at": "2024-07-17T19:15:11Z",
    "severity": "MODERATE"
  },
  "details": "A Server-Side Template Injection (SSTI) vulnerability in the Theme Editor Function of openCart project v4.0.2.3 allows attackers to execute arbitrary code via injecting a crafted payload.",
  "id": "GHSA-xrh7-2gfq-4rcq",
  "modified": "2024-12-18T22:03:16Z",
  "published": "2024-07-17T21:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36694"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencart/opencart/issues/13863"
    },
    {
      "type": "WEB",
      "url": "https://github.com/A3h1nt/CVEs/blob/main/OpenCart/Readme.md"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/opencart/opencart"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencart/opencart/releases/tag/4.0.2.3"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@pawarit.sanguanpang/opencart-v4-0-2-3-server-side-template-injection-0b173a3bdcf9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "openCart Server-Side Template Injection (SSTI) vulnerability"
}

GHSA-XRMJ-5G4G-8987

Vulnerability from github – Published: 2026-07-31 16:01 – Updated: 2026-07-31 16:01

Summary

@dynatrace-oss/dynatrace-mcp-server has a workflow template injection via create_workflow_for_notification

Details

Summary

A template injection vulnerability in the create_workflow_for_notification tool lets a caller embed Jinja2 expressions that the Dynatrace workflow engine evaluates at runtime, exfiltrating event data to attacker-controlled destinations through a workflow that persists in the tenant after the MCP session ends.

Details

The create_workflow_for_notification tool interpolates three caller-supplied parameters (teamName, problemType, channel) directly into a Dynatrace Workflow definition. Dynatrace Workflows use Jinja2 templating: per the official documentation, {{ ... }} expressions in action inputs are evaluated at workflow runtime for every action except Run Javascript (which is carved out specifically to avoid code injection). A caller can therefore supply, for example, teamName = "{{ event() }}" and have the workflow engine evaluate that expression at runtime, serialising the full event object into the message body delivered to the Slack channel.

The vulnerable code is in src/capabilities/create-workflow-for-problem-notification.ts, lines 82-99:

let notificationWorkflow: WorkflowCreate = {
  title: `[MCP POC] Notify team ${teamName} on problem of type ${problemType}`,
  description: `Automatically created workflow to notify team ${teamName} on problems of type ${problemType} - ...`,
  isPrivate: isPrivate,
  type: 'SIMPLE',
  tasks: {
    send_notification: {
      name: 'Send notification',
      action: 'dynatrace.slack:slack-send-message',
      description: 'Sends a notification to a Slack channel',
      input: {
        connectionId: 'slack-connection-id',
        channel: `{{ \"${channel}\" }}`,        // <-- channel sits inside {{ }}
        message: `🚨 Alert for Team ${teamName}\n*Problem Type*: ${problemType}\n` +
                 `*Problem ID*: {{ event()["display_id"] }}\n*Status*: {{ event()["event.status"] }}\n` +
                 `<{{ environment().url }}/ui/apps/.../problem/{{ event()["event.id"] }}|Click here>`,
      },
      active: true,
    },
  },
};

The action used is dynatrace.slack:slack-send-message, which is not in the documented Jinja-expression exception list. Its inputs are evaluated at workflow runtime.

The schema in src/index.ts:1052-1070 registers teamName, problemType, and channel as z.string().optional() with no pattern validation. The isPrivate parameter has .default(false), so created workflows are visible tenant-wide unless the caller explicitly sets it.

The approval prompt at src/index.ts:1069-1072:

const approved = await requestHumanApproval(
  `Create a workflow for notifying team ${teamName} via ${channel} about ${problemType} problems`,
);

Renders {{ event() }} literally to the operator with no indication that it will be templated, and does not surface the workflow's visibility.

The workflow is persistent: it remains in the tenant after the MCP session ends, after the operator's MCP credentials are revoked, and after the MCP server is uninstalled. It fires on every matching problem until manually deleted from the Workflows app. The channel parameter is uniquely dangerous because it is interpolated inside an existing {{ "..." }} expression context - close the string with " and you can run arbitrary Jinja expressions in the destination field itself.

PoC

Tested end-to-end against a real Dynatrace tenant. The MCP server was run in stdio mode with the operator's Platform Token. A tools/call create_workflow_for_notification was sent with:

{
  "teamName":    "{{ event() }}",
  "problemType": "ERROR",
  "channel":     "#mcp-sec-poc",
  "isPrivate":   true
}

The operator approved the prompt (which read: "Create a workflow for notifying team {{ event() }} via #mcp-sec-poc about ERROR problems"). The MCP returned a workflow ID. Fetching the stored workflow body via the Dynatrace Automation API (GET /platform/automation/v1/workflows/<id>) showed the injected expression stored verbatim:

title:   "[MCP POC] Notify team {{ event() }} on problem of type ERROR"
message: "🚨 Alert for Team {{ event() }}\n*Problem Type*: ERROR\n*Problem ID*: {{ event()[\"display_id\"] }}\n..."
channel: '{{ "#mcp-sec-poc" }}'
action:  "dynatrace.slack:slack-send-message"

The workflow was then triggered manually via the "Run workflow" feature in the Dynatrace Workflows app, with a synthetic event payload {"display_id":"P-123","event.status":"OPEN","event.id":"abc-123"}. The execution log for the send_notification task shows the workflow engine evaluated the injected expressions at runtime. The "Input" tab for the executed action contains:

channel: #mcp-sec-poc
message: Alert for Team
         {'display_id': 'P-123',
          'event.status': 'OPEN',
          'event.id': 'abc-123'}
         *Problem Type*: ERROR
         *Problem ID*: P-123
         *Status*: OPEN
         <https://<tenant>.apps.dynatrace.com/ui/apps/.../problem/abc-123|Click here for details>

The injected {{ event() }} resolved to the actual event object before the Slack action was called. The Slack action then failed only because the workflow uses a hardcoded placeholder connectionId: 'slack-connection-id' that does not resolve to any real connection. If a real Slack connector had been configured, the message would have been delivered with the serialized event data in place of {{ event() }}.

This is end-to-end confirmation of the Jinja-evaluation chain.

Impact

A workflow created with a malicious template payload acts as a persistent exfiltration channel:

It fires on every matching problem indefinitely.
The injected template is evaluated at runtime and resolves to whatever the Jinja function returns (event() gives the full event object, environment() gives tenant metadata, plus other available functions per the Dynatrace Workflows documentation).
The resolved output is delivered to a destination the attacker controls (the channel parameter is also templated, and is even more dangerous because it is interpolated inside an existing {{ "..." }} expression context).
The workflow persists in the tenant after the MCP session, operator credentials, and MCP server are gone.
With isPrivate=false (the default), the workflow is visible to all tenant users.

Exploitation requires either prompt injection (an LLM under the MCP server's control is reading attacker-controlled data and follows an injection that calls create_workflow_for_notification with the malicious arguments) or operator carelessness (the approval prompt shows the raw team name literal and the operator clicks Approve without recognising {{ event() }} as a template fragment). Both are realistic in practice.

Severity

4.2 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@dynatrace-oss/dynatrace-mcp-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-31T16:01:07Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nA template injection vulnerability in the `create_workflow_for_notification` tool lets a caller embed Jinja2 expressions that the Dynatrace workflow engine evaluates at runtime, exfiltrating event data to attacker-controlled destinations through a workflow that persists in the tenant after the MCP session ends.\n\n### Details\nThe `create_workflow_for_notification` tool interpolates three caller-supplied parameters (`teamName`, `problemType`, `channel`) directly into a Dynatrace Workflow definition. Dynatrace Workflows use Jinja2 templating: per the [official documentation](https://docs.dynatrace.com/docs/analyze-explore-automate/workflows/reference), `{{ ... }}` expressions in action inputs are evaluated at workflow runtime for every action except `Run Javascript` (which is carved out specifically to avoid code injection). A caller can therefore supply, for example, `teamName = \"{{ event() }}\"` and have the workflow engine evaluate that expression at runtime, serialising the full event object into the message body delivered to the Slack channel.\n\nThe vulnerable code is in `src/capabilities/create-workflow-for-problem-notification.ts`, lines 82-99:\n\n```typescript\nlet notificationWorkflow: WorkflowCreate = {\n  title: `[MCP POC] Notify team ${teamName} on problem of type ${problemType}`,\n  description: `Automatically created workflow to notify team ${teamName} on problems of type ${problemType} - ...`,\n  isPrivate: isPrivate,\n  type: \u0027SIMPLE\u0027,\n  tasks: {\n    send_notification: {\n      name: \u0027Send notification\u0027,\n      action: \u0027dynatrace.slack:slack-send-message\u0027,\n      description: \u0027Sends a notification to a Slack channel\u0027,\n      input: {\n        connectionId: \u0027slack-connection-id\u0027,\n        channel: `{{ \\\"${channel}\\\" }}`,        // \u003c-- channel sits inside {{ }}\n        message: `\ud83d\udea8 Alert for Team ${teamName}\\n*Problem Type*: ${problemType}\\n` +\n                 `*Problem ID*: {{ event()[\"display_id\"] }}\\n*Status*: {{ event()[\"event.status\"] }}\\n` +\n                 `\u003c{{ environment().url }}/ui/apps/.../problem/{{ event()[\"event.id\"] }}|Click here\u003e`,\n      },\n      active: true,\n    },\n  },\n};\n```\n\nThe action used is `dynatrace.slack:slack-send-message`, which is not in the documented Jinja-expression exception list. Its inputs are evaluated at workflow runtime.\n\nThe schema in `src/index.ts:1052-1070` registers `teamName`, `problemType`, and `channel` as `z.string().optional()` with no pattern validation. The `isPrivate` parameter has `.default(false)`, so created workflows are visible tenant-wide unless the caller explicitly sets it.\n\nThe approval prompt at `src/index.ts:1069-1072`:\n\n```typescript\nconst approved = await requestHumanApproval(\n  `Create a workflow for notifying team ${teamName} via ${channel} about ${problemType} problems`,\n);\n```\n\nRenders `{{ event() }}` literally to the operator with no indication that it will be templated, and does not surface the workflow\u0027s visibility.\n\nThe workflow is persistent: it remains in the tenant after the MCP session ends, after the operator\u0027s MCP credentials are revoked, and after the MCP server is uninstalled. It fires on every matching problem until manually deleted from the Workflows app. The `channel` parameter is uniquely dangerous because it is interpolated inside an existing `{{ \"...\" }}` expression context - close the string with `\"` and you can run arbitrary Jinja expressions in the destination field itself.\n\n\n### PoC\n\nTested end-to-end against a real Dynatrace tenant. The MCP server was run in stdio mode with the operator\u0027s Platform Token. A `tools/call create_workflow_for_notification` was sent with:\n\n```json\n{\n  \"teamName\":    \"{{ event() }}\",\n  \"problemType\": \"ERROR\",\n  \"channel\":     \"#mcp-sec-poc\",\n  \"isPrivate\":   true\n}\n```\n\nThe operator approved the prompt (which read: `\"Create a workflow for notifying team {{ event() }} via #mcp-sec-poc about ERROR problems\"`). The MCP returned a workflow ID. Fetching the stored workflow body via the Dynatrace Automation API (`GET /platform/automation/v1/workflows/\u003cid\u003e`) showed the injected expression stored verbatim:\n\n```\ntitle:   \"[MCP POC] Notify team {{ event() }} on problem of type ERROR\"\nmessage: \"\ud83d\udea8 Alert for Team {{ event() }}\\n*Problem Type*: ERROR\\n*Problem ID*: {{ event()[\\\"display_id\\\"] }}\\n...\"\nchannel: \u0027{{ \"#mcp-sec-poc\" }}\u0027\naction:  \"dynatrace.slack:slack-send-message\"\n```\n\nThe workflow was then triggered manually via the \"Run workflow\" feature in the Dynatrace Workflows app, with a synthetic event payload `{\"display_id\":\"P-123\",\"event.status\":\"OPEN\",\"event.id\":\"abc-123\"}`. The execution log for the `send_notification` task shows the workflow engine evaluated the injected expressions at runtime. The \"Input\" tab for the executed action contains:\n\n```\nchannel: #mcp-sec-poc\nmessage: Alert for Team\n         {\u0027display_id\u0027: \u0027P-123\u0027,\n          \u0027event.status\u0027: \u0027OPEN\u0027,\n          \u0027event.id\u0027: \u0027abc-123\u0027}\n         *Problem Type*: ERROR\n         *Problem ID*: P-123\n         *Status*: OPEN\n         \u003chttps://\u003ctenant\u003e.apps.dynatrace.com/ui/apps/.../problem/abc-123|Click here for details\u003e\n```\n\nThe injected `{{ event() }}` resolved to the actual event object before the Slack action was called. The Slack action then failed only because the workflow uses a hardcoded placeholder `connectionId: \u0027slack-connection-id\u0027` that does not resolve to any real connection. If a real Slack connector had been configured, the message would have been delivered with the serialized event data in place of `{{ event() }}`.\n\nThis is end-to-end confirmation of the Jinja-evaluation chain.\n\n### Impact\nA workflow created with a malicious template payload acts as a persistent exfiltration channel:\n\n- It fires on every matching problem indefinitely.\n- The injected template is evaluated at runtime and resolves to whatever the Jinja function returns (`event()` gives the full event object, `environment()` gives tenant metadata, plus other available functions per the Dynatrace Workflows documentation).\n- The resolved output is delivered to a destination the attacker controls (the `channel` parameter is also templated, and is even more dangerous because it is interpolated inside an existing `{{ \"...\" }}` expression context).\n- The workflow persists in the tenant after the MCP session, operator credentials, and MCP server are gone.\n- With `isPrivate=false` (the default), the workflow is visible to all tenant users.\n\nExploitation requires either prompt injection (an LLM under the MCP server\u0027s control is reading attacker-controlled data and follows an injection that calls `create_workflow_for_notification` with the malicious arguments) or operator carelessness (the approval prompt shows the raw team name literal and the operator clicks Approve without recognising `{{ event() }}` as a template fragment). Both are realistic in practice.",
  "id": "GHSA-xrmj-5g4g-8987",
  "modified": "2026-07-31T16:01:07Z",
  "published": "2026-07-31T16:01:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dynatrace-oss/dynatrace-mcp/security/advisories/GHSA-xrmj-5g4g-8987"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dynatrace-oss/dynatrace-mcp/pull/547"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dynatrace-oss/dynatrace-mcp/commit/64dfcb1095823d0fb43013635446288a6ff60e29"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dynatrace-oss/dynatrace-mcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dynatrace-oss/dynatrace-mcp/releases/tag/v2.0.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@dynatrace-oss/dynatrace-mcp-server has a workflow template injection via create_workflow_for_notification"
}

CWE-1336

Improper Neutralization of Special Elements Used in a Template Engine

GHSA-WJV6-JCFJ-MF9R

Summary

Details

PoC

Impact

Resolution

Remediation

GHSA-WJW6-95H5-4JPX

Impact

Patches

Workarounds

References

GHSA-WQC2-GWGP-9P7W

GHSA-X238-V9F9-93G8

GHSA-X7GR-MMJJ-HX3H

GHSA-X7M9-MWC2-G6W2

Impact

Patches

Workarounds

GHSA-XJW8-8C5C-9R79

Impact

Patches

Workarounds

Credits

GHSA-XQMJ-J6MV-4862

Impact

Patches

Workarounds

GHSA-XRH7-2GFQ-4RCQ

GHSA-XRMJ-5G4G-8987

Summary

Details

PoC

Impact

Mitigation

Mitigation