On 21 October 2026 PHP released an urgent security update for two critical flaws, nicknamed php2shell. It affects every site that runs on PHP, including WordPress, Joomla, Drupal, Magento, PrestaShop and custom-built sites. Updating your site's software won't fix it. Your host, or whoever runs your server, has to. Here's how to tell if it's done.
Prefer WhatsApp? Message us
On 21 October 2026, PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws (CVE-2026-109618 and CVE-2026-109619) that can let an attacker run code on a web server without logging in.
Details leaked before the planned release and exploit code was circulating, so every site that runs PHP needs the fix now.
Status on 28 October: Wordfence says there are still no confirmed cases of WordPress sites broken into through php2shell. Confirmed attacks so far are outside WordPress, on Windows servers running IIS and on Palo Alto PAN-OS devices. That can change, so an unpatched server still needs the fix. Source: Wordfence, 28 October 2026.
On 26 October, the US Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its Known Exploited Vulnerabilities list, its list of flaws with evidence of real attacks. US federal agencies must fix them by 29 October and check whether their servers were already broken into. The same two steps make sense for any site: get the fix, then look for signs of a past break-in. Sources: CISA, CISA's PHP alert and Tenable.
On 26 October, php2shell was confirmed exploited in the wild. On 24 October, attackers got working shells on a researcher's honeypots: ordinary PHP pages on unpatched PHP 8.4.26, with 35 shells from 2 IP addresses. The researcher says that test setup was favourable to attackers, but the attack now works outside a challenge server, and attack traffic is still rising (busiest hour so far: 14:00 UTC on 26 October, per the Delft Threat Intelligence Lab tracker, read 15:04 UTC). The fix hasn't changed: your server needs one of the fixed versions above. Sources: SecurityWeek, BleepingComputer and the researcher's evidence.
On 25 October, a researcher used php2shell to take over a public test server running unpatched PHP 8.4.26 (the "StealMyBitcoin" challenge, set up to show the attack doesn't work in practice). It took real skill and an attack tuned to that one server, but it shows the attack can work on a server without the fix. The 21 October update fixes the flaws it used. Sources: Mark Maunder, Wordfence and the researcher's write-up.
Known problem with the fix: PHP 8.5.12 and 8.4.27 have a confirmed bug that can crash some sites, with the error “zend_mm_heap corrupted”. PHP 8.3.36 and older are not affected. PHP has written the fix, but as of 27 October it is not in a release yet. Don't go back to an unpatched version: if your site crashed after the update, send your host PHP's bug report. More in the questions below.
On 23 October, PHP flagged one more flaw (CVE-2026-115560) that this update doesn't fix. PHP says it's unlikely to affect most sites, and the stopgap is a setting many hosts already turned off. What it means for you.
Most small-business sites are on shared or managed hosting, so the host installs it. We wrote the message for you: copy it here.
Get the messageWordPress, WooCommerce, Joomla, Drupal and most small-business sites run on PHP. Not sure what yours runs on? Ask us in the chat.
Every PHP version before 8.5.12, 8.4.27, 8.3.36 and 8.2.35 is affected. Hostinger says the flaws go “back at least to PHP 5.4”.
Both flaws are rated 9.2 on the CVSS v4.0 scale. An attacker can run their own code on the server, with no login.
These versions “no longer receive updates from the PHP project”, so there is no new release. PHP’s security team did publish minimal source patches for PHP 7.4, 8.0 and 8.1. Your host or Linux vendor has to build and apply them, so ask your host, then plan an upgrade.
As Wordfence puts it: “These are flaws in PHP, not WordPress, so updating WordPress, a plugin, or a theme will not install the fixes.” PHP runs on the server, so whoever runs the server fixes it. WordPress updates still matter, they just don't touch PHP.
| How your site is hosted | Who fixes it | What you do |
|---|---|---|
| Shared or managed hosting | Your host | Ask the host to confirm the fix in writing. Don't wait for an email. |
| VPS or your own server | You or your developer | Install the PHP security update and restart PHP, then check the version or build date. |
| Wix, Squarespace, Shopify | The platform | Nothing. It isn't something you can or need to touch. |
Not sure which kind of hosting you have? See how website hosting works, or check the email you got when you signed up.
Some hosts add the fix to the PHP you already run, without changing the number. So a site can be fixed and still say 8.5.11, or show a new-looking number and still need checking.
8.5.12, 8.4.27, 8.3.36, 8.2.35 or later means the fixed release. In WordPress you'll find it under Tools → Site Health → Info → Server.
A lower number doesn't always mean unsafe.
Hostinger says some fixed sites “show PHP version 8.5.11 rather than 8.5.12. This is expected”. The proof is the PHP Info “Build Date”: “October 21, 2026 or later”.
Look for it in your host panel's PHP info screen.
WordPress: Tools → Site Health → Info → Server. cPanel: Software → MultiPHP Manager or Select PHP Version. Hostinger hPanel: your website → Advanced → PHP Configuration. Plesk: Websites & Domains → PHP. Other panels: look under PHP settings.
8.5.12, 8.4.27, 8.3.36, 8.2.35 or later.
21 October 2026 or later is a good sign the fix is in.
Ask your host to confirm the fix for CVE-2026-109618 and CVE-2026-109619 is on your server. That's the answer you can rely on.
Never leave a public PHP info page on your site to check this. It tells attackers exactly what you run. View it in your host panel only. More on versions: which PHP version your site should be on.
On 23 October 2026, PHP posted an advisory for CVE-2026-115560, a flaw that can let an attacker run code on the server. The 21 October releases (8.5.12, 8.4.27, 8.3.36, 8.2.35) don't fix it. The real fix comes in PHP's next regular release.
It only affects sites whose code switches PHP's session settings while running, with upload progress turned on. That isn't the default setup. No severity score or list of affected versions has been published yet.
PHP's stopgap is session.upload_progress.enabled=0, the same setting many hosts switched off on 21 October. If your host already did that, keep it off until the next PHP release. Ask in the same message: copy it here.
Source: php.net (advisory, 23 October 2026). Still install the 21 October update: it fixes php2shell.
A careful host patches in hours, not weeks. Here's what Hostinger says it did, as an example of a good answer.
PHP's own advice is blunt: “There are no complete mitigations, updating is the only safe choice.” Firewall rules help while you wait, but they don't replace the update.
Rules added to block the known exploit before it reaches sites.
session.upload_progress switched off on its servers as a stopgap. PHP's 23 October advisory asks for the same setting, so it should stay off for now.
The fix built into the PHP its managed plans run. Hostinger: “Every Hostinger hosting plan except VPS: nothing to do”.
Make sure you can roll back too: backups that actually restore.
Paste it into a support ticket or chat. Fill in the parts in brackets. Keep the reply: it's your proof.
US, UK, Canadian and Australian hosts. We only list a host here when its own status page, blog or help page says so. No second-hand reports. Last checked 26 October 2026, 03:30 UTC.
Hostinger's monitoring update says some fixed sites still show 8.5.11, and to check that the PHP Info Build Date is October 21, 2026 or later. 23 October, on the separate CVE-2026-115560 advisory: Web, Agency and cPanel plans are already protected by the 21 October mitigation, so no action needed.
Hostinger status pageFirewall rules, session.upload_progress off and the fixed PHP installed. VPS customers update their own PHP. Updated 23 October, 13:25 UTC, after the CVE-2026-115560 advisory: every plan except VPS is already fully protected by the 21 October changes, no action needed.
Hostinger blog postManaged WordPress patched 21 October, Web Hosting 22 October, no action needed. The version number doesn't change: look for a build date of October 21, 2026 or later. Self-managed VPS: update PHP yourself. 23 October, on the separate CVE-2026-115560 advisory: the setting PHP recommends was already on for Managed WordPress, Web Hosting and Windows Hosting, so no action there; VPS owners set it themselves.
GoDaddy blog postServer rules went in after PHP's advance notice. PHP's fixes were applied on all SiteGround servers on 21 October. Customers don't need to do anything.
SiteGround blog post23 October, 12:35 EST: the majority of platforms are up to date. Self-managed VPS and dedicated customers should watch for emails. 20:55 EST: CVE-2026-115560 is covered by the protections already in place, PHP's fix goes on when it's released, and managed hosting customers don't need to do anything.
Bluehost status noticeShared hosting fixes finished 22 October; EasyWP sites updated too. Late 22 October (US Eastern): CloudLinux re-released the fixes with the right version numbers, now on all Shared Hosting servers: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 5.2 to 8.1 keep their old numbers but are patched. VPS and dedicated owners still update PHP themselves.
Namecheap status noticeProtections in place on shared, VPS, DreamPress and dedicated. The PHP fix is applied across most of the network. Sites on PHP 8.1 and older stay covered by mitigations while their fixes are built. DreamHost has also reset some email and SFTP passwords since 23 October; our DreamHost password reset guide explains what to do.
DreamHost status pagePatches rolled out across the platform for PHP 7.4 to 8.5 on 22 October. Firewall rules stay in place. 23 October: mitigations for CVE-2026-115560 already in place.
Kinsta status page22 October, 20:47 UTC: PHP is updated on every server Kualo manages, and upload and form blocks are lifted everywhere. A few servers on old PHP can't be fixed as they are; they keep the protections, and Kualo is contacting those customers.
Kualo status noticePatches deployed for every PHP version it runs (builds 7.4.33.17, 8.2.35, 8.4.27 and 8.5.12), resolved 21 October, 8:19 PM CDT. No action needed. Its 22 October blog post says the same.
WP Engine status notice23 October: Web and WordPress, Reseller, Managed Cloud and Managed VPS are patched, with the fixes backported to PHP 5.3 to 8.5. No action needed. Unmanaged VPS owners patch PHP themselves.
20i help pageNo action needed for Web Hosting customers. CloudLinux backported the fixes to PHP 5.2 to 8.5, so the version number can look lower than PHP's. Upload limits were removed on 22 October.
VentraIP status noticeThe patch is applied on every server WHC manages, so no action is needed there. Servers you manage yourself are not covered.
WHC blog postShared, reseller and managed WordPress patched, and most managed servers. Unmanaged VPS and dedicated servers must update PHP themselves. PHP 7.3 or older on cPanel without CloudLinux gets no fix.
HostPapa help pageNo statement found on its own pages, checked 26 October 2026, 03:30 UTC: Krystal (UK).
Your host isn't listed? That doesn't mean it isn't patched. Send it the message above.
An unpatched site can be broken into before the fix lands. Patching closes the door, but it doesn't remove anything already inside. That's why CISA asks for both: patch, and check for signs of a past break-in (CISA's PHP alert).
What to do next: my website was hacked. Want to know sooner next time? Website monitoring watches for changes. No tool catches everything, and we don't promise it does.
We watch PHP security releases and your host's status, check your server's version and build date, and follow up with your host until it's confirmed. Your first fix is free, before you pay a cent.
Month to month, and everything stays in your name. Prices in US dollars. See every plan
Something else? Ask in the chat, email hello@penguina.website or WhatsApp us.
It's the nickname for two critical PHP flaws fixed on 21 October 2026: CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 (CVSS v4.0) and can let an attacker run code on a web server without logging in. The fix is PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a patched build from your host.
It fixes php2shell (CVE-2026-109618 and CVE-2026-109619). On 23 October PHP posted a separate advisory, CVE-2026-115560, that it doesn't fix. PHP calls that one unlikely in practice: it only affects sites whose code changes the session settings while running, with upload progress on. Until PHP's next regular release, keep session.upload_progress.enabled=0, the same setting many hosts already turned off. Details on php.net.
No. These are flaws in PHP, the software your server runs, not in WordPress. Updating WordPress, a plugin or a theme won't install the fix. Your host, or whoever runs your server, has to update PHP.
Maybe. Some hosts add the fix to the version you already run without changing the number. Hostinger says this is expected on its plans. Check the PHP build date in your host panel: 21 October 2026 or later is a good sign. Then ask your host to confirm in writing.
PHP 8.1 and older no longer receive updates from the PHP project, so there is no new release for them. PHP’s security team did publish minimal source patches for PHP 7.4, 8.0 and 8.1 that fix both flaws. They aren’t a new PHP version: your host or Linux vendor has to build and apply them, so ask your host if yours has. Then plan a move to a supported version: see which PHP version your site should be on.
On shared or managed hosting, patching the server is the host's job, as part of the plan you already pay for. On a VPS or your own server, the work is yours or your developer's.
Usually not for long. A security patch within the same PHP line (for example 8.5.11 to 8.5.12) is a small change, and on managed hosting most owners notice nothing. Moving to a different PHP line (for example 8.2 to 8.4) is a bigger change: back up and test first.
PHP 8.5.12 and 8.4.27 have a confirmed bug (in SimpleXML, the part of PHP that reads XML files) that can crash some sites with the error “zend_mm_heap corrupted”. PHP 8.3.36 and older are not affected. PHP has committed a fix, but as of 27 October 2026 it is not in a release yet. Don't ask your host to go back to an unpatched version: php2shell is being used in real attacks. Send your host PHP's bug report and ask how they're handling it, or ask us in the chat.
Look for admin users you don't recognize, visitors sent to spam sites, a Google warning, new files you didn't add, or an email from your host about suspicious activity. No check catches everything. If you see any of these, read my website was hacked or ask us in the chat.
No. Every plan is month to month: cancel any month, keep everything, and pay $0 setup. See "Is there a contract?" on our pricing page.
