PHP2Shell: What WordPress Website Owners Need to Know and Do

Last updated: 22 October 2026, 14:00

Key takeaways

• PHP2Shell is the nickname for two critical flaws in PHP (CVE-2026-109618 and CVE-2026-109619), announced on 21 October 2026.
• They let attackers take over a website’s server without a password, and read passwords and keys from its memory.
• Every self-hosted WordPress website was exposed until its host installed the fix, however up to date WordPress and its plugins were.
• Squarespace, Wix, Shopify, Webflow and Lovable websites aren’t affected.
• Your hosting company has to install the fix. Ask them to confirm it’s done.
• Security plugins like Wordfence can’t block this attack. Cloudflare lowers the risk but doesn’t remove it.
• Once the fix is in, check your website for signs of a break-in. Change your WordPress admin passwords and security keys as a precaution, and any other credentials if a break-in is suspected.

What is PHP2Shell?

PHP2Shell is the name for two critical security flaws in PHP, the programming language that runs WordPress and most of the web. They’re tracked as CVE-2026-109618 and CVE-2026-109619, and each is rated 9.2 out of 10 for severity.

In plain English: PHP is the engine that builds your website’s pages every time someone visits. The flaws are in how this engine cleans up when something goes wrong, such as running out of memory. With specially crafted requests, an attacker can make PHP reuse memory it should have thrown away. That can let them:

• Run their own code on the server, which means taking control of the website, with no password or login needed
• Read the server’s memory, which can hold passwords, login sessions and API keys

Because the problem is in PHP itself, it doesn’t matter how well your website is built. Researchers showed the attack working on a fresh, fully updated WordPress install. Every PHP version from 5.4 onwards is affected, which covers more than a decade of releases.

Key dates

17 October is the date to remember. It’s the earliest publicly reported attack attempt, so check for signs of a break-in from at least that date. Backups from before then may be useful if you need to restore your website, but they aren’t automatically guaranteed to be clean.

Which websites are affected?

Any website running on an unpatched version of PHP is affected until its host installs the fix. That includes:

• Every self-hosted WordPress website, including WooCommerce shops and sites built with Elementor or Divi
• Other PHP platforms, such as Joomla, Drupal and Magento
• Staging sites, test copies and old websites still sitting on a hosting account

Updating WordPress, your theme or your plugins does not fix this. The flaws are in PHP, which sits underneath WordPress and is managed by your hosting company.

Which websites are not affected?

Websites built on Squarespace, Wix, Shopify, Webflow or Lovable. These platforms run your website on their own systems, so there’s nothing for you to update.

Which PHP versions are safe?

The fix is in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Anything older needs updating.

How to check your PHP version

1. Log in to WordPress.
2. Go to Tools > Site Health > Info.
3. Open the Server section and find “PHP version”.

The number alone doesn’t settle it, for two reasons:

• Some hosts add the fix without changing the version number, so a lower number doesn’t always mean you’re exposed.
• The fix only works once PHP has been restarted, so a safe number on its own isn’t proof either.

Only your host can confirm both, which is the next step.

If you need to upgrade from an old version such as 7.4 or 8.0, take a backup first. Big jumps can break older themes and plugins, so test on a staging copy if you can, or ask your developer.

What should I do first?

Confirm with your hosting company that the fix is installed. Your website can’t install it itself: the host has to update PHP on its servers and restart it.

Many hosts acted quickly. South African host xneelo, for example, says its firewall blocked one of the known published attacks before the fix came out, and it then installed the fix across all its hosting servers.

Ask your host to confirm:

• The PHP fix for CVE-2026-109618 and CVE-2026-109619 is installed on the server your website uses
• PHP has been restarted since the update
• The fix covers everything on your hosting account, including staging sites and old websites

While you wait for an answer:

• Clear out what you don’t use. Staging sites, test copies and old websites on the same hosting account are just as exposed as your main site, and an attacker can use one to reach the others. Delete any you no longer need.
• Keep your backups. Don’t delete or overwrite any backup from before 17 October. If something turns out to be wrong, an earlier backup may help you recover your website. Ask your host or developer to check that it’s safe before restoring it.

What if my host hasn’t confirmed the fix yet?

Keep chasing them, because the fix is the only complete protection. In the meantime, two options lower your risk, strongest first.

1. Lock the website temporarily

Security agencies, such as the UK’s National Cyber Security Centre, advise taking a system offline if it can’t be updated straight away. For a small business website, the practical way to do this is a password lock at hosting level.

• Visitors see a username and password box instead of your website.
• It has to be set up on the hosting account, for example with a password-protected directory in your control panel. A WordPress maintenance mode plugin won’t help, because the attack happens before WordPress loads.
• Customers, Google and enquiries can’t reach your website until it’s unlocked.
• Shops may miss payment confirmations sent during this time, so check your orders afterwards.
• Remove the lock as soon as your host confirms the fix.

It’s a big step, so it’s usually only worth it for online shops, membership sites and websites holding customer information.

2. Ask your host to apply PHP’s temporary settings

PHP has published settings that block some known attack routes, such as switching off upload progress tracking and lowering the maximum upload size. Several only work when they’re set at server level, not through a plugin or a .user.ini file, so this is a job for your host.

They reduce the risk but don’t remove it. A lower upload limit will also stop large images and videos uploading, so ask your host to reverse it once the fix is in.

