← In The Field
In The Field

In The Field 027: Patched The Same Day: The PHP Flaw Every Website Owner Should Know About

2 min read
Screenshot of the PHP.net page showing the security advisory about the critical remote code execution vulnerabilities

Screenshot of the PHP.net page showing the security advisory about the critical remote code execution vulnerabilities

If your website runs on PHP, this one matters.

Security advisory: Critical remote code execution vulnerabilities, update now

If you are a BizPinPro client, the short version is this: every server I manage was patched late on October 21, the same day the fix was released.

What Happened

On October 21, 2026, the PHP team released fixes in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 for two critical flaws. Both vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell by researchers, carry a severity rating of 9.2 out of 10.

In plain terms, the flaws let an attacker without an account run code on a web server. No password, no login, no foothold needed. That is about as serious as it gets for a website.

This was not theoretical for long. watchTowr reported observing active exploitation attempts of both flaws on October 21. CISA urged organizations to patch immediately, noting the flaws affect all PHP installations serving web requests.

Why Updating Was The Only Real Fix

Some early alerts mentioned configuration changes as a stopgap. The PHP team was clear that those were not enough: only updating fully protects a server.

Older sites face a harder problem. End-of-life branches, PHP 8.1 and older, no longer receive updates from the PHP project. A site still running an old version of PHP has no official patch coming.

What I Did

When the fix was released, everyone running PHP tried to download it at once, and the download servers were overloaded. Rather than wait and try again by hand, I set up a process that kept retrying patiently until the files came through.

Every server I manage was updated late that same day.

Custom Code Did Not Make Me Immune

I build every site in custom PHP, with no WordPress and no plugins. That cuts down a lot of risk, but it did not matter here. This flaw was in PHP itself, the language underneath everything. A custom site and a WordPress site running the same version of PHP were equally exposed.

What protected my clients was not how the sites were built. It was that someone was watching and acted the day the fix came out.

If You Are Not A BizPinPro Client

Ask whoever hosts your website a simple question: has the server been updated to a patched version of PHP, and when? If they can give you a version number and a date, good. If they cannot answer, or do not know what you are talking about, that tells you something too.

If your site runs on an old, unsupported version of PHP, it needs more than a patch. It needs an upgrade.

The Foundation Connection

A Digital Foundation is not just how a site is built. It is whether anyone is watching it after launch. Paying for hosting means paying for someone to act when something like this happens, not weeks later, not when it becomes a headline, but the day the fix is available.

This week, that is exactly what it meant.

Our In The Field posts describe problems we see every day. Many of these problems are solved when people follow proper standards. Ours are right here. See our standards →

Terms Used in This Post

Is This Your Site?

If your digital presence has problems like these, we can fix them. Start with a free assessment. No commitment, no pitch, straight conversation about what's wrong and what it would take to fix it.

Get a Free Assessment →
Find us on