Short answer: if your website runs on WordPress, an e-commerce platform or anything else built on PHP, yes, you need to act. Just not in the way you might expect. Updating WordPress or your plugins won't help here, because the flaw sits underneath them, in PHP itself. The fix has to be installed on the server, and for most small and mid-sized companies that is the hosting provider's job. Your job is one question: has it been done, and which version are you on?
What happened?
On 21 October the PHP developers shipped an out-of-band security release for two critical flaws (CVE-2026-109618 and CVE-2026-109619), which the press has nicknamed PHP2Shell. Both are rated 9.2 in severity and allow an unauthenticated attacker to run code on the server remotely. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. According to PHP's own advisory, the 7.4, 8.0 and 8.1 branches, which are no longer officially supported, received only minimal emergency backports.
The Register reports that every PHP installation serving web requests is affected, however it runs: PHP-FPM, Apache mod_php, php-cgi or LiteSpeed. The developers rate mod_php as the highest risk, because there the attack can start before any application code runs.
According to TechCrunch, the bugs had been present in every version since PHP 5, released in 2004, and were found with AI-powered security tools. That is the real lesson of the week. Something that stayed hidden for twenty years has now been found by a machine. And defenders are not the only ones running those machines.
Attackers didn't wait. Amazon says the first exploitation attempts appeared on 17 October, four days before the patches. Hungarian tech site HWSW, citing Cloudflare's CEO, reports that attempts reached tens of thousands within 45 minutes of the announcement and hundreds of thousands two hours later. How many succeeded is unclear. The PHP security team says the exploit code that leaked before the patch did not work, and the analysts quoted by BleepingComputer knew of no confirmed compromises.
The caution was still very visible. The Register lists government sites in Finland and the Netherlands among those taken offline as a precaution, and according to HWSW, Hungary's national e-government portal had to go offline temporarily while the fix was installed. On 23 October PHP also published an advisory on a further, much narrower issue (CVE-2026-115560), with a fix due in the next release.
What does this mean for an SMB?
Most small and mid-sized companies don't run their own web server. They have a WordPress site or an online shop with a hosting provider, built years ago by an agency or a freelancer. TechCrunch notes that WordPress itself said the flaw is not WordPress-specific: site owners need their servers patched and should work with their hosting companies.
That leads to three practical risks.
First, nobody feels they own it. The agency assumes the host patches. The host assumes the customer picks the PHP version in the control panel. The managing director assumes "we have someone for that". A typical pattern is that a week like this is when a company discovers that nobody has written down who is responsible for the website's server.
Second, the old version. Plenty of older sites still run on PHP 7.4 or 8.0 because an outdated plugin breaks on anything newer. Those branches only received minimal fixes this time, and PHP 8.2 itself reaches end of life on 31 December. If your site is in that position, PHP2Shell won't be the last week like this.
Third, patching doesn't clean up. If an attacker got in before the fix, the update won't remove whatever they left behind. As Amazon put it, defenders should not assume the public disclosure date is the earliest date of exploitation.
It's the same lesson as the ConnectWise incident we wrote about last week. The question isn't whether you trust your provider. It's whether you know what they do on your behalf.
What should you do now?
- Ask your hosting provider today (or whoever runs the site) whether they have installed the 21 October fix, and exactly which PHP version your site runs on. Get the answer in writing, with the version number.
- If you're on 8.1 or older, plan the move. Ask your developer what is blocking the upgrade and how much work it takes to reach a supported version. If you're on 8.2, the same applies before the end of the year.
- Look around the site. Is there an unfamiliar administrator account in WordPress? Have files changed recently that nobody touched? If you're unsure, ask whoever maintains the site to review it.
- Keep a recent backup of the site and its database that doesn't live on the same server, and know who can restore it. Our ransomware and backup strategy article explains how to set this up.
- Write down in one place who is responsible for the website's server, who tells you when a critical update lands, and how quickly it gets installed. The next week like this won't be years away.
If you'd like someone to review how your company website and other systems are patched and backed up, take a look at our infrastructure service.
Sources
- PHP.net – News archive 2026 (critical security advisory, 21 Oct; session upload progress advisory, 23 Oct)
- The Register – PHP devs publish critical bug fix as site owners warned: Pull 'em offline if you're unpatched
- BleepingComputer – Amazon says PHP2Shell exploitation began 4 days before patches
- TechCrunch – PHP Armageddon: OpenAI, Google's Wiz find ancient holes, panicking the internet
- HWSW – Azonnal ráugrottak a hackerek a súlyos PHP-sérülékenységekre
