@jmondi/url-to-png enables capture screenshot of localhost web services (unauthenticated pages)GHSA-342q-2mc2-5gmp
LOWFix: jasonraimondi/url-to-png@f62ff40GHSA-342q-2mc2-5gmp is a low-severity (CVSS 3.7) Information Exposure vulnerability in @jmondi/url-to-png. A fix is available for @jmondi/url-to-png — see the affected versions and patch details below.
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.
Exploitation and automatability from CISA’s SSVC triage for GHSA-342q-2mc2-5gmp.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@jmondi/url-to-pngnpmDescription
Summary
The maintainer been contemplating whether FTP or other protocols could serve as useful functionalities, but there may not be a practical reason for it since we are utilizing headless Chrome to capture screenshots. The argument is based on the assumption that this package can function as a service.
The package includes an ALLOW_LIST where the host can specify which services the user is permitted to capture screenshots of. By default, capturing screenshots of web services running on localhost, 127.0.0.1, or the [::] is allowed.
The maintainer is of the opinion that the package should also have a blacklist due to a potential vulnerability (or rather design oversight). If someone hosts this on a server, users could then capture screenshots of other web services running locally.
Unless this is strictly for web pages. Something similar here: https://github.com/follow-redirects/follow-redirects/issues/235 (localhost is intended for end users or hosts to deny, and the package is for HTTP/HTTPS.)
This is marked as a LOW since the maintainer is not sure if this is a vulnerability, but it's still best to highlight it. :)
PoC
Have a service like so running locally:
const http = require("http")
const server = http.createServer((req, res) => {
console.log("Received headers:", req.headers)
res.writeHead(200, { "Content-Type": "text/plain" })
res.end("Something private! But Hello from Server 2 :)")
})
server.listen(3001, () => {
console.log("Server two running on http://localhost:3001")
})
Run the package in dev mode, pnpm dev. Feed these URLs:
http://localhost:3089/?url=http://[::]:3001&width=4000
http://localhost:3089/?url=http://localhost:3001&width=4000
http://localhost:3089/?url=http://127.0.01:3001&width=4000
Impact
Disclose internal web services?
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @jmondi/url-to-png | all versions | 2.1.2npm install @jmondi/url-to-png@2.1.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @jmondi/url-to-png, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @jmondi/url-to-png to 2.1.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-342q-2mc2-5gmp is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.
Frequently Asked Questions
Is GHSA-342q-2mc2-5gmp in your dependencies?
Find it across npm, including transitive dependencies.