On Saturday 17 October 2026, a decoy server run by Amazon’s threat intelligence team logged something that, officially, did not exist yet: an attempt to exploit a flaw in PHP that the world would not hear about for another four days.
PHP is the programming language running behind a large share of the web, including every WordPress site and countless booking systems, client portals and online forms. The flaws now known as PHP2Shell let an attacker who has never signed in run their own code on a web server. If your business website runs on PHP, this one is worth five minutes of your week.
How a planned fix turned into a race
The PHP project had been preparing a quiet, coordinated release. It did not stay quiet.
- 2024: a PHP core developer first spots signs of a memory problem, but no concrete way to exploit it is found and other work takes priority.
- 11 August 2026: researchers report a working attack built on that same root cause. Others, including a team at OpenAI, independently find it too. The fix becomes the PHP Foundation’s top security priority, with people working weekends to finish it.
- Saturday 17 October: Amazon’s decoy server records the first known exploitation attempt.
- Tuesday 20 October: the two vulnerability numbers start circulating on forums and social media, with the wrong release time and an inflated score of 10 out of 10. PHP pulls its release forward by a full day. That evening, a security firm mistakenly publishes a video of its own working exploit.
- Overnight into Wednesday 21 October: public proof-of-concept exploits appear, a software vendor publishes patched builds more than six hours before the agreed time, and Cloudflare starts blocking attack traffic.
- Wednesday 21 October, 8 am in Calgary: PHP releases the fixes.
- Monday 26 October: the US Cybersecurity and Infrastructure Security Agency (CISA) adds both flaws to its Known Exploited Vulnerabilities catalogue, the list of flaws being used in real attacks.
The PHP Foundation’s own account is unusually candid about how long the fix took, and well worth reading if you like the inside story.
What the bugs actually do
Think of PHP as the kitchen of a busy restaurant, and every visit to your website as an order:
- CVE-2026-109618 is a kitchen that runs out of space halfway through writing up an order, then treats the half-written ticket as complete. Inside PHP, that corrupts memory.
- CVE-2026-109619 is a kitchen that, after a mishap, hands the next table a plate that belonged to the previous one. Inside PHP, a later request uses memory left over from an earlier one.
A carefully crafted request can cause either mess on purpose, and a skilled attacker can turn the mess into control of the server. Both are rated 9.2 out of 10. On servers running Apache with mod_php, which the PHP project rates as the highest risk, the attack lands before the website’s own code even sees the request.
Why updating WordPress will not save you
Every PHP installation that serves web pages is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed are all named in the PHP security advisory. That covers most shared hosting, managed hosting and self-managed servers.
The fault is in the engine, not the bodywork. Updating WordPress, a theme or a security plugin changes nothing here. PHP itself has to be updated on the server, which is usually the job of your hosting company or your developer.
The fixed versions
| PHP branch | Fixed version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Linux distributions and long-term support vendors received the patches in advance, so a server updated through its operating system may show a different version number and still be safe. Ask the host or vendor to confirm.
The bad news for older sites: PHP 8.1 and older no longer receive official releases. The PHP project published minimal fixes for 7.4, 8.0 and 8.1 that have to be built by hand, and CISA advises taking systems on these versions offline until they are patched or upgraded. If your site was built years ago and never moved on, this is the moment. PHP 8.2 itself reaches end of life on 31 December 2026.
What about firewalls?
Some web application firewalls added blocking rules within hours. Cloudflare’s rules switched on automatically for every plan with its firewall, including free accounts, and Amazon published rules for its own firewall too. Both say the same thing: a firewall buys time, and patching PHP is still required. The PHP project puts it even more plainly: “There are no complete mitigations, updating is the only safe choice.”
Your five-minute check
- Find out who runs your website’s server. Usually a hosting company, a developer or an agency. If nobody knows, that is the first problem to fix.
- Send them the email below and ask for an answer this week.
- Do not accept a workaround as the final answer. Configuration changes reduce exposure while an update is arranged; they do not make a server safe.
- Plan the move off PHP 8.1 or older, testing the site on a supported version first, because old themes and plugins sometimes need updating to cope.
- Check your other software. Client portals, booking systems and intranet tools can run on PHP too. CISA’s advice is to find every system running PHP, including PHP built into other products, and patch the internet-facing ones first.
An email you can copy and send
Subject: PHP2Shell (CVE-2026-109618 and CVE-2026-109619)
Hi,
Could you confirm the following for our website?
- Which PHP version is it running, and is it patched for CVE-2026-109618 and CVE-2026-109619?
- When was the patch applied, and has PHP been restarted since?
- Have you checked the site and server for signs of compromise, such as unexpected files, new administrator accounts or unusual processes?
- Is our PHP version still supported? If not, when can we move to one that is?
Thank you.
A third, lower-risk issue
On 23 October the PHP project published a further advisory, CVE-2026-115560. It only affects sites with an unusual combination of settings and code, and it will be fixed in the next regular PHP release. Until then, the project suggests turning off the session.upload_progress.enabled setting. That is a change for your host or developer; if they already made it after the 21 October advisory, nothing more is needed.
Keeping on top of it
The websites most likely to miss an update like this are rarely the busy ones. They are the sites built a few years ago that nobody clearly owns any more, still running whatever version of PHP they launched with. Security updates for the platform and its components are part of our monthly website maintenance checklist, and our managed security service keeps operating systems and common applications patched on a schedule.
This article reflects the advisories as published on 26 October 2026. Check the PHP project’s news page for later updates.