On 21 October 2026, the PHP project released emergency security updates for two critical vulnerabilities, nicknamed “PHP2Shell”. Both could let an attacker run their own code on a web server without logging in. OpenAI says one of the flaws was found with the help of one of its models before attackers found it, and the security firm Wiz found and reported both independently. Several governments briefly took some public services offline while they patched.
We don’t use PHP in our own applications. The lesson still applies to every piece of software, because every application stands on layers it didn’t write, and a flaw in any one of them is a flaw in the application.
Technical details of the PHP incident
- Two flaws: CVE-2026-109618 (remote code execution through corruption when memory runs out) and CVE-2026-109619 (remote code execution through state that leaks between requests). Both are rated 9.2 (CVSS v4).
- All PHP installations that serve web requests are affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
- Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive official updates. PHP 8.2 reaches end of life on 31 December 2026.
- The PHP project lists configuration changes that reduce exposure, but states that updating is the only complete fix.
Sources: PHP security advisory, 21 October 2026, The Next Web, The National.
1. Know what you are running
The first question after any security warning is “are we affected, and where?” If you can answer that in minutes, you are in a far better position than someone who has to go looking. Keep a current list of the runtimes, libraries and services your systems depend on.
Technical: how to keep that list
- Generate a software bill of materials (SBOM) as part of every build, instead of maintaining a spreadsheet by hand.
- Record runtime versions per environment (development, staging, production).
- Subscribe to the security announcements for each technology you depend on, so you hear about issues from the source on the day.
2. Make updating routine, not a decision
Many teams only update when something breaks or an incident forces them to, which is when updating costs the most. Updates should be a standing process: small, tested and frequent. A team that is afraid to update usually has a weak safety net (tests, staging, rollback), and that safety net is the thing to fix.
Technical: what a safe update process looks like
- Automated dependency updates (for example Dependabot or Renovate) that propose changes as pull requests.
- Vulnerability scanning in the build pipeline, failing the build on critical findings.
- Two tracks: security patches applied within days, and major upgrades scheduled against vendor end-of-support dates.
- A solid automated test suite, a staging environment, and a one-step rollback.
- A short waiting period before adopting brand-new package releases, which reduces exposure to compromised packages.
3. Don’t run on unsupported software
Software that no longer receives security fixes becomes a liability that grows every month. Plan upgrades before support ends, not after.
Technical: when a component really can't be updated yet
- “The flaw doesn’t affect the features we use” is a claim, not a defence. Document it for each vulnerability, have someone independent review it, and check it again whenever the code changes.
- Record the reason, the compensating controls and a date to revisit.
- Re-analysing every new advisory against a frozen component often costs more over time than upgrading once.
4. Limit what an attacker can reach
Assume that something will get through eventually, and design so the damage stays small. Give each part of the system only the access it needs, keep internal systems off the public internet, and keep each customer’s data separate from everyone else’s.
Technical: reducing the blast radius
- Run services and database accounts with least privilege: no superuser, and no schema changes from the application’s account.
- Enforce tenant isolation in the database itself (for example with row-level security), not only in application code.
- Segment the network, and keep databases off the public internet.
- Encrypt especially sensitive fields with separate keys.
- Split large systems into independent “cells” (each with its own database, credentials and network) that hold a limited number of customers.
- Set sensible limits on request size and rate at the web server or proxy.
5. Be able to see what is happening, and recover
Logging and monitoring turn “we think we’re fine” into “we can show it”. A backup you have never restored is only a hope, so test it.
Technical: detection and recovery
- Alert on unusual requests, crashing workers, unexpected processes and bulk data reads.
- Keep a list of the secrets (keys, tokens, passwords) that must be rotated after a breach, and practise rotating them.
- Test restoring backups on a schedule.
The takeaway
No technology is immune to critical flaws, so what matters is how quickly and safely you can respond. Security is ongoing work: know what you run, keep it current, limit the damage when something fails, and be ready to act on the day a warning lands.
Last updated: