PHP2Shell: Patch, Rotate, Harden. A 10-Point Checklist for the Rest of Us.

Yesterday, researchers from Wiz, OpenAI, and Calif disclosed PHP2Shell: two critical vulnerabilities in the core of the PHP language, tracked as CVE-2026-109618 and CVE-2026-109619 and rated CVSS 9.2. PHP runs roughly 70% of websites. WordPress, Drupal, Joomla, Moodle, Laravel, Symfony, Nextcloud, and MediaWiki (the software behind Wikipedia) all sit on top of it.

In April we wrote that five supply chain attacks in three weeks was not a coincidence. We called it the early-warning period and said the defenses needed to be in place before the next round. This is the next round.

This post is for anyone who runs a business on the web and wants to know what to do. The first section is the urgent part. The rest is a hardening checklist we recommend to any organization running custom or bespoke software.

PHP2Shell

What It Is

The flaw is in PHP itself, not in any particular application. The researchers describe two related classes of bug: memory corruption triggered by how PHP handles running out of memory, and state that leaks from one request into the next. An unauthenticated attacker on the public internet can trigger either. The researchers demonstrated full remote code execution against up-to-date WordPress, Drupal, and Joomla installs, and they note that a trivial "Hello World" page on an affected PHP version is just as exposed.

The second bug matters even if an attacker never gets code execution. It lets them read the PHP worker's memory, which can contain passwords, authentication tokens, API keys, and certificates belonging to other users' requests or to the server itself. That kind of theft leaves far fewer traces than a defaced page.

What to Do

Upgrade PHP. This is the only complete fix. The fixed releases are:

Nearly every PHP release back to 5.4 is affected by at least one of the two bugs. If you are on an end-of-life branch (8.1 or older), there is no fix for you; upgrading to a supported branch is the only path.

Three things people get wrong:

1. Updating the application is not the fix. Updating WordPress, Drupal, or your plugins does nothing here. The fix is to the PHP runtime underneath, which is usually managed by your hosting company or IT team.
2. The update is not done until the workers restart. Apache, PHP-FPM, and any long-running PHP processes must be restarted after the new version is installed.
3. "We are on managed hosting" is not a reason to relax. The large managed hosts are rolling the patch out. Ask yours for written confirmation of the PHP version your site is now running.

Assume exposure, rotate secrets. If a site was reachable from the internet on a vulnerable version, treat the secrets on that server as potentially read. After patching, rotate database credentials, API keys, SMTP and email credentials, OAuth client secrets, and any certificates stored on the box. Ask your host to review access logs for the period before the patch. Several security vendors have published detection guidance and WAF rules; a WAF rule reduces exposure but does not replace the upgrade.

Find the sites you forgot. The site that gets compromised is rarely the main one. Create a complete inventory of domains, subdomains, and DNS records, and assign an owner to each. Anything without an owner should be patched or taken offline.

The official guidance, including temporary mitigations for teams that genuinely cannot upgrade today, is at php2shell.com.

What Changed Since April

In the spring, we catalogued five incidents in three weeks: LiteLLM poisoned on PyPI through a compromised security scanner, axios hijacked on npm by North Korean state actors, thirty-plus WordPress plugins bought on Flippa and backdoored for eight months before activation, malicious pull requests against better-auth, and a breach at Vercel that started with a third-party AI tool. The common thread was the trust chain between open-source packages and production systems, and the observation that the attackers were patient, well-resourced, and willing to wait months for a single payoff.

PHP2Shell is a different kind of event. It is not a supply chain compromise; nobody slipped malicious code into PHP. It is a vulnerability that sat in the runtime for over a decade across every version, found now because the tools for finding such things have gotten dramatically better. In April we wrote about AI coding agents amplifying supply chain risk by converging every project onto the same dependencies. The flip side arrived six months later: AI-assisted vulnerability research, run by OpenAI's Codex Security team alongside Wiz and Calif, found two memory-safety bugs in the most widely deployed language on the web.

Both things are true at once. AI has made vulnerability discovery faster for everyone, and AI agents have lowered the skill needed to turn a disclosed bug into a working attack. The window between "patch available" and "mass exploitation" is shrinking. The defenders found PHP2Shell first this time. The structural lesson is that the baseline for a small or mid-size company has moved, and it will keep moving.

The WordPress plugin incident from April deserves a second mention here, because it is the same audience. The attacker did not exploit a bug. They bought a plugin business, embedded a backdoor, and waited. If your marketing site runs WordPress, the plugins you install are code you are running on your users' behalf, and the registry's trust model does not survive a change of ownership. PHP2Shell is the runtime; the plugin attack was the layer above it. Both need attention.

Ten Things to Do: A Security Hardening Checklist

This is the hardening checklist we recommend to any organization running custom software. None of it is exotic. Most of it maps directly onto the CIS Controls Implementation Group 1, which is the framework we point small organizations toward (item 9). Where we have written the technical detail up before, we link to it rather than repeat it.

1. Inventory What You Own

You cannot patch what you do not know about. List every domain, subdomain, hosted application, SaaS tool with your data in it, and server. Assign an owner to each. Review the list quarterly. This is the precondition for every other item.

