CVE-2026-82531 is a high severity (CVSS 8.1) PHP code injection flaw in Smarty before 4.5.8 and 5.x before 5.8.5. Template inheritance through extends leaves a cache hash unset, so forged marker text can end up executable in a cache file. Upgrade to 4.5.8 or 5.8.5.
What's affected
The record says Smarty before 4.5.8, and Smarty 5.x before 5.8.5. The GitHub security advisory I fetched lists the same: affected versions below 5.8.5 and below 4.5.8, patched versions 5.8.5 and 4.5.8. It rates the issue High.
Conflict note: the advisory text describes the mechanism in terms of Smarty 5, where the top level hash is never restored on the extends path. The record and the patched versions list cover the 4.x line as well, so follow the version lists and upgrade both branches.
The trigger is a template loaded through extends or multi-component inheritance. Plain templates that do not use inheritance do not follow that path, though it is common in layouts that extend a base template. The package on Packagist is smarty/smarty.
How to check if you're exposed
Find the installed version through Composer:
composer show smarty/smarty
composer why smarty/smarty
The second command tells you which package pulled Smarty in, which matters because many PHP applications bundle it as a transitive dependency. Some projects vendor a copy under their own directory instead of using Composer. Search for it:
grep -rl "class Smarty" --include=*.php . | head
If the version is below 4.5.8 on the 4.x line, or below 5.8.5 on the 5.x line, you are in scope. Then check whether your templates use extends. If they do, and any value echoed into the page can be controlled by a user without escaping, the conditions described in the advisory are present.
What to do now
- Upgrade to Smarty 4.5.8 or 5.8.5, whichever matches your major version, and run your template tests.
- Clear the compiled and cache directories after upgrading, so no tampered cache file survives.
- Escape every value that you echo into a template, especially data that came from users, even when it seems harmless.
- Make the cache and compiled template directories writable only by the application user, and keep them outside the web root.
- Search cache files for the nocache marker text in places where it should not appear, and treat any hit as a sign of tampering.
Why it matters
This is code injection, tracked as CWE-94. Smarty marks parts of a template that must not be cached with special comment markers, and when it writes the cache it copies marked content as is, while ordinary output gets PHP tags neutralized. If the hash that identifies real markers is empty, text that looks like a marker is accepted. Content inside is copied verbatim, and the next include of the cache file runs it as PHP.
That chain depends on a user controlled value reaching the page unescaped, which is the reason the advisory scores attack complexity as high. Even so, remote code execution on a web server is the top outcome for an attacker, and template engines sit in the path of every page. The record does not list this CVE as exploited in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does it affect Smarty 4 or only Smarty 5?
The record and the patched version list cover both lines, with fixes in 4.5.8 and 5.8.5. The advisory text describes the Smarty 5 mechanism.
Is clearing the cache really needed?
It is a sensible step. A cache file written before the upgrade could still contain forged content, so rebuild it from patched code.
Sources
Last reviewed: 18 October 2026.
