CVE-2026-109618 and CVE-2026-109619: an analysis of two critical PHP vulnerabilities and the response procedure

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. Both vulnerabilities are rated 9.2 and allow arbitrary code to be run on the server without authentication.

Since PHP remains the most widespread server-side language of the web — WordPress, Joomla, OpenCart, Bitrix, Laravel and a substantial volume of home-made integrations with CRM and accounting systems all run on it — the range of affected systems covers most organizations with a web presence of their own, including research and analytical institutions.

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.

Risk assessment for institutions

The key feature of this case is that no targeted attack is needed. Once exploitation examples are published, mass scanning of the address space begins within hours and does not distinguish between types of organization: the only selection criterion is the version the server answers with.

For research and analytical institutions, two specific consequences are added to the typical ones (placing a web shell, sending spam, the domain ending up on blocklists, loss of mail delivery). The first is data integrity: research data sets, regulatory documents and survey results stored on the same server become open to alteration, and the substitution of figures in a publication is discovered with a long delay. The second is reputational: material published in the institution's name is taken as its official position.

When assessing your own risk, it is worth including systems where PHP is present implicitly: equipment management panels, network devices, video surveillance systems and internal portals. They rarely make it onto the list of resources due for updating.

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

---

An external perimeter audit and a version check can be ordered, among others, from SmartGT — a team that maintains the digital resources of partner organizations.

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