PHP2Shell: How Sweent Patched Every Client System in Under 12 Hours

On October 21, 2026, the PHP project shipped emergency fixes for two critical flaws in PHP core, CVE-2026-109618 and CVE-2026-109619, which the security community quickly named PHP2Shell. Few disclosures in recent years have caused this much alarm. PHP runs WordPress, Drupal, Joomla, Magento, WooCommerce and a large share of the custom applications on the web, and the PHP team said the bugs affect every PHP installation that serves web requests.

Our team moved as soon as we learned of the issue. In under 12 hours, Sweent patched every system we are responsible for, both our own and our clients'. We then scanned each of those systems for signs of intrusion or attempted compromise.

What PHP2Shell is

Both vulnerabilities carry a CVSS v4.0 score of 9.2 out of 10. They let an attacker run code on a server without logging in, with the same permissions as the PHP process. In practice that can mean stolen data, a defaced website, or a hidden backdoor that survives long after the original attack.

• CVE-2026-109618 comes from how PHP handles running out of memory, which can leave request data only partly set up.
• CVE-2026-109619 comes from request state that lingers after its memory has been freed.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive routine security updates from the PHP project, so sites still on those versions need an upgrade, not just a patch.

Why the industry panicked

The disclosure did not go to plan. Details leaked before the scheduled release, so defenders and attackers were racing at the same time. Cloudflare reported early attack traffic within hours, and security firms reported active exploitation attempts.

Government agencies responded quickly:

• CISA urged every organization to inventory its PHP systems and patch immediately. Anything that could not be updated, including PHP 8.1 and older, should be taken offline.
• The UK's National Cyber Security Centre advised taking systems offline until they could be fully mitigated.
• CERT-EU told organizations to consider isolating internet-facing PHP applications from public networks.
• The NSA issued its own warning that also raised the option of taking sites offline.

Large organizations took drastic steps. Parts of Wikipedia went temporarily offline, as did Pinboard, 4chan and Something Awful while they waited for the patch. Domain registrar NameSilo reportedly took its entire customer portal offline, showing a maintenance notice that described the move as a precaution against the PHP flaws. According to the notice, access would return only after the patch was installed and security checks were complete. When companies of that size choose downtime over risk, the threat is real.

What Sweent did

When a vulnerability of this size lands, the first hours matter most. Here is how we handled it.

1. Inventory. We listed every server, container and application we manage that runs PHP, including software that embeds PHP and is easy to overlook.
2. Patch. We upgraded each one to a fixed PHP release, starting with internet-facing systems. Where a client was on an unsupported PHP version, we upgraded it to a supported one.
3. Verify. We checked every system after the update to confirm it was running the patched build. A patch counts only once it is confirmed in production, not when it is scheduled.
4. Scan for intrusions. Patching closes the door, but it does not tell you whether someone already got in. Because attacks began before and during the patch window, we scanned every system we manage for signs of intrusion or attempted penetration. That covered unexpected processes started by PHP workers, new or modified files in web directories, unfamiliar admin accounts, and suspicious requests in the logs.

All of it was done in under 12 hours from the moment we learned of the issue.

If you are a Sweent client

You are already protected from PHP2Shell. Every system Sweent manages has been patched and scanned for signs of intrusion or breach. You do not need to do anything. If you have questions about a specific site or server, contact your Sweent team and we will walk you through what was done on your systems.

If you are not a Sweent client

Do not wait. Here is what to do now:

1. Find every system running PHP, including plugins, appliances and vendor software that ship with it.
2. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or upgrade if you are on 8.1 or older.
3. Confirm the update is live. Ask your host or IT provider for confirmation that it is installed, not just scheduled.
4. If you cannot patch right away, take the system offline. A web application firewall can reduce exposure, but it is a stopgap, not a fix.
5. Look for signs of compromise. Check for shells or downloads launched by PHP processes, new files in web directories, and new admin accounts.

If you need help with any of this, talk to Sweent. We can patch, verify and scan your systems the same way we did for our clients.

Sources: CISA alert · Malwarebytes · NBC News · Qualys · The Next Web