Critical PHP vulnerabilities: why charitable foundations should check their websites right now

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 an attacker to run their own code on the server — with no login, no password and no action by staff or volunteers.

PHP is the language most websites on the internet are written in: WordPress, Joomla, OpenCart, Bitrix, Laravel. The sites of charitable foundations, volunteer initiatives and fundraisers are almost always built on it, which means the risk applies to them just as much as to large companies.

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 means for fundraising

Nobody looks for one particular foundation's website. Once examples of a break-in become public — and they already are — automated scanners start within hours and sweep the entire internet in order. They do not care whether it is a corporate portal or a page collecting money for a vehicle: all that matters is whether the server answers with a vulnerable version.

The most dangerous scenario for a foundation is not the one where the site is visibly broken. The opposite: the site works, looks the same as always — while the card number or the donation jar details on the collection page have been quietly changed. Donations keep coming, people transfer money, and it is discovered only when someone reconciles the receipts. Alongside this come the usual consequences: a web shell on the server, someone else's advertising on the pages, the domain on blocklists and email that stops reaching donors and partners.

The third risk is the data. Donor lists, requests from military units and documents on the handover of aid 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 a foundation has no one responsible for the site and the hosting, the check can be ordered externally — for instance from SmartGT: they will look at the resources and say plainly whether there is a threat.

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