The PHP2Shell exploit has been used in a China-linked campaign to gain root access to internet-facing firewalls. Attackers reportedly combined remote code execution in PHP with a Linux kernel privilege-escalation flaw, then pivoted deeper into a US government-affiliated environment.
Dream Research disclosed the operation on 26 October 2026 after analysing compromise artefacts from servers in four countries. SecurityWeek highlighted the findings on 28 October, while official alerts and vendor telemetry confirmed that PHP2Shell was being exploited more broadly in the wild.
How the PHP2Shell exploit rooted firewall servers
The reported attack began at a firewall’s PHP-based web management interface. PHP2Shell provided pre-authentication remote code execution, meaning an attacker could reach the vulnerable component without first supplying valid credentials.
According to Dream, a single unauthenticated HTTP request could trigger the PHP2Shell exploit on the exposed interface. This initially allowed code execution with the privileges of the affected PHP process, rather than complete control of the underlying appliance.
The attackers then used Fragnesia, a local privilege-escalation vulnerability in the Linux kernel. Combining the two flaws elevated their access to root, the highest privilege level on a Linux system.
From remote access to root control
PHP2Shell is the collective name used for CVE-2026-109618 and CVE-2026-109619, two memory corruption vulnerabilities in PHP request handling. CVE-2026-109618 involves an allocation failure that leaves partially initialised state, after which cleanup can interact with uninitialised memory.
CVE-2026-109619 involves a fatal error during cleanup that leaves stale pointers to request memory that has already been freed. With careful manipulation of the heap, either condition can potentially be turned into remote code execution. Technical analysis indicates that risk is higher in mod_php configurations than under typical PHP-FPM defaults.
Fragnesia affects the Linux kernel’s XFRM ESP-in-TCP subsystem. An attacker can place file-backed pages into a TCP receive queue before enabling ESP-in-TCP processing. In-place decryption can then corrupt controlled page-cache content, enabling modification of otherwise read-only binaries in memory and escalation to root.
Fragnesia is not limited to one Linux distribution, and public proof-of-concept code is available. In this campaign, it supplied the second stage needed to turn PHP-level access into control of the firewall operating system.
PHP2Shell exploit campaign scope and victim impact
Dream reported 25 rooted servers across the United States, Japan, Taiwan and South Korea. It described three affected servers in a US government-affiliated environment, while SecurityWeek reported that two servers at the organisation were compromised. The discrepancy remains unresolved.
The number of firewalls within the total is also unclear. Some secondary accounts have characterised the campaign as affecting 24 firewalls and one management server, but that breakdown is not established by the primary findings.
Neither the firewall vendor nor the affected firewall software versions have been disclosed. Dream said the devices used specific versions of a large vendor’s firewall software with a PHP-based management interface, but public evidence does not support naming a particular supplier.
Persistence, tunnelling and internal movement
After obtaining root, the attackers reportedly installed a persistent PHP root webshell. A webshell provides a concealed interface through which commands can be executed after the original entry point has been closed or patched.
They also established a reverse SSH tunnel for command-and-control and internal pivoting. Instead of requiring an inbound connection to the compromised appliance, the firewall initiated an outbound connection that could carry attacker traffic into the victim’s network.
The tunnel was reportedly used to reach an internal firewall management server. Reusing the PHP2Shell exploit and Fragnesia chain there gave the attackers potential access to centrally held firewall configurations, credentials and settings for the managed estate.
Follow-on activity included Active Directory enumeration and credential extraction. Dream identified approximately 40 custom post-exploitation scripts, indicating an organised toolkit for discovery, credential access and movement through affected networks.
Artefacts included references to Chinese large language models and FOFA API keys. These details contributed to Dream’s China-linked assessment, but they are circumstantial and do not prove the identity or sponsorship of the operators. The findings also suggest AI-assisted development, not a fully autonomous attack.
Timeline and active exploitation status
The PHP2Shell exploit moved from non-public knowledge to widespread defensive concern in a short period. The established timeline is:
- 17 October 2026: Amazon Threat Intelligence observed a PHP2Shell exploitation attempt in MadPot telemetry before public disclosure.
- 20 October 2026: Details of the two PHP vulnerabilities leaked ahead of coordinated disclosure, prompting urgent advisories.
- 21 October 2026 at 14:00 UTC: PHP released fixed versions for the supported branches.
- 23 October 2026: Zscaler reported exploitation attempts within 48 hours of disclosure, and Red Hat published technical analysis.
- 25 to 26 October 2026: Dream analysed artefacts from the firewall compromises and published its campaign report on 26 October.
- 26 to 27 October 2026: CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalogue.
- 28 October 2026: SecurityWeek reported the campaign and its impact on the US government-affiliated organisation.
CISA’s listings confirm that both PHP vulnerabilities are being exploited in the wild. Other researchers and vendors have also observed scanning and attack attempts, although these sources do not independently verify Dream’s specific victim details.
Affected PHP versions and required action
The PHP2Shell exploit affects PHP branches up to 8.5. Fixed releases issued on 21 October are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP branches from 5.4 through 8.1 are end-of-life upstream, so organisations need a vendor backport or must migrate to a supported release.
For embedded PHP in a firewall or appliance, administrators should consult the product vendor because the underlying runtime may not be directly upgradeable. The undisclosed vendor in this incident makes it especially important to inventory appliances with web management interfaces rather than assuming conventional PHP servers are the only exposed systems.
Organisations should prioritise the following event-specific actions:
- Apply fixed PHP packages or vendor appliance updates as soon as they are available.
- Remove internet access to management interfaces and restrict administration to trusted networks.
- Hunt for PHP webshells, unusual child processes and unexplained changes on exposed appliances.
- Investigate anomalous outbound SSH connections that could indicate reverse tunnelling.
- Apply vendor kernel fixes for Fragnesia. Where appropriate, assess interim restrictions on esp4, esp6, rxrpc and unprivileged user namespaces.
- Use CISA’s PHP2Shell detection rules and review firewall management servers for credential or configuration access.
Patching closes the known entry points but does not remove persistence already established by an attacker. Any appliance exposed while vulnerable should therefore be examined for compromise, particularly where it can reach central management systems or Active Directory.
Originally reported by securityweek.com.
