Two critical flaws in PHP, now known as PHP2Shell, were disclosed on 20 and 21 October 2026. Either one lets an attacker take over a website without logging in. Within about 24 hours, every server BeeTcore looks after had been checked, and every one was confirmed safe.
The most useful lesson from that day was not the fix. It was learning that the number most people check first could not be trusted.
What PHP2Shell is
PHP is the language that runs WordPress and a large share of the web. The two flaws, CVE-2026-109618 and CVE-2026-109619, are both rated 9.2 out of 10 for severity. They sit in PHP itself, not in WordPress, a theme or a plugin.
That detail changes the response. Updating WordPress or plugins does nothing here. Only a patched PHP closes the hole. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, published in the official PHP advisory.
The first 24 hours
BeeTcore’s sites run across several hosting providers, from shared hosting to managed WordPress platforms and self-managed servers. No single dashboard shows the state of PHP across all of them. A control panel shows what a host intends to run, not always what is running.
So every server was checked directly. On one live site per server, the team inspected the PHP build actually serving pages. Most providers had already applied the fix, and each one was verified rather than taken on trust. On the servers BeeTcore manages itself, the team applied the patch and an extra safeguard directly.
Then came malware scans across every site, to confirm nothing had got in before the fix landed.
Why the version number misled
The obvious test was simple: is the server on 8.3.36 or newer? On several servers, the answer was no. And those servers were safe.
Some hosts fix a flaw without changing the version number. Known as backporting, it means the security repair is copied into the version already installed. The server still reports an older number, while the code underneath is fixed.
A checklist that said “upgrade to 8.3.36” would have flagged safe servers as broken and sent the team chasing problems that did not exist. Worse, a number on its own proves nothing either way. The reliable evidence was the build date of the running PHP, checked against the host’s own security notice.
How to check your own website
- Ask your host. Send one line: “Is PHP on my server patched for CVE-2026-109618 and CVE-2026-109619?” A good host answers the same day.
- Check your PHP version. In WordPress, open Tools, then Site Health, then the Info tab, then Server. PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or newer means you are on a fixed release.
- Lower number? Check the build date. Your hosting panel’s PHP info page shows a “Build Date”. A build from 20 October 2026 or later, confirmed by your host as backported, means you are covered.
- On PHP 8.1 or older? Those versions no longer get security fixes from the PHP project. Moving to a supported version is the fix.
- Read the source. Search “PHP2Shell” or “CVE-2026-109618” to confirm the details for yourself, starting with the PHP advisory.
What this means for looking after a website
Most site owners hear about a server flaw after something has already gone wrong. Clients on BeeTcare did not have to do anything this week. Their sites were checked, verified and scanned before most people had read the news.
That is the job: know every server, check what is actually running, act fast, and confirm nothing got in. If you are not sure where your website stands, send BeeTcore your address and the team will check it for you.