Blog

Most people do not think about PHP.

They think about WordPress, online stores, client portals, booking systems and the little administration panel someone built in 2017 and nobody has touched since. PHP is simply somewhere underneath it all, quietly receiving requests and assembling pages.

That anonymity has served it well. PHP became part of the plumbing: inelegant in places, remarkably durable and too useful to remove.

This week, the plumbing demanded attention.

On October 21, the PHP project disclosed two critical vulnerabilities—CVE-2026-109618 and CVE-2026-109619—that can allow an unauthenticated attacker to execute code on a server. In plain English: under the right conditions, someone may be able to take control without logging in first.

The flaws affect PHP installations serving web requests through common setups including PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers mod_php particularly exposed because a malicious request can trigger the attack before the website's own code begins running.

Read PHP's official security advisory

That last detail matters. A well-maintained WordPress installation may still be sitting on a vulnerable PHP runtime. So may a Laravel application with impeccable code. The lock on the apartment door is not much consolation when the problem is in the building's foundation.

What actually broke

Both vulnerabilities concern the way PHP handles memory and request state.

CVE-2026-109618 involves an out-of-memory condition interrupting PHP while internal request data is only partly initialized. During cleanup, PHP may then treat invalid data as legitimate.

CVE-2026-109619 involves internal state surviving after the memory behind it has been released. A later request handled by the same worker can encounter that stale state before PHP resets it.

These are technical failures with an unusually direct consequence: remote code execution. A successful attacker could potentially run commands with the permissions of the PHP process, alter a site, steal credentials, read application data or use the server as a foothold into something larger.

The vulnerabilities are especially uncomfortable because they exist below the application layer. They are not primarily the result of a careless plugin, a reused password or an administrator clicking the wrong attachment. They sit inside the engine.

The forgotten server problem

The obvious targets will be well-known platforms. WordPress, Drupal, Laravel and countless commercial products rely on PHP. The less obvious targets may be more interesting.

There is the old reporting dashboard reachable at an obscure subdomain. The internal tool that became public during the pandemic. The staging site protected by nothing more than an unguessable URL. The client project that was ‘temporary’ five years ago. The appliance with a browser-based management interface whose underlying technology was never documented.

Software rarely announces that it has become infrastructure. It simply works for long enough that people stop looking at it.

That is the real lesson here. Most businesses do not know precisely where PHP runs. They know which websites they own. Those are not the same inventory.

PHP can live inside containers, marketplace images, control panels, vendor products and old virtual machines. Updating the PHP package on the main web server does not update a bundled runtime inside a Docker image. Updating WordPress does not necessarily update PHP. Updating the host does not automatically repair every appliance running on it.

The PHP incident is therefore partly a security problem and partly an accounting problem. Before an organization can patch its systems, it has to remember that they exist.

Supported is a security feature

Fixed versions are now available:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1 and earlier no longer receive normal updates from the PHP project. Some operating-system vendors and long-term-support providers may issue backported packages, and the PHP security team has published minimal source backports for PHP 7.4, 8.0 and 8.1. But these are escape routes, not a persuasive reason to remain on obsolete software.

Version support can feel administrative when everything is working. During a critical disclosure, it becomes the difference between installing an update and beginning an emergency migration.

Old software does not become safer because it has been quiet.

What to do now

Start with an inventory, not an assumption.

Identify every internet-facing site, container, virtual machine, control panel and vendor product that may include PHP. Check the runtime itself rather than relying on the version shown inside a CMS dashboard.

Then update to one of the fixed releases or install the patched package supplied by your operating-system or managed-hosting vendor. Rebuild and redeploy containers rather than merely updating the host beneath them. Confirm that the new runtime is the one actually serving requests.

If you cannot patch immediately, PHP has published temporary measures involving memory limits, request-size controls, session upload progress and worker restarts. These can reduce exposure to known attack paths, but the project is explicit: there is no complete mitigation. Updating is the safe resolution.

Restrict anything that does not need to be public. Review logs and file changes. Rotate credentials if there is evidence of compromise. And resist the seductive idea that a web-application firewall turns vulnerable software into maintained software.

Maintenance is part of the product

Websites are usually discussed as visible objects: typography, animation, conversion, speed and content.

But every polished interface rests on a stack of less glamorous decisions. Runtime versions. Package sources. Container images. Backups. Access controls. Someone knowing which machine performs which job.

None of this is especially cinematic. That may be why it is neglected.

The two PHP vulnerabilities are serious, but they are also clarifying. They reveal the difference between owning a website and maintaining a system. The first can be purchased. The second is a continuing practice.

PHP spent years becoming invisible.

For the moment, anyone responsible for a website should look directly at it.

Operational guidance from the Dutch National Cyber Security Centre