Your Website Is Working. Why Isn't That Enough Today?
PHP2Shell, two critical vulnerabilities, and a very good reason to find out who's keeping an eye on the doors to your digital business.
October 21, 2026
Picture a perfectly ordinary morning for a business owner. The coffee is hot, orders are coming in, and you've finally replaced that website image you meant to change back in the spring. Then a message pops up on your phone: “PHP needs an urgent update.” You look at your perfectly functioning website and think: wonderful, now even the internet needs a vehicle inspection.
The website does load, after all. The buttons work, products land in the shopping cart, and nothing suggests an uninvited guest has entered your digital premises. But this is where the less pleasant part of the story begins: a website that looks perfectly fine tells you very little about how secure it is behind the scenes. An attractive storefront doesn't tell you what's happening behind the doors.
On October 21, 2026, the PHP developers released fixes for two critical vulnerabilities. Under certain conditions, these flaws can allow an attacker to execute their own code on a server without even logging in to the website. This time, the update notification deserves a little more attention than yet another request to accept cookies. 1
First, Meet the Person Working Behind the Counter
If the letters PHP mean absolutely nothing to you, you're in good company. You don't need to understand how an engine works to drive a car, and you don't need to know how to code to run an online store. Still, it helps to understand why the mechanic is calling about the engine when the bodywork is looking as shiny as ever.
PHP is a programming language and runtime that powers much of the behind-the-scenes work on many websites. While visitors browse an attractive product catalogue, the server is processing requests, preparing content, and retrieving information from a database. WordPress and many online stores use PHP to do rather more than display a static poster.
Think of a website as a shop. The design is its window display, the content fills the shelves, and PHP helps run the operation behind the counter. You can buy the most beautiful shop sign in town, but it won't help if a dangerous fault has been discovered in the back room. And that's exactly the kind of fault we're talking about.
“But There's Nothing Interesting on My Website”
It's an understandable reassurance. A small business might assume that cybercriminals are only interested in banks, government ministries, and vaults straight out of an action movie. Who would want to attack a local carpenter's website or a blog about growing tomatoes?
An automated attacker, however, doesn't need to be fascinated by your products. They may be interested in your server's resources, the opportunity to plant someone else's content, or information accessible to the website's processes. A small shop is still a shop, and someone can try the door handle without first reading the company's mission statement.
At the same time, a vulnerable website is not necessarily a compromised website. That distinction matters: concern should prompt action, not turn a possibility into a disaster that has supposedly already happened. A serious opportunity for an attack has been identified, and it needs to be addressed before a hypothetical scenario starts featuring your company's name and address.
An Exclamation Mark in Your Password Won't Save You This Time
The two flaws are publicly known together as PHP2Shell. Their technical identifiers are CVE-2026-109618 and CVE-2026-109619, and CERT-EU assigns each a severity score of 9.2 out of 10. That does not mean 92% of websites have been hacked; it describes the severity of the vulnerabilities. 2
The dangerous capability is called remote code execution, or RCE. In plain English, it means an attacker may be able to make the server execute their instructions. What they could do next depends on access permissions and how well the server is isolated, but the consequences for the website and the data it can access could be serious.
One flaw involves the handling of out-of-memory conditions: a request may be interrupted before internal data structures have been properly initialized, and cleaning them up later can cause memory corruption. The other allows references to already-freed memory to remain, potentially exposing them to the next request handled by the same worker process. Developers will recognize the second issue as use-after-free. Everyone else just needs to know that the system may start relying on information it should no longer trust. 34
Here's a particularly unpleasant detail: in an Apache setup using mod_php, an attack has been demonstrated before the application's own code even runs. That means even a carefully designed login form may never get a chance to do its job. The warning also covers PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. An administrator password like “OnlyIKnow2026!” won't fix this PHP vulnerability. 1
The Good News: The Doors Can Be Fixed
There is some very practical good news here: fixes are available. You don't need to wait for a miracle cure or rebuild your entire website just because something unpleasant is happening on the internet again. You need to apply the appropriate PHP security update for your particular website.
As of October 21, 2026, these are the first releases containing fixes for both vulnerabilities. If you're reading this later, check for newer security releases and announcements from your provider as well. What counts as the “latest version” changes over time; the numbers below identify the fixes released on that particular date. 1
| PHP version branch used by your website | First fixed release |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
There's a little detective work hidden in those numbers: seeing “PHP 8.5” does not prove that you're running 8.5.12. Professional Linux package maintainers may also backport security fixes into builds that retain an older base version number. In that case, you need confirmation that the specific package contains fixes for both vulnerabilities, not a guess based on the first digit. Anyone still using PHP 8.1 or an older branch should check their provider's support arrangements or plan a move to a supported environment. 2
The Biggest Button in the Control Panel Isn't Always the Right One
After hearing news like this, it's tempting to open your hosting control panel and select the highest version number available. It feels great: a couple of clicks and you're the hero who just saved the business. Then you open your online store and discover that your payment module wasn't informed of your heroic achievement.
Moving to a different PHP version branch can reveal compatibility problems in older code, modules, or plugins. PHP's own migration documentation recommends checking compatibility before switching a live production environment. So, for a website running on a supported PHP 8.3 branch, updating to 8.3.36 may be enough to address this particular issue. It doesn't necessarily need to jump to PHP 8.5 on the same day. 6
A good website maintainer first identifies what powers the site, prepares a way to restore it if necessary, and applies the appropriate fix. They then test the things you can't see in a screenshot of the homepage: form submissions, logins, orders, and other business-critical functions. A business owner needs a working store, and the success of a security update cannot be measured by how pretty the homepage looks.
So Who Exactly Should You Call?
A website owner doesn't need to become a server administrator overnight. The most important thing is to establish who is responsible and make sure the outcome has actually been checked. Problems begin when the owner assumes the hosting company handles everything, the hosting company is waiting for the customer to select an option in the control panel, and the developer stopped being involved the moment the site went live.
Start by contacting your hosting provider or website maintainer and asking: “Has the PHP environment running my website received fixes for both vulnerabilities disclosed today, and has the website been tested after the update?” Add the two CVE numbers if more detail is needed. You don't need a computer science degree to ask that question, but the answer ought to be more specific than “we take security seriously.”
Other domains and forgotten test websites need checking too. For example, cPanel allows different domains to use different PHP configurations, so switching one setting doesn't necessarily secure everything you operate. 5 That test site you've been promising to “delete tomorrow” for the past three years suddenly becomes a surprisingly important member of the family.
There is another important detail for maintainers: php -v shows the version of the command-line PHP executable being run, but that alone doesn't confirm the state of the PHP environment serving the website. 7 You need to verify the actual request handlers, every instance, and that old worker processes are no longer serving requests. Having an updated file on disk is not the same as having the update running.
If the fix cannot be applied immediately, CERT-EU recommends considering isolating the vulnerable application from the public network until the patch has been installed and verified. Temporary protective measures are no substitute for the actual fix. 2 A “Website Under Maintenance” notice only helps if the solution genuinely blocks public access to the vulnerable environment. A sign on the door doesn't lock it.
What Are We Really Paying a Professional For?
If you're only now planning your first website, all of this might come as a surprise. The advertisement made it sound so simple: choose a design, add some text, and click “Publish.” And that's a perfectly valid way to start. Building a website yourself is possible, and learning how to do it is worthwhile.
But once a business website is published, its working life is only beginning. It needs updates, backups, compatibility checks, and someone who responds when news like this breaks. Even a professionally built website can be affected by a vulnerability discovered later in the technology it uses. A professional's value becomes clear in how that risk is managed.
So when commissioning a website, it's worth asking about more than the colour scheme and the price. Who will follow security advisories? Who will update the system, test the ordering process, and help if something breaks? These are the questions that give a beautiful design something it desperately needs: the ability to keep working.
Updating a website also doesn't remove the need to investigate suspicious changes if you've already noticed any. An unfamiliar administrator account or an unexplained redirect is a reason to investigate; installing a patch does not, by itself, prove that nothing happened beforehand. Backups, logs, and monitoring therefore belong in routine maintenance, not just in the emergency-response ritual. 8
Today, website owners don't need to memorize every technical acronym. They simply need to find out who's responsible for their website, whether both fixes have been applied, and whether everything important still works afterward. Once those questions have been answered, it's safe to get back to the orders, the customers, and that image you finally got around to replacing.
You will probably need another coffee, though. This one's gone cold in the meantime.
Sources
- PHP project security announcements and October 21, 2026 releases.
- CERT-EU: Critical Vulnerabilities in PHP — Security Advisory 2026-018.
- PHP: RCE via OOM corruption.
- PHP: RCE via stale global state.
- cPanel: MultiPHP Manager.
- PHP: Migrating from PHP 8.4.x to PHP 8.5.x.
- PHP: Command line options.
- WordPress: Hardening WordPress.
