Skip to content
Mimir Lab
← Back to blog

how it works

PHP2Shell: the two-line email every business owner should send their host

Published · php, security, wordpress, hosting, smb

In short: on 21 October 2026 PHP shipped four security releases, 8.5.12, 8.4.27, 8.3.36 and 8.2.35, for two critical flaws called PHP2Shell. If your WordPress or Joomla site sits on shared hosting, the update is your host’s job, not yours. Your job is smaller: ask, in writing, whether it has been done.

The email to send today

If you are on shared hosting, write to your host’s support. Two lines:

For the domain [yourdomain.ch]: is the fix for CVE-2026-109618 and CVE-2026-109619 installed, and on which PHP version?
Was PHP restarted after the update?

A good answer: a version equal to or above 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or a backported fix with both CVE IDs named, plus a yes on the restart.

What happened

PHP is the language that runs on the server and builds your site’s pages on every visit. WordPress and Joomla run on PHP.

The two flaws are CVE-2026-109618 and CVE-2026-109619. PHP rates them 9.2 out of 10 (CVSS 4.0); the US NVD database rates them 9.8 (CVSS 3.1). The first needs no login at all: it goes through the way PHP reads data sent from a form. Both let an attacker run code on the server, which means taking control of it.

The sequence. On 17 October an Amazon honeypot, a decoy server that records attacks, logged the first exploit attempt, four days before the patch. On 20 October PHP announced the releases and the CVE IDs leaked. A proof-of-concept video had been published by mistake, and on the morning of the 21st the embargo broke. The patch, planned for the 22nd, shipped on 21 October.

Why it probably reaches your site too

PHP runs on 69.3% of sites whose server-side language is known (W3Techs, 22 October). WordPress alone is on 39.6% of all websites. And about 1 in 3 WordPress sites runs PHP 8.1 or older, versions the 21 October releases do not cover.

The demonstrated case is Apache with mod_php, the most exposed setup. But php.net lists FPM, php-cgi, FrankenPHP and LiteSpeed as affected too. No need to guess which one your host uses: ask.

Attacked or not? What we actually know

As of 22 October:

  • there have been attempts to exploit since 17 October (Amazon);
  • CISA, the US cybersecurity agency, had observed no exploitation when it published on 21 October;
  • the two flaws are not in CISA’s catalogue of exploited vulnerabilities (KEV);
  • the BACS, the Swiss Federal Office for Cybersecurity, told Keystone-SDA it knows of no attacks in Switzerland, but that its overview is incomplete.

So: attempts yes, confirmed exploitation no. But “nobody knows” is not the same as “nothing happened”.

What does not protect you

Updating WordPress. The “update” button in the dashboard updates WordPress, plugins and themes. PHP sits underneath, on the server, and is separate software.

A web application firewall (WAF) on its own. The BACS says it plainly: update immediately, a WAF alone is not enough.

Configuration changes. Some tweaks reduce the risk, but according to php.net there are no complete mitigations and updating is the only safe choice. If your host replies “we changed the configuration”, that is a stopgap, not the fix.

Same day, three different choices

I read the status pages of three Swiss hosts.

At 15:45 on 21 October, cyon took every customer website offline: web hosting, managed servers, Sitebuilder, the my.cyon panel and webmail. Email kept working; webmail was back that evening. cyon runs CloudLinux and chose to keep sites offline until the vendor delivered patched builds. Those arrived late and rolled out from 2:49. At 4:00 on 22 October every site was reachable again, with patches on all servers: about 12 hours and 15 minutes offline.

METANET warned customers at 10:30 on 21 October, put interim protection in place that day and installed the CloudLinux builds that arrived overnight. On 22 October the work on managed, shared and reseller hosting was complete. VPS and root servers remain the customer’s job.

Hostpoint posted four notices on 21 October. The last one says the security update was installed on all servers by 17:30.

None of these choices is wrong. cyon gave up 12 hours of availability so as not to leave unpatched servers online; METANET protected in the interim while it waited. Which trade-off suits you depends on what an online site is worth to you. What matters is knowing what your host did, and hearing it from them.

What to do today

If you are on shared hosting, the first step is the two-line email at the top of this article. Below, how to read the answer.

The restart matters: until PHP restarts, the old version is still running in memory.

A good answer takes one of two forms:

  • a version equal to or above 8.2.35, 8.3.36, 8.4.27 or 8.5.12, depending on your branch;
  • or a “backport”, a fix applied to your version without changing its number, with both CVE IDs named in the reply. Some distributions and vendors work this way: the number looks old, but the flaw is closed.

Either way, with a yes on the restart. “We use a firewall”, “we changed the configuration” or “update WordPress” are not enough.

If the server is yours, a VPS or a dedicated server, send the same email to your sysadmin: there, the patch is on you.

Do not check it yourself with a public phpinfo page or an anonymous “checker” site. A phpinfo page shows your server’s configuration to anyone. A checker whose operator you don’t know receives your domain and learns you are looking for a flaw. Your host’s written answer is worth more than both.

One date to note: security support for PHP 8.2 ends on 31 December 2026. If the answer today is “8.2.35”, you are covered, but ask now when you will move to a newer version.

Found with AI, fixed by people

The part that strikes me most is how it was found. The flaws were reported by Wiz Research, Calif and OpenAI’s Codex Security team.

Wiz’s timeline: first bug on 19 August, code execution on Drupal on the 20th, on WordPress on the 21st, reported to PHP on 24 August, acknowledged by PHP on 21 September, patched on 21 October. Wiz used AI models at every step: finding the bug, building the exploit, detecting it, validating the patch. According to Wiz, a single researcher did in a week what would have taken a team months.

And the problem was not new. According to the PHP Foundation, a 2024 Quarkslab audit had already found the first signs of the memory flaw; the fix then stalled for months, which the Foundation itself calls a structural failure. Calif reported code execution on 11 August, OpenAI the same day, Wiz on the 24th.

My reading: AI shortens the road from “known defect” to “exploitable defect”. For anyone with a website, how fast the patch arrives matters more than before.

If your site runs PHP 8.1 or older

There is no 21 October release for these versions. Some hosts say they have patched older versions on their shared servers too: if that is your case, get it in writing, with the CVE IDs.

Otherwise there are three roads. Update PHP to a supported version, testing the site on a copy first. Move the site onto an up-to-date base. Or, for unsupported versions that cannot be updated, CISA advises taking PHP systems offline. It is an extreme measure, but for that case it is the recommendation.

The bigger point

The Mobiliar 2026 study of 507 Swiss SMEs with 1 to 49 staff found that only 28% have an emergency plan and 15% run regular audits.

PHP2Shell is a good test. Who in your company knows which PHP version your site runs? Who has your host’s support contact? If the answer is “nobody”, today’s email is the first piece of the plan.

If you don’t know whom to write to or how to read the answer, there is the free first meeting, 30 minutes: tell me the situation and I’ll tell you where to start.

This article is also available in Italian.

Sources

Checked on 22 October 2026.

https://www.php.net/archive/2026.php

What it means