If a website you rely on showed a maintenance page on October 21, 2026, there is a good chance PHP2Shell was the reason. Within hours of a leak, security teams, hosting companies and even government bodies were taking PHP servers offline or rushing out emergency updates. The cause was a pair of critical flaws in PHP itself, the programming language that powers WordPress, Drupal, Joomla, Magento and a huge share of the web.
This guide explains PHP2Shell in plain English: what it is, who found it, how it works, why it matters so much, and exactly what to do to protect your website. It is written for site owners, bloggers, agencies and developers, with a strong focus on practical steps for WordPress websites.
Key Takeaways
- PHP2Shell is the nickname for two critical PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619. Each is rated 9.2 out of 10 (CVSS v4.0) by the PHP security team.
- Both flaws can allow remote code execution (RCE): an attacker can run their own commands on your server without logging in.
- The bug is in the PHP engine, not in WordPress, a plugin or a theme. Updating WordPress or plugins does not fix it.
- The fix is a PHP security update: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a patched package from your hosting provider or Linux distribution).
- PHP 8.1 and older no longer receive official fixes. Those sites must move to a supported version or get a vendor backport.
- Attack attempts were seen before the patch was public, and scanners are now sweeping the internet. Treat this as urgent.
What Is PHP2Shell?
PHP2Shell is the name that security researchers and the media have given to two serious security flaws in the core of PHP. PHP’s own advisories refer to them only by their CVE numbers, while the PHP2Shell name spread after an exploit tool and write-ups appeared publicly.
To understand the name, it helps to know two terms:
- PHP is the server-side programming language behind a large part of the internet. When you visit a WordPress page, PHP builds it on the server before sending it to your browser.
- A shell is a command line, the place where you type instructions to control a computer. If an attacker gets a shell on your web server, they can read files, change your pages, steal data, install malware and often use your server to attack others.
So PHP2Shell literally means going from a PHP web request to a shell on the server. An attacker sends a specially crafted request, and if the server is unpatched, the flaw can let them execute commands as the user account that PHP runs under.
In simple words: your website’s engine has a crack in it, and it does not matter how clean your own code is.
Is PHP2Shell the same as a PHP web shell?
Not exactly, although they are related. A web shell is a malicious script that attackers upload to a hacked website so they can control it later. PHP2Shell is a vulnerability that could help an attacker get in and drop a web shell in the first place. Old tools such as PHPShell are a different story entirely and have nothing to do with these two CVEs.
The two vulnerabilities at a glance
| Detail | CVE-2026-109618 | CVE-2026-109619 |
| Short description | Remote code execution through out-of-memory corruption | Remote code execution through stale (leftover) global state |
| Type of bug | Memory-safety flaw (use-after-free) | Memory-safety flaw (use-after-free) |
| PHP severity (CVSS v4.0) | 9.2 Critical | 9.2 Critical |
| Login needed? | No | No |
| Extra risk | Can leak server memory, similar in spirit to Heartbleed | Can be reached through session upload progress handling |
The National Vulnerability Database also lists its own CVSS 3.1 score of 9.8 for these issues, which is the highest tier of severity.
Who Discovered PHP2Shell?
The vulnerabilities were not found by a single person. According to published research and security vendors, the discovery credit is shared:
- Calif, a security research lab. Ryan Austin of Calif is named in public credits, and Calif’s research is credited with the PHP2Shell exploit tool.
- Wiz Research, the research team at cloud security company Wiz. The named researchers are Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz. Wiz reported the issues to PHP in late August 2026.
- OpenAI, which is credited alongside the others as part of a joint effort described by security researchers as the Patch the Planet initiative.
The PHP security team coordinated the response. The fixes were developed by PHP core contributors including Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka and Nora Dossche, according to a notice from the AlmaLinux project, which thanked them for their work.
It is worth noting that the catchy name PHP2Shell came from the community and the public tooling, not from PHP itself. If you search PHP’s official advisories, look for the CVE numbers and the GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.
PHP2Shell Timeline: From Discovery to Emergency Patch
The timeline matters because it shows how quickly this went from a quiet, coordinated disclosure to a public emergency. Dates below come from several security write-ups, and small differences between sources are normal in a fast-moving event.
- August 1, 2026: Calif finds multiple remote code execution paths.
- August 11, 2026: Calif reports the first bug to PHP.
- Around August 19-24, 2026: Wiz Research finds the first flaw and reports the vulnerabilities to PHP.
- September 2026: PHP acknowledges the reports and begins work on fixes.
- October 20, 2026: Details leak publicly, including a working proof of concept. CERT-EU publishes Security Advisory 2026-018 naming both CVEs. PHP brings its release forward by a day, from the planned October 22.
- October 21, 2026, morning (UTC): Cloudflare reports early attacks, and security sensors record the first exploit-style requests hours before the fix is public.
- October 21, 2026, 14:00 UTC: PHP releases the patched versions and publishes advisories.
- October 21, 2026, afternoon and evening: CISA and the UK’s NCSC publish alerts, researchers report active exploitation attempts, and scanning tools spread.
The key lesson is speed. The patch and the attacks arrived almost at the same time. Websites that waited a week to update were exposed during the most dangerous window.
How Does PHP2Shell Work? (Explained Simply)
You do not need to be a security engineer to understand the idea. Here is a simple picture.
Imagine PHP as a restaurant kitchen. Each incoming web request is an order. PHP uses a limited amount of counter space (memory) to prepare each order, and when an order is finished, the cook is supposed to clear the counter and throw away what is no longer needed.
In a use-after-free bug, something goes wrong during clean-up. A cook throws a tray into the bin, but another part of the kitchen still thinks the tray is on the counter and keeps using it. If an attacker can control what ends up on that tray, they can trick the kitchen into doing things it was never meant to do. In a computer, that can mean running attacker-supplied code.
What triggers the bugs?
Security researchers report that the known attack requests use multipart/form-data. This is the format web browsers use when you upload a file or submit certain forms. PHP has to read and parse that data very early, before your WordPress code, your plugins or your security plugin even start running.
This detail is the reason PHP2Shell is so serious. Security tools that live inside your application, such as a WordPress security plugin or a maintenance-mode plugin, may never get a chance to stop the request.
CVE-2026-109618: out-of-memory corruption
When PHP runs out of memory in the middle of a request, it can stop abruptly and leave some request data only half set up. During shutdown, PHP then works with that damaged data. Researchers explain that an attacker can push PHP toward running out of memory by sending oversized or oddly built form data, such as many headers inside one part or deeply nested field names. PHP’s advisory confirms this path can be exploited against Apache with mod_php using default settings.
This bug can also behave like a memory leak. According to Sansec’s analysis, PHP’s upload progress handler can return pieces of freed memory to the attacker inside a session cookie. Memory from a busy server can contain passwords, session tokens, API keys and even private keys from other visitors’ requests. Researchers compare this to the famous Heartbleed bug.
CVE-2026-109619: stale global state
If a request dies at the wrong moment because of a fatal error, a timeout or a memory problem, it can leave stale data behind in a PHP worker. A later request handled by the same worker can then read that data after it has already been freed. The session upload progress feature is one of the code paths involved, which is why attack attempts often include a form field called PHP_SESSION_UPLOAD_PROGRESS. PHP validated this path against both Apache mod_php and PHP-FPM.
Together, the two flaws can be chained into a single attack that needs no login and no help from the victim.
Why Is PHP2Shell So Crucial and Dangerous?
Security teams do not describe many bugs as emergencies. PHP2Shell earned that label for several reasons.
1. No login is required
Most website attacks need something: a vulnerable plugin, a stolen password or a trick played on an administrator. Here, researchers say an unauthenticated visitor can reach the flaw, and the exploit works against default settings. That makes automated, internet-wide scanning easy.
2. The flaw sits underneath your website
Because the problem is in the PHP engine, every PHP application on an unpatched server may be exposed, even if the application itself is perfectly maintained. Security researchers reported showing unauthenticated code execution against default installs of many popular PHP applications, including WordPress, Drupal, Joomla, Magento, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS.
3. It affects a very long history of PHP versions
The vulnerable code reportedly dates back to PHP 5.4, released in 2012. That means millions of old servers, forgotten websites and unmanaged devices could be affected.
4. Attacks started before the patch
Cloudflare reported early attacks on the morning of October 21, and independent honeypot operators saw exploit-style requests roughly five and a half hours before PHP published the fix. Within hours, researchers noticed scanners named after the bug, then more advanced tools that attempt to download and run malware on a vulnerable host.
5. A hacked trusted website is a weapon
As one security researcher quoted by Malwarebytes put it, this is a goldmine for hackers because they can hijack real websites and use their reputation to phish people or deliver malware. A hacked WordPress site can be used to redirect visitors, steal customer data, host spam pages, send junk email or become part of a botnet.
6. Business impact is real
Even when sites are not hacked, protecting them is costly. Several well-known Dutch websites, including a technology news site and government organisations, went offline as a precaution on October 21. For a small business, downtime means lost orders, lost leads and lost trust. If customer data or payment pages are involved, a breach can also bring legal and compliance headaches.
Which Websites and PHP Versions Are Affected?
In short: any server running PHP that handles web requests and has not been patched.
- PHP versions: reports describe affected releases from PHP 5.4 through the 8.x line, before the October 21 updates.
- Fixed versions: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
- Server setups: both Apache with mod_php and PHP-FPM have been shown to be affected. Researchers note that some attack paths are demonstrated on one setup more than the other, but you should not rely on your setup to keep you safe.
- Platforms: WordPress, WooCommerce, Drupal, Joomla, Magento, Shopware, Laravel, Symfony, custom PHP sites and PHP-based admin panels.
What about PHP 8.1 and older?
The PHP project only supports versions 8.2 and later, so there are no official fixes for PHP 8.1, 8.0, 7.x or 5.x. These sites should be moved to a supported version as soon as possible. Some Linux distributors maintain their own older packages and publish backported fixes, so ask your hosting provider or check your distribution’s security notices before assuming you are unprotected or protected. For example, AlmaLinux announced patched packages, including a fix for its PHP 7.4 stream on AlmaLinux 8 that rebuilt Red Hat’s update.
Are visitors at risk?
If you only browse websites, you do not need to install PHP updates on your own computer. The danger lies in the web servers. Visitors should still be careful about unexpected redirects, strange downloads and repeated login prompts, even on familiar sites, because a trusted website may have been compromised.
Is PHP2Shell Being Exploited in the Wild?
Short answer: attack activity has been observed, and you should assume it will grow.
Reports differ slightly depending on the time they were written. PHP’s own early statements did not report in-the-wild exploitation, while Cloudflare warned of early attacks, the watchTowr honeypot network reported active exploitation attempts, and ELLIO’s sensors recorded PHP2Shell scanning hours before the patch was public. By the evening of October 21, researchers described multiple tool families, including scanners that carry commands to download and run a second-stage program on the target. No public source had confirmed a large wave of successful compromises at the time of writing, but the pieces of a working attack chain are clearly being assembled in the open.
The bigger worry is automation. A new unauthenticated RCE rarely stays with its first author. Botnet operators who already scan the internet for other weaknesses simply add the new bug to their routine, and those scanners run around the clock.
Signs to look for in your logs
If you or your host keep web server logs, security researchers have published these indicators of PHP2Shell scanning:
- User agents such as php2shell-scan/109618, php2shell-109618 and php2shell-verify/1.0.
- Multipart boundary strings that begin with —-p2s, including —-p2shell.
- POST requests containing a field named PHP_SESSION_UPLOAD_PROGRESS. Some legitimate sites use this feature, so treat it as a signal, not proof.
- Multipart POST requests built from hundreds of empty file fields, or with form field names nested many levels deep.
- PHP workers that crash or exit on memory errors in bursts, or a PHP process suddenly starting a shell or network tool.
Attackers can change these details at any time, so a clean log search is not a guarantee. Patching is the only complete fix.
How to Check Whether Your Website Is Vulnerable
Follow these quick checks:
- Find your PHP version. In WordPress, open Tools > Site Health > Info > Server and read the PHP version. You can also check your hosting control panel.
- Compare it with the fixed versions. You are on a safe upstream release if you run PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer.
- Remember distribution backports. Linux distributions often keep an older version number but add the security fix. For example, a server can report 8.3.6 and still contain the patch. Check your provider’s security notice or the package changelog for CVE-2026-109618 and CVE-2026-109619.
- Ask your host in writing. If you are on shared or managed hosting, ask them to confirm that the PHP fix is installed on your account, not just scheduled.
- Do not forget secondary sites. Staging sites, old campaign pages, subdomains, forgotten test installs and PHP admin tools such as phpMyAdmin all run on PHP and need the same protection.
How to Fix PHP2Shell: Step-by-Step PHP Update Guide
The fix is a PHP update on the server. You cannot repair PHP2Shell from inside WordPress. Here is a safe process for most websites.
Step 1: Take a full backup
Back up your site files and database, and store the copy somewhere other than the same server. Confirm that you can download it. This takes ten minutes and can save your business if an update causes trouble.
Step 2: Update WordPress, plugins and themes first
Old plugins and themes are the usual reason a site breaks on a newer PHP version. Update core, plugins and themes, and delete anything you no longer use. This is good hygiene, but remember that it does not fix PHP2Shell on its own.
Step 3: Update PHP
The exact method depends on your hosting.
Shared hosting with cPanel
- Log in to cPanel and open MultiPHP Manager (or Select PHP Version).
- Choose your domain and switch it to a supported PHP version such as 8.3 or 8.4.
- Click Apply. Then ask your host to confirm that the version they run includes the October 21 security fixes.
Plesk
- Open Websites & Domains, choose the domain and select PHP Settings. Pick a supported version and save.
Managed WordPress hosting
- Most managed hosts have a PHP version setting in the site dashboard. If you cannot find it, open a support ticket and ask them to apply the PHP2Shell patch.
Your own VPS or dedicated server (Ubuntu or Debian example)
Run these commands as an administrator:
php -v
sudo apt update
sudo apt upgrade
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2
Replace php8.3-fpm with your PHP-FPM service name. If you use nginx, reload nginx instead of Apache. If you installed PHP from a third-party repository, check whether that repository has published the fixed packages. According to Sansec, a popular volunteer-run repository used on many RHEL-based servers had not published the update on October 21, so switching to your distribution’s packages or building from source may be necessary until it does. Always re-check the repository’s status before acting, because this can change quickly.
Step 4: Test the site
Open your homepage, a few posts, your contact form, login, checkout and the WordPress admin. Enable WordPress debugging on a staging copy if you can, and read the error log. If something breaks, switch back to the old PHP version temporarily, update or replace the problem plugin and try again. Do not leave a vulnerable PHP version running for longer than necessary, and use the temporary protections below in the meantime.
Step 5: Confirm the patch is really installed
Recheck Site Health and ask your host for written confirmation. Selecting 8.3 in a control panel does not by itself prove the newest security release is active.
Step 6: Plan for PHP 8.1 and older
If you run PHP 8.1, 8.0 or any PHP 7 or 5 version, no official fix is coming. Either obtain a vendor backport that explicitly names the two CVEs, or upgrade to a supported branch. Treat this as a project for this week, not for next quarter.
Temporary Protection If You Cannot Patch Right Now
If you truly cannot update immediately, these steps reduce risk. They are partial, they can break features, and they are not a substitute for the update. Adapt them with the help of your developer or host.
1. Block multipart/form-data requests
All known triggers use multipart form data, and PHP parses it before your application runs. You can reject those requests at the web server.
For nginx, inside each server block that passes requests to PHP:
if ($http_content_type ~* multipart/form-data) {
return 403;
}
For Apache, inside each virtual host that serves PHP:
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ – [F]
This will stop file uploads, including WordPress media uploads and some contact forms with attachments, and some checkout forms may also stop working. Test after applying and remove the rule once PHP is updated.
2. Take the site offline or make it read-only
If you can afford it, taking the PHP site offline is the safest short-term choice. Stop PHP and serve a static maintenance page from the web server. Be aware that a WordPress maintenance-mode plugin does not help here, because PHP processes each request before WordPress gets to check the maintenance flag.
If you cannot go offline, you can configure the web server to reject every request method except GET and HEAD. Visitors can still read pages but cannot log in, comment or buy.
3. Adjust PHP settings
Researchers published two partial PHP-level stopgaps: turn off session upload progress, and remove the memory cap. PHP’s advisory treats them as targeting different bugs, so neither is enough alone. Setting the memory limit to unlimited is risky because one request can use all of the server’s memory, so monitor closely and restore the limit after patching.
For Apache with mod_php, in php.ini:
session.upload_progress.enabled = 0
memory_limit = -1
For PHP-FPM, add this to each pool configuration and reload the service:
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
On PHP 8.5, also set fatal_error_backtraces=0. Restart your PHP workers afterward and confirm the values from a real web request, not only from the command line.
4. Use a web application firewall as a speed bump
A firewall such as Cloudflare’s can filter some malicious requests, but experts warn that these rules are a stopgap and may be bypassed. Keep patching on the top of your list.
5. Keep sensible upload limits after patching
Even after the update, limit request body size, the number of form parts and the number of headers per part where possible. A patched PHP still stops a worker that runs out of memory, so reasonable limits reduce abuse.
After Patching: Check for Signs of a Hack and Rotate Secrets
Updating PHP closes the door, but it does not tell you whether someone already walked through it. This is especially important because attacks began before the patch was released, and because one of the bugs can leak server memory.
Look for signs of compromise
- Unknown PHP files, especially inside wp-content/uploads, which normally holds images and documents, not code.
- New administrator users you did not create, or existing users with changed roles.
- Recently modified core files, a modified .htaccess or an unexpected change to wp-config.php.
- Unfamiliar scheduled tasks (cron jobs) or WordPress cron events.
- Strange outbound traffic, sudden CPU spikes, spam emails, or search results showing Japanese or pharmaceutical spam pages for your domain.
- Redirects to unknown sites, especially on mobile or when arriving from Google.
Run a reputable malware scanner such as Wordfence or Sucuri, and ask your host to run a server-side scan. Compare your files with a clean copy of WordPress and your plugins.
Rotate your secrets
Because the memory-disclosure behavior can expose sensitive data, security professionals recommend rotating credentials on any server that was exposed before patching, particularly on busy or high-value sites:
- WordPress administrator, editor and shop manager passwords.
- Database username and password (and update wp-config.php).
- Hosting, SFTP and SSH credentials and keys.
- API keys for payment providers, email services and any third-party integrations.
- WordPress authentication keys and salts, which forces all users to log in again.
- TLS private keys, if you manage your own server and suspect exposure.
If you find a compromise
Take the site offline, preserve a copy of the evidence, restore from a clean backup made before the intrusion, update everything, rotate all credentials, and remove any web shells or unknown users. Consider professional incident response if customer data or payments may have been affected, and check whether you have legal duties to notify users.
How to Secure Your WordPress Website Against Attacks Like PHP2Shell
No single setting makes a site invincible, but layers make life hard for attackers. Use this checklist for stronger WordPress security.
- Keep everything updated, including WordPress core, plugins, themes and the PHP version. Enable automatic updates for minor and security releases where it makes sense.
- Use supported PHP versions only, and put PHP version checks on your monthly maintenance list.
- Remove what you do not use. Every inactive plugin or theme is extra code that can be attacked.
- Use strong, unique passwords and two-factor authentication for all admins and for your hosting account.
- Apply least privilege. Give people only the role they need, and do not use the admin account for daily publishing.
- Disable the built-in file editor by adding define(‘DISALLOW_FILE_EDIT’, true); to wp-config.php, so a hijacked admin session cannot edit plugin code from the dashboard.
- Stop PHP from running in the uploads folder with a server rule. This blocks a common trick of uploading a web shell disguised as an image.
- Use a web application firewall and rate limiting, and keep a malware scanner active.
- Back up automatically (daily for active sites), keep copies off the server, and test restores.
- Use SFTP or SSH instead of plain FTP, and give each website its own hosting account or user where possible, so one hacked site cannot easily infect another.
- Monitor file changes and logs. Alerts for new PHP files or new admin users give you an early warning.
- Choose a hosting provider that patches fast and communicates clearly during emergencies.
Common PHP2Shell Myths
Myth: I updated WordPress, so I am safe. No. The flaw is in PHP, so WordPress and plugin updates do not fix it. Someone must update PHP on the server.
Myth: My security plugin will block it. Not reliably. PHP processes the request before WordPress and its plugins run, so application-level protection may never see it.
Myth: Maintenance mode protects me. No. PHP still parses each request before the maintenance page logic runs.
Myth: A firewall is enough. A firewall can reduce attacks, but experts call these rules a stopgap. The update is the real fix.
Myth: My site is small, so nobody cares. Automated scanners do not choose targets by size. They test every reachable server.
Myth: If my site is offline for a few hours, I was hacked. Not necessarily. Many administrators took sites offline only as a precaution while they installed updates.
Quick Checklist for Agencies, Freelancers and Site Owners
- Make a list of every client site, its host and its PHP version.
- Contact each host and request written confirmation of the patch.
- Back up each site before changing anything.
- Update PHP, then test forms, logins, payments and admin screens.
- Scan every site for web shells and suspicious admin users.
- Rotate passwords, keys and salts where exposure is possible.
- Move PHP 8.1 and older sites to supported versions.
- Tell clients what happened and what you did, in plain language.
- Schedule a monthly check so PHP never falls behind again.
Frequently Asked Questions About PHP2Shell
What is PHP2Shell?
PHP2Shell is the nickname for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can let an attacker run code on a web server without logging in.
Who found the PHP2Shell vulnerabilities?
Public credit goes to Calif (Ryan Austin), Wiz Research and OpenAI, with the PHP security team coordinating the fix.
Is WordPress vulnerable to PHP2Shell?
WordPress runs on PHP, so a WordPress site on an unpatched PHP server may be exposed even if WordPress itself is fully updated. Researchers reported demonstrating attacks against default WordPress installs.
Which PHP version fixes PHP2Shell?
PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, or a vendor package that explicitly includes the fix.
Do I need to update PHP on my computer?
No. The risk is on web servers. Site visitors do not need to install PHP updates.
Can Cloudflare or a firewall stop PHP2Shell?
They can help filter some attack traffic, but they are only a temporary measure. Update PHP.
Will updating PHP break my website?
It can, if you use outdated plugins or themes. That is why you should back up, update plugins first, test on staging if possible and keep a rollback plan.
How do I know if my site was hacked?
Look for unknown PHP files, new admin accounts, changed core files, spam pages, redirects and odd server activity, and run a malware scan. If you find anything, follow the compromise steps above.
What should I do if I use PHP 7 or PHP 8.1?
Ask your provider for a backported fix that names both CVEs or upgrade to a supported PHP version as soon as possible.
Final Thoughts
PHP2Shell is a reminder that websites are only as safe as the software underneath them. This time the weak spot was not a plugin or a bad password but the PHP engine that quietly runs a huge part of the internet. The good news is that the fix exists, and the steps are clear: confirm your PHP version, update to a patched release, test your site, check for signs of compromise, and rotate sensitive credentials where needed.
Make PHP version checks a permanent part of your website maintenance routine, because the next emergency will not announce itself either. Bookmark DigiZipe for clear, practical guides on website security, WordPress and web technology as this story develops.
