On October 21, the PHP project shipped emergency patches for two critical vulnerabilities — CVE-2026-109618 and CVE-2026-109619, together nicknamed PHP2Shell — after details leaked a day ahead of the planned coordinated disclosure. Both are rated CVSS 9.2 and allow unauthenticated remote code execution against the PHP runtime itself. Exploitation began before the patches were even published: Cloudflare observed attack attempts at 07:43 UTC on release day, hours ahead of the 14:00 UTC fix, and scanning has since reached scale. As a team that runs Laravel services in production, we spent release day patching. This guide is the checklist we worked through, so your team can run it too.
PHP2Shell is the name given to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, disclosed on October 20–21, 2026. They are memory-safety bugs (including a use-after-free) in PHP's session upload progress feature that allow an attacker to execute arbitrary code on a vulnerable server with no authentication required — effectively turning a crafted upload request into a remote shell, which is where the name comes from. Both carry a CVSS 4.0 score of 9.2, the vulnerable feature is enabled in default PHP configurations, and exploitation was observed in the wild within hours of disclosure. The fix is upgrading PHP to 8.5.12, 8.4.27, 8.3.36, or 8.2.35.
Almost everyone running PHP. The flaws are memory-safety bugs in PHP's session upload progress mechanism and affect PHP 5.4.0 through 8.5.11 — fourteen years of releases, with the vulnerable feature enabled by default. That footprint covers roughly 78% of websites: WordPress, Magento, Drupal, Joomla, and framework applications including Laravel. Researchers confirmed unauthenticated RCE against Magento 2.4.9 and ten other PHP applications; Laravel applications are exploitable when a usable gadget chain is present, which in practice means you should assume exposure rather than argue about it.
If your business runs a WordPress marketing site, a Magento store, or any Laravel service, this applies to you today — not at your next maintenance window.
Patching PHP is the only complete fix. The emergency releases are:
| Your PHP branch | Patched version | Status |
|---|---|---|
| 8.5.x | 8.5.12 | Patch now |
| 8.4.x | 8.4.27 | Patch now |
| 8.3.x | 8.3.36 | Patch now |
| 8.2.x | 8.2.35 | Patch now |
| 8.1 and older (incl. 5.x, 7.x) | No patch — end of life | Mitigate immediately, then plan an upgrade |
Managed platforms (major cloud hosts, cPanel-type providers) are rolling patched builds — verify your actual running version with php -v rather than trusting a dashboard. If you build containers, rebuild and redeploy from patched base images; a patched host means nothing if the container ships its own PHP.
Apply interim mitigations, and understand their limits. The primary attack path abuses the session upload progress feature, so the first moves are in php.ini:
session.upload_progress.enabled = Off
session.use_only_cookies = On
Huntress notes this blocks the main entry path but does not cover every variant — disabling upload progress addresses one route into CVE-2026-109619 while other paths for CVE-2026-109618 remain. Layer additional controls: block the PHP_SESSION_UPLOAD_PROGRESS field in multipart POST bodies at your WAF or web server (it has near-zero legitimate use), and restrict multipart uploads to the specific routes that genuinely need them. watchTowr's FAQ is a solid reference for testing whether your configuration remains exposed. Treat mitigations as a bridge measured in days, not a destination.
Mitigate now, then treat this as the forcing event for the upgrade you deferred. PHP 8.1 and earlier receive no patch for a 9.2-severity, actively exploited RCE — that is the concrete cost of running end-of-life runtimes, and it will not be the last such event. The path out is a planned migration, and for older codebases that usually means more than a version bump: dependency upgrades, deprecation fixes, and regression testing. Our guide to legacy system modernization covers how to sequence that work without a risky big-bang rewrite. Budget reality: an emergency weekend migration costs multiples of a planned one.
Assume scanners reached you before you patched, and look for evidence. Review web server logs for multipart POST requests containing PHP_SESSION_UPLOAD_PROGRESS from unfamiliar sources, especially between October 20 and your patch time. Check for newly created PHP files in upload and session directories, unexpected scheduled tasks, and outbound connections you cannot explain. Webshells dropped through this class of bug are typically small files with innocuous names in writable directories. If you find indicators, isolate the host and treat it as an incident — patching after a compromise does not evict an attacker who already established persistence.
The uncomfortable lesson is speed: this went from leak to in-the-wild exploitation in under 24 hours, faster than most organizations' monthly patch cycles. Three practices separate teams that handled it calmly from teams that scrambled. First, an inventory — you cannot patch what you do not know you run; the teams that struggled most on release day were the ones discovering PHP versions during the incident. Second, a patch path that takes hours, not meetings: containerized builds, staging smoke tests, and the kind of deploy pipeline that makes shipping a runtime update boring. Third, layered controls — a WAF rule bought many teams the hours they needed. Our cybersecurity checklist for growing companies covers the baseline; events like this are why the unglamorous items on it matter.
If you run PHP or Laravel applications and want help verifying your exposure, applying the patches safely, or getting off an end-of-life runtime before the next PHP2Shell arrives, our security team and engineering team do exactly this work — get in touch and we will review your setup.
The real AI security risks for businesses — data leakage, prompt injection, over-permissioned tools, and shadow AI — ranked honestly, with a policy outline.
A tiered, 20-item cybersecurity checklist for growing businesses — the cheap wins, what SOC 2 and GDPR actually require, and when to bring in an audit.