Chained PHP2Shell exploit roots 25 servers, including US Government servers

A recently disclosed exploit chain targeting a critical PHP request-parsing vulnerability (“PHP2Shell”) has been used to gain root access on at least 25 servers, including systems behind a major firewall vendor and a US government–affiliated environment. Commenters debate how severe and widespread the underlying PHP flaw truly is, noting that it executes before application code or auth checks and often needs to be chained with Linux kernel privilege escalations, while also pointing out that real-world impact has been limited by deployment specifics, patching, and configuration. The incident raises broader concerns about the fragility of core internet infrastructure, the security posture of commercial firewalls and public-sector systems, and the growing role of AI tools in both finding and exploiting such bugs.

Severity and exploitability of PHP2Shell

  • Core issue: RCE in PHP’s request parsing, before any application code or auth, so “secure PHP code” and typical auth checks don’t help.
  • Some argue it was overhyped because:
    • Only a small number of real-world systems (25 of ~15k scanned) ended up fully rooted via this chain.
    • Many PHP deployments were not actually exploitable in practice due to deployment details or patches.
  • Others insist it’s one of the worst bugs in years:
    • Platform-wide, pre-auth RCE in a ubiquitous interpreter.
    • Only reliable mitigations before patching were basically “don’t run PHP” or take services offline.
  • The “stealmybitcoin” challenge caused confusion:
    • Initially misconfigured (no real PHP endpoint), later fixed and exploited within ~2 hours.
    • Used to argue both “harder than advertised” and “definitely real and dangerous.”

Attack Chain and Affected Systems

  • The reported intrusions used a chain:
    • PHP2Shell for initial code execution as www-data.
    • A Linux kernel local-privilege-escalation (XFRM ESP-in-TCP / likely “Dirty Frag”) to get root.
  • Only unpatched PHP on a specific firewall platform was affected in this incident; the public CVE is patched upstream.

Firewall Management, Vendor Stack, and Misconfiguration

  • Strong criticism that firewall admin interfaces were exposed directly to the internet instead of isolated on management networks.
  • Thread consensus that the vendor is Palo Alto Networks (PAN-OS), based on:
    • PHP versions mentioned.
    • SELinux configuration.
    • Appweb + PHP stack.
  • Debate on why a “world-class firewall” still runs PHP:
    • Historical context: PHP was a natural choice in the 2000s.
    • Once large GUIs exist, rewriting into a safer/simpler stack is expensive, so legacy persists.

AI, Hype, and Exploit Development

  • Multiple commenters report LLMs (Claude Code, DeepSeek, Qwen, others) assisting with exploit construction and optimization (e.g., more efficient memory exhaustion).
  • Split views:
    • Some see AI’s role and the media narrative as overhyped “AI safety marketing” and clickbait.
    • Others argue critics are downplaying a genuine AI-enabled shift in exploit capability.

Linux Kernel Attack Surface and Hardening

  • Concern that Linux ships with a very broad attack surface:
    • Features like XFRM, MPTCP, algif_aead, SMB, io_uring+DMABUF often enabled by default.
  • Some users respond by auditing loaded modules and disabling unneeded subsystems.
  • Acknowledgement that general-purpose distros enable “everything” for compatibility, while hardened setups (e.g., Gentoo with custom kernels, Android + SELinux) can reduce exposure.

Broader Security and Trust Concerns

  • Frustration that government-adjacent systems with strict regulatory demands still expose misconfigured, vulnerable gear.
  • Some question whether public cloud / SaaS (e.g., O365) is meaningfully safer, given constant new exploit chains.
  • A minority speculate about pushing more critical functionality into hardware/FPGA for determinism, while others note that would make patching design flaws harder.