GHSA-cq55-c7wv-pxmq: SSRF
When a Security policy is active, {fetch} validates the requested remote URL against the trusteduri allowlist via Security::isTrustedUri(). For non-http:// schemes (e.g. https://) the resource was then read with filegetcontents(), 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 trusteduri 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 trusteduri 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 (followlocation => 0, maxredirects => 1) to filegetcontents() for remote resources. Behavior is unchanged when no security policy is set, since there is no trusteduri to bypass.
Workarounds
Avoid fetching remote resources from within templates under untrusted control; ensure hosts listed in trusteduri do not expose open redirects.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/smarty/smartyto a version that resolves this vulnerability.Fixed in 4.5.7 - Upgrade
Upgrade
composer/smarty/smartyto a version that resolves this vulnerability.Fixed in 5.8.2 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 5.8.2 - Configuration
When a security policy is active, pass a stream context to file_get_contents() for {fetch} remote resources with follow_location => 0 and max_redirects => 1 to disable redirect following.
{fetch} remote resource fetching (Security policy enabled) follow_location (stream context) / max_redirects = 0 / 1 - Compensating control
Avoid fetching remote resources from within templates under untrusted control; ensure hosts listed in trusted_uri do not expose open redirects that could redirect requests to non-trusted internal targets.
Event History
Frequently Asked Questions
Who is exposed to this SSRF bypass?
Deployments using Smarty with an active Security policy are exposed if templates can fetch attacker-influenced remote URLs, a trusted_uri host has an open redirect, and the redirect can reach an internal target. Deployments without a Security policy are not affected by this trusted_uri bypass behavior.
What does an attacker need to exploit it?
The attacker needs to supply or influence a {fetch} target and use an open redirect on a host allowed by trusted_uri. The initial URL must pass the allowlist check, after which redirect following can send the server request to an attacker-chosen internal endpoint.
What can be done if updating is not immediately possible?
Avoid fetching remote resources from templates where the fetch target is under untrusted control. Also ensure hosts in trusted_uri do not provide open redirects.
How is the issue fixed?
The issue is fixed in version 5.8.2. With a Security policy active, remote {fetch} requests use a stream context that disables redirect following.