If your website runs on WordPress, it runs on PHP, and PHP has just had two of its most serious flaws in years. The fix is a server update, not a plugin update. Most Australian businesses on managed hosting will be patched by their host within days, but anyone on a VPS, an old PHP version or a cheap shared plan needs to check today.
This guide explains what PHP2Shell is in plain English, who is responsible for patching it on your type of hosting, and how to confirm your site is both patched and clean.
What is PHP2Shell?
PHP2Shell is the nickname for two critical vulnerabilities in the PHP language itself, tracked as CVE-2026-109618 and CVE-2026-109619. Both let an attacker run code on a web server without logging in, by sending specially crafted requests. Each is rated 9.2 out of 10 on the CVSS v4.0 scale, which is critical severity.
The details leaked online on 20 October 2026, two days before a planned coordinated disclosure. The PHP project responded with an emergency release on 21 October at 14:00 UTC, which was 1:00 am on Thursday 22 October in Sydney and Melbourne.
In simple terms, the two bugs work like this:
- CVE-2026-109618 (out-of-memory corruption): an attacker can deliberately make PHP run out of memory partway through a request, for example with a file upload request stuffed with headers or empty file fields. PHP then cleans up memory that was never properly set up, which can be turned into code execution.
- CVE-2026-109619 (stale state between requests): when a request crashes with a fatal error, some of its data is never cleared. The next request handled by the same PHP worker can pick up that stale data and be hijacked.
PHP rates the risk highest on Apache servers using mod_php, but PHP-FPM (the most common setup on modern hosting), php-cgi, LiteSpeed and FrankenPHP are all affected too.
Will updating WordPress or my plugins fix PHP2Shell?
Updating WordPress core, themes or plugins will not fix PHP2Shell. The flaws sit in the PHP engine on the server, and the attack can trigger before WordPress loads a single file. Only an updated PHP build on the server closes the hole, which is why your host or server administrator has to apply the fix.
This also means security plugins such as Wordfence or Solid Security cannot block it. They run inside WordPress, and by the time they start, the damage may already be done. Keep them installed for everything else they catch, but do not count them as protection here.
Is PHP2Shell being exploited yet?
Reported attacks have already started. WordPress security firm Patchstack says it has confirmed multiple active exploitation incidents, and Aikido has reported in-the-wild exploitation as well. As of 21 October, the PHP project had not confirmed attacks and the US CISA had not added the CVEs to its Known Exploited Vulnerabilities catalogue.
History says the window is short. When an earlier PHP flaw (CVE-2024-4577) went public in June 2024, Akamai saw exploit attempts within 24 hours. Treat any unpatched PHP site as a target from today.
Which PHP versions fix PHP2Shell?
The fixed PHP versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all released on 21 October 2026. Any PHP install serving web pages on a version older than these is vulnerable, including end-of-life versions 7.4, 8.0 and 8.1. PHP 7.3 and older will never receive a fix.
| PHP branch | Fixed version | Support status | Our advice |
|---|---|---|---|
| 8.5 | 8.5.12 | Active support to 31 Dec 2027 | Fine if your plugins support it |
| 8.4 | 8.4.27 | Active support to 31 Dec 2026, then security fixes | Recommended |
| 8.3 | 8.3.36 | Security fixes only to 31 Dec 2027 | Recommended |
| 8.2 | 8.2.35 | Security fixes end 31 Dec 2026 | Patch now, plan to move off it |
| 7.4, 8.0, 8.1 | Source backports only | End of life | Upgrade this week |
| 7.3 and older | No fix | End of life | Upgrade or take offline |
The trap here is PHP 8.2. It gets the fix, but its security support ends in ten weeks, so a site moved to 8.2 today will need moving again before Christmas. If you are going to the effort of testing a PHP upgrade, go straight to 8.3 or 8.4.
Version numbers can mislead. Linux distributions such as Ubuntu, Debian and AlmaLinux often patch PHP without changing the headline version number, adding a suffix instead. If your host says you are patched but the version looks old, ask them to confirm the package includes the PHP2Shell fix rather than assuming either way.
Who patches PHP2Shell on my hosting?
Who applies the PHP2Shell fix depends entirely on your hosting type. On managed WordPress hosting, the host does it. On shared cPanel hosting, the host patches PHP but you choose which version your site uses. On a self-managed VPS or cloud server, nobody patches it unless you or your developer do.
| Hosting type | Who installs the patch | What you need to do |
|---|---|---|
| Managed WordPress (WP Engine, Kinsta and similar) | Your host | Check the host’s status page or email for a PHP2Shell notice, then confirm your version in Site Health |
| Shared cPanel or Plesk hosting | Your host, for each PHP version it offers | Make sure your site is not set to PHP 8.1 or older in Select PHP Version or MultiPHP Manager |
| Self-managed VPS or cloud (AWS, DigitalOcean, Linode, Vultr) | You or your developer | Update the PHP packages and restart PHP-FPM and the web server today |
| Site built by a developer who has since moved on | Often nobody | Find out what server it is on and who has the login, before anything else |
That last row is more common than it should be. If you are not sure what kind of hosting you have, your monthly invoice usually tells you, and that is the first question to answer.
How to protect your WordPress site from PHP2Shell
Step 1: Check your current PHP version
Log in to WordPress and go to Tools > Site Health > Info > Server. The PHP version listed there is the one your site actually runs, which can differ from the version shown on the command line of the same server. Compare it with the table above.
Step 2: Get the patch applied
On managed or shared hosting, contact support and ask two direct questions: has the PHP2Shell patch been applied to the PHP version my site uses, and when? Get the answer in writing.
On a self-managed server, update the PHP packages for the version you run, then restart the PHP workers so the new build actually loads. On Ubuntu or Debian that looks like this, using PHP 8.3 as the example:
sudo apt update
sudo apt install –only-upgrade ‘php8.3*’
sudo systemctl restart php8.3-fpm
sudo systemctl restart nginx # or apache2
On AlmaLinux, Rocky or RHEL, run sudo dnf upgrade ‘php*’ and then restart php-fpm and your web server. Skipping the restart is the most common mistake: the old, vulnerable code stays in memory until the workers reload.
Step 3: Upgrade off end-of-life PHP, on staging first
If your site is on PHP 8.1 or older, the real fix is moving to 8.3 or 8.4. Older themes and plugins can throw errors or cause a blank “white screen” on newer PHP, so test on a staging copy first, update every plugin and theme, and have a developer review any custom code in functions.php that fails.
If an upgrade will take days, tell your host or developer it is urgent. An unpatched end-of-life site is exactly what attackers scan for.
Step 4: Use a firewall and config limits only as a stopgap
The PHP project says no complete workaround exists and updating is the only safe choice. If you genuinely cannot patch straight away, these measures reduce exposure to specific attack paths:
- Disable upload progress tracking: set session.upload_progress.enabled=0 in php.ini and restart every PHP worker. Few WordPress sites rely on this feature.
- Limit request sizes: lower post_max_size (around 8M without file uploads, 32M with them) and enforce request size limits at the web server or proxy.
- Put a web application firewall in front: a network-level WAF such as Cloudflare can filter some malicious requests before they reach your server. Check whether your provider has published rules specifically for PHP2Shell, and do not treat it as a substitute for patching.
How do I know if my site was already hacked?
A patched site is not necessarily a clean one. Exploitation was reported before many hosts finished patching, so any site that was exposed between 20 October and the day it was patched should be checked for signs of compromise.
Ask your developer or host to look for:
- Unfamiliar PHP files in the website folders, especially in wp-content/uploads, which should normally contain only images and documents
- New WordPress admin users you did not create
- New scheduled tasks (cron jobs) on the server or in WordPress
- PHP or web server processes launching shell commands or download tools such as curl and wget, which shows up in server logs and monitoring
If you find any of these, take a backup of the site and logs as evidence, then restore from a clean backup taken before 20 October and change every password. Australian businesses can report incidents to the Australian Signals Directorate through ReportCyber at cyber.gov.au.
What to do today
Check your PHP version in Site Health now. It takes two minutes. If it is below 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or you are on PHP 8.1 or older, contact your host or developer today and ask them to patch, restart and check for compromise.
If you would rather hand it over, Canty Digital can check your WordPress site’s PHP version, confirm the patch with your host, manage the upgrade on staging and look for signs of compromise. Book a call with the team or explore our WordPress Care and Security Plans.
Sources
- CSA Singapore alert AL-2026-151: CVSS scores and vulnerability types
- SOCRadar PHP2Shell FAQ: fixed versions, support dates, exploitation reports, workarounds and detection
- AlmaLinux security post: attack mechanics and PHP-FPM exposure
- SecurityWeek: leak timeline
- PHP advisory GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp
Meta tags and internal links
| Field | Value | Length |
|---|---|---|
| Title tag | PHP2Shell and WordPress: What to Do Now | Canty Digital | 55 characters |
| Meta description | PHP2Shell hits the PHP engine behind every WordPress site. See who patches it on your hosting, which PHP versions are safe and how to check for a hack. | 151 characters |
| URL slug | /blog/php2shell-wordpress/ |
Internal link anchors (each appears verbatim in the article):
- “managed WordPress hosting” → your hosting or WordPress services page
- “test on a staging copy first” → a WordPress maintenance or care plan page
- “Book a call with the team” → contact page (confirm the /contact URL is correct)
- “WordPress Care and Security Plans” → care plans page (URL still a placeholder)
JSON-LD schema
Paste into the page head or a custom HTML block. Replace the placeholders in curly braces (author, logo, image path) before publishing.
{
“@context”: “https://schema.org”,
“@graph”: [
{
“@type”: “Article”,
“@id”: “https://cantydigital.com.au/blog/php2shell-wordpress/#article”,
“headline”: “PHP2Shell and WordPress: What Australian Site Owners Need to Do Now”,
“description”: “PHP2Shell hits the PHP engine behind every WordPress site. See who patches it on your hosting, which PHP versions are safe and how to check for a hack.”,
“articleSection”: “WordPress Security”,
“keywords”: “PHP2Shell, WordPress, CVE-2026-109618, CVE-2026-109619, PHP-FPM, PHP versions”,
“inLanguage”: “en-AU”,
“datePublished”: “2026-10-22”,
“dateModified”: “2026-10-22”,
“author”: { “@type”: “Person”, “name”: “{{AUTHOR_NAME}}”, “jobTitle”: “{{AUTHOR_TITLE}}”, “url”: “{{AUTHOR_BIO_URL}}” },
“publisher”: {
“@type”: “Organization”,
“name”: “Canty Digital”,
“url”: “https://cantydigital.com.au”,
“logo”: { “@type”: “ImageObject”, “url”: “{{LOGO_URL}}” }
},
“image”: { “@type”: “ImageObject”, “url”: “https://cantydigital.com.au/{{IMAGE_PATH}}/php2shell-wordpress-hero.png”, “width”: 1600, “height”: 900 },
“mainEntityOfPage”: { “@type”: “WebPage”, “@id”: “https://cantydigital.com.au/blog/php2shell-wordpress/” },
“about”: [
{ “@type”: “Thing”, “name”: “PHP2Shell” },
{ “@type”: “Thing”, “name”: “WordPress” },
{ “@type”: “Thing”, “name”: “PHP” }
]
},
{
“@type”: “FAQPage”,
“@id”: “https://cantydigital.com.au/blog/php2shell-wordpress/#faq”,
“mainEntity”: [
{ “@type”: “Question”, “name”: “What is PHP2Shell?”,
“acceptedAnswer”: { “@type”: “Answer”, “text”: “PHP2Shell is the nickname for two critical vulnerabilities in the PHP language itself, tracked as CVE-2026-109618 and CVE-2026-109619. Both let an attacker run code on a web server without logging in, by sending specially crafted requests. Each is rated 9.2 out of 10 on the CVSS v4.0 scale, which is critical severity.” } },
{ “@type”: “Question”, “name”: “Will updating WordPress or my plugins fix PHP2Shell?”,
“acceptedAnswer”: { “@type”: “Answer”, “text”: “Updating WordPress core, themes or plugins will not fix PHP2Shell. The flaws sit in the PHP engine on the server, and the attack can trigger before WordPress loads a single file. Only an updated PHP build on the server closes the hole, which is why your host or server administrator has to apply the fix.” } },
{ “@type”: “Question”, “name”: “Which PHP versions fix PHP2Shell?”,
“acceptedAnswer”: { “@type”: “Answer”, “text”: “The fixed PHP versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all released on 21 October 2026. Any PHP install serving web pages on a version older than these is vulnerable, including end-of-life versions 7.4, 8.0 and 8.1. PHP 7.3 and older will never receive a fix.” } },
{ “@type”: “Question”, “name”: “Who patches PHP2Shell on my hosting?”,
“acceptedAnswer”: { “@type”: “Answer”, “text”: “Who applies the PHP2Shell fix depends entirely on your hosting type. On managed WordPress hosting, the host does it. On shared cPanel hosting, the host patches PHP but you choose which version your site uses. On a self-managed VPS or cloud server, nobody patches it unless you or your developer do.” } }
]
}
]
}
Hero image
Two brandless banner files were supplied in the chat: a 1600×900 in-page banner and a 1200×630 social card, in a dark ink palette.
- Filenames: php2shell-wordpress-hero.png and php2shell-wordpress-hero-og.png
- Alt text: Article banner reading: PHP2Shell and WordPress, what site owners need to do now.