Critical PHP vulnerabilities: the update cannot wait

On 21 October 2026 the PHP team shipped out-of-band updates and the European cyber-incident response team CERT-EU issued an emergency advisory. The reason: two vulnerabilities rated 9.2 out of 10 that let an attacker run their own code on your server. No login, no password, and no action at all from anyone on your staff.

PHP is the language most of the web is written in: WordPress, Joomla, OpenCart, Bitrix, Laravel, and hundreds of hand-written scripts that tie a site to a CRM, to email or to an accounting system. If your site does not run PHP, you can close this article. If you do not know what it runs on, that in itself is a reason to ask whoever looks after it.

What exactly was found

There are two vulnerabilities, both rated 9.2, and both lead to the same outcome — execution of somebody else's code on the server without authentication.

CVE-2026-109618 — a crash when memory runs out

PHP has a memory_limit setting: a request that has eaten too much memory is terminated by force. The problem is how exactly it is terminated. PHP can break off at a moment when the request's internal data is only half filled in — while a file submitted through an upload form is being parsed, for instance. The clean-up after such a request mistakes the half-finished data for the real thing and tries to free memory that never existed. And that memory may hold whatever an attacker put there with earlier requests.

CVE-2026-109619 — leftovers from the previous request

The second hole is about the server not quite «forgetting» the previous visitor. Internal state belonging to one request sometimes survives the freeing of memory — after a fatal error, say. The next request to land in the same worker process gets to use those leftovers before the ordinary initialisation zeroes them out.

At risk is any PHP installation serving web requests: PHP-FPM, Apache with the mod_php module, php-cgi, FrankenPHP, LiteSpeed. The PHP team names Apache with mod_php as the riskiest combination of all — and it is still the default on many cheap hosting plans.

The proof-of-concept exploit fires on a single unauthenticated request — before the site's own code starts running at all. Which means security plugins, strong passwords and two-factor authentication will not help here: the attack happens one level below them.

Which versions are at risk

Anything below these versions is vulnerable:

PHP branch	Safe version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 and older	no longer supported

A separate risk category is commercial and open products with PHP embedded inside them where you cannot see it from the outside: control panels, network appliances, video surveillance systems, corporate portals. A list of such software is maintained in the Dutch NCSC repository.

Why «our site is small» does not work here

Nobody is looking for your site specifically. Once exploitation examples become public — and they already are — automated scanners start within hours, sweeping the entire internet in order. They do not care whether it is a factory's site or a hairdresser's page: all that matters is whether the server answers with a vulnerable version.

What follows is the usual script: a web shell is uploaded to the server, the site starts serving spam or pages of somebody else's advertising, the domain lands on blocklists and email from it stops arriving. And the losses are counted not by whoever broke in but by whoever needs the site for work.

What to do, step by step

1. Find out your version. In a hosting panel that is the «PHP version» or «PHP Selector» section; on your own server, the php -v command. It matters that you check the version the site actually runs on rather than the one on the command line: they are often different.
2. Update within your own branch. Going from 8.2.29 to 8.2.35 is a fix inside one branch: compatibility is preserved and the site does not break because of it. Do not confuse that with going from 8.2 to 8.4 — that one does need testing.
3. If you are on 8.1 or older, those branches are no longer supported. Given the seriousness, the PHP security team released minimal fixes for 7.4, 8.0 and 8.1 as well, and some hosting providers keep their own builds. But the right answer is moving to a supported branch, and it is better planned now than next time.
4. Restart the handlers. Without a restart of php-fpm or Apache the worker processes carry on running the old code, and the update effectively does nothing.
5. Verify the result. The simplest way is a temporary page with phpinfo(), to be deleted immediately after the check, or the «PHP version» section of the panel after a reload.

Hosting customers will most often have nothing to do by hand: the larger providers received the fixes in advance and update their machines themselves. It is worth sending support a single line — «has PHP been updated to the releases of 21 October 2026?» — and getting the answer in writing.

If you cannot update right now

Sometimes the site is old and the update needs preparation. There are then temporary measures that narrow the window for an attack:

• deny memory exhaustion as an entry point: memory_limit=-1, set so that the application cannot override it, plus a check that no pool or directory puts the limit back;
• reduce post_max_size — 8M for sites with no file uploads, 32M if uploads are needed — and keep upload_max_filesize below it;
• disable session.upload_progress.enabled and restart every worker process;
• on PHP 8.5 also disable fatal_error_backtraces;
• limit request size and complexity at the web server or proxy.

None of these measures makes an installation safe. They only block the known paths — only the update closes the problem completely.

If even that is impossible, CERT-EU advises the simple and unpopular answer: take the vulnerable service off the public internet until the fix is installed and verified.

Where this comes from

• CERT-EU, Security Advisory 2026-018 «Critical Vulnerabilities in PHP»
• The release announcement on php.net
• The technical description of CVE-2026-109618 and CVE-2026-109619

---

Not sure which PHP version your site runs on, or whose job it is to update it? Write to us — we will check your systems and tell you plainly whether there is a threat and what to do about it.