PHP2Shell: AI uncovers critical RCE in PHP

Original Article ↗ Hacker News Discussion ↗

AI-assisted code analysis has uncovered two critical remote code execution vulnerabilities in core PHP, a language that underpins a large share of the web via platforms like WordPress, Drupal and MediaWiki. Commenters examine how long‑standing C memory-safety bugs in decades‑old PHP code went unnoticed, the muddled responsible disclosure timeline and leak, and the role of multiple AI models and security firms in both finding and publicizing the flaws. The thread also broadens into concerns about legacy stacks, the practicality of hardening PHP deployments, and whether newer, memory-safe languages and aggressive sandboxing should replace C-based interpreters for high‑exposure internet services.

Impact and scope

  • Discussion agrees the RCE is a very big deal given PHP’s dominance (WordPress, Drupal, forums, webmail, LMSs, Nextcloud, etc.).
  • Some compare it to Log4Shell or even EternalBlue in potential impact; others note exploit reliability and real-world damage are still unclear.
  • Governments and CERTs are taking sites offline or issuing top-level alerts; admins are scrambling to patch or front PHP with mitigation proxies.
  • A few argue properly isolated web servers should not be an easy “foot in the door,” but many acknowledge that in practice they often are.

Role of AI

  • Multiple AI systems (from different vendors) were used for code scanning, exploit development, validation, and detection.
  • Commenters see this as a strong use case: AI can grind through decades-old C code that humans rarely review.
  • Others criticize the heavy marketing, branding, and “tech-noir” writeup style and worry about overhyping AI’s role.
  • There is debate over whether AI discovered something truly new vs. rediscovering previously reported or partially fixed issues.
  • Some fear defender-facing models are over-guardrailed while attackers can use less restricted tools.

Disclosure timeline and leak

  • Reported in August, acknowledged by PHP in late September, patched and disclosed in late October; many feel two months is long given severity.
  • Confusion over a previously filed OOM bug that was marked fixed; comments suggest earlier fixes were narrow and didn’t address the broader root cause.
  • Coordinated disclosure involved many vendors and distros, increasing leak risk.
  • CVE IDs and inaccurate details leaked early, then a firm accidentally published a PoC video; another vendor shipped patched images hours before embargo end, drawing criticism.

Technical and language issues

  • The vulnerabilities are rooted in very old C code: OOM handling, use-after-free, PHP session upload progress, HashTable internals, OPcache, etc.
  • Several comments say that once heap corruption is possible, RCE is usually achievable via function pointers or similar primitives.
  • Long subthread debates whether C is “not fit for purpose” for internet-facing software; others argue C is fine but requires extreme discipline and tooling.
  • Many advocate moving critical components to memory-safe languages and relying more on sandboxing and strict isolation.

PHP ecosystem and alternatives

  • Discussion revisits PHP’s ubiquity and “legacy but huge” status, especially via WordPress.
  • Some sysadmins already treat PHP servers as hostile (isolated VLANs, hardened configs) and feel vindicated.
  • Others use this as another argument to move to static-site-based or non-PHP CMS solutions.