CVE-2025-54287 — lxd
CVE-2025-54287 is a CWE-1336 vulnerability in github.com/lxc/lxd. A fix is available for github.com/lxc/lxd — see the affected versions and patch details below.
Arbitrary File Read via Template Injection in Snapshot Patterns
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2025-54287.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
github.com/lxc/lxd🐹github.com/lxc/lxd🐹github.com/lxc/lxdReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Impact
In LXD's instance snapshot creation functionality, the Pongo2 template engine is used in the snapshots.pattern configuration for generating snapshot names. While code execution functionality has not been found in this template engine, it has file reading capabilities, creating a vulnerability that allows arbitrary file reading through template injection attacks.
Reproduction Steps
- Log in to LXD-UI with an account that has permissions to modify instance settings
- Set the following template injection payload in the instance snapshot pattern:
{% filter urlencode|slice:":100" %}{% include "/etc/passwd" %}{%endfilter %}
Note that the above template uses the Pongo2 template engine's include tag to read system files. It also uses urlencode and slice filters to bypass character count and type restrictions.
- Set scheduled snapshots to run every minute and wait for snapshot generation
- Wait about a minute and confirm that file contents can be obtained from the created snapshot name
Risk
The attack requires having configuration change permissions for LXD instances. The attack allows reading arbitrary files accessible with LXD process permissions. This could lead to leakage of the following information: - LXD host configuration files (/etc/passwd, /etc/shadow, etc.) - LXD database files (containing information about all projects and instances) - Configuration files and data of other instances - Sensitive information on the host system
Countermeasures
Pongo2 provides mechanisms for sandboxing templates.
Template sandboxing (directory patterns, banned tags/filters) ( https://github.com/flosch/pongo2/tree/master?tab=readme-ov-file#features )
This functionality allows banning specific tags and filters by generating a custom TemplateSet.
At minimum, the following tags are considered to pose a risk of file leakage on the LXD host when used. Therefore, banning these can provide countermeasures against file reading attacks. - include - ssi - extends - import
The deny-list approach is prone to vulnerability recurrence due to missed countermeasures or new feature additions. Therefore, as the safest approach, we recommend using an allow-list format to permit only necessary functions.
However, as far as our investigation shows, pongo2 does not have functionality to retrieve a list of registered tags or filters, nor does it provide means to implement an allow-list approach. Therefore, it is necessary to either forcibly obtain the registration list through reflection and ban anything not on the allow-list, or ban everything from the current implemented list since the library has not been updated for about two years.
In LXD's implementation, template injection attacks can be prevented by modifying the RenderTemplate function in shared/util.go to use a restricted TemplateSet as shown above.
Patches
| LXD Series | Status |
|---|---|
| 6 | Fixed in LXD 6.5 |
| 5.21 | Fixed in LXD 5.21.4 |
| 5.0 | Ignored - Not critical |
| 4.0 | Ignored - EOL and not critical |
References
Reported by GMO Flatt Security Inc.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/lxc/lxd | ≥ 4.0.0&&< 5.21.4 | 5.21.4go get github.com/lxc/lxd@v5.21.4 |
| 🐹Go | github.com/lxc/lxd | ≥ 6.0.0&&< 6.5.0 | 6.5.0go get github.com/lxc/lxd@v6.5.0 |
| 🐹Go | github.com/lxc/lxd | ≥ 0.0.0-20200331193331-03aab09f5b5c&&< 0.0.0-20250827065555-0494f5d47e41 | 0.0.0-20250827065555-0494f5d47e41go get github.com/lxc/lxd@v0.0.0-20250827065555-0494f5d47e41 |
Affected Products
lxdcanonicalDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/lxc/lxd, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/lxc/lxd to 5.21.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-54287 is resolved across your whole dependency graph.
Workarounds
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.
Frequently Asked Questions
Is CVE-2025-54287 in your dependencies?
Find it across Go, including transitive dependencies.