- CVE-2026-82531 lets forged data in Smarty templates run as PHP code on the server. Fixed versions are 4.5.8 and 5.8.5.
- The flaw sits where one template extends another. The record says a value is left empty. WebPulse reads this as a lost check, though the record does not say so.
- Leaders should ask which applications embed Smarty, which versions they run, and whether user data reaches templates that use inheritance.
An empty value appears to have removed a safeguard
Forged data placed in a Smarty template can turn into running PHP code on the server. The fix is in Smarty 4.5.8 and in 5.8.5 for the 5.x line.
This is CVE-2026-82531, a code injection flaw in the Smarty PHP template library. The National Vulnerability Database (NVD) published the record on October 6, 2026. The record says one value, the top-level nocache_hash, is left empty during template inheritance. It does not say what that hash is for. WebPulse reads the empty value as a lost check. That reading is interpretation, not part of the record.
How the flaw works
Smarty builds pages from templates. Templates can extend one another, so a child template builds on a parent. This is called template inheritance.
The NVD record says the top-level nocache_hash is not restored during extends: or multi-component inheritance. It is left null, meaning empty.
Smarty also writes PHP cache files and later includes them. According to the record, an attacker can supply assigned data that contains a forged SmartyNocache marker. Smarty copies that marker word for word into the regenerated cache file. When the file is included, the attacker's PHP runs.
Here is WebPulse's interpretation of the mechanism. The hash appears to act as the check that tells genuine template markers from look-alikes in user data. With the hash empty, a forged marker is not caught. The record states the result, which is arbitrary PHP execution on include, and does not describe the hash's purpose.
Why one flaw carries two scores
The same scorer, VulnCheck, rated this flaw twice. The older CVSS 3.1 system gives 8.1. The newer CVSS 4.0 system gives 9.2.
Both vectors show an attack over the network with no privileges and no user interaction. Both rate the impact on confidentiality, integrity and availability as high.
The difference is in how hard the attack is. The 3.1 vector marks attack complexity as high (AC:H). The 4.0 vector marks it low (AC:L), with attack requirements present (AT:P).
A leader should read this as one flaw, not two opinions. Exploitation depends on conditions in how an application uses Smarty. The record names two of them: template inheritance and data passed into templates.
Who carries the risk
The people most exposed are those who own applications built on Smarty. A library like this sits inside the application. Nobody installs it as a product, so nobody may be watching it.
The record does not say whether attacks are under way. It also does not say which applications are exposed. Those answers depend on each organisation's own code.
That is why the fix is more than a version bump. The flaw needs attacker-influenced data to reach a template. Whether that happens is a question about your application, not about Smarty.
Questions to put to your team
First, which applications use Smarty, and at what version? Include copies bundled inside other software. Smarty 4 releases below 4.5.8 and Smarty 5 releases below 5.8.5 are the ones in scope.
Second, do any templates use extends: or inherit across several components? That is the path the record describes.
Third, does any user-supplied data, such as form fields or profile text, reach Smarty's assigned variables? If it does, and those templates use inheritance, the flaw is reachable.
Fourth, after upgrading, do cache files created by the old version need to be rebuilt? The record does not say, so ask the vendor or the maintainers.
If the empty value did remove a check, as it appears to, the lesson is plain. A boundary between data and code is only as strong as the state that enforces it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: NIST NVD.
