On 21 October 2026, the PHP project issued emergency updates for two critical PHP vulnerabilities collectively nicknamed “PHP2Shell.” PHP powers a large portion of the web, including WordPress, Drupal, Joomla, many online shops, booking systems, and client portals. Even if no one in your office knows what PHP is, your website may depend on it.
What happened
Both flaws — CVE-2026-109618 and CVE-2026-109619 — are rated 9.2 out of 10 for severity. They can let an attacker with no username or password execute their own code on the web server and read fragments of server memory, which may contain passwords, login tokens, and keys belonging to other visitors. The weakness is in PHP’s engine, not in your website’s own code. That means a well-built, fully updated site can still be exposed if the PHP version underneath it has not been patched. Researchers found affected releases going back to PHP 5.4, with nearly every version before the fixes affected by at least one issue. How easily a site can be attacked depends on how its server is configured.
Why the timing matters
Details leaked online on 20 October, a day before the planned release. Security firms including Cloudflare and watchTowr have already reported attack attempts. In the Netherlands, several government and education websites were taken offline as a precaution while they were patched.
Updating WordPress is not enough
Many business owners correctly keep WordPress and its plugins up to date, but those updates do not fix these vulnerabilities. PHP is part of the server, not the website. It is updated by whoever runs the server: your hosting company, web developer, or IT provider. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The server’s PHP services must be restarted afterward for the fix to take effect.
Older websites are the biggest concern
PHP 8.1 and earlier no longer receive routine updates from the PHP project. The PHP team has published fixes for versions 7.4, 8.0, and 8.1, but only in a form that requires technical work to apply. Some Linux distributions deliver the fix under an old-looking version number, so the version number alone is not proof either way. A site built years ago and left untouched since is most likely to slip through. Anyone on PHP 8.2 should also note that it reaches end of life on 31 December 2026, so another deadline is close behind.
What to do today
First, establish who looks after the server your website runs on. Then ask them three plain questions:
- Does our site use PHP?
- Have the security fixes for both CVE-2026-109618 and CVE-2026-109619 been applied and verified?
- If we are on an unsupported version, what is the plan?
Do not forget other web-based systems such as intranets, client portals, booking or e-commerce platforms, and any old microsites or test sites still online. Some large hosts applied protections before the patch was released, but do not assume yours did. If the fix cannot be applied straight away, your provider may need to restrict access to the affected site or service, or take it offline temporarily, until the fix has been applied and verified.
If you think you may have been targeted
Because attack attempts began before many servers were patched, updating is not necessarily the end of the story for sites that handle sensitive information. Researchers suggest looking for repeated server errors, unexplained restarts of PHP services, and unusual upload requests in the period before patching. These are leads for investigation rather than proof of compromise, and clean logs do not prove a server was safe: the attacks happen beneath the website itself, so the website’s own logs may show very little. If your site handles logins, payments, or client data, it is sensible to ask your provider to investigate and to consider changing any passwords or keys stored on that server.
A sign of things to come
The flaws were found by Wiz Research, Calif and OpenAI. Wiz says AI tools helped a single researcher turn a long-standing weakness into a working attack in about a week — work it estimates would otherwise have taken a team months. The PHP Foundation has acknowledged that early signs of one flaw were identified while addressing findings from a 2024 security audit, but the fix stalled. Expect more of this: AI is speeding up the discovery of old bugs for defenders and attackers alike, and the time small businesses have to react is shrinking.
Our view
As a managed cloud provider, we see PHP2Shell as a reminder that a website is not a set-and-forget asset. The part most likely to be neglected is the part nobody sees: the server software underneath. Business owners do not need to understand PHP, but they do need to know who is responsible for patching it — and to get a straight answer within hours rather than weeks when something like this lands. If you are not sure who that is for your website, that is the gap to close today.