Include your AI agents in that inventory. We wrote about agent sprawl as the new shadow IT in May, with a five-step inventory you can run in a week. The Vercel breach started with one employee's third-party AI tool. Every agent with an OAuth grant into your Google Workspace or GitHub is part of your attack surface.

2. Keep the Whole Stack Current, Not Just the Framework

Upgrade the main components of your stack to supported versions: the language runtime, the web framework, the database, the reverse proxy, the operating system packages, and the base images of any containers. The layer people skip is the one "under" the application, which is exactly where PHP2Shell lives. Run a CVE scan against installed dependencies on a schedule and treat the output as a to-do list, not a report.

3. Audit and Prune Dependencies

Walk the dependency tree. Remove anything unused. Replace anything abandoned, archived, or with a single inactive maintainer. Check ownership history on the packages and plugins you depend on most; the EssentialPlugin attack came from a buyer, not a hacker. For Python teams, our dependency management comparison covers the tooling that makes this tractable.

4. Defend Against the Next Supply-Chain Attack, Not the Last One

Pruning handles what is already there. The spring attacks were about what you pull in next. The April post lays out the full defense stack with commands and configuration; the short version:

• Commit lockfiles and use frozen installs in CI.
• Set a minimum release age of a few days so you never install a version in the window when a poisoned release is most likely to be live.
• Disable package lifecycle install scripts in CI.
• Pin CI/CD actions by commit hash, not by tag.
• Verify provenance on critical packages, and enable it on anything you publish.
• Run behavioral analysis on packages at install time.
• Generate a software bill of materials (SBOM) for each deployable, so the next "are we affected?" takes minutes instead of days.

5. Lock Down Authentication

Review how your application stores and checks passwords (a modern slow hash, nothing older), how it issues and verifies MFA codes, and whether login and MFA endpoints are rate-limited. Then look at how your own staff get into admin areas. If your company already uses a directory (Microsoft Entra, Google Workspace, Okta), move admin login to it over OIDC or SAML and retire the separate admin password list. Require hardware-backed MFA (passkeys or security keys) for anyone with admin rights, review who has access every quarter, and make offboarding an immediate step, not a monthly one.

Public signup forms are part of this surface too. Bots registering with real email addresses are a sender-reputation problem long before they are a security problem, and the same throttling and verification that protects deliverability protects your login endpoints.

6. Manage Secrets As If They Will Leak

Because sometimes they do, as PHP2Shell's memory-disclosure bug shows. Keep secrets out of source code and out of plain files on disk; use a secrets manager or your platform's equivalent. Scope every API key and service account to the minimum it needs. Rotate on a schedule, and have a written procedure for rotating everything in an afternoon when you need to.

7. Secure the Pipeline and the Cloud Account

Most modern breaches land in CI/CD or the cloud console, not the application. The TeamPCP campaign in March got into LiteLLM through a misconfigured GitHub Actions workflow and cascaded across five ecosystems in nine days. Enforce branch protection and code review. Remove long-lived cloud access keys from CI in favor of short-lived federated credentials. Review IAM for stale users and over-broad roles. Turn on the cloud provider's own threat detection.

8. Log, Monitor, and Put Something in Front of the App

"Can we tell if we were exploited?" is only answerable if logs exist, are retained for months, and are stored somewhere an attacker on the box cannot erase them. Centralize logs, alert on anomalies (failed login spikes, new admin users, outbound connections you do not expect), and put a WAF or CDN in front of anything public. Cloudflare and others shipped PHP2Shell rules within hours of disclosure; that buys time, which is what a WAF is for.

9. Adopt a Framework, and Know Your Regulatory Obligations

If you are in a regulated industry, your obligations are already written down: HIPAA for health data, PCI DSS if you touch card numbers, the GLBA Safeguards Rule for financial services, FERPA for education, SOX for public companies, GDPR for EU residents' data. Meet them. For fintech specifically, we have a guide to the US regulatory landscape.

If you are not regulated, pick a voluntary framework anyway, because it turns "be more secure" into a finite list with checkboxes. Our recommendation for small and mid-size companies is the CIS Controls v8, Implementation Group 1: about 56 safeguards, free, written for organizations without a security team, and it covers everything on this page. NIST CSF 2.0 is the better choice if you need a governance-level framework for leadership. SOC 2 is worth pursuing only when customers start asking for the report; it is an audit, not a security program. ISO 27001 is for companies selling to enterprises or internationally that require it. Cyber insurers increasingly require most of this list regardless of which framework you name.

10. Backups, Recovery, and a Plan for the Bad Day

Backups should be automated, stored offsite or in an immutable tier, and restored successfully within the last quarter as a test. Define how much data you can afford to lose (RPO) and how long you can be down (RTO), and confirm your backup design actually meets those numbers. Then write a one-page incident response plan: who gets called, who talks to customers, who talks to the lawyer, what the notification obligations are in your jurisdiction, and where the secrets-rotation procedure from item 6 lives. Review it once a year.

The web is going to get rougher for a while. Most of what protects a small company is not clever; it is a short list of boring things done consistently. This is that list. If you want help running it against your own systems, we do structured software reviews scoped to exactly this kind of assessment. Get in touch.