The vulnerability CVE-2026-62993 in Smarty allows for Server-Side Request Forgery (SSRF) due to improper handling of HTTP redirects when fetching remote resources using the {fetch} function. The core issue is that Security::isTrustedUri() only validated the initial URL provided to {fetch}. However, PHP's file_get_contents() function, which was used internally to retrieve the content, follows HTTP redirects by default. This meant that if an attacker could supply a URL that initially pointed to a trusted host (passing the trusted_uri check) but then redirected to an arbitrary internal or external endpoint, the trusted_uri allowlist could be bypassed. This effectively allowed an attacker to make the server perform requests to arbitrary locations.
My analysis focused on the provided commit diffs for both Smarty 4.x and 5.x branches. Both commits introduce a change to how file_get_contents() is called when a security policy is active and a remote resource is being fetched. Specifically, a stream_context_create() call is added to configure the HTTP stream wrapper to disable follow_location (set to 0) and limit max_redirects to 1. This prevents file_get_contents() from automatically following redirects, thus ensuring that only the initially validated URL is accessed.
Therefore, the vulnerable functions are those that contained the file_get_contents() call without this redirect-disabling context:
Smarty\FunctionHandler\Fetch::handle in src/FunctionHandler/Fetch.php for Smarty 5.x.
smarty_function_fetch in libs/plugins/function.fetch.php for Smarty 4.x.
These functions would appear in a runtime profile when the {fetch} template function is used to retrieve a remote resource, and the vulnerability is triggered by supplying a URL that redirects to an attacker-controlled target.