Answer in brief
CVE-2026-62993 records a Medium severity (CVSS 0.0) vulnerability in Smarty: SSRF via redirect bypass of trusted_uri using {fetch}. The current sources do not mark it as known exploited. The current feed maps smarty/smarty (composer), smarty/smarty (composer), smarty-php/smarty (generic), smarty/smarty (packagist) and additional mapped packages. Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 0.0. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps smarty/smarty (composer), smarty/smarty (composer), smarty-php/smarty (generic), smarty/smarty (packagist) and additional mapped packages. Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| smarty/smartycomposer | >=5.0.0,<5.8.2 | 5.8.2 |
| smarty/smartycomposer | <4.5.7 | 4.5.7 |
| smarty-php/smartygeneric | >= 5.0.0, < 5.8.2 || < 4.5.7 | Not reported |
| smarty/smartypackagist | >=5.0.0 <5.8.2 | 5.8.2 |
| smarty/smartypackagist | >=0 <4.5.7 | 4.5.7 |
Published upstream
Aug 31, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 8, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 31, 2026
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 trusted_uri when a security policy was active. For resources handled by file_get_contents(), 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 trusted_uri allowlist, and perform server-side request forgery. This issue is fixed in versions 4.5.7 and 5.8.2.
Quoted source text, attributed separately from HOL analysis.