PHP 8.2.35

Original Article ↗ Hacker News Discussion ↗

Emergency security releases for PHP 8.2–8.5 aim to patch two critical “PHP2Shell” vulnerabilities that allow unauthenticated remote code execution on nearly any PHP-powered web server, including popular stacks like WordPress and shared hosting platforms. Commenters swap short‑term mitigation tactics (disabling upload progress, blocking multipart form data, tightening memory limits, restarting workers aggressively) while waiting for patched packages and Docker images from distros, cloud providers, and third‑party repos. The incident also triggers wider concern about coordinated disclosure in the age of AI‑assisted vulnerability hunting, the slow patch rollout of some vendors, and the long tail of unsupported PHP 5/7 installations still running much of the web.

New Releases and Vulnerabilities

  • Security releases: PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12; also minimal source backports for 7.4, 8.0, 8.1.
  • Two critical vulnerabilities (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp) allow RCE via out‑of‑memory handling and multipart parsing; all web SAPIs are said to be at risk (FPM, mod_php, CGI, etc.).
  • Vulnerabilities are related to OOM during request initialization, longjmp-based error handling, and multipart/form-data parsing; many defensive checks for OOM were added across the codebase.

Mitigations and Operational Responses

  • Common temporary mitigations:
    • Disable session.upload_progress.enabled.
    • Block multipart/form-data requests at the web server, accepting that this breaks file uploads.
    • Set pm.max_requests=1 in FPM to avoid stale state reuse.
    • Reduce post_max_size and max_input_nesting_level.
    • Ensure no .php is served from uploads and remove phpinfo.php.
  • Some operators took PHP sites offline or shut off front-end web servers until patches were available; others inserted temporary reverse proxies/filters between web server and FPM.
  • Debate over whether CGI/classic one-request-per-process is practically exploitable; official advisory treats all SAPIs as risky.

Distro, PPA, and Docker Patch Lag

  • Debian (including oldstable and some PHP 7 backports) and Gentoo updated quickly; Ubuntu security updates lagged and were inconsistent across LTS releases but eventually landed.
  • Ondřej Surý’s Debian/Ubuntu repos and other third‑party repos (including for PHP 5.6/7.4) shipped patched builds early; Launchpad and PECL were overloaded.
  • Official Docker images for PHP and popular apps (WordPress, Matomo, Nextcloud) were notably slow or briefly published images still on vulnerable PHP, leading many to rebuild images themselves or use distro packages instead.

Older PHP Versions and Shared Hosting

  • Large fractions of the ecosystem still run PHP 5/7; some distros and community maintainers backported fixes, but official PHP stopped at 7.4 minimal patches.
  • Managed WordPress and shared hosting providers varied: some forcibly disabled all PHP sites; others rolled out patched versions hours later, frustrating users.

Role of AI and Disclosure Process

  • Vulnerability chain attributed to work by security firms using LLMs; there is strong debate whether the coordination and embargo were mishandled and overly PR-driven.
  • Some argue earlier, quieter fixes or faster release after the leak would have reduced chaos; others note any public patch instantly reveals the bug in the LLM era.
  • Significant meta‑discussion about “AI slop” in comments, with both criticism (low trust, noisy writeups) and praise (fast mitigations, tooling, audits generated).

Technical and Cultural Reactions

  • Longjmp, manual OOM handling, and scattered goto-style checks are criticized as unsafe C patterns; others note such techniques are common in interpreters.
  • Some view this as yet another sign PHP is a “fractal of bad design” and advocate migrating off PHP, especially now that AI can help port code.
  • Others counter that all major runtimes (JVM, V8, etc.) see critical bugs; PHP’s ubiquity makes its failures more visible, not uniquely bad.