Two holes in PHP rated 9.2: what it means for business and what delay costs

On October 21, 2026 the PHP team released out-of-band updates, and the European cyber incident response team CERT-EU published an emergency advisory. Two vulnerabilities with a severity score of 9.2 out of 10 let an attacker run their own code on the server — with no login, no password and no action whatsoever from the company's staff.

For a business this is not abstract technical news. PHP is the language most websites are written in: WordPress, Joomla, OpenCart, Bitrix, Laravel, plus hundreds of homemade scripts that tie a site to a CRM, to mail or to 1C. If your company has a website, an online store or a customer account area, the only question is whether you managed to update in time or not.

What exactly was found

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

CVE-2026-109618 — a breakdown when memory runs short

PHP has a setting called memory_limit: a request that has eaten too much memory is aborted by force. The problem is exactly how it is aborted. PHP can break off at the moment when the request's internal data is only half filled in — while it is parsing a file sent through an upload form, for example. The cleanup after such a request takes the unfinished data for real data and tries to free memory that never existed. And that memory may hold whatever the attacker put there with earlier requests.

CVE-2026-109619 — leftovers from the previous request

The second hole is about the server not fully “forgetting” the previous visitor. Internal state that belonged to one request sometimes survives the freeing of memory — after a fatal error, say. The next request that lands in the same worker process gets to use those leftovers before the usual initialisation zeroes them out.

At risk is any PHP installation that serves web requests: PHP-FPM, Apache with the module mod_php, php-cgi, FrankenPHP, LiteSpeed. The riskiest setup, the PHP team says, is precisely Apache paired with mod_php — it is still the default on many cheap hosting plans.

The proof-of-concept exploit works with a single unauthenticated request — before the site's own code even starts running. Which means security plugins, complex passwords and two-factor authentication are of no help here: the attack happens one level below.

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 support

A separate risk category is commercial and open-source products with PHP built in, even though nothing shows it from the outside: control panels, network devices, video surveillance systems, corporate portals. A list of such software is kept in the repository of the Dutch NCSC.

What this costs a company

Nobody is hunting for your business specifically. Once exploitation examples go public — and they already are public — automated scanners start up within hours and work through the entire internet in order. They do not care whether it is a factory's website or a hair salon's page: all that matters is whether the server answers with a vulnerable version.

After that comes the part that is counted in money. A web shell is uploaded to the server, the site hands out spam or someone else's ads, the domain lands on blacklists — and mail from it stops reaching customers and partners. Meanwhile the store is not selling, sales staff receive no enquiries, and search engines get a chance to flag the site as dangerous. Recovery is not one night of work but a cleanup, reissuing keys, changing passwords and getting the domain off blacklists, which drags on for weeks.

Data is a separate risk. If the server holds a customer database or an order history, a leak means questions put to the company by customers and by the regulator, not just a technical incident.

What to do — step by step

1. Find out your version. In a hosting control panel this is the “PHP version” or “PHP Selector” section; on your own server it is the command php -v. It is important to check the version the site actually runs on, not the one in 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 have no support. Given the seriousness of the situation, 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 decision is a move to a supported branch, and it is better to plan it now rather than next time.
4. Restart the handlers. Without restarting php-fpm or Apache, worker processes keep running the old code and the update effectively does nothing.
5. Check the result. The simplest way is a temporary page with phpinfo(), which must be deleted right after the check, or the “PHP version” section in the panel after the restart.

Hosting customers most often will not have to do anything by hand: large providers received the fixes in advance and update their machines themselves. It is worth writing one line to support — “has PHP been updated to the versions of October 21, 2026” — and getting the answer in writing.

If updating right now is not possible

It happens that a site is old and the update needs preparation. In that case there are temporary measures that narrow the window for an attack:

• shut off 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 without file uploads, 32M if uploads are needed, and upload_max_filesize kept lower;
• disable session.upload_progress.enabled and restart all worker processes;
• on PHP 8.5 additionally disable fatal_error_backtraces;
• limit the size and complexity of requests at the level of the web server or the proxy.

None of these measures makes the installation safe. They only close off known paths — the problem is fully closed only by the update.

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

Where this information comes from

• CERT-EU, Security Advisory 2026-018 “Critical Vulnerabilities in PHP”
• The release announcement of the updates on php.net
• Technical description of CVE-2026-109618 and CVE-2026-109619

---

If your company has no one responsible for versions and updates on the server, an audit can be commissioned externally — for example from SmartGT: they will check the resources and say plainly whether there is a threat and what to do about it.

Author of the article — SmartGT. Original source: “Critical PHP vulnerabilities: the update cannot be postponed”.