Two critical flaws in PHP itself, together known as PHP2Shell, let an attacker run code on a web server without logging in. Patches arrived on 21 October 2026, but the first attack attempt was seen four days earlier. A patched server is not automatically a clean one.
Do these three things today:
Confirm every PHP install runs a fixed build. That means 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later, or a vendor package that lists the fix, with PHP workers restarted.
Check for signs of a break-in back to 17 October, not just since the day you patched.
Find the PHP you forgot about. Election microsites, old archives, plugins and agency-built sites all count.
Details leaked early, the fix was rushed out, and attackers were already probing.
PHP2Shell timeline · 17–23 October 2026
17 October: Amazon's honeypots log the first exploitation attempt, three days before the CVE IDs appear online. (IT-Connect)
20–21 October: the IDs leak, PHP warns admins to prepare, then ships fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. (ArmorCode)
22–23 October: Censys counts about 36.7 million internet-facing services on possibly affected versions, and PHP discloses a related partial bypass (CVE-2026-115560). (Fortinet)
In short: PHP could stop halfway through a task, then trust the half-finished result.
CVE-2026-109618: when a request runs out of memory mid-way, PHP's clean-up step treats half-written data as valid. That corrupts memory and can let an attacker run their own code.
CVE-2026-109619: leftover state from one request can survive into the next request handled by the same worker.
It sits in PHP itself, not in WordPress, Drupal or your own code. Every PHP install serving web traffic is exposed, and researchers trace the affected code back to PHP 5.4.
It can leak secrets too. A separate path can expose passwords, tokens and API keys from other requests without running any code.
The detail most people missed: a 2024 audit by OSTIF and Quarkslab flagged the out-of-memory weakness, but nobody could prove it was exploitable and the fix stalled. This year, Calif, Wiz and OpenAI used AI-assisted auditing to turn it into working remote code execution. (SentinelOne, ArmorCode)
If any server runs PHP for web traffic, assume yes until you've checked. Apache with mod_php is the riskiest setup, because the attack runs before your own code does.
On a managed host? Ask for written confirmation of the fixed build and the date it went live.
Don't trust php -v alone. Ubuntu, AlmaLinux and others backport the fix without changing the version number, so check the package changelog for the two CVE IDs. (ComputingForGeeks)
Not necessarily. Amazon's honeypots logged the first exploitation attempt on 17 October, while the bug was still secret. Amazon now says the flaws are being broadly exploited, though it's unclear how many attacks succeeded. Patching closes the door; it doesn't remove anyone already inside. (BleepingComputer)
Look back to 17 October, not to the day you patched:
Odd processes. PHP workers (php-fpm, httpd, apache2) starting shells, commands like whoami, or download tools.
New files. .php files in the web root, or files in /tmp, that nobody deployed.
Unusual traffic out. Web servers connecting to addresses they never normally talk to.
Crashing workers. PHP processes dying for no clear reason.
New accounts. CMS or server admins nobody remembers creating.
The secret-leaking path starts no process, so it won't show up on the server itself. Check web server, firewall and CDN logs too, and rotate any keys your PHP workers could read. (SentinelOne, Fortinet)
And confirm the fix is actually running. Installing the package isn't enough on its own. Apache with mod_php needs a full restart, and containers must be rebuilt from a fixed image. (ComputingForGee
Why is this worse for newsrooms?
A breached news site doesn't just lose data. It can lose readers' trust. The risks that matter most for publishers:
Fake stories under your masthead. CMS access means an attacker can publish new articles or quietly edit live ones.
Sources at risk. Unpublished drafts and investigation notes often sit in the CMS.
Downtime at the worst moment. The UK's NCSC told organisations to patch or take servers offline. On election night, offline isn't an option.
Your archive. Years of journalism, often on the oldest and least-patched systems.
Subscriber data. Reader accounts and payment details bring disclosure duties under India's DPDP Act and Europe's GDPR.
Your audience's devices. A compromised page or ad slot can serve malware to the readers you've spent years building.
Contain first, investigate second, and treat your published content as evidence.
Incident response · first hour, day and week
The step most security guides skip is the editorial one: compare recent publishes and edits against your CMS's revision history, so an altered story doesn't stay live while the servers get fixed.
Plan to respond in hours, not weeks. Six habits that would have made the week of 20 October calmer:
Keep a live inventory. List every site, microsite, container and vendor-hosted app, with its runtime version and a named owner. Many teams only found some of their PHP installs during the scramble.
Agree patch deadlines in advance. For example, critical fixes within 24 to 48 hours. Decide now who has the authority to take a site offline.
Treat firewall rules as a seatbelt, not a fix. WAF signatures and temporary settings buy time, but PHP said only the update fully protects you.
Limit the blast radius. Run web workers with minimal permissions, keep secrets out of their reach, restrict outbound traffic, and keep the editing CMS separate from the public site.
Keep logs long enough to look back. This incident needed logs from before anyone knew about it. Ninety days is a sensible minimum.
Know who answers at 2 a.m. Name an on-call owner, rehearse an incident drill, and write patch deadlines into vendor and agency contracts.
AI is shrinking the gap between finding a bug and exploiting it. PHP2Shell was found with AI-assisted auditing, and the same tools can turn a published fix into a working attack within hours. Expect more critical flaws, in every stack: PHP, Node, Java and the libraries they all depend on.
The newsrooms that cope best won't be the ones on the "safest" language. They'll be the ones that can answer three questions within hours: What do we run? Is it fixed? Would we know if someone got in?
Download the printable PHP2Shell checklist for newsrooms. It covers the "am I affected?" check, the warning signs, the first-week response plan and the prevention habits above. Free, no sign-up. PHP2Shell checklist for newsrooms
Quintype’s own platform doesn’t run on PHP, so it isn’t affected by PHP2Shell. Some clients use custom PHP front ends, and we’ve worked with them to move to fixed versions. Our existing firewall rules also block requests that try to exploit these flaws, as an extra layer of protection alongside patching.
If you'd like to compare notes on platform security for publishers, reach out to the Quintype team.
Amazon says PHP2Shell exploitation began 4 days before patches, BleepingComputer
PHP2Shell : exploitation avant les correctifs, selon Amazon, IT-Connect
Stopping PHP2Shell, SentinelOne
PHP2Shell RCE, ArmorCode
Understanding PHP2Shell vulnerabilities and reducing risk while you patch, Fortinet
PHP2Shell CVE-2026-109618: check and patch, ComputingForGeeks