CVE-2026-62993: Smarty: SSRF via redirect bypass of trusted_uri using {fetch}
Smarty is a template engine for PHP, facilitating the separation of presentation (HTML/CSS) from application logic. Prior to 4.5.7 and 5.8.2, depending on the release line, Smarty's {fetch} handling in libs/plugins/function.fetch.php and src/FunctionHandler/Fetch.php used Security::isTrustedUri() to validate only the initial remote URL against trusteduri when a security policy was active. For resources handled by filegetcontents(), including HTTPS URLs, PHP followed HTTP redirects by default. An attacker who could supply or influence a fetch target and had an open redirect on a trusted host could redirect the request to an attacker-chosen internal endpoint, bypass the trusteduri allowlist, and perform server-side request forgery. This issue is fixed in versions 4.5.7 and 5.8.2.
Other sources
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.
— GitHub
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
Smartyto a version that resolves this vulnerability.Fixed in 4.5.7 - Upgrade
Upgrade
Smartyto 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 remote resources with follow_location set to 0 and max_redirects set to 1 to disable redirect following (bypass of trusted_uri via open redirects is possible otherwise).
Smarty {fetch} (libs/plugins/function.fetch.php / src/FunctionHandler/Fetch.php) stream context for file_get_contents() = follow_location => 0, max_redirects => 1 - Compensating control
Avoid fetching remote resources from within templates under untrusted control; ensure hosts listed in trusted_uri do not expose open redirects.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Deployments using Smarty before 4.5.7 or 5.8.2 are exposed if a security policy is active, {fetch} can be supplied or influenced by an attacker, and a trusted_uri-allowlisted host has an open redirect.
What does an attacker need to exploit the bypass?
The attacker needs to control or influence the URL passed to {fetch} and use an open redirect on a host permitted by trusted_uri. The redirect can then send the server-side request to an attacker-chosen internal endpoint.
Are HTTPS fetch targets affected?
Yes. Resources handled through file_get_contents(), including HTTPS URLs, can be affected because PHP follows HTTP redirects by default.
How can this be remediated?
Upgrade Smarty to version 4.5.7 on the 4.x release line or 5.8.2 on the 5.x release line.