The PHP flawin plain English.
Two flaws in PHP, the language most small business websites run on, let a stranger run their own commands on the server without logging in. Here is what they do, how they were fixed, and what to ask your host.
What happened
In October 2026, researchers at Calif found two serious flaws in PHP and reported them privately to the people who make it, so a fix could be ready before anyone else knew. Details leaked online on 20 October, two days early. PHP brought its fix forward and released it the next day, 21 October.
The flaws were nicknamed php2shell, because they can turn a normal visit to a PHP website into a shell: a way for someone to type commands on the server as if they were sitting at it. The US cyber security agency, CISA, told every organisation to update straight away. Amazon's security team later said someone had tried to use the flaws on 17 October, before they were public.
Why it matters to you
PHP is the language behind WordPress, Joomla, Drupal, WooCommerce and a large share of hand built sites. You never see it. It runs on your web host's server, and builds each page as a visitor asks for it.
That is why this one is serious. It is not a flaw in a plugin you could remove. It sits underneath everything, and the attacker does not need a password, a form or a login page. Sending the right requests to the website is enough.
How the flaws work
There are two flaws, and both come down to PHP keeping notes it should have thrown away.
The first (CVE-2026-109618) happens when PHP runs out of memory part way through setting up a visit. It stops what it was doing, but some of its notes are left half written. The clean up that follows trusts those half written notes, and an attacker who can cause this on purpose can steer what happens next.
The second (CVE-2026-109619) is about leftovers between visitors. One server process handles many visits in turn. Some of PHP's notes from one visit were not properly cleared, so the next visit could read memory that no longer belonged to it. Besides running commands, this can leak whatever was in that memory, such as passwords and keys.
Both are rated critical: 9.2 out of 10 by PHP, 9.8 by the US national flaw database. Using them reliably takes some skill, but that is the kind of work that ends up built into automated attack tools, which then try every website they can find.
Who is affected
Every PHP website that has not been updated. The fixed versions are:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Anything older on those lines is affected. PHP 8.1 and older no longer get official updates, so there is no fixed version to move to; some hosts and Linux distributions have made their own fixes for them. Qualys, a security company, found that 71% of the PHP installs it can see are on these older lines.
Sites where PHP runs inside the Apache web server (often called mod_php, common on older shared hosting) are the most at risk. Other setups are affected too.
How it was fixed
The real fix is the new PHP version. Once it is installed, every PHP process must be restarted, or the old one carries on answering visitors.
PHP also listed settings that make the flaws harder to use while you wait, such as switching off upload progress tracking and lowering the largest upload allowed. It was clear that none of these make an unpatched site safe. Firewall services such as Cloudflare added rules to block known attack patterns, which helps, but only for visits that go through the firewall.
One thing catches people out. Some hosts and Linux distributions fix the flaw without changing the version number to match, so a server can say 8.4.26 and still be safe. The only way to be sure is to ask whoever looks after it.
What to do now
You do not need to understand any of the above to act on it. Send your host or developer this:
Ask your developer“Which version of PHP does our website run, is it patched for php2shell (CVE-2026-109618 and CVE-2026-109619), and were the PHP processes restarted afterwards?”
If the answer is PHP 8.1 or older, ask what it would take to move to a supported version. Every new flaw from now on will stay open on those versions for good.
How Mendbird helps
Many sites tell every visitor which version of PHP they run, in the replies their server sends. The Mendbird reads that, and checks it against the public lists of known flaws, updated daily. php2shell was in those lists the day the fix came out, and a site still showing an affected version is marked Dangerous, with the version that fixes it and the question to ask.
On a Watch plan, the Mendbird checks your site every morning and emails you the day something serious is new, so you hear about the next php2shell from us rather than from the news, or from your host after the fact.
Plenty of sites hide their PHP version, which is good practice. When we cannot see it, the report says so, rather than guess. A small helper you install on your site, which reads the real versions from the inside, is on the way.