Two 9.2 out of 10 flaws. One interpreter. Most of the web.
If you are an aratech client, or your website is hosted with us, email [email protected] immediately. We will confirm your PHP version, your patch status, and what we are doing about it. Do not wait for a newsletter to explain this to you.
This is not a plugin problem. This is not a theme problem. This is not a WordPress bug, a Magento bug, or a Laravel bug.
This is PHP itself.
Two critical vulnerabilities in the PHP core, tracked as CVE-2026-109618 and CVE-2026-109619, allow an unauthenticated attacker to execute arbitrary code on a web server. Both are rated 9.2 out of 10 under CVSS v4.0 by the PHP security team. The emergency patch set landed today, 21 October 2026, at 14:00 UTC (18:00 Dubai). Fixed branches are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
The detail that should make you sit up: these flaws were leaked publicly on 20 October, roughly a day before the coordinated disclosure. The leak carried the CVE IDs, a severity score and a date, and a screenshot circulated of an exploit tool called PHP2Shell, credited to Calif.IO, with a banner claiming it works against every PHP release from 5.4.0 onward. The technical details stayed embargoed until 14:00 UTC today. Which means the entire internet receives the patch and the reverse-engineering material at the same moment.
What the two vulnerabilities actually are
Both are memory-safety failures in the request lifecycle. Neither requires a login, a plugin, or a badly written page.
CVE-2026-109618, RCE via OOM corruption. When PHP hits an out-of-memory condition, it can be interrupted while internal request data is only partially initialised. Cleanup then treats that invalid data as if it were valid, and an attacker who can provoke the memory failure gets to shape what happens next.
CVE-2026-109619, RCE via stale global state. Request-owned internal state can survive after the memory backing it has been freed. A later request handled by the same worker can consume that stale state before normal initialisation resets it. This is worker reuse as an attack surface.
PHP's own advisory says the risk is highest on mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs. That last part matters more than anything else in this article: your framework, your firewall rules, and your application logic are not in the path.
Who is exposed
Anyone serving PHP through PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed is in scope. In other words, the default configuration of a very large part of the internet.
PHP runs on roughly seven in ten websites that use a known server-side language. WordPress, Drupal, Joomla, Magento, Laravel, Symfony, custom applications, and a long tail of appliances that quietly bundle PHP underneath. Reports suggest the affected range reaches back to the PHP 5 era of 2004. The exact scope of every affected version will firm up as vendors publish their own advisories. Mallory counted roughly 884,000 internet-facing hosts that still reported PHP 8.1 or older to Shodan on 20 October: 59% of every host that reported a version at all.
Here is the part most people will skim past: PHP 8.1 and older no longer receive updates from the PHP project. The team published minimal source backports for 7.4, 8.0 and 8.1, but if you are on an end-of-life branch and you do not control your build, you are not patched. You are waiting for someone else's schedule.
Why the next 48 hours matter more than the flaw
A vulnerability that is known but not public is a race between researchers and defenders. A vulnerability whose patch is public is a race between attackers and everyone else.
Once the fixed versions are downloadable, anyone can diff them against the vulnerable code and reverse-engineer the trigger. That is not a theoretical concern: it is the standard playbook, and it usually takes hours, not weeks. Sansec expects mass attacks within about fifteen minutes of the release. Patchstack reports active exploitation against hosting partners, and Cloudflare has logged early attack attempts. That head start is already being spent.
You can also read the response from institutions as a signal. Dutch services including DigiD, MijnOverheid, the House of Representatives website and Tweakers went offline as a precaution. Several major Japanese platforms moved into emergency maintenance. The SEO Framework took its servers down. CERT-EU published advisory 2026-018, and the UK's NCSC told organisations to patch immediately or take systems offline where remediation is not feasible.
When governments choose downtime over exposure, that is the honest severity rating.
Do this now, in this order
- Inventory before you patch. Every PHP install you run: production, staging, containers, cron-only hosts, and third-party appliances or tools that bundle PHP. You cannot patch what you have forgotten.
- Update to a fixed version. 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On managed hosting, ask your provider for the exact window, in writing, and get the current version confirmed afterwards. Do not assume a maintenance notice means your sites are done.
- If you are on PHP 8.1 or older, decide today. Either build from the PHP security team's backports or upgrade to a supported branch. There is no third option that involves being safe.
- Restart every worker. PHP-FPM, Apache, LiteSpeed, FrankenPHP, and any long-lived CLI workers. A patch that is installed but not reloaded is a patch that is not running.
- Apply the interim hardening even if you patched. It is cheap in
php.inior your pool config, and it costs nothing to keep:session.upload_progress.enabled = 0, set at pool or server level, never viaini_set()or.user.inimemory_limit = -1, enforced where applications cannot override itpost_max_size = 8Mif you do not take uploads,32Mif you do, withupload_max_filesizebelow it- on PHP 8.5,
fatal_error_backtraces = 0
- Hunt, do not just patch. If your site has been reachable and unpatched, look for unexpected files, modified PHP in upload directories, new admin users, outbound connections you did not configure, and cron entries you did not create. A patch closes the door; it does not remove a guest who came in earlier.
- Ignore the internet's fix plugins. Copy-pasted snippets and unverified "PHP2Shell fix" plugins are circulating. They are not endorsed, they will not work, and some of them are the attack.
The uncomfortable lesson
Every few years the web gets a reminder that the runtime underneath everything is a piece of software with its own bugs. The reminder is usually expensive.
The pattern we see at aratech over and over: the application was upgraded, the frameworks were kept current, and the PHP version underneath was left alone for years because it worked. PHP 7.4 has been end-of-life since November 2022. That is nearly four years of no official security patches, on a branch that now needs vendor backports to survive a flaw like this one.
End-of-life is not a maintenance preference. It is an unmanaged risk with a date on it, and today is the day the date came due.
If you are running an old branch, plan the upgrade as a real project: a clean server, a current PHP and framework version, full testing, then a cutover with the old environment kept as a fallback. It is a few days of uncomfortable work, repeated once every few years, against the alternative of hoping the next 9.2 does not find you.
If you are not sure, ask us today
If you are an existing aratech client, or your site is hosted with us, email [email protected] immediately and we will tell you exactly where you stand: your PHP version, whether it is patched, whether we have seen anything suspicious on your infrastructure, and what needs to happen next.
If you are not a client and you do not know what version of PHP your site runs, that is your answer. Email us anyway. This is the week to find out.