Critical PHP vulnerabilities: check the website of your business or initiative

Many veterans start their own business after service, take on a community project or launch an educational initiative — and almost always a website appears at some point. It was usually built on WordPress: quickly, cheaply, often by an acquaintance or a freelancer with whom there has been no contact for a long time.

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. The reason is two vulnerabilities with a severity score of 9.2 out of 10, which let an attacker run their own code on your server. No login, no password, not a single action on your part.

Below, without unnecessary technical language: what happened, why it concerns even the smallest website and which three sentences are worth writing to your hosting provider today.

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 “I have a small website” does not help here

Nobody looks for your website specifically. Once examples of the attack 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 website of a large company or the page of a workshop with five services: all that matters is whether the server answers with a vulnerable version.

After that the scenario is typical: someone else's code is uploaded to the server, the site starts handing out spam or pages with other people's advertising, the domain ends up on blacklists, and the mail sent from it stops reaching customers. For a small business this hurts twice as much: the website is often the only shop window, and recovery takes weeks and money that was not budgeted.

We warn separately about what usually follows. After news like this, “specialists” become active and write to site owners themselves: “you have a vulnerability, give us access urgently”. Hand over access to your site and hosting only to someone you know and whom you pay for maintenance.

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 you do not know what your website is built on and who is responsible for it, that is already a reason to sort it out without waiting for the next piece of news. A check can also be ordered from SmartGT, the team that maintains the cluster's digital resources.

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