php2shell: What the PHP Security Emergency Means for Your Author Website

What happened? On Wednesday, October 21, the PHP project shipped emergency updates for two critical security holes in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed "php2shell." PHP is the programming language that runs WordPress and a large share of the rest of the web. If your author website runs on WordPress, or on any server you or a developer set up yourself, this one is worth twenty minutes of your day.

The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The official PHP changelog lists the security fixes in those releases, and the US Cybersecurity and Infrastructure Security Agency told organizations to patch immediately, saying the flaws "allow for unauthenticated remote code execution." In plain terms, an attacker doesn't need your password to take over a vulnerable server.

Why it was rushed

The fixes weren't supposed to come out this week. According to security firm Huntress, details of the two flaws leaked online on October 20, ahead of a coordinated disclosure. The PHP security team moved its release forward, rated both flaws critical (9.2 on the CVSS v4.0 scale), and published the patched versions around 9:30 a.m. Eastern on the 21st.

The UK's National Cyber Security Centre put out an alert the same day, urging organizations to update and, where that isn't possible, to consider taking affected systems offline until they can be fixed.

Is anyone actually being attacked? Reports differ by the hour. CISA said it had not seen exploitation when it published. Huntress said it hadn't seen attacks across its own customers as of 10 a.m. Eastern but that others were reporting them. Researchers at watchTowr now list the flaws as exploited in the wild. With working attack code reported to be circulating, it's safest to assume unpatched sites will be probed soon if they haven't been already.

The cloud security company Wiz, whose researchers were involved in finding the flaws, says nearly every PHP version going back to 5.4 is affected by at least one of the issues. PHP 8.1 and older no longer get official fixes, which is why CISA advises taking those systems offline until they're upgraded.

Is your site affected?

That depends on how your site is built.

WordPress (self-hosted, through a host like Bluehost, SiteGround, GoDaddy or similar): Yes, WordPress runs on PHP. Most shared and managed WordPress hosts update PHP for their customers, and many will have done it already. But not every host does it automatically, and some let customers pin an old version. Don't assume. Check.

WordPress.com: This is hosted WordPress, and the company runs the servers. Patching is on them, not you.

Squarespace, Wix, Shopify, Substack: These are hosted platforms. You never touch the server or choose a PHP version, so there's nothing for you to patch. If any of them uses PHP somewhere behind the scenes, fixing it is the platform's job.

A site a developer built and hosts for you, or a server you manage yourself: Ask the developer or check it yourself. Any site that runs PHP and hasn't been updated since Wednesday morning is at risk, including older forums, shop plugins or a mailing-list tool sitting on the same server.

A plain static site (just HTML pages, or one built with tools that don't run PHP on the server): not affected by this.

A plain checklist

1. Ask your host which PHP version your site runs. Many hosting dashboards show it under something like "PHP settings" or "Site tools." If it's not 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer, ask them when they're updating, or switch it yourself if the panel lets you.
2. If you're on PHP 8.1 or older, move up. Those versions aren't getting a fix. Ask your host to move you to a supported version, and test the site afterward.
3. Update WordPress, your theme and every plugin. This bug is in PHP, not WordPress, but an out-of-date plugin is the most common way small sites get hacked, and an attacker who gets in one way will look for others.
4. Back up before and after. Take a full backup (files and database) before you change anything, and keep a copy somewhere other than your host.
5. Change your passwords if anything looks off. Strange new admin users, pages you didn't write, or redirects to spam sites are signs to call your host right away.
6. Watch your inbox. Big security news always brings fake "your site has been compromised, click here" emails. Your host won't ask you to log in through a link in an unexpected message. Go to their site directly instead.

The short version

If your author site is on Squarespace, Wix, Shopify, Substack or WordPress.com, you can relax. If it's a self-hosted WordPress site or anything else running PHP on a server, send your host one email today asking whether you're on a patched PHP version, then update your plugins and take a backup. That covers most of the risk.