PHP2Shell: hardened the same day, patched by breakfast
On 21 October 2026, two critical security vulnerabilities in PHP were made public. Nicknamed “PHP2Shell” (CVE-2026-109618 and CVE-2026-109619), they have understandably caused concern across the hosting and WordPress community.
If you host with Black Label Hosting, here is the short version: we applied protective measures across our entire platform on the day the vulnerabilities were announced, and the official patched PHP versions were running on our shared hosting servers by 6:26 AM AEST on 22 October, about six and a half hours after the PHP project released them. You do not need to do anything, and there was no downtime.
This post explains what PHP2Shell is, what we did and when, and what it means for your website.
What is PHP2Shell?
PHP is the programming language that runs WordPress, WooCommerce and most of the websites on the internet. PHP2Shell is the nickname for two vulnerabilities in PHP itself. Government cyber security advisories rated them critical and asked hosting providers to act urgently, because in the worst case they could let an attacker run their own code on a vulnerable web server without needing a login.
Two things make PHP2Shell different from the WordPress security issues you usually hear about:
- It is not a WordPress, plugin or theme problem. The flaws are in the server software that runs your website, so updating WordPress or your plugins does not fix them. The fix has to come from your hosting provider.
- Security plugins cannot block it. The vulnerable code runs before WordPress even loads, so protection inside WordPress, such as security plugins and login rules, never gets the chance to step in.
The PHP project released fixed versions of every supported branch (PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12) at 12:00 AM AEST on 22 October.
21 October: protection applied the same day
We did not wait for the official patch. On 21 October, the day the vulnerabilities were announced, we applied the interim mitigation recommended by security researchers across our entire hosting platform.
- Where: every shared hosting server and every managed VPS, on every PHP version installed, so every website had the extra protection regardless of which PHP version it runs.
- What: two PHP configuration changes that switch off a rarely used PHP feature and tighten how PHP handles sessions, to reduce exposure while the official patches were prepared.
- Impact on websites: none expected. The only side effect is that session-based upload progress bars stop working, a feature very few sites use.
- Checked: we confirmed the settings were active on live websites and that sites kept working normally afterwards.
- Kept in place: the mitigation stays on permanently as an extra layer of protection, even after patching.
Interim measures like this reduce risk, but they are not a substitute for the fix itself. That is why installing the patched PHP versions was our priority the moment they became available.
22 October: patched within hours of release
The PHP project released its patched versions at 12:00 AM AEST on 22 October. By 6:26 AM the same morning they were running on all of our shared hosting servers, before most of our clients had started their working day.
| When (AEST) | What happened |
|---|---|
| 21 October | PHP2Shell announced. Interim mitigation applied to every shared hosting server and managed VPS, then checked on live websites |
| 22 October, 12:00 AM | The PHP project releases patched versions, including PHP 8.2.35 and 8.3.36 |
| 22 October, 6:26 AM | Patched versions installed on all of our shared hosting servers |
| 22 October, morning | Every server verified as running the new versions, with no websites left on the old code, and client sites checked to confirm they were serving the patched version and loading normally |
- Websites on PHP 8.2 and 8.3 on our shared hosting servers, the large majority of the sites we host, are now fully patched.
- Clients did not need to do anything, and there was no downtime.
- Where testing showed it was safe, we also moved some older sites up to PHP 8.3 on the same day.
Managed VPS clients: the same interim mitigation has been in place on every managed VPS since 21 October, and the patched PHP versions are being rolled out to managed VPS servers as part of the same process. If you would like confirmation for your server, contact our support team.
Older PHP versions: extra protection now, upgrades next
Some sites still run PHP 7.4, 8.0 or 8.1. These versions have reached end of life, which means the PHP project no longer publishes official releases for them, including this fix. These sites keep our interim mitigation in place, and our priority is moving them to a supported, patched version of PHP as quickly and safely as possible.
- We are contacting the owners and web developers of these sites directly, with a list of the websites affected.
- Before switching any site to a newer PHP version, we test it on that version first, so we can flag any theme or plugin that would break before it affects the live site.
- Any switch can be reversed immediately if something unexpected appears.
- The most common blockers are very old themes, plugins or WordPress versions, so keeping a site up to date is the best way to stay on supported, patched software.
If we contact you about one of your sites, please work with us to schedule the upgrade. The mitigation reduces the risk in the meantime, but moving to a supported PHP version is the only complete fix.
What you need to do
For most clients, nothing. If your website runs PHP 8.2 or 8.3 on our shared hosting, it is already running the patched version. If your site needs a PHP upgrade, we will contact you.
To check which PHP version your WordPress site uses, log in to your WordPress dashboard and go to Tools > Site Health > Info > Server. A patched site shows PHP 8.2.35, 8.3.36 or newer. If you have any questions about PHP2Shell or a specific site, get in touch with our support team.
How we handle incidents like this
PHP2Shell is a reminder that some of the most serious risks to a website sit below WordPress, in server software that only your hosting provider can update. When an issue like this is announced, our approach is the same every time: put protection in place straight away, install the official fix as soon as it is released, verify the result on live websites, and keep our clients informed. You can read more about how managed hosting keeps pace with fast-moving vulnerabilities.
Frequently asked questions
Is my website affected by PHP2Shell?
The vulnerabilities are in PHP itself, so any website running an unpatched version of PHP was potentially exposed, whoever hosts it. At Black Label Hosting, websites on PHP 8.2 and 8.3 on our shared hosting servers are now running the patched versions, and every site has had our interim mitigation in place since 21 October.
Do I need to update WordPress or my plugins to fix PHP2Shell?
No. PHP2Shell is a flaw in PHP, the server software, not in WordPress, plugins or themes, so the fix has to be applied by your hosting provider. Keeping WordPress, plugins and themes up to date is still good practice, and it makes future PHP upgrades much easier.
Was there any downtime?
No. The interim mitigation and the PHP updates were both applied without downtime, and we checked client sites afterwards to confirm they were loading normally.
My site runs PHP 7.4, 8.0 or 8.1. Is it safe?
These versions no longer receive official PHP updates, so they cannot be patched in the usual way. Your site has our interim mitigation in place, which reduces the risk, and we are contacting owners and developers to test and upgrade these sites to a supported PHP version. Upgrading is the only complete fix.
How can I check which PHP version my site is using?
In your WordPress dashboard, go to Tools > Site Health > Info > Server. A patched site shows PHP 8.2.35, 8.3.36 or newer.
