Critical PHP vulnerabilities: what this means for the websites of reconstruction projects

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 allow someone else's code to be run on the server without authorization.

PHP is the language most websites are written in: WordPress, Joomla, OpenCart, Bitrix, Laravel. In the context of reconstruction this means programme portals, fundraising pages, registers of damaged property, the sites of civil society organizations and contractors — that is, resources where personal data, documents and payment details sit side by side.

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.

Why a hacked project website is a matter of trust, not just technology

Nobody looks for your project specifically. Once exploit examples become public — and they already are — automated scanners start within a few hours and go through the entire internet one address after another. They do not care whether it is the portal of a national programme or the page of an initiative serving a single community: all that matters is the version the server replies with.

The typical consequences are known: a webshell on the server, spam and someone else's advertising on the pages, the domain on blacklists, email that stops being delivered. For reconstruction projects, however, something else costs the most. First, the substitution of payment details for contributions — the classic scenario in which a site with donations is hacked not to damage it, but to quietly change the account number. Second, public reporting: if documents and figures can be changed from outside, the very point of the openness on which the trust of donors and partners rests is lost.

Third, people's data. Applications, registers of damaged property and the questionnaires of programme participants usually sit on the same server as the website.

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 project has no one responsible for updates and access, an audit of the resources can be ordered externally — for instance from SmartGT.

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