GHSA-p75g-cxfj-7wrx
MEDIUMGHSA-p75g-cxfj-7wrx is a medium-severity (CVSS 6.8) CWE-73 vulnerability in io.pebbletemplates:pebble. O3 Security confirms whether GHSA-p75g-cxfj-7wrx is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Pebble has Arbitrary Local File Inclusion (LFI) Vulnerability via `include` macro
Blast Radius
io.pebbletemplates:pebbleReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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.
/**
* 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;
}
}
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:
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:
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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | io.pebbletemplates:pebble | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.pebbletemplates:pebble. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of io.pebbletemplates:pebble has shipped for GHSA-p75g-cxfj-7wrx yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-p75g-cxfj-7wrx is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-p75g-cxfj-7wrx. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-p75g-cxfj-7wrx in your dependencies?
O3 detects GHSA-p75g-cxfj-7wrx across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.