Older PHP code often rebuilds stored data with a function called unserialize(). When that data comes from a visitor, it can let an attacker run code on your server. It sits behind exploited flaws in Joomla, Laravel and PEAR. Here's what it means for your business.
Most security flaws are mistakes in how a feature was built. Some come from a feature doing exactly what it was designed to do, in a place it was never meant to be used. One of the best-known examples in PHP is a function called unserialize(), and it sits quietly inside a great deal of code written a decade or more ago.
It has been behind serious flaws in Joomla, Laravel and a widely used PHP library called PEAR Archive_Tar, flaws that allowed attackers to run their own code on other people's servers. If your business relies on an older PHP application, the same habit may appear somewhere in its code.
When your server trusts data it shouldn't
Web applications constantly need to save information and load it back later: the contents of a shopping basket, a visitor's preferences, the state of a half-completed form. PHP offers a convenient pair of built-in tools for this. One packs data, including complex "objects" (bundles of data and behaviour that the application works with), into a line of text. The other, unserialize(), unpacks that text and rebuilds whatever it describes.
The problem appears when the text comes from a visitor. Think of flat-pack assembly instructions. If your own team wrote the instructions, you get the furniture you expected. If a stranger can hand in their own instructions, your server will faithfully assemble whatever they describe, using parts already in your warehouse. In a large application with hundreds of ready-made parts, a skilled attacker can arrange them so that the end result runs their own code on your server.
Security specialists call this "PHP object injection". The PHP manual now carries a direct warning: "Do not pass untrusted user input to unserialize() regardless of the options value of allowed_classes. Unserialization can result in code being loaded and executed due to object instantiation and autoloading, and a malicious user may be able to exploit this."
The pattern has a long record:
- Joomla, 2015 (CVE-2015-8562). According to the US National Vulnerability Database (NVD), versions 1.5 to 3.4.5 of this popular content management system allowed attackers to run their own code, "as exploited in the wild in December 2015".
- Laravel, 2018 (CVE-2018-15133). Older versions of this framework could be made to run code, NVD says, provided the attacker knew the application's secret key. The US Cybersecurity and Infrastructure Security Agency (CISA) added it to its catalogue of Known Exploited Vulnerabilities on 16 January 2024.
- PEAR Archive_Tar, 2020 (CVE-2020-28949). CISA describes this as an "unserialization attack" in a widely used PHP library for handling archive files. The library is used by Drupal core, which shipped a fix. CISA added it to its catalogue on 25 August 2022.
As of 23 October 2026, both the Laravel and Archive_Tar flaws remain in CISA's catalogue of vulnerabilities known to be exploited.
What could go wrong for your business
When an attacker can run their own code on your server, the realistic consequences include:
- Data exposure. Customer details, orders, account information and internal records stored by the application may be read or copied.
- Loss of control of the server. An attacker can change your website, plant hidden ways back in, or use your server as a stepping stone to other systems.
- Downtime and disruption. Investigating and cleaning up after a break-in often means taking systems offline, sometimes for days.
- Financial and reputational cost. Investigation and rebuilding cost money, and lost trust is slow to win back.
- Compliance obligations. Depending on your sector and the data you hold, a breach may need to be reported to regulators, partners or customers. These are potential outcomes, not certainties. Many applications use this function safely, with data only the server controls. The risk lies in the places where visitor-supplied data reaches it, directly or indirectly, and those places are not always obvious.
Could your website be next?
Attackers rarely sit down and pick one business to target. More often, they use automated tools that scan large numbers of websites for known flaws, and then follow up wherever something responds. A small or little-known website is not automatically safe: it only needs to be reachable and running something with a known weakness.
Flaws in widely used platforms and libraries, like the three above, are the easiest for automated tools to look for, because the same weakness exists on every site running the affected version. The Joomla flaw was exploited in the wild, and the Laravel and Archive_Tar flaws are on CISA's list of vulnerabilities known to be exploited.
The same habit in your own custom code is harder for a generic tool to find, but that is not the same as being safe. It may be found by someone probing your application more closely, or reached through a second weakness, such as a leaked secret key, a file-upload feature or an outdated library. Older systems tend to have several such weaknesses, which is why these problems chain together so easily.
A clean record so far is reassuring, but it isn't evidence.
Why legacy PHP applications deserve attention
This is a problem of older code and older PHP versions, not of PHP as it stands today.
The pattern used to be normal. Storing packed-up PHP data in cookies and hidden form fields was common advice in the PHP 5 era. Code written then still runs in many live systems, and it was never reviewed against today's guidance.
Older PHP lacks the safeguards. PHP 7.0 added an option to limit what unserialize() may rebuild, and PHP 8.0 closed a less obvious route by which simply opening certain files could trigger the same problem. PHP 5 has neither. As of 23 October 2026, W3Techs reports that 7.7% of websites using PHP still run PHP 5. Every PHP 7 version is past end of life, so those versions won't change.
Old libraries widen the risk. How much damage an attacker can do depends on the ready-made parts the application has loaded. Legacy applications tend to carry old, unpatched libraries, and the longer they go without updates, the more publicly known attack recipes are likely to apply.
To be fair, this isn't unique to PHP. Node.js has had the same class of bug: a package called node-serialize (CVE-2017-5941) allowed code execution in the same way. Current PHP has added safeguards, and well-maintained PHP code avoids the pattern for untrusted data. The exposure lies in older code written before that guidance became standard.
What this means for your organisation
You don't need to read code to act on this. You need a few answers about your application:
- Which PHP version does it run in production, and is that version still supported?
- How old is the codebase, and when did someone last review it for security?
- How out of date are the libraries, plugins and frameworks it relies on?
- Is there anyone on your team, or at your supplier, who fully understands how it handles data from visitors?
If the honest answer is "we're not sure", that is useful to know. An application that relies on patterns current guidance warns against, running on a version of PHP that may no longer receive fixes, is a business risk whether or not anything has gone wrong yet.
A clear picture of the application's condition is also the starting point for any modernisation decision.
Recommended next step
Don't wait for a security incident to find out whether your application trusts data it shouldn't. Our free Legacy PHP assessment looks at the areas this issue touches: your PHP version, the age and patterns of your code, and the libraries and plugins your application depends on. It is designed to help you understand potential security concerns, maintenance challenges and modernisation opportunities.
Once you have that picture, we're happy to talk it through with you. Some applications are best brought up to date where they are. For others, a move to the modern Node.js stack, which Sketchmonk builds on, may be the right path, depending on the application's requirements, architecture and your business goals. Node.js is not a security guarantee, and serialisation bugs exist in every ecosystem; what protects a system is safe defaults, current dependencies and a team that keeps them that way.
Understand your risk before an incident forces you to.
Free Legacy PHP Risk Assessment
Not sure whether your codebase relies on unserialize()? We'll review your PHP version, code patterns, hosting setup and dependencies, and tell you plainly where you're exposed and what your options are, whether that's a patch, an upgrade or a migration.
