ghsa-p75g-cxfj-7wrx
Vulnerability from github
7.0 (High) - CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:H/SC:L/SI:N/SA:N
Summary
If untrusted user input is used to dynamically create a PebbleTemplate
with the method PebbleEngine#getLiteralTemplate
, then an attacker can include arbitrary local files from the file system into the generated template, leaking potentially sensitive information into the output of PebbleTemplate#evaluate
. This is done via the include
macro.
Details
The include
macro calls PebbleTempateImpl#resolveRelativePath
with the relativePath
argument passed within the template:
Example template:
{% include [relativePath] %}
When resolveRelativePath
is called, the relativePath
is resolved against the PebbleTemplateImpl.name
variable.
java
/**
* This method resolves the given relative path based on this template file path.
*
* @param relativePath the path which should be resolved.
* @return the resolved path.
*/
public String resolveRelativePath(String relativePath) {
String resolved = this.engine.getLoader().resolveRelativePath(relativePath, this.name);
if (resolved == null) {
return relativePath;
} else {
return resolved;
}
}
https://github.com/PebbleTemplates/pebble/blob/82ad7fcf9e9eaa45ee82ae3335a1409d19c10263/pebble/src/main/java/io/pebbletemplates/pebble/template/PebbleTemplateImpl.java#L380
Unfortunately, when the template is created from a string, as is the case when PebbleEngine#getLiteralTemplate
is used, the PebbleTemplateImpl.name
variable is actually the entirety of the contents of the template, not a filename as the logic expects. The net result is that the relativePath
is resolved against the system root directory. As a result, files accessible from the root directory of the filesystem can be included into a template.
PoC
The following test demonstrates the vulnerability:
```java PebbleEngine e = new PebbleEngine.Builder().build();
String templateString = """ {% include '/etc/passwd' %} """; PebbleTemplate template = e.getLiteralTemplate(templateString);
try (final Writer writer = new StringWriter()) { template.evaluate(writer, new HashMap<>()); System.out.println(writer); } ```
As an attacker, the following malicious template demonstrates the vulnerability:
{% include '/etc/passwd' %}
Impact
This is an arbitrary Local File Inclusion (LFI) vulnerability. It can allow attackers to exfiltrate the contents of the local filesystem, including sensitive files into PebbleTemplate
output. This can also be used to access the /proc
filesystem which can give an attacker access to environment variables.
Fix
There exists no published fix for this vulnerability. The best way to mitigate this vulnerability is to disable the include
macro in Pebble Templates.
The following can safeguard your application from this vulnerability:
java
new PebbleEngine.Builder()
.registerExtensionCustomizer(new DisallowExtensionCustomizerBuilder()
.disallowedTokenParserTags(List.of("include"))
.build())
.build();
Report Timeline
Vulnerability was reported under the Open Source Security Foundation (OpenSSF) Model Outbound Vulnerability Disclosure Policy: Version 0.1.
- Jul 15, 2024 Maintainer Contacted to enable private vulnerability reporting
- Jul 18, 2024 I opened a GHSA to report this vulnerability to the maintainer https://github.com/PebbleTemplates/pebble/security/advisories/GHSA-7c6h-hmf9-7wj7 (private link)
- Jul 29, 2024 GHSA updated to ping maintainer about vulnerability, no response
- Oct 1, 2024 GHSA updated to ping maintainer about vulnerability, no response
- Nov 15, 2024 GHSA updated to inform maintainer that disclosure timeline had lapsed, no response.
- Feb 19, 2025 GHSA updated to inform maintainer that disclosure would occur imminently, no response.
- Feb 24, 2025 this GHSA was created to disclose this vulnerability without a patch available.
For further discussion, see this issue: https://github.com/PebbleTemplates/pebble/issues/688
Credit
This vulnerability was discovered by @JLLeitschuh while at Chainguard Labs. Jonathan is currently independent.
{ "affected": [ { "package": { "ecosystem": "Maven", "name": "io.pebbletemplates:pebble" }, "ranges": [ { "events": [ { "introduced": "0" }, { "last_affected": "3.2.3" } ], "type": "ECOSYSTEM" } ] } ], "aliases": [ "CVE-2025-1686" ], "database_specific": { "cwe_ids": [ "CWE-73" ], "github_reviewed": true, "github_reviewed_at": "2025-02-28T19:45:03Z", "nvd_published_at": "2025-02-27T05:15:14Z", "severity": "HIGH" }, "details": "### Summary\n\nIf untrusted user input is used to dynamically create a `PebbleTemplate` with the method `PebbleEngine#getLiteralTemplate`, then an attacker can include arbitrary local files from the file system into the generated template, leaking potentially sensitive information into the output of `PebbleTemplate#evaluate`. This is done via the `include` macro.\n\n### Details\n\nThe `include` macro calls `PebbleTempateImpl#resolveRelativePath` with the `relativePath` argument passed within the template:\n\nExample template:\n```\n{% include [relativePath] %}\n```\nWhen `resolveRelativePath` is called, the `relativePath` is resolved against the `PebbleTemplateImpl.name` variable.\n\n```java\n /**\n * This method resolves the given relative path based on this template file path.\n *\n * @param relativePath the path which should be resolved.\n * @return the resolved path.\n */\n public String resolveRelativePath(String relativePath) {\n String resolved = this.engine.getLoader().resolveRelativePath(relativePath, this.name);\n if (resolved == null) {\n return relativePath;\n } else {\n return resolved;\n }\n }\n```\nhttps://github.com/PebbleTemplates/pebble/blob/82ad7fcf9e9eaa45ee82ae3335a1409d19c10263/pebble/src/main/java/io/pebbletemplates/pebble/template/PebbleTemplateImpl.java#L380\n\nUnfortunately, when the template is created from a string, as is the case when `PebbleEngine#getLiteralTemplate` is used, the `PebbleTemplateImpl.name` variable is actually the entirety of the contents of the template, not a filename as the logic expects. The net result is that the `relativePath` is resolved against the system root directory. As a result, files accessible from the root directory of the filesystem can be included into a template. \n\n### PoC\n\nThe following test demonstrates the vulnerability:\n\n```java\nPebbleEngine e = new PebbleEngine.Builder().build();\n\nString templateString = \"\"\"\n {% include \u0027/etc/passwd\u0027 %}\n \"\"\";\nPebbleTemplate template = e.getLiteralTemplate(templateString);\n\ntry (final Writer writer = new StringWriter()) {\n template.evaluate(writer, new HashMap\u003c\u003e());\n System.out.println(writer);\n}\n```\n\nAs an attacker, the following malicious template demonstrates the vulnerability:\n\n```\n{% include \u0027/etc/passwd\u0027 %}\n```\n\n### Impact\n\nThis is an arbitrary Local File Inclusion (LFI) vulnerability. It can allow attackers to exfiltrate the contents of the local filesystem, including sensitive files into `PebbleTemplate` output. This can also be used to access the `/proc` filesystem which can give an attacker access to environment variables.\n\n### Fix\n\nThere exists no published fix for this vulnerability. The best way to mitigate this vulnerability is to disable the `include` macro in Pebble Templates.\n\nThe following can safeguard your application from this vulnerability:\n\n```java\nnew PebbleEngine.Builder()\n .registerExtensionCustomizer(new DisallowExtensionCustomizerBuilder()\n .disallowedTokenParserTags(List.of(\"include\"))\n .build())\n .build();\n```\n\n### Report Timeline\n\nVulnerability was reported under the Open Source Security Foundation (OpenSSF) [Model Outbound Vulnerability Disclosure Policy: Version 0.1](https://openssf.org/about/vulnerability-disclosure-policy/).\n\n - [Jul 15, 2024](https://github.com/PebbleTemplates/pebble/issues/680#issue-2409727829) Maintainer Contacted to enable private vulnerability reporting\n - [Jul 18, 2024](https://github.com/PebbleTemplates/pebble/issues/680#issuecomment-2236970984) I opened a GHSA \n to report this vulnerability to the maintainer https://github.com/PebbleTemplates/pebble/security/advisories/GHSA-7c6h-hmf9-7wj7 (private link)\n - Jul 29, 2024 GHSA updated to ping maintainer about vulnerability, no response\n - Oct 1, 2024 GHSA updated to ping maintainer about vulnerability, no response\n - Nov 15, 2024 GHSA updated to inform maintainer that disclosure timeline had lapsed, no response.\n - Feb 19, 2025 GHSA updated to inform maintainer that disclosure would occur imminently, no response.\n - Feb 24, 2025 this GHSA was created to disclose this vulnerability **without a patch available**.\n\nFor further discussion, see this issue: https://github.com/PebbleTemplates/pebble/issues/688\n\n### Credit\n\nThis vulnerability was discovered by @JLLeitschuh while at [Chainguard Labs](https://www.chainguard.dev). Jonathan is currently independent.", "id": "GHSA-p75g-cxfj-7wrx", "modified": "2025-02-28T19:45:03Z", "published": "2025-02-28T19:45:03Z", "references": [ { "type": "WEB", "url": "https://github.com/JLLeitschuh/security-research/security/advisories/GHSA-p75g-cxfj-7wrx" }, { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1686" }, { "type": "WEB", "url": "https://github.com/PebbleTemplates/pebble/issues/680" }, { "type": "WEB", "url": "https://github.com/PebbleTemplates/pebble/issues/688" }, { "type": "PACKAGE", "url": "https://github.com/PebbleTemplates/pebble" }, { "type": "WEB", "url": "https://pebbletemplates.io/wiki/tag/include" }, { "type": "WEB", "url": "https://security.snyk.io/vuln/SNYK-JAVA-IOPEBBLETEMPLATES-8745594" } ], "schema_version": "1.4.0", "severity": [ { "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N", "type": "CVSS_V3" }, { "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:H/SC:L/SI:N/SA:N", "type": "CVSS_V4" } ], "summary": "Pebble has Arbitrary Local File Inclusion (LFI) Vulnerability via `include` macro" }
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.