Summary: PHP2Shell is the name given to two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619 (CVSS 9.2). They let an unauthenticated attacker run code on any web server that uses PHP, and attacks were reported on the day the fixes came out (21 October 2026). Any organisation running WordPress, Joomla, Drupal, Magento, Moodle or another PHP-based CMS, e-commerce store or web form should patch PHP to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 now, or confirm in writing that its hosting provider has done it.
What is PHP2Shell?
PHP2Shell is a pair of flaws in PHP itself, the programming language behind most of the world's websites, rather than in any single application or plugin. Both were disclosed on 21 October 2026 and rated 9.2 (Critical) on CVSS v4.0.
- CVE-2026-109618 abuses the way PHP handles running out of memory while it reads an incoming web request. A crafted form submission leaves request data half-built, which an attacker can turn into command execution.
- CVE-2026-109619 is a use-after-free bug. A later request can reuse data left behind by an earlier one, including through PHP's built-in session upload progress feature, which is switched on by default.
The key point for defenders is that the attack happens before any application code runs. Passwords, login pages, CMS security plugins and application-level controls can't block it. Any PHP page on an exposed server is enough.
Is it being exploited?
Yes. Technical details leaked before the patches were released. Security vendors including watchTowr and Cloudflare reported exploitation attempts and broad internet scanning from 21 October 2026. Researchers have also demonstrated working remote code execution against popular PHP applications, including Magento. Treat every unpatched, internet-facing PHP server as at risk now.
Remote code execution isn't the only danger. Armis reports that some attack paths can also leak memory from other users' requests, exposing passwords, session tokens and encryption keys, in a way that recalls the 2014 Heartbleed bug. So even a server that was never taken over may have leaked secrets.
Which PHP versions are affected?
- Affected: every PHP version from 5.4 up to (but not including) the fixed releases below, on Apache mod_php, PHP-FPM, php-cgi, LiteSpeed and FrankenPHP. Apache with mod_php carries the highest risk.
- Fixed: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
- PHP 7.4, 8.0 and 8.1: no official release, only source-code backports. These versions are end-of-life and should be upgraded.
- PHP 7.3 and older: no fix at all. Upgrade.
Which platforms and organisations are affected?
Because the flaw is in PHP itself, every application running on a vulnerable PHP version is exposed, however well it's maintained. Common examples include:
- Content management systems: WordPress, Joomla, Drupal, TYPO3, Craft CMS and Concrete CMS
- E-commerce: WooCommerce, Magento / Adobe Commerce, PrestaShop, OpenCart and Shopware
- Learning, community and collaboration: Moodle, MediaWiki, phpBB and Nextcloud
- Business tools: PHP-based CRMs, helpdesks, booking and payment portals, and custom contact, enquiry or registration forms
- Admin tools and appliances: phpMyAdmin, hosting control panels, and network or security devices with PHP-based management interfaces
This affects every industry: corporate and marketing websites, online retail, education, healthcare, not-for-profits, local government and financial services. Forgotten systems carry the most risk, such as an old campaign microsite, a staging copy of the website, or a form built years ago by a contractor.
One important clarification: PHP2Shell is not the "wp2shell" WordPress vulnerability patched in July 2026. Updating your CMS core, themes or plugins does not fix PHP2Shell. The PHP version on the server is what has to change.
What should IT teams do now?
- Build an inventory. List every website, web application and appliance that runs PHP, including staging and development copies, who hosts each one, and which PHP version it uses. Your hosting control panel shows the version, and most CMS admin areas have a system information page (for example Tools > Site Health > Info in WordPress, or System > System Information in Joomla).
- Find the sites you've forgotten about, using DNS. Your inventory is only as good as your records. In a recent engagement, one of our customers found DNS records that had never been cleaned up. One of them pointed to an old website, built years earlier and forgotten, that was running a vulnerable PHP version. To find yours, use free tools such as DNSDumpster and Shodan to list every subdomain, hostname and IP address linked to your domain names. Certificate transparency logs such as crt.sh are another useful source. Check each result against your inventory, find an owner for anything unfamiliar, and decommission or patch it. Delete DNS records that point to services you no longer use, because they can also be hijacked.
- Prioritise internet-facing systems. Patch anything reachable from the internet first, starting with Apache mod_php servers and systems that handle personal, payment or login data. Internal systems come next.
- Patch PHP to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later, or apply your Linux distribution's patched package. Then restart the web server or PHP-FPM so no worker is still running the old version, and rebuild any container images. If you suspect a server has already been compromised, capture evidence before you restart it (see below).
- Confirm the fix is actually running. A patched file on disk doesn't help if the old version is still loaded in memory. Check the PHP version and settings that web requests actually get (for example from a temporary, access-restricted status page), not just
php -v on the command line, which often uses a different binary or configuration. - Check with your hosting, SaaS and agency providers today. If someone else hosts or manages the platform, they patch the server, not you. Ask for written confirmation that the fixed PHP version is in place. Don't assume.
- Upgrade end-of-life PHP. If anything still runs PHP 8.1 or older, schedule an urgent upgrade to a supported branch. Patching internet-facing applications within 48 hours when an exploit exists is also a core requirement of the ASD Essential Eight.
- Check appliances. Look for vendor advisories for firewalls, VPNs, NAS devices and other products with PHP-based management portals, and apply their updates as they're released.
How can you reduce the risk if you can't patch yet?
These interim measures reduce exposure but are not a fix. Use them only until PHP is patched.
- Restrict access. Take non-essential PHP sites offline. Limit admin panels, staff-only and internal applications to corporate networks or VPN. For sites that only need to display content, consider allowing only GET and HEAD requests until they're patched.
- Tighten firewall and security group rules. Allow inbound traffic only from the sources, ports and protocols each server needs, and remove broad "any source" (0.0.0.0/0) rules from admin and back-end services.
- Turn on WAF protection. Make sure your web application firewall (for example Cloudflare, AWS WAF, Azure Front Door or your host's WAF) has up-to-date managed rules. Ask your provider whether they cover PHP2Shell, and block requests with abnormally long form field names or binary data in form fields.
- Change PHP settings in
php.ini or the server configuration, not with ini_set() or .user.ini, which take effect too late. Then restart all PHP workers:session.upload_progress.enabled = 0- On PHP 8.5 only:
fatal_error_backtraces = 0 - Keep
post_max_size low (Armis suggests around 8M for sites without uploads and 32M with them), with upload_max_filesize below it. - Apply the PHP advisory's
memory_limit guidance, and prefer container or cgroup memory limits over RLIMIT_AS/RLIMIT_DATA, which can trigger the vulnerable code path. - As extra hardening, turn on
session.use_strict_mode and session.use_only_cookies.
- Limit requests at the edge. Enforce limits on request size, number of form fields and upload parts, and nesting depth at the web server, reverse proxy or WAF. If a site doesn't accept file uploads, block multipart form submissions completely.
- Segment exposed servers from internal networks, databases and identity systems they don't need to reach. A Zero Trust approach, where web servers get only the access they need and no implicit trust, limits how far an attacker can move after compromising one server. Our Zero Trust assessment can show where your architecture needs tightening.
How can you tell if a server has been compromised?
- The web server account (for example
www-data or apache) starting a shell such as sh or bash, especially with outbound network connections. This is the strongest indicator. - PHP error log entries reading
Allowed memory size of ... bytes exhausted with Unknown on line 0, meaning PHP failed before any script ran. - Apache
AH00052 child process crashes with Segmentation fault. - New or modified
.php files in upload folders, unexpected admin accounts, injected payment-page scripts, or unfamiliar scheduled tasks. - Large or malformed multipart POST requests containing
PHP_SESSION_UPLOAD_PROGRESS, unusually high field counts, or chunked requests with no content length, sent to any .php path. - Odd files in the PHP session folder, such as session files containing PHP code or serialized objects, or
PHPSESSID cookies with strange, high-entropy values. - Web servers making outbound connections to unfamiliar addresses, a common sign of a reverse shell.
Search your logs from before 20 October 2026, when the details leaked, not just from the patch date. A successful attack can return a normal HTTP 200 response, so a clean access log isn't proof of safety. If you run EDR or a SIEM on your web servers, such as Microsoft Defender for Endpoint or Microsoft Sentinel, hunt for web server processes starting shells.
What should you do if you think you've been compromised?
- Isolate the server from the network, but don't wipe or restart it yet. Capture volatile evidence first: memory from the PHP and web server processes, the running process tree, network connections and open files. Restarting PHP workers erases the in-memory traces this attack leaves behind. Then preserve logs and disk images, and patch.
- Rotate every credential the PHP process could read: database passwords, SMTP and email accounts, API keys, payment gateway keys and admin accounts. Because of the memory-leak risk, consider rotating these even without signs of compromise on any internet-facing server that was still unpatched after 20 October.
- Activate your incident response plan, or call our emergency cyber breach response team, and report the incident to the Australian Cyber Security Centre at cyber.gov.au or on 1300 CYBER1.
- Assess whether personal or payment card information was accessed. This may trigger obligations under the Notifiable Data Breaches scheme or PCI DSS.
Frequently asked questions
Does PHP2Shell affect WordPress and Joomla websites?
Yes. Any WordPress, Joomla, Drupal or other PHP-based site running on a vulnerable PHP version is exposed, whatever plugins or security tools it uses. The fix is to update PHP on the server, not the CMS.
Our website is hosted by a provider or agency. Do we need to do anything?
Yes. Ask your provider to confirm they've upgraded PHP to a fixed version and restarted services. Keep the confirmation on record. Fully managed platforms usually patch quickly, but shared hosting, VPS and agency-managed servers often depend on someone taking action.
We don't use PHP. Are we safe?
Check before you assume. PHP often turns up in places teams don't expect, such as marketing microsites, plugins in a vendor's product, monitoring tools and device management portals. An external attack surface review or infrastructure penetration test is the quickest way to find out.
How do we find websites we've forgotten about?
Start with DNS. Free tools such as DNSDumpster and Shodan list the subdomains, hostnames and IP addresses linked to your domain names, and certificate transparency logs (crt.sh) show every certificate issued for them. Anything you don't recognise, such as an old campaign site, a staging copy or a retired portal, needs an owner, then a patch or decommissioning. Clean up stale DNS records while you're there.
Is changing PHP settings enough?
No. The configuration changes only block known attack paths and reduce risk. Updating PHP is the only complete fix.
How Spartans Security can help
Spartans Security helps organisations across every industry respond to critical vulnerabilities like PHP2Shell, and build defences that hold up against the next one.
Contact our team for urgent assistance.
Sources
Last updated 22 October 2026: added guidance on finding forgotten sites through DNS, prioritising internet-facing systems, capturing evidence before patching, and the memory-disclosure risk. This is a developing situation, and we will update this article as new information becomes available.
.png)
