Security advisory: Critical remote code execution vulnerabilities, update now

Original Article ↗ Hacker News Discussion ↗

A critical pair of PHP vulnerabilities (CVE‑2026‑109618/109619, dubbed “PHP2Shell”) enables unauthenticated remote code execution on virtually any PHP installation from version 5 onward, putting an estimated majority of the web — including countless WordPress and MediaWiki sites — at risk. With proof‑of‑concept exploits circulating before official patches were available, operators weighed emergency mitigations like blocking multipart POST requests or taking sites offline entirely, while CDNs and hosting providers rushed out WAF rules and backported fixes. The incident has reignited concerns about coordinated disclosure in the LLM era and about the long‑term security of large C‑based runtimes such as PHP.

Scope & Severity

  • Vulnerabilities (CVE-2026-109618 / -109619, nicknamed “PHP2Shell”) affect essentially all PHP versions from 5.x onward, default configs, typical FPM setups, and any server that accepts POST/multipart requests.
  • Multiple commenters compare impact to or worse than Heartbleed/Log4Shell, given PHP’s ~70% web share and ease of exploitation for unauthenticated RCE as the webserver user.
  • Later released advisories describe two main chains: RCE via OOM corruption and via stale global state in multipart parsing.

Exploit & PoC Status

  • Video demos and PoCs circulated on social media before official patches; early PoCs were incomplete or just crashers, but Cloudflare and others report active exploitation in the wild.
  • Exploit path appears to abuse multipart/form-data parsing and upload progress handling; default session/upload settings increase exposure.
  • Some commenters claim to have achieved at least memory corruption or limited database access on test systems.

Mitigations & Defenses (Pre‑Patch)

  • PHP core maintainers repeatedly state that config-only mitigations are insufficient; only upgrading PHP fully fixes it.
  • Common suggested temporary steps:
    • Disable session.upload_progress.enabled and sometimes file_uploads.
    • Block multipart/form-data or all POST/PUT/PATCH/DELETE at webserver or WAF.
    • Restrict requests to GET/HEAD only, or shut down PHP services entirely.
  • Several providers (Cloudflare, other CDNs, managed WordPress/hosting, Plesk, distros) deploy WAF rules and/or backports; effectiveness is framed as partial/heuristic.

Operational Impact

  • Many admins shut down MediaWiki, WordPress, Drupal, and custom PHP apps pre‑patch; some governments, universities, and large services temporarily take sites offline.
  • Shared hosting users often cannot disable PHP cleanly, causing confusion over what “offline” really means.
  • People rush to get patched PHP packages, Docker images, and distro builds; some complain that official container images lagged behind source releases.

Disclosure & Process Debate

  • Strong debate over:
    • Embargo vs immediate patch release once PoCs leak.
    • Whether delaying patches to coordinate with big providers “abandons” smaller operators.
    • Whether LLMs make any public hint (or SEO keywords in third‑party writeups) enough to rapidly rediscover the bug.

Broader Reflections

  • Renewed criticism of PHP’s C codebase, multipart parser quality, and long history of security issues; calls to “oxidize” PHP or migrate to Rust/Go/.NET or static sites.
  • Counterpoints note every stack has severe CVEs; real issue is defense‑in‑depth, process isolation, least privilege, and reducing dynamic attack surface.