PHP2Shell: two critical PHP flaws, and the one question to ask your host

What happened

On October 21, 2026, the PHP project disclosed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, together nicknamed PHP2Shell. They allow remote code execution on affected PHP servers: in plain English, an attacker who can reach a vulnerable server over the internet could run their own commands on it, without needing a password.

The PHP team shipped an emergency release the same day. The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The NSA urged organizations to patch immediately or take unpatched systems offline until they could be mitigated, and the UK's NCSC gave similar advice. Organizations including Wikimedia temporarily took services offline to patch. Widespread exploitation had not been confirmed at disclosure: the urgency is patching before that changes, not panic.

Why this matters to a small business

PHP quietly runs a huge share of the web, including every WordPress site. If you have a small-business website, there is a good chance PHP is involved somewhere, and an equally good chance you have never touched it yourself, because your hosting company manages it. That is normal. It also means the fix is probably not yours to install. It is yours to confirm.

What to do

• Email your web host (or whoever manages your site) one question: "Is this server running a PHP version patched for PHP2Shell, meaning 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer?"
• If the answer is anything other than a clear yes, ask when it will be, and consider the NSA's advice about unpatched systems.
• If your site runs on a platform that manages PHP for you (most site builders, managed WordPress hosts), they almost certainly patched quickly, but it costs nothing to ask.
• While you're at it, ask whether the server advertises its PHP version in response headers. It shouldn't.

Can you check this from the outside?

Only partially, and anyone who says otherwise is selling fear. Some servers advertise their PHP version in a response header, and our free check reads that and compares it to the patched releases. But many servers hide the version (good practice), and a header can lag behind reality. A passive check only sees what your site shows the public. We verify from the inside.