Security & operations
The PHP vulnerability of 21 October It hits well-built sites too
Two critical PHP vulnerabilities allow code to be executed on the server — without authentication, and before your application even starts. How well your site is built makes no difference. Every publicly reachable PHP installation is affected.
What was published on 21 October
The PHP project disclosed two vulnerabilities, both allowing unauthenticated remote code execution — an attacker can run code on the server with no credentials at all. Both are rated critical at CVSS 9.2.
CVE-2026-109618 concerns out-of-memory handling: PHP can break off midway through preparing a request and leave partially initialised internal data that is then treated as valid. CVE-2026-109619 concerns state that outlives a request: a later call handled by the same worker can reach data whose memory has already been freed.
Both are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you are on one of those, you are out of it.
This flaw has nothing to do with your code. It sits in the layer that runs your code — and it fires before a single line of your application executes.
Why a well-built site does not help here
According to the advisory, everything that serves web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed. The highest risk is with mod_php, where a single unauthenticated request was shown to trigger the attack before application code runs.
That is what sets this announcement apart from most others. Whether your server runs Contao, WordPress, Shopware or something custom makes no difference. Whether your forms validate input makes no difference. The layer below is what gets attacked.
The flip side: there is nothing in your application you could fix. Updating is the only complete answer.
Four questions to settle today
None of them needs a developer. Your host can answer all four — and if they take their time, that tells you something too.
- Which PHP version runs on each of your sites? Not the one you assume, the one actually being served. And per site, not per server — one host often runs several versions side by side.
- Is it already patched? The reference versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 or later. A higher major number is not enough: 8.4.20 is newer than 8.3.36 and still vulnerable.
- Who installs the update, and when? On managed hosting that is your provider — ask for a date, not an intention. On your own servers it is you. Linux distributions received the patches in advance, so the package is often already waiting.
- Are there systems nobody is thinking about? An old test environment, a subdomain from three years ago, the customer portal of a discontinued project. Reachable is reachable. In our experience those are the systems an attack comes through, not the main site everyone watches.
Old PHP versions are now the real problem
PHP 8.1, 8.0 and 7.4 no longer receive regular updates from the project. Minimal backports exist for these two flaws specifically, but that is an emergency measure, not a solution — at the next disclosure you are back where you are today. The 8.2 branch also ends on 31 December 2026.
This is where it gets uncomfortable for a company our size. In a forty-person business there is almost always an application that has been running for years, that nobody looks after, and whose original supplier is no longer reachable. As long as nothing happens, it costs nothing. On a day like this it becomes the most expensive system in the building.
In our case the day looked like this: read the advisory, go through our own systems, move every site we host onto the patched versions. That is not an achievement, it is the baseline — the only question is whether somebody owns it.
When the big answer is the wrong one
A 9.2 rating tempts people into fundamental decisions. We would advise against that — this week at least.
- Do not start a migration you had not planned. Updating a PHP version takes hours. Replacing a system takes months. Mix the two and in four weeks you are still on the vulnerable version, now with a project running as well.
- Do not switch provider because they have not patched yet. Ask for a date first. A host that updates within days is working normally. One that will not answer a specific question specifically is the actual problem — and already was before this flaw.
- Do not rely on the workarounds. The advisory lists configuration changes that reduce the attack surface where updating is not possible in the short term. It states explicitly that they do not make an installation safe. Fine as a bridge over a weekend, not as a state of affairs.
Quellen
Do you know which PHP version your site runs?
If you cannot answer that in a minute, we will look for you — including sites we do not host. We will tell you what has to be patched, what can wait and what should be replaced. And if everything is fine, we will say that too.