Do Wordfence or Cloudflare protect me?

Not on their own. They help in different ways, but neither replaces the fix.

Wordfence and other security plugins

Security plugins run inside WordPress, and some PHP2Shell attacks happen before WordPress even starts, so the plugin never sees them. Wordfence itself says updating and restarting PHP is essential for these flaws. Keep your security plugin switched on, though, as it still protects you from plenty of other attacks.

Cloudflare

Since 05:02 SAST on 21 October, Cloudflare’s firewall has blocked known versions of the attack for all its customers, including those on the free plan. That lowers your risk, but attackers have been changing their attacks to get around it, and anyone who finds your server’s real address can skip Cloudflare entirely. Cloudflare itself says you still need the PHP fix.

If your website already uses Cloudflare:

• Check that the orange cloud (“Proxied”) is switched on for your domain in the DNS settings. If it’s grey, traffic skips Cloudflare’s firewall.
• On a paid plan, make sure the Cloudflare Managed Ruleset is set to block.
• See blocked attempts under Security > Security Analytics > Events. A blocked attempt means someone tried, not that they got in.

Updating WordPress and plugins

Good practice, but it doesn’t fix this. The flaws are in PHP, which WordPress updates don’t touch.

How can I tell if my website was hacked?

Check for anything unusual from 17 October onwards. These checks catch the most common signs, but a clean result isn’t proof, because this attack can leave very little trace.

Checks anyone can do

1. Open your website in a private or incognito window on your phone. Look for pages you didn’t create, pop-ups, or being sent to another website.
2. In WordPress, go to Users and look for administrator accounts you don’t recognise.
3. Go to Plugins and look for anything you didn’t install.
4. Search Google for site:yourwebsite.co.za (with your own address) and look for odd pages, such as casino, pharmacy or foreign-language pages.
5. Run a security scan. In Wordfence, choose High Sensitivity under Scan Options, then start a new scan. Check for recent alert emails too.
6. Check your inbox for warnings from your host about harmful files or a suspended account.

Checks for your host or developer

• Unfamiliar or recently changed files, especially PHP files in the uploads folder (wp-content/uploads), where they don’t belong
• Scheduled tasks (cron jobs) nobody set up, both in the hosting control panel and inside WordPress. Attackers use these to get back in after being removed
• Server logs from 17 October showing unusual file-upload requests followed by memory errors or bursts of 500 errors
• Requests containing PHP_SESSION_UPLOAD_PROGRESS, which Amazon flags as a sign of attack attempts
• Unusually large PHPSESSID cookies in server responses, or PHP restarting for no clear reason
• New user accounts or unexpected programs started by PHP

What should I do after the fix is installed?

Review your passwords and keys. One of the flaws can expose sensitive information stored in the server’s memory, including passwords, login sessions and API keys. Having a vulnerable website doesn’t necessarily mean someone accessed that information, but this kind of access may leave no sign at all, so a website that looks clean could still have been affected.

Wait until your host confirms the fix is installed before changing anything. Then, even if your checks find nothing, change your WordPress admin passwords and security keys as a precaution. Review other credentials, such as database passwords and payment gateway keys, with your host or developer.

If you find signs of a break-in, ask your host or developer to investigate and secure the website first, then change any credentials that may have been exposed.

Also after the fix

• Undo any temporary measures. Remove the password lock and ask your host to reverse any lowered upload limits.
• Watch for errors. The fix adds a new hard memory limit. If your website shows a blank page, a “critical error” message or 500 errors after the update, ask your host or developer to review the PHP memory settings.
• Keep everything updated. Keeping WordPress, your theme and plugins up to date won’t fix this flaw, but it closes plenty of others.

What if I find signs of a hack?

Don’t start deleting things yourself. Deleting files can destroy the evidence of what happened and miss the hidden “back doors” attackers leave behind. Instead:

1. Save the evidence. Ask your host to keep the server logs, and any suspicious files, from 17 October onwards.
2. Lock the website if it’s causing harm. If it’s sending visitors elsewhere or showing anything strange at checkout, lock it at hosting level while you deal with it.
3. Ask your host or developer to investigate the break-in and check whether a backup can safely be restored. A backup from before 17 October is a good starting point, but it still needs checking. Make sure the underlying security issue is fixed, and preserve any orders, form entries or content added since the backup so they can be recovered.
4. Change any passwords and keys that may have been exposed, once your host or developer confirms the website is secure.
5. Check again. Look for unknown admin users and scheduled tasks once more, in case anything survived.

Your duty under POPIA

In South Africa, if there are reasonable grounds to believe customers’ personal information was accessed, section 22 of POPIA requires you to notify the Information Regulator and the affected customers as soon as reasonably possible. This covers names, email addresses, phone numbers and physical addresses, not just card details. Other countries have similar rules, such as GDPR in Europe. If you’re unsure whether it applies to you, speak to a legal adviser.

Watch out for scams

Criminals use news like this to send fake “urgent security update” emails, often pretending to be your host, WordPress or a security company.

• No plugin can install this fix. It’s a server update, so treat any “PHP2Shell patch” plugin or file as a scam.
• Your host won’t ask for your password by email.
• Don’t log in through email links. Go to the website yourself, or contact the company using details you already have.