Kelvin

Appearance

Language

· 9 min read

PHP2Shell (Part 2): Broken embargo, real attacks, and what to do now

The PHP2Shell embargo broke early, a honeypot caught working shells, and CISA added both CVEs to KEV. Part 2 covers the timeline, Taiwan's exposure count, and a checklist for versions, SAPI, patching and restarts.

Part 1 used a hotel keycard encoder to explain what PHP2Shell is, why the root cause sits under your app, and how AI sped up discovery. This part is the messy aftermath: news of the defect before the repair crew was ready, fake front desks watching thieves try the trick, how many Taiwanese "hotels" still run this machine model, and a checklist you can run today.

Reminder: the encoder analogy is a simplification. What actually keeps you safe is the version string, the SAPI, and whether the patch is live.

How the embargo broke

Coordinated disclosure was aimed at 22 October 2026 (UTC). What happened instead (Taipei = UTC+8 where a clock time is given; public "top of the hour" disagrees by ~30 minutes across documents):

  • ~23:00 Taipei on 20 Oct / ~15:00 UTC: per the PHP Foundation, the two CVE IDs began circulating on forums and social media with a wrong release time and a wrong CVSS 10.0 (actual: 9.2); no technical details leaked. PHP then brought its pre-announcement forward and moved the drop from 22 Oct to 21 Oct 14:00 UTC (22:00 Taipei).
  • Later on 20 Oct: Calif briefly left a demo video public, then pulled it; impact not independently verified.
  • 15:41 Taipei on 21 Oct / 07:41 UTC: Chainguard unilaterally published patched PHP images — more than six hours before the coordinated release (Foundation's wording). One supplier putting new firmware on the truck early. CEO Dan Lorenc later said the goal was protecting customers.
  • Evening of 21 Oct: PHP went public early. Scheduled for 14:00 UTC (22:00 Taipei); reported times disagree: CERT-EU ~13:30 UTC, some trackers ~13:34 UTC for the GitHub advisories, Infosecurity 4pm BST (15:00 UTC), OpenAI about 14:00 UTC. Wiz and Calif posts give dates only, not clock times — we do not use them as timestamps. This article treats it as roughly 21:30–22:00 Taipei and keeps the spread.
  • Same day: PHP Foundation long-form, Calif / Wiz / OpenAI technical posts, and a CISA urgent alert.

Leaked CVE IDs are like a headline that the encoder is defective before the repair crew has firmware on every desk. Early images protected some customers and also gave attackers an earlier look at "what changed." That tension is baked into coordinated disclosure.

In the wild: what the fake desks saw

Honeypots are fake front desks put out to watch who tries the trick:

  • AWS MadPot: recorded attempts against related paths about four days before disclosure (~17 Oct), then more after the public drop. AWS describes attempts / scanning; it has not claimed confirmed successful RCE on real customer hosts.
  • 21–22 Oct: Cloudflare, watchTowr, and others reported exploit attempts; CISA's alert said it had not observed successful exploitation at publication time. Governments and firms took sites offline preventively while patching (banks, retail, gaming, hospitals, government services — categories in TechCrunch and similar; this piece does not name individual sites that only appear on Wikipedia without a primary report).
  • 24 Oct: researcher Adel Karimi (Perplexity) published honeypot results — 35 successful shells on an Apache mod_php / PHP 8.4.26 single-worker honeypot from two IPs; no second-stage payload observed (SecurityWeek / BleepingComputer). That is evidence a honeypot was exploited, not that "many real production sites were hacked." As of this draft, no primary source has confirmed a named production site successfully taken over via PHP2Shell. What we have is attempts plus honeypot traffic.
  • Marcus Hutchins: pointed at the flood of AI-generated fake PoCs — fake "how to crack the encoder" guides. Do not copy random GitHub exploits, and do not validate them on production.

CISA KEV: on 26 Oct (US time) CISA added both CVEs to its Known Exploited Vulnerabilities catalog and updated its 21 Oct PHP alert to match. The 21 Oct alert had said no successful exploitation at publish time; the 23 Oct update mainly added detection (including SIGMA) and partner resources. A KEV listing means CISA now treats the bugs as actively exploited, and US federal agencies must patch by a deadline.

Taiwan: how many hotels still run this model

Taiwan's Administration for Cyber Security / related notices (as relayed by local press around 22 Oct) roughly reported:

  • on the order of 28,000 internet-facing, identifiable PHP-related sites;
  • about 200 government / public-sector related;
  • urgent update guidance, plus detection / response pointers.

Those numbers are an inventory of deployments that may still run affected PHP — not a count of confirmed breaches. In the analogy: tens of thousands of front desks may still be running this encoder model; about two hundred of them wear a government badge. Newer CMS themes, plugins, or WAF rules are still room locks. They do not reflash the machine.

If you run a school site, a clinic site, an SME brochure site — often one box plus WordPress or custom PHP — assume you might be in that inventory, and do not wait to be named.

Do this now: checklist

1. Check the version against the fixed builds

On the server:

php -v

Targets:

Branch Fixed build
8.5 8.5.12 or newer
8.4 8.4.27 or newer
8.3 8.3.36 or newer
8.2 8.2.35 or newer

On 8.1 / 8.0 / 7.4: no regular project security updates — only slim source backports; prefer distro / LTS packages or move to a supported branch. 7.3 and older, including PHP 5: no upstream fix; upgrade only. PHP 8.2 reaches EOL on 31 Dec 2026. If you cannot patch immediately, CISA suggests taking internet-facing PHP offline until you can.

Containers: rebuild and redeploy anything built on older layers or tags, and confirm the running process is actually a fixed build. Vendor images: trust the digest / version you pull — do not assume "official images are already updated."

2. Know your SAPI: mod_php vs php-fpm

php -i | grep -E 'Server API|sapi'
# or a phpinfo() page
  • Apache module (mod_php): official highest risk — encoder built into the desk, most exposed. Patch first. Migrating to php-fpm is a longer-term architecture choice; it does not replace the patch.
  • php-fpm / FastCGI / cgi: still in scope. 109619 paths are validated or source-supported on FPM. 109618's "full FPM exploit not shown" is not permission to wait.
  • FrankenPHP, LiteSpeed, and similar: CISA / PHP treat PHP installs that serve web requests as in scope — confirm with your vendor.

Windows builds of the four fixed versions are on the PHP downloads site.

3. Updating is the only complete fix; WAF and ini are stopgaps

In the analogy: new firmware is what fixes the encoder. PHP is blunt: config mitigations do not make you safe. A WAF may help until you update — a bridge, not a substitute.

While you bridge:

  • set session.upload_progress.enabled=0 and restart every worker (covers confirmed 109619 paths and the 23 Oct informational CVE-2026-115560);
  • shrink internet-facing PHP surface to what you truly need;
  • watch for PHP workers spawning shells, fetching tools, or talking to mining endpoints (CISA's 23 Oct update adds SIGMA and similar); hunt logs back to 17 Oct (Amazon's suggested start);
  • inventory routers, NAS, firewalls, VPNs, and other appliances that embed PHP — the Dutch NCSC keeps a php2shell software list.

4. After the patch: reboot every encoder

Restart every PHP worker (apache2 / httpd, php-fpm, containers) after packages or images update — new firmware does nothing if the desk machine never reboots — then run php -v again so the live process is the new build.

5. A third CVE — not "another PHP2Shell"

CVE-2026-115560 (23 Oct) is an informational advisory: exploitation needs session.serialize_handler set to php_binary or php_serialize, then switched back to php with ini_set() before session_start(), with upload progress still on. PHP calls that combination uncommon; there will be no emergency release — full details wait for the next regular cycle. No exploitation reports and no public PoC as of this draft. If you already disabled upload progress on 21 Oct, you usually need nothing more.

Lessons worth keeping

  1. A runtime bug is not an application bug. Better room locks do not fix a broken encoder.
  2. AI cheapens turning a bug into an exploit, not "prompt once, dump every bug"; independent rediscovery still shrinks quiet windows.
  3. A honeypot getting shelled ≠ a production site breached. The former proves a working chain is in the wild; the latter is still unconfirmed in primary sources as of this draft. Fake PoCs spike at the same time — do not validate them on prod.
  4. "~69% run PHP" ≠ "you are owned"; "modern framework" ≠ "you are safe." Check version and SAPI; inventory embedded-PHP appliances too.
  5. Stopgaps (WAF, ini, taking systems offline) buy time; only update + restart every worker ends the incident.
  6. What you depend on is part of your security boundary. The PHP Foundation's own post: security work still depends on "a small group of foundation-funded developers" — while roughly seven in ten identifiable server-side sites lean on PHP. Same lesson as the earlier Zeabur piece: the maintainer layer is your risk surface. (TechCrunch also cites NSA: about 75% of actively exploited vulnerabilities abuse memory-safety flaws.)

Close

Back at the desk: no guest identity, no password. Stand at the counter, jam odd cards until the encoder dies mid-write, and the next card may hold permissions it should never have. A long-lived worker that never resets is the same encoder serving the next guest with yesterday's half-written card still in memory. Your website's own code — the room locks — barely gets a vote on this path.

What to do is concrete: learn your PHP version and SAPI, match 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 (or the distro equivalent), update, restart every worker, re-check. Taiwan still has on the order of tens of thousands of internet-facing PHP sites that may be on affected builds. The one you run should not wait to be scanned.

That is as far as the encoder analogy goes. It is there to make the intuition stick. The thing that actually protects you is the version string.

Clock times are given in Taipei time (UTC+8) where a time is stated. Date-only items keep the source UTC date or the official publish date. Disclosure clock times (13:30 / 13:34 / ~14:00 / ~15:00 UTC) and the date of OpenAI's first independent report disagree across primary sources; both hedges are kept above.

Sources