GHSA-cq55-c7wv-pxmq
Fix: smarty-php/smarty#1194GHSA-cq55-c7wv-pxmq is a Server-Side Request Forgery (SSRF) vulnerability in smarty/smarty. O3 Security confirms whether GHSA-cq55-c7wv-pxmq is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Smarty: SSRF via redirect bypass of trusted_uri using {fetch}
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-cq55-c7wv-pxmq.
Real-World Exposure
smarty/smarty🐘smarty/smartyReal-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
When a Security policy is active, {fetch} validates the requested remote URL against the trusted_uri allowlist via Security::isTrustedUri(). For non-http:// schemes (e.g. https://) the resource was then read with file_get_contents(), which follows HTTP redirects by default. Because isTrustedUri() only validates the initial URL, an open redirect on an otherwise-trusted host could be used to redirect the request to a non-trusted, internal target — bypassing the trusted_uri policy.
Impact
An attacker who can supply a fetch target (or influence one) and who has an open redirect available on a trusted host can cause the server to issue requests to attacker-chosen internal endpoints, defeating the trusted_uri allowlist (server-side request forgery).
Patches
Fixed in 5.8.2. When a security policy is active, {fetch} now passes a stream context that disables redirect following (follow_location => 0, max_redirects => 1) to file_get_contents() for remote resources. Behavior is unchanged when no security policy is set, since there is no trusted_uri to bypass.
Workarounds
Avoid fetching remote resources from within templates under untrusted control; ensure hosts listed in trusted_uri do not expose open redirects.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | smarty/smarty | ≥ 5.0.0&&< 5.8.2 | 5.8.2 |
| 🐘Packagist | smarty/smarty | all versions | 4.5.7 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for smarty/smarty. 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 smarty/smarty to 5.8.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-cq55-c7wv-pxmq 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-cq55-c7wv-pxmq 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-cq55-c7wv-pxmq. 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-cq55-c7wv-pxmq in your dependencies?
O3 detects GHSA-cq55-c7wv-pxmq across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.