PHP vulnerability: what to do now, even on an old PHP version

01What is wrong with PHP

PHP is the programming language under a large part of the web. WordPress, Drupal, Magento and Laravel run on it, as do many custom portals and back-office systems. It contains two flaws, CVE-2026-109618 and CVE-2026-109619, which the PHP project's advisory rates 9.2 on the 10-point CVSS scale. An attacker can use them to run code on your server without logging in.

The flaw is in PHP itself, not in a plugin or theme, so updating WordPress or your framework does not fix it. According to the PHP project, every installation that serves web requests is at risk, whether it runs through PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. The developers see the highest risk with mod_php, where a single unauthenticated request has been shown to start the attack before a line of your own code runs.

This is the situation as of Wednesday evening, 21 October 2026. With the details now public, it can change quickly.

02Why so many websites went offline

The Dutch National Cyber Security Centre (NCSC) warned that attackers could use these flaws against any website or web server running PHP, the Dutch government reports. At that point there were no signs of active exploitation. The advice to organisations was still to weigh the risks themselves and consider taking their site offline until the update arrived.

Many did. The update came out at 15:43, a little earlier than announced, and by five o'clock the first sites were back.

That trade-off differs per system. An information website that is down for an afternoon loses some visitors. A customer portal with personal data that someone breaks into costs far more: a data breach, a report to your data protection authority, and customers who are owed an explanation. Going offline on Wednesday bought time. Nothing more.

03What to do now about the PHP vulnerability

Now that the update is out, the work itself is not complicated. Most of the time goes into finding everything that runs on PHP.

• List your PHP systems. Look beyond your website: the customer portal, the intranet, a forgotten campaign site, a subsidiary's WordPress site, or a tool a supplier built for you years ago.
• Check which version each system runs. On your own server, php -v tells you. In WordPress it is under Tools > Site Health > Info > Server. On shared hosting, ask your hosting provider.
• Update to a version with the fix. Those are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux distributions received the patches in advance, so your server's package manager is usually the fastest route.
• Restart and verify. Restart PHP-FPM or Apache after the update, or the old version keeps running. If you use containers, rebuild your images and redeploy them: an image built on a fixed PHP version does not update itself.

Then check on the production server itself which version is running. An update in the test environment does not count.

If you cannot update yet

Sometimes you cannot update straight away, for example because the application needs testing first or the supplier cannot be reached. For that situation the PHP project lists a few settings that close known attack paths:

• session.upload_progress.enabled=0 in php.ini or in the FPM pool configuration, followed by a restart of every worker. It does not work through ini_set() or a .user.ini file.
• A low post_max_size: 8M for applications without uploads, 32M when uploads are needed.

The project is clear about it: these measures reduce the risk but do not make an installation safe. Only the update does. Use them for the hours or days until the update is in place, and write down who will do that update and when. If your site sits behind a web application firewall, ask your provider whether it already has rules for these flaws.

04Old PHP versions: where the real problem is

The PHP project no longer releases updates for PHP 8.1 and older. Given the severity, the team did publish minimal source patches for PHP 7.4, 8.0 and 8.1, meant for people who compile PHP themselves. Some distributions and long-term support vendors offer a patched build. On anything older, you depend entirely on your vendor.

PHP 8.2 also stops getting security updates after 31 December 2026. Updating to 8.2.35 today closes this flaw, but in just over two months you face the same question again.

With an old PHP version, updating is rarely a single click. An application stuck on PHP 7 is usually stuck for a reason: a framework nobody maintains anymore, functions that disappeared in PHP 8, or code nobody fully understands. Then the PHP update is really a modernization project. How to recognise such a system and when replacing it makes sense is covered in our post on recognising and replacing legacy systems.

A system like that does not have to be rebuilt in one go. In legacy modernization we work step by step: we keep what works, replace what holds you back and keep the system running the whole time. For an application on PHP 7, the first step is usually making the code ready for a supported PHP version, so it receives updates again. After that you tackle the parts that slow you down most.

05After this week: faster at the next flaw

This was not the last serious flaw in software your business runs on. What you sort out this week saves you hours next time:

• Keep a list of your applications, with the language, version, hosting provider and who handles updates for each one.
• Agree with your supplier or hosting provider how fast a critical security update gets installed, and who you call when it happens.
• Run updates through a fixed route, so a new PHP version is tested and rolled out without manual work on the server.
• Put in your planning when each version loses support. For PHP 8.2 that is the end of this year.

Isatis has been ISO 27001 certified since 2015, and that standard asks exactly this: know what you run and show that you keep it secure.

06Frequently asked questions

Is my WordPress site vulnerable?

If the server runs a PHP version without the fix, yes. Updating WordPress or a plugin does not solve it, because the flaw is in PHP. On shared hosting, your provider updates PHP. Ask whether they have done so, and to which version.

Is the vulnerability being exploited?

On Wednesday 21 October, the Dutch NCSC and the PHP developers had seen no signs of active exploitation. Now that the technical details are public, that can change fast. Do not wait for reports of attacks.

Should I take my website offline?

Only if you cannot update soon and people log in to the site or it handles personal data. For most sites, updating now is faster and wiser than going offline.

Are websites without PHP safe?

From this flaw, yes. Sites such as Rijksoverheid.nl do not use PHP and, according to the Dutch government, are not affected. Other software still needs its own updates, of course.

Not sure which PHP version your portals and integrations run on, or is an application stuck on a version that no longer gets updates? Get in touch for a short call. You will hear back within 24 hours.