A company website, online store, or customer portal often represents years of development, integrations, and customer data. Many of these run on PHP-based platforms such as WordPress, Magento, and Laravel, and the PHP version underneath deserves the same attention as the platform itself. For businesses responding to the PHP2Shell vulnerability, the task goes beyond installing an update. It comes down to knowing which systems run PHP, which versions they use, and who keeps them current.
PHP has a clear answer for supported versions. Its October security release fixes both flaws in PHP 8.2 through 8.5, and many hosting providers have already applied it. Older versions need a different plan, because PHP no longer releases updates for them. Qualys estimates that about 110 million installations fall into that group, so for many organizations the right response pairs a short-term patch with a planned upgrade.
This blog explains the PHP2Shell update, the affected versions, how to check and fix your PHP installations, and how to plan an upgrade if you run an older release.
What is the PHP2Shell vulnerability?
PHP2Shell is the name for two security flaws inside PHP itself, the programming language that runs a large share of business websites. The flaws are not in WordPress, Magento, or your custom code. They sit in the engine underneath, so application updates cannot fix them.
The name reflects the outcome: an attacker can get a “shell,” meaning command-level access to your server, without a password. Researchers found the first flaw with AI-assisted code analysis in August 2026, according to FortiGuard Labs. Details leaked online on 20 October, and PHP released fixes on 21 October.
On 26 October, the US Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its Known Exploited Vulnerabilities catalog, confirming real attacks. The NSA advised organizations to patch or take affected systems offline, as CNBC reported.
PHP2Shell CVEs explained: CVE-2026-109618 and CVE-2026-109619
Both flaws carry a severity score of 9.2 out of 10. The attack does not succeed on every server because it depends on how each server is set up, which is why the score is not a full 10. Attackers simply retry, so lower odds per attempt do not make a site safe. Here is what each flaw means without the jargon.
- CVE-2026-109618 (running out of memory mid-request): An attacker sends oversized uploads that push PHP past its memory limit. PHP stops abruptly with some request data half prepared, and the cleanup step treats that broken data as valid. Think of a cashier interrupted mid-sale who closes the register using half-written entries.
- CVE-2026-109619 (leftover data from a previous visitor): PHP keeps some information from one request after it should have been cleared, and the next request on the same server process can reuse it. Compare it to a hotel room not cleaned between guests, where the next guest finds the previous guest’s key card.
On 23 October, PHP also flagged a related, narrower issue (CVE-2026-115560) with a temporary setting change, according to the Dutch National Cyber Security Centre’s tracker.
What attackers can do with PHP2Shell?
Once an attacker can run commands on your web server, the impact goes well beyond a defaced homepage:
- Take over the server: Attackers can run commands on the server without logging in.
- Steal secrets from memory: Researchers showed that the flaws can expose passwords, login tokens, and API keys held in server memory, according to Qualys.
- Reach customer and order data: Server access often leads straight to customer records and order history, and lets attackers add card-skimming code to checkout pages.
- Plant hidden backdoors: CISA warned that attackers are pairing PHP2Shell with a Linux flaw to install hidden web shells and run commands as the root user, as BleepingComputer reported. A backdoor can stay in place even after you patch.
- Move deeper into your network: A compromised server becomes a launch point toward ERP, CRM, and other connected systems.
Amazon Threat Intelligence spotted an exploitation attempt on 17 October, four days before the fix was public, so any review of server activity should go back to that date.
PHP2Shell affected versions and fixed releases
PHP2Shell affects PHP 5.4 through 8.5, but PHP releases fixes only for the four branches it still supports. End-of-life branches get no official release.
| PHP Branch | Support Status | Fixed Release | What to Do |
| 8.5 | Active support | 8.5.12 | Update now |
| 8.4 | Active support | 8.4.27 | Update now |
| 8.3 | Security fixes until 31 Dec 2027 | 8.3.36 | Update now |
| 8.2 | Security fixes end 31 Dec 2026 | 8.2.35 | Update now, then plan an upgrade |
| 8.1, 8.0, 7.4 | End of life | No official release | Use a vendor or distribution patch, then upgrade |
| 7.3 and older | End of life | No fix | Upgrade or take offline |
Sources: TuxCare and the University of Toronto security advisory.
Three details catch teams out. Linux distributions such as Ubuntu and Red Hat often apply the fix to an older-looking version number, so check the package against your vendor’s advisory.
PHP 8.2 loses security support at the end of 2026, so patching it takes only weeks before the next upgrade decision. And sites still on Magento 1 or PHP 5 will never get a fix, so they need a replatform or isolation plan.
Which applications and platforms are affected?
Any application that runs on PHP and serves web pages is in scope, including WordPress, WooCommerce, Drupal, Joomla, Magento and Adobe Commerce, Shopware, Laravel and Yii applications, and custom portals. California confirmed attacks without a login on Magento 2.4.9, WordPress, and Drupal, as Scandiweb noted.
PHP rates the risk highest for servers running PHP through Apache’s built-in module (mod_php), where an attack can trigger before application code runs. Other setups, such as PHP-FPM and LiteSpeed, also need the update, according to the NCSC tracker.
PHP2Shell WordPress guidance for WordPress and CMS admins
WordPress.org has said no WordPress update is required or planned for PHP2Shell, as this agency summary explains, so updating themes or plugins will not close this risk. The fix depends on who runs your server:
| Hosting Type | Who Updates PHP | Your Action |
| Managed hosting (WP Engine, Kinsta, Adobe Commerce Cloud) | Your provider | Get the provider's patch status in writing |
| Shared hosting with cPanel or Plesk | Your host, but you may choose the PHP version | Confirm your selected version is patched, and move off end-of-life versions |
| Cloud servers or VPS (AWS, Azure, DigitalOcean) | Your team or agency | Patch, restart, and verify yourselves |
A store on a SaaS platform such as Shopify Plus does not run its own PHP, but a connected PHP-based blog or integration service still needs a check.
Shell, the global energy company, recently applied the PHP2Shell update, bringing its PHP environment onto a patched release.
How to check if your PHP installation is vulnerable
Knowing how to check the PHP version on each site comes first, and no coding is needed:
- List every PHP system: Include live and staging sites, internal tools, container images, and appliances that bundle PHP.
- Find the PHP version serving each site: Your hosting control panel is the easiest place to start. WordPress admins can also open Tools, then Site Health, then the Server tab. Ask your PHP developers to confirm the version that serves web pages, because the command-line version can differ.
- Compare against the fixed releases: Use the table above, or your Linux vendor’s advisory for distribution packages.
- Confirm a restart: Running processes keep the old, vulnerable code in memory until they restart.
- Check activity since 17 October: Ask for a log review from the first known attack onward.
When the PHP2Shell update was released, our team started with our own website, which ran on PHP 8.1, a version that no longer receives official fixes. We upgraded it to PHP 8.3.36, which includes the PHP2Shell fix and keeps the site on a supported release until the end of 2027.
How to fix PHP2Shell: Step-by-step patch guide
The PHP core team has been clear that updating is the only complete fix, as TuxCare reports. Here is how to fix PHP2Shell in a sensible order:
- Start with internet-facing systems: Patch public websites and portals first, beginning with Apache mod_php servers.
- Apply the PHP2Shell patch: Install PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or your distribution’s patched package.
- Restart every PHP service: This includes web servers and background queue workers. A patch on disk does nothing until PHP processes reload it.
- Handle end-of-life versions separately: Apply a vendor or distribution backport as a stopgap, then schedule a PHP upgrade to a supported branch. Some platforms need an application upgrade first; for example, Magento 2.4.4 and 2.4.5 are limited to PHP 8.1.
- Test before full rollout: Where time allows, validate the PHP2Shell fix on staging first.
- Assign owners and deadlines: Give every unpatched system a named owner and a target date.
Temporary mitigations if you cannot patch yet
When a patch cannot go live today, PHP and security vendors recommend interim steps that reduce exposure. None of them makes an unpatched server safe.
- Turn off upload progress tracking: PHP recommends disabling this feature, which many sites do not use. Doing so blocks the confirmed attack paths for CVE-2026-109619 and the newer CVE-2026-115560.
- Lower upload and request size limits: Smaller limits make the out-of-memory attack harder. Warn customer-facing teams, since some customers may notice upload limits.
- Turn on web application firewall rules: Cloudflare added temporary firewall rules, though Qualys notes attackers have already tried to get around them.
- Restrict access or take the system offline: For systems that cannot be patched, the NSA advises limiting public access until a fix is ready.
Post-patch verification and security hardening
Patching closes the door, but it does not tell you whether someone walked through first. After the update, confirm three things:
- The patch is live everywhere: Check that every server, container image, and staging copy runs the fixed build.
- There are no signs of intrusion: Review servers for unfamiliar files in upload folders, unexpected processes started by PHP, and unusual outbound connections.
- Secrets are safe: Because the flaws can expose server memory, rotate passwords, API keys, and tokens used by affected applications.
Then turn the response into lasting PHP security best practices:
- Keep a current inventory of every PHP system and its version.
- Track PHP end-of-life dates and budget upgrades a year ahead.
- Set a patch deadline of days, not weeks, for flaws on CISA’s exploited list.
- Run the PHP worker account with the lowest permissions it needs.
- Keep monitoring, alerts, and tested backups in place.
Why Ranosys for PHP2Shell remediation and PHP upgrades
PHP2Shell shows how quickly a server-level flaw becomes a board-level question. Ranosys has spent more than 15 years building and supporting PHP platforms, including Magento and Adobe Commerce, WordPress, Drupal, Laravel, and Yii, so our PHP team knows where to look. Every project starts with your written go-ahead:
- Exposure check: We confirm the PHP version and patch status on every server and share a one-page report that marks each site as safe, at risk, or without an official fix.
- Patch and verify: We apply the fixed PHP release, restart every service, add interim protections where needed, and review logs for signs of an earlier break-in.
- End-of-life PHP upgrade: We move PHP 7.x, 8.0, and 8.1 sites, including Magento 1 stores, to a supported release, with the code, plugin, and extension updates and regression testing that it requires.
- Managed security care: Our managed services team handles monthly patching, version monitoring, and incident support.
The PHP2Shell vulnerability will not be the last flaw of its kind. Organizations that know where PHP runs, patch fast, and keep versions current can handle the next one as routine maintenance rather than an emergency.
