Skip to content
The Code Under 7 in 10 Websites Had a Takeover Flaw, page 1 of 7
The Code Under 7 in 10 Websites Had a Takeover Flaw, page 2 of 7
The Code Under 7 in 10 Websites Had a Takeover Flaw, page 3 of 7
The Code Under 7 in 10 Websites Had a Takeover Flaw, page 4 of 7
The Code Under 7 in 10 Websites Had a Takeover Flaw, page 5 of 7
The Code Under 7 in 10 Websites Had a Takeover Flaw, page 6 of 7
The Code Under 7 in 10 Websites Had a Takeover Flaw, page 7 of 7
1 / 7

The Code Under 7 in 10 Websites Had a Takeover Flaw

By Michael Mancuso · October 22, 2026 · Originally published on LinkedIn

The code under 7 in 10 websites had a flaw that let strangers take over servers.
AI proved it in 2 days.

The code is PHP. It runs 69% of websites whose server language can be detected, including WordPress. The flaw was spotted in 2024. No one had shown a working attack, so it waited.

That's a sensible habit. Teams rank work by proof. "Theoretical" sinks to the bottom.

This summer, researchers at Calif and Wiz used AI to build working attacks.

The first attack attempt hit an Amazon decoy server on Oct 17. PHP shipped the fix on Oct 21.

The flaw didn't change. The price of proof did.

Every backlog has a pile marked "can't prove it." AI just repriced it.

Update PHP itself, not just the app on top. Then reopen whatever you parked as unproven.

In an AI-native org, "unproven" is a timestamp, not a verdict.

#AI #Cybersecurity

Read slide text

Slide 1

PHP2SHELL · October 2026.

The code under 7 in 10 websites had a server-takeover flaw. AI proved it in 2 days.

69 of 100 run PHP, including WordPress, Drupal, Wikipedia’s MediaWiki. 36: PHP 8.2 to 8.5, fix released October 21. 33: PHP 8.1 or older, no official fixed release. 31: no PHP detected.

Each square = 1 of 100 websites whose server language W3Techs can detect (October 22). Running PHP means exposed until patched, not hacked.

9.2/10 severity rating (CVSS). No login needed to take over. Go offline if you can’t patch: CISA, NSA, EU. Attempts to attack began before the fix.

Slide 2

The whole story.

Two years parked, two months to patch: the four stages of one flaw.

From the 2024 audit to the October 21, 2026 fix (about 10 weeks after the first AI-assisted report). Each later slide zooms in on one stage.

Known, 2024: A PHP developer spots a memory-handling flaw during a security audit.

Parked, 2024–26: No one has shown a working attack. The fix stalls for months.

Proven, August 2026: Calif, OpenAI and Wiz use AI to find attack paths. Calif and Wiz show working takeovers.

Patched, October 21, 2026: PHP ships fixes. Attack attempts had started 4 days earlier.

PHP: the programming language that runs much of the web, including WordPress. Remote code execution: an outsider can run their own commands on your server.

Slide 3

Known, then parked.

The flaw was found in 2024 and sat unfixed. Without a proven attack, it never jumped the queue.

Milestones in the life of the flaw, 2020 to August 2026, from the PHP Foundation’s and Calif’s own timelines.

2020: A related bug is reported: very long form fields make PHP run out of memory. Treated as minor.

2024: PHP’s first outside security audit in years. A developer spots the out-of-memory flaw. An attack is theorized; none is shown.

2024–26: Every proposed fix has trade-offs. With no proven attack, the work stalls and restarts for months.

July 30, 2026: Security firm Calif starts an AI-assisted audit of PHP.

August 1: Calif finds paths to remote code execution, about 2 days in.

August 11: Calif and OpenAI report the same root cause, independently, the same day. Fixing it becomes PHP’s top priority.

Calif’s researcher credits his own knowledge of PHP’s bug history for knowing where to point the AI.

Slide 4

Who got a fix.

About half of PHP sites report a version that got no official fixed release.

Share of PHP-running websites by the PHP version they report, W3Techs, October 22, 2026. Teal = PHP released a fixed update on October 21.

PHP 8.5: 2.9%; 8.4: 7.9%; 8.3: 22.7%; 8.2: 18.1%; 8.1: 9.9%; 8.0: 3.8%; 7.x: 26.9%; 5.x: 7.7%.

51.6%: fix released October 21. 8.2 to 8.5: safe once updated and restarted.

48.4%: no official fixed release. 7.4 to 8.1: source patches only. 7.3 and older: none. Upgrade, or get a vendor backport.

Versions as sites report them; a vendor-patched server can still show an old number. The flaw dates to PHP 5.4; PHP 4 (0.1%) not shown.

Slide 5

The clock.

Attack attempts started 4 days before the fix. A 30-day patch deadline assumes attackers wait.

Days before and after PHP released the fix (October 21, 2026, 10:00 AM ET). Events as reported by Amazon, the PHP Foundation and Cloudflare.

October 17: First attack attempt seen on an Amazon decoy server (honeypot).

October 20: The flaw ID numbers leak online. PHP moves the fix up a day.

October 21: Fix released. Amazon reports broad attack attempts; Cloudflare counts millions by October 22.

“Measure patch and mitigation timelines in hours. A 7-day or 30-day SLA assumes a delay that no longer exists.” — Amazon Threat Intelligence.

SLA = a team’s promised deadline. A decoy server (honeypot) exists to attract attackers. watchTowr says the public exploit code it has seen fails to take over servers.

Slide 6

Where it lives.

The flaw sits below your app. Updating WordPress does not update PHP.

The layers of a typical PHP website, from the code a team writes down to the server, and which one holds the flaw:

Your app: WordPress, Drupal, a custom site. The layer teams watch and update. Updating it leaves the engine below unchanged.

PHP engine: Runs the app’s code on each request. The flaw lives here. Wiz: even a “Hello World” page on an affected version can be hit.

Server: Apache, Nginx, hosting. Highest risk: Apache with PHP built in (mod_php), per PHP.

“PHP is often a component of other software and prevalence may not be directly observable.” — CISA.

Slide 7

The takeaway.

“Unproven” used to mean “unlikely.” AI just cut the cost of proof.

Three cheap moves for any team, drawn from the PHP, Amazon and CISA guidance published October 21, 2026.

1. Patch the engine, not just the app. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every PHP worker. On 8.1 or older, upgrade or ask your vendor.

2. Count critical fixes in hours. For internet-facing systems, a 30-day deadline is now a 30-day window.

3. Reopen the “can’t prove it” pile. Anything parked because no one could show an attack deserves a second look.

The flaw didn’t change. The price of proof did.

Sources cited in the slides: W3Techs, October 22, 2026; PHP security advisory and PHP Foundation, October 21, 2026; CISA; NSA; ENISA; Amazon Threat Intelligence; Calif; Wiz Research; SecurityWeek, October 21–22, 2026.