GHSA-95wr-3f2v-v2wh
GHSA-95wr-3f2v-v2wh is a security vulnerability in craftcms/cms. O3 Security confirms whether GHSA-95wr-3f2v-v2wh is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Craft CMS has a host header injection leading to SSRF via resource-js endpoint
Blast Radius
craftcms/cms🐘craftcms/cmsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The resource-js endpoint in Craft CMS allows unauthenticated requests to proxy remote JavaScript resources.
When trustedHosts is not explicitly restricted (default configuration), the application trusts the client-supplied Host header.
This allows an attacker to control the derived baseUrl, which is used in prefix validation inside actionResourceJs().
By supplying a malicious Host header, the attacker can make the server issue arbitrary HTTP requests, leading to Server-Side Request Forgery (SSRF).
Details
The vulnerability exists in AppController::actionResourceJs().
The function validates that the url parameter starts with assetManager->baseUrl. However, baseUrl is derived from the current request host. If trustedHosts is not configured, the Host header is fully attacker-controlled.
Attack chain:
- Attacker sends request with controlled
Hostheader. - Application derives
baseUrlfrom the malicious Host. urlparameter is required to start with thisbaseUrl.- Validation passes.
- Guzzle performs a server-side HTTP request to the attacker-controlled host.
- SSRF occurs.
This does not rely on string parsing bypass. It relies on Host header trust.
PoC (safe reproduction steps)
Environment:
- Craft CMS 5.9.12
- Default configuration (no trustedHosts restriction)
- Docker deployment
-
Start a listener inside the container: python3 -m http.server 9999
-
Send a request to resource-js with a controlled Host header.
-
Observe that the internal listener receives a request (OOB confirmation).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | craftcms/cms | ≥ 5.0.0-RC1&&< 5.9.15 | 5.9.15 |
| 🐘Packagist | craftcms/cms | ≥ 4.0.0-RC1&&< 4.17.9 | 4.17.9 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for craftcms/cms. 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 craftcms/cms to 5.9.15 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-95wr-3f2v-v2wh 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-95wr-3f2v-v2wh 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-95wr-3f2v-v2wh. 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-95wr-3f2v-v2wh in your dependencies?
O3 detects GHSA-95wr-3f2v-v2wh across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.