GHSA-jc7g-x28f-3v3h
CRITICALlistmonk's Sprig template Injection vulnerability leads to reading of Environment Variable for low privilege user
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/knadh/listmonkReal-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
Summary
The env and expandenv template functions which is enabled by default in Sprig enables capturing of env variables on the host. While this may not be a problem on single-user (super admin) installations, on multi-user installations, this allows non-super-admin users with campaign or template permissions to use the {{ env }} template expression to capture sensitive environment variables.
Upgrade to v5.0.2 to mitigate.
Demonstration
Description
A critical template injection vulnerability exists in Listmonk's campaign preview functionality that allows authenticated users with minimal privileges (campaigns:get & campaigns:get_all) to extract sensitive system data, including database credentials, SMTP passwords, and admin credentials due to some dangerous function being allowed.
Proof of Concept
- Create a user and give him
campaigns:getandcampaigns:get_allprivileges
-
Now login with that user, go to any campaign, go the Content section and here lies the vulnerability, we're able to execute template content which allows us to get environment variables, execute Sprig functions...
-
Now in the text field you can input the following and press Preview:
{{ env "AWS_KEY" }}
{{ env "LISTMONK_db__user" }}
{{ env "LISTMONK_db__password" }}
Preview:
I had the AWS_KEY variable set like that to confirm the vulnerability:
Impact
- Through these environment variables the attacker can access, they can fully compromise the database, cloud accounts, admin credentials, and more depending on what was setup leading to total system takeover and data breach.
Suggested Fix
- Blacklist some function for templates like env, expandEnv and fail as they can be used to leak environment variables which leads to a full takeover.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/knadh/listmonk | ≥ 4.0.0&&< 5.0.2 | 5.0.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/knadh/listmonk. 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.
Fix
Update github.com/knadh/listmonk to 5.0.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jc7g-x28f-3v3h 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.
How O3 protects you
O3 pinpoints whether GHSA-jc7g-x28f-3v3h 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-jc7g-x28f-3v3h. 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-jc7g-x28f-3v3h in your dependencies?
O3 detects GHSA-jc7g-x28f-3v3h across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.