Dream says a chained PHP2Shell and kernel exploit rooted 25 servers, three in a US government affiliated network
Dream says an attacker chained PHP2Shell with a Linux kernel flaw to root 24 firewalls and a management server, three in a US government affiliated network. The first was rooted 52.4 hours after the CVE records, on a PHP branch they do not list. Read 28 October 2026.
By Parminder Kumar Sharma · · 19 min read
Dream's timestamps put the first government affiliated firewall rooted 52.4 hours after the PHP records were published
Dream, a security company, says it recovered an attacker's toolkit and logs and that they show 25 servers rooted. Read from Dream's post and SecurityWeek's report on 28 October 2026, first fetched at 18:42 UTC. By Dream's own timestamps, the first firewall it links to a US government affiliated organisation was rooted at 18:14 UTC on 23 October. The CVE.org records for the two PHP flaws, CVE-2026-109618 and CVE-2026-109619, were published at 13:48 and 13:54 UTC on 21 October. The gap is 52.4 hours (derived). Dream says the firewall operating system uses PHP 8.0.30, a branch PHP's own page lists as end of life since 26 November 2023, which is 1,062 days before the attack (derived). The CVE records list only the 8.2, 8.3, 8.4 and 8.5 branches.
What that does not establish: which vendor or product this is, which firmware versions, whether a fix exists for them, which organisation was reached, or who did it. Dream withheld the vendor and the versions and says the vendor has been notified. The government affiliation is Dream's reading of a configuration file, not a statement from the organisation or from any US authority. No vendor, victim or government response was in either source. The post prints no hashes, addresses or domains, and its two figures are images.
The flaws, the emergency releases, the decoy server shells and the federal catalogue listing are covered elsewhere: the fixes, the decoy shells, which showed no real victim and the CISA listing. This briefing is only what the incident report adds: how the campaign was counted, what it did inside one network, and how far the evidence for China and for AI assistance goes.
Who reports it, and where the headline and the report differ
Dream Research published the post. Its page is headed 26 October 2026 and says its researchers uncovered the artifacts on 25 October; the page's own metadata gives 27 October, 17:02 UTC, as the publication time. SecurityWeek's report is dated 28 October, 8:00 AM ET, which is 12:00 UTC. Dream's commercial interest is stated in its own post: it sells two products, Sphere and Hero, and says the investigation was done with Hero, its autonomous research tool. A report that shows what a product found is also a demonstration of the product, and that is no reason to doubt the artifacts, only a reason to note who chose what to publish.
Where SecurityWeek's summary and Dream's post part company, both read 28 October 2026
| Point | SecurityWeek, 28 October | Dream, the primary |
|---|---|---|
| Servers rooted | 25 firewalls exploited on 23 to 24 October | 24 firewalls rooted; the 25th server is an internal firewall management server reached through a tunnel on 24 October |
| Government servers | Two servers of a US government affiliated organisation | Two firewalls and the management server, so three; the affiliation is described as apparent |
| Attribution | Headline: China linked hackers | No named actor; indicators point to a Chinese nexus operation; says it does not appear to be a fully autonomous nation state attack |
| Vendor | A specific vendor | Not disclosed, vendor notified |
| AI | Not mentioned | Claude Code installed, an offensive platform configured with two Chinese models; no direct evidence AI wrote the exploit |
None of these differences changes the story, but the first two matter to anyone counting. The headline number, 25, is a mix: 24 firewalls from a pool of 19,000 plus one internal server that was never in that pool. Dream's own sentences do not fully reconcile either, as the next section shows.
A funnel from 19,000 firewalls to 25 servers, with a 90 per cent miss rate nobody explains
Dream describes a targeting funnel. The attacker used FOFA, a Chinese internet asset search engine, to find about 19,000 internet facing firewalls from one vendor, scanned them for versions with 200 concurrent threads, and got about 5,000 answers. A filter on country (United States, Japan, Taiwan, South Korea) and on versions matching prepared exploit profiles left 240 targets. An automated runner attacked them five at a time with a 30 minute limit each and rooted 24.
Derived from Dream's counts: 240 attempted and 24 rooted is a 10 per cent hit rate, so 216 attempts did not root. The post does not say why. The first government affiliated firewall crashed, which Dream says was likely from about 900 MB of exploit traffic, and the exploit rounds it describes (about 383 MB and about 500 MB) sum to 883 MB (derived), so a failed or crashed target is plausible, but that is an inference, not a statement in the post. A 10 per cent rate also says something about reliability: this is a chain tuned per firmware build, not a fire and forget payload.
The country filter is the basis for Dream's attribution, and it has a confound. The filter was applied in two steps, geography and then versions with prepared profiles, so the final list reflects where the attacker's exploitable builds were as well as where the attacker wanted to look. The post gives no count after the geography step alone, so the two cannot be separated.
One internal inconsistency is worth stating. Dream's text says the second government affiliated firewall timed out in the original batch and was rooted separately on 24 October at 10:09 UTC, yet its Figure 1 puts 24 firewalls rooted by 21:55 on 23 October, and the arithmetic of 22 parked plus two government affiliated firewalls only gives 24 if the 10:09 firewall is inside the 24. Either the batch rooted 23 or the total is 26. The difference is one server and does not change the findings, but the post does not reconcile it.
The timeline starts on 8 October, 13 days before the PHP records were published and four days before the CVE identifiers were reserved (12 October, per CVE.org, derived). That date is when an AI platform was configured, per Dream's figure. It is not a date for exploit work, and the post gives no date for when exploit development began or how the attacker learned of the flaws.
Two flaws chained in one request, on a PHP branch the CVE records do not list
Dream says the attacker built two exploits and chained them so that one unauthenticated HTTPS request to the firewall's management web server ended in root. The first is a custom, non public build of PHP2Shell, which Dream says follows the same concept as known work but was tailored to the firewall platform. It runs in four stages that exhaust memory (about 383 MB, then about 500 MB), leak an address and forge an internal structure, ending in command execution as the unprivileged user nobody. That user cannot change system files because SELinux confines it, so the second exploit does: Dream names it Fragnesia, CVE-2026-46300, a Linux kernel flaw in the ESP in TCP path, and says it overwrites the su authentication rules so that su root needs no password. Dream says the whole chain, from connection to a persistent root webshell, takes under 15 minutes.
Three checks against the records, since Dream's post is the only source for the chain itself. First, the PHP records. CVE.org lists CVE-2026-109618 and CVE-2026-109619 as affecting 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12, with other versions defaulting to unaffected, and gives each a CVSS 4.0 base score of 9.2. Dream's profile table is for older branches: 9 profiles for PHP 8.0.30 builds (one calibrated in a lab, 8 provisional) and 2 provisional ones for PHP 7.4.33, where remote code execution as nobody was verified in a lab but the full chain was not calibrated. So the record of the flaws says nothing about 8.0 or 7.4, while Dream reports them exploitable. A branch missing from an affected list is not the same as a branch that was tested and found clean, and no upstream fix exists for an end of life branch: the fix has to come from the firmware vendor.
Second, the kernel record. CVE.org gives CVE-2026-46300 a publication date of 23 May 2026, which is 153 days before the first rooting (derived), a CVSS 3.1 base score of 7.8 with a local attack vector and low privileges required, and fixed kernel versions including 5.10.257, 5.15.208, 6.1.174, 6.6.141 and 6.12.91. The name Fragnesia does not appear in the CVE record; it is Dream's and SecurityWeek's label. CISA's enrichment on the record, timestamped 16 October, rates exploitation as none, and the catalogue of known exploited vulnerabilities, version 2026.10.27, lists the two PHP flaws but not this one. Which kernel the firewall runs, and whether the vendor backported the fix, is not stated.
Third, how Dream's description maps to the PHP advisory. The advisory describes out of memory handling that leaves request state invalid; Dream describes a chain built on the session upload progress mechanism of the firewall's web server. The post does not map its stages to each CVE, so this site cannot say which stage corresponds to which flaw. The advisory's partial mitigation is to set and enforce an unlimited memory limit, because a predictable per request limit is what the confirmed exploit used; Dream says this firewall has a high memory limit that enables the memory stages. Whether anyone changed that setting on the firewall is not stated.
The government affiliated network: what the report actually says
Dream says the running configuration taken from the first firewall showed characteristics that suggest government affiliation: Common Access Card authentication, a specific naming prefix, and standardised government style asset names. The configuration also held the organisation's internal topology: domain controllers, a central firewall management server, a Keycloak single sign on server, a GitLab instance, VPN gateways and the Active Directory domain. For the second firewall, Dream says certificate data definitively linked it to the target organisation. No organisation, agency or country level of government is named, and the word affiliated is Dream's.
The sequence, per Dream: the first firewall was rooted at 18:14 UTC on 23 October, then crashed and never came back; the attacker sent 240 automated probes over two hours waiting for it. Having read its configuration, the attacker ran a dedicated campaign against the second firewall and rooted it at 10:09 UTC on 24 October. Within hours, per Dream, the attacker built an 8 port reverse SSH tunnel with a boot hook, used it to reach the internal firewall management server and rooted that at 11:35 with the same chain, 86 minutes later (derived), and from that server attacked Active Directory.
What Dream says the attack on Active Directory did, and what it could not see; from Dream's post, read 28 October 2026
| Activity | Dream's status | What stops it being known |
|---|---|---|
| Decrypted the LDAP service account password | Confirmed from recovered artifacts | Root gave the attacker the master key to the device configuration, per Dream |
| Listed every user and group | Confirmed from recovered artifacts | Dream calls the listing a complete organisational blueprint |
| Password spray with organisation themed passwords | Attempted, outcome unknown | Results stayed on the management server; the domain had no lockout (lockoutThreshold=0) |
| Backdoor user and machine accounts | Attempted, outcome unknown | Same: results not among the recovered artifacts |
| Extraction of SAML signing keys, probe of Keycloak | Attempted, outcome unknown | Same; Dream also notes a weak setting on the identity provider configuration |
Dream lists what the attacker holds from the recovered artifacts: a boot surviving tunnel and a SOCKS proxy, root webshells on two firewalls and the management server, the user and group listing, decrypted LDAP credentials, private keys from the firewall (high availability replication, TLS certificate and device authentication keys), the complete topology, and 22 parked firewalls. It describes the access as likely still active. That is Dream's judgement from artifacts. Nothing in either source says anyone checked the live network or that the organisation responded.
Attribution and AI: six indicators, none of them a named actor
Dream does not attribute the activity to a named actor. It lists six indicators that it says point to a Chinese nexus operation, and says the target set suggests potential nation state efforts. SecurityWeek's headline says China linked; the post's wording is weaker. The table sets each indicator against what it can and cannot show. The right hand column is this site's assessment, not Dream's.
Dream's six attribution indicators and what each can and cannot show; indicators from Dream's post, assessment by this site
| Indicator (Dream) | What it can show | What it does not show |
|---|---|---|
| Targets only in the United States, Japan, Taiwan, South Korea | The attacker chose those countries or had builds there | Confounded by the version filter; a commercial buyer or a criminal could choose the same list |
| FOFA used for discovery | The attacker used a Chinese search service | FOFA is a commercial service anyone can use, and its use is not unique to one country |
| ioX, a Chinese developed tunnelling utility | A tool of Chinese origin was among the recovered files | Public tools are used by many; origin of a tool is not origin of an operator |
| DeepSeek and Kimi configured in the AI platform | The operator had access to two Chinese models | Anyone can configure them; it says nothing about who the operator works for |
| Clock on UTC plus 8, checked against HTTP Date headers | The machine's clock was set to China Standard Time or an equal zone | UTC plus 8 is also the standard time in Taiwan and Singapore, among others (general knowledge, not in Dream's post), and a clock can be set |
| Chinese language prompts in session logs | A Chinese speaker typed them | A language is not an employer |
Together the indicators fit a Chinese speaking operator using Chinese services. They do not show a state, an intelligence service or any named group, and Dream does not claim they do. Dream also says the operation does not appear to be a fully autonomous nation state attack, and that the investment in vendor research (obtaining the firmware, decrypting it, extracting the PHP libraries, building profiles for 9 versions) sets it apart from opportunistic exploitation.
On AI, Dream says Claude Code had been installed, an offensive security platform called aiscan was configured with DeepSeek and Kimi, and FOFA API keys were present. It says it has no direct evidence the AI tools were used to write the exploit or the post exploitation scripts, and infers possible AI assisted development from code structure, comments and consistency across about 40 scripts. That inference is Dream's, from style. Anthropic makes and sells Claude Code, and the report says only that it was installed, not that it did anything; Anthropic's response was not part of the sources read.
Stated and not stated
What Dream's post states and what it leaves out, with SecurityWeek read for differences; read 28 October 2026
| Topic | Stated | Not stated |
|---|---|---|
| Vendor and product | A large vendor's firewall software; vendor notified | The name, the versions, whether a fix exists |
| The count | 24 firewalls rooted plus a management server as the 25th | Why 216 of 240 attempts did not root; whether 24 includes the 10:09 firewall |
| Government affiliation | Configuration features and certificate data point to one organisation | Its name, its level of government, any confirmation from it or from US authorities |
| Inside the network | LDAP password decrypted, users and groups listed, tunnel and webshells | Whether the spray, the backdoor accounts or the SAML key attempt worked |
| Current access | Likely still active, from recovered artifacts | Any live check, any containment, any victim response |
| Attribution | Six indicators, Chinese nexus, potential nation state effort | A named actor, a state link, intent beyond targeting |
| AI | Three tools present; style suggests AI assisted scripts | Direct evidence that AI wrote or ran anything |
| Indicators and dates | A 103 byte webshell, an 8 port tunnel, timestamps for 23 and 24 October | Hashes, addresses, domains, file names; when exploit work began or how the attacker learned of the flaws |
Where a label stands in for a control
A firewall is a control for the networks behind it. Here the control was the entry point: the firewall's own management web server, reachable from the internet, was the attack surface, and a search on certificate fingerprints and response signatures was enough to find about 19,000 of them. Dream's conclusion says the interface should never have been exposed. A management interface is a service like any other and it needs the same inventory and the same patches.
Three more labels do the work of a control in this story. Not listed as affected is a statement about a record, not a test of a product, and the PHP records stop at 8.2. Patch PHP is advice a firewall owner cannot follow when PHP is bundled in firmware, because the update path runs through the vendor, who has not been named. Government affiliated is a reading of a configuration; it should be held as an allegation until the organisation or an authority says so.
Technical details
Dream's post prints no hashes, IP addresses, domains, webshell file names or tunnel endpoints, and the two figures are images. What it does print is below, copied exactly from the saved page where the text is quoted, and from the saved CVE.org, PHP and CISA records. Nothing here is exploit code. Each block is for a defender: what to compare against, what to hunt for, what to set.
The first block is the list of host and network artifacts Dream describes, one phrase per line, each an exact copy of a phrase in the post. Dream's sentence about the su file continues with a dash in the original; the phrases are cut at that point. Use it to decide what to check on a firewall you cannot patch yet.
Planted a 103-byte PHP root webshell in a publicly accessible directory on the firewall
Verified root by executing id through the webshell
An 8-port reverse SSH tunnel connected the compromised firewall back to the operator's infrastructure
The tunnel was wrapped in a systemd service and an rc.local boot hook
overwrite /etc/pam.d/su
replacing its authentication rules with pam_permit.so (accept all)
Because the PAM file is only 774 bytes
The attacker monitored it with 240 automated probes over two hours, waiting for it to recover.
The domain had lockoutThreshold=0
exploiting the default MachineAccountQuota setting
validate-idp-certificate: no
A Chinese-developed tunneling utility observed among the recovered tools.
The second block is this site's own hunting list, built from the sizes and behaviours above. It is derived, and a clean result does not clear a device whose logs the attacker could edit; Dream's Figure 1 says forensic traces were cleaned.
Derived by this site from the sizes and behaviours in Dream's post. Hunting pointers, not detection rules, and no indicator here is printed by Dream.
1. Request volume: two memory pressure rounds of about 383 MB and about 500 MB per target (883 MB, derived); Dream says about 900 MB of exploit traffic likely crashed one firewall.
Look for very large multipart POST bodies to a management address from one source, in front of the device if the device keeps no logs.
2. New files: a file of about 103 bytes in a web reachable directory of the appliance, created within minutes of the large requests.
3. /etc/pam.d/su: Dream says the original is 774 bytes and that its rules were replaced with pam_permit.so. Compare it with a known good copy of the same build.
4. Persistence: a new systemd service or an rc.local line that starts an outbound SSH session; an outbound SSH session from the appliance that forwards 8 ports.
5. From the management server: LDAP binds with the appliance's service account from unusual times, user and group enumeration, repeated failed logons across many accounts, new user or machine accounts.
The third block is the version data in the PHP record. It lists four branches and a default of unaffected, which is why an older bundled branch cannot be cleared by the record alone.
cveMetadata.cveId: CVE-2026-109618
cveMetadata.dateReserved: 2026-10-12T21:03:58.117Z
cveMetadata.datePublished: 2026-10-21T13:48:34.845Z
containers.cna.metrics[0].cvssV4_0.vectorString: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
containers.cna.metrics[0].cvssV4_0.baseScore: 9.2
containers.cna.affected[0]:
{
"vendor": "PHP Group",
"product": "PHP",
"packageName": "php-src",
"versions": [
{
"status": "affected",
"version": "8.2.*",
"lessThan": "8.2.35",
"versionType": "semver"
},
{
"status": "affected",
"version": "8.3.*",
"lessThan": "8.3.36",
"versionType": "semver"
},
{
"status": "affected",
"version": "8.4.*",
"lessThan": "8.4.27",
"versionType": "semver"
},
{
"status": "affected",
"version": "8.5.*",
"lessThan": "8.5.12",
"versionType": "semver"
}
],
"defaultStatus": "unaffected"
}
The fourth block is the PHP project's own mitigation advice for installations that cannot update. It is a partial mitigation and the advisory says updating is the only complete one.
For installations that cannot update, setting and enforcing memory_limit=-1 administratively is the primary configuration mitigation.
Restart every PHP worker and confirm that no pool, directory or application setting restores a finite PHP memory limit.
Keep post_max_size conservative and independently enforce the decoded request size at the frontend.
If the application does not use multipart form data, block such requests at the frontend before they reach PHP.
The fifth block is the kernel record Dream names for the privilege escalation. The attack vector is local, which fits a chain where PHP2Shell supplies the local foothold.
cveMetadata.cveId: CVE-2026-46300
cveMetadata.datePublished: 2026-05-23T11:44:02.231Z
containers.cna.title: net: skbuff: preserve shared-frag marker during coalescing
containers.cna.metrics[0].cvssV3_1.vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
containers.cna.metrics[0].cvssV3_1.baseScore: 7.8
fixed versions listed (status unaffected, from the version shown): 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33, 7.0.10
The sixth block is what the federal catalogue says about the two PHP flaws and the kernel flaw as of its 27 October release. A listing can change after that.
catalogVersion 2026.10.27 dateReleased 2026-10-27T19:00:02.2307Z
CVE-2026-109618 dateAdded 2026-10-26 dueDate 2026-10-29 forensicTriage Yes knownRansomwareCampaignUse Unknown
CVE-2026-109619 dateAdded 2026-10-26 dueDate 2026-10-29 forensicTriage Yes knownRansomwareCampaignUse Unknown
CVE-2026-46300: no entry in this catalogue version
A ranked checklist for anyone with an exposed firewall management interface
The order puts exposure first because it is the one step that does not depend on a vendor patch, and it is the step Dream says would have prevented the whole chain.
Take this with you
In the order worth doing
- List every firewall, VPN gateway and management server whose web management interface answers from the internet. Dream says the targets were found by certificate fingerprints and HTTP response signatures, so search your own address space for the same signs.
- Take the management interface off the internet today: allow it from a management network or a VPN only. Dream's conclusion is that the interface should never have been exposed.
- Ask each vendor in writing whether the appliance bundles PHP, which version, whether CVE-2026-109618, CVE-2026-109619 and CVE-2026-46300 apply to its builds even on an older branch, and which fixed build to install. Do not accept the CVE affected list as an answer for an end of life branch.
- If you run PHP yourself, update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 and restart every PHP worker, as the PHP advisory says; until then apply its frontend limits on multipart requests.
- On any appliance that was exposed, hunt before you reboot or patch: large multipart requests, a small new file in a web reachable directory, a changed su rules file, a new systemd unit or rc.local line, and outbound SSH. Keep a forensic copy where the vendor allows it.
- Treat a central firewall management server as a top tier asset. If any managed device was reachable, assume the stored credentials, high availability keys, certificate keys and device keys are exposed, as Dream says the attacker took them, and replace them.
- Rotate the LDAP service account used by the appliance and any other account whose secret the appliance stores, and reduce that account's rights to what the appliance needs.
- In Active Directory, set an account lockout threshold (Dream says this domain had none), review the machine account quota, and review user and machine accounts created since 23 October.
- Review identity provider settings: whether certificate validation is on (Dream notes it was off in the recovered configuration), and whether SAML signing keys could have been read from a server the appliance could reach.
- Block outbound SSH from firewalls and management servers except to named hosts, and alert on any new long lived outbound session from them.
- Patch the kernel flaw where you control the kernel, or take the vendor's backport: CVE.org lists fixed versions from 5.10.257 to 7.0.10 depending on the line.
The question that exposes the gap
Dream's account is a single vendor's report of artifacts it chose to describe, with the vendor, the victim and the versions withheld. That leaves defenders with a hard test they can run on themselves. Which of your internet reachable management interfaces runs a web stack that you cannot patch yourself, on a branch the CVE record never mentioned, and who told you it was not exposed?
Key facts at a glance
Sources
- PrimaryDream Research, 'Chained PHP2Shell Exploit Roots 25 Servers, including US Government Servers', page dated 26 October 2026 (metadata 27 October 17:02 UTC), read in full: the funnel, the chain, the pivot, the Active Directory attack, the attribution indicators, the two figures. Vendor and versions withheldDream Researchaccessed 2026-10-28
- PrimaryCVE record CVE-2026-109618, RCE via OOM corruption: published 21 October 2026 13:48 UTC, reserved 12 October, affected 8.2 to 8.5 with fixed versions, CVSS 4.0 score 9.2CVE Program (PHP Group as CNA)accessed 2026-10-28
- PrimaryCVE record CVE-2026-109619, RCE via stale global state: published 21 October 2026 13:54 UTC, same versions and scoreCVE Program (PHP Group as CNA)accessed 2026-10-28
- PrimaryCVE record CVE-2026-46300, skb coalescing shared frag marker: published 23 May 2026, local vector, CVSS 3.1 score 7.8, fixed kernel versions, CISA SSVC exploitation none at 16 OctoberCVE Program (Linux kernel CNA)accessed 2026-10-28
- PrimaryPHP advisory GHSA-w8hw-w9fx-j79w, published 21 October 2026: affected below 8.2.35, 8.3.36, 8.4.27, 8.5.12, the mitigation advice for installations that cannot updatePHP project (GitHub security advisory)accessed 2026-10-28
- PrimaryPHP 8 ChangeLog: the fixes for the two advisories in 8.2.35, 8.3.36, 8.4.27 and 8.5.12 listed under 22 October 2026; 8.0.30 dated 3 August 2023The PHP Groupaccessed 2026-10-28
- PrimaryPHP unsupported branches: 8.0 end of life 26 November 2023, last release 8.0.30; 7.4 end of life 28 November 2022, last release 7.4.33The PHP Groupaccessed 2026-10-28
- PrimaryPHP supported versions: only 8.2, 8.3, 8.4 and 8.5 are currently supportedThe PHP Groupaccessed 2026-10-28
- PrimaryKnown Exploited Vulnerabilities catalogue, version 2026.10.27 released 19:00 UTC: both PHP flaws added 26 October with a 29 October due date; CVE-2026-46300 not listedCISAaccessed 2026-10-28
- Reported bySecurityWeek, 'China Linked Hackers Exploit PHP2Shell to Root Firewalls', 28 October 2026, 8:00 AM ET: the secondary summary of Dream's post, read for differencesSecurityWeekaccessed 2026-10-28
