On October 21, 2026, the PHP project pushed out emergency security updates for two vulnerabilities that researchers are calling PHP2Shell. These are not minor bugs. They let an attacker take over a website without logging in first, and part of the flaw has existed in PHP since 2012. If your website, online store, or client portal runs on PHP (and a huge share of the web does, including WordPress and Magento), this is worth five minutes of your attention this week.
What PHP2Shell actually is
The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619, and both are rated 9.2 out of 10 for severity. In plain terms, they are flaws in how PHP itself handles certain requests, not flaws in WordPress, your theme, or your plugins. That means updating WordPress alone will not fix this. The fix has to happen at the PHP level, on the server.
The vulnerable code affects PHP 5.4 and newer, running in common setups such as PHP-FPM, Apache with mod_php, php-cgi, and LiteSpeed. Security researchers at Sansec found the bugs and reported them to the PHP team in August. Details leaked publicly on October 20, and PHP shipped patched versions (8.2.35, 8.3.36, 8.4.27, and 8.5.12) the next day. The Canadian Centre for Cyber Security issued an alert the same week, and the US Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its list of vulnerabilities known to be actively exploited on October 26.
Who needs to actually do something
This is the part that matters most for small business owners: if your website runs on managed or shared hosting, meaning the host takes care of server software for you, there is a good chance you do not need to lift a finger. A lot of well known hosts moved fast:
- Hostinger rolled out the PHP fix across its platform by October 22. Customers on anything other than a VPS plan do not need to act.
- Kinsta protected its managed WordPress hosting with a web application firewall before the patch even shipped, and no customer changes were needed.
- GoDaddy patched Managed WordPress, Web Hosting, and Windows Hosting by October 22. VPS and dedicated customers had to update their own servers.
- SiteGround rolled out server level mitigation rules and disabled the affected PHP functionality across all supported PHP versions by October 21.
- HostGator, which shares infrastructure with Bluehost under the same parent company, Newfold Digital, posted on its status page that managed hosting customers needed no action, while self-managed VPS and dedicated customers were told to update PHP themselves.
- Namecheap rolled out patches across its shared servers in stages through October 22. VPS and dedicated customers had to patch on their own.
- DreamHost covered older, otherwise unsupported PHP versions through its own extended support program.
- OVHcloud, Hetzner, and IONOS each patched PHP across their hosting platforms within a day of the fix shipping.
Wix and Squarespace are closed platforms where you never manage server software yourself, so there was nothing for a site owner on either platform to patch directly, and neither company has made a public statement naming PHP2Shell specifically.
If your site sits behind Cloudflare, its web application firewall started blocking known PHP2Shell exploit attempts on October 21 for every plan, including the free tier (Cloudflare does ask paid plan customers to confirm their ruleset is set to actually block, not just log). That is a useful extra layer, but Cloudflare itself says it is not a substitute for patching PHP on your actual server.
Other hosts moved quickly too, but the pattern is consistent across the industry: shared and managed hosting plans were patched by the provider, while VPS, dedicated servers, and anything you manage yourself were left for you to fix.
If you run your own server or a VPS
If you, your web developer, or your IT contractor manages the server directly (a VPS, a dedicated box, or an on premise server running a public website), check your PHP version now:
- Confirm your PHP version and compare it against the fixed releases: 8.2.35, 8.3.36, 8.4.27, or 8.5.12.
- If you are on PHP 8.1 or earlier, there is no official fix from the PHP project for that version. Ask your hosting provider or developer whether a backported patch is available, or plan an upgrade to a supported PHP version. PHP 8.2 itself loses security support at the end of 2026, so this is a good time to plan that move anyway.
- If you cannot patch right away, ask your developer to temporarily block multipart form data uploads at the web server level, and turn off session upload progress in the PHP configuration. This is not a full fix, but it closes the door the attack uses until you can update properly.
- Restart PHP FPM or Apache after any change, and confirm the new version is actually running rather than assuming the update took effect.
If you are not sure what hosting you have
A lot of small business owners genuinely do not know whether they are on shared, managed, or VPS hosting, and that is normal. It is not your job to know. The fastest way to find out is to log into your hosting account and look for the word "VPS" or "dedicated" in your plan name, or simply ask your host directly: have you patched PHP2Shell (CVE-2026-109618 and CVE-2026-109619) on my account, and do I need to do anything on my end? A reputable host will have a clear, specific answer, not a vague reassurance.
This one moved fast: from private disclosure to active exploitation in about ten weeks, and from public leak to patch in under a day. That is the system working the way it is supposed to. The part that is on you is making sure the patch actually landed on your setup, especially if you are on a VPS or a self-managed server. Take five minutes this week to check, and then you can move on.
