Cisco, Palo Alto and Nextcloud app flaws are under attack; Cisco warns upgrading a compromised virtual appliance destroys forensic data

Each vendor in this set gives operators something to search for. Cisco goes furthest with a one-command check, and The Hacker News's account of the advisory says a clean result from it is not proof ^[8]. The patches close the holes going forward. Whether anyone used a hole first has to be answered from device logs, file names and published addresses, and the sources show those answers are partial.

The four cases are separate events. Neither Cisco nor Palo Alto Networks said who is behind the exploitation of its flaw ^[4][14]. Unit 42 tracks the intruders in its Fortinet case as CL-STA-0954, also called UNC5820 ^[34], and no source here ties them to the others. What the cases share is the outcome of a successful attack: code execution on the device, as root on the Cisco and Palo Alto boxes ^[1][12] and as the web server user on Nextcloud ^[23].

The fix lands after the first attacker

Nextcloud shows the sequence most plainly. The first logged attack was on September 10 ^[20]. Collabora fixed its built-in CODE app in version 26.4.303 on September 11 ^[21], one day later ^[39]. The first report came from an administrator who hosts several Nextcloud servers. Access logs from two of them show requests at 19:51 on September 10 and 09:56 on September 11 (UTC+2), both from one IP address and both aimed at proxy.php?status with a shell command hidden in the request path. All of that administrator's servers ran 26.4.302 ^[25]. The app's store listing describes it as "for local testing and non-production use" ^[33].

Updating closes the entry but does not delete a shell already written. mmeeks, who answered for the project in the GitHub thread, told users to update and also to remove any leftover shx*.php files ^[30]. Switching the app off does not help either. "It is not sufficient to disable the app to avoid the problem; it must be upgraded to >= 26.4.303 or removed," Collabora said in its advisory ^[24]. The flaw fires only while the built-in CODE server is down, on a container restart, an upgrade or after a crash ^[23]. An upgrade is therefore one of the moments an attacker can use it.

The fix was also quiet. A commenter on the GitHub issue wrote: "I could not find any mention of security fixes in the release notes." ^[31] Collabora published its advisory, with the identifier CVE-2026-110447, on October 14 ^[22]. That is 33 days after the fix ^[38]. In our view, an operator who updated on release day from the notes alone had no prompt to look for a shell.

Two of the reports show how the intrusions were found. One administrator found the shell when Nextcloud's integrity check flagged a new PHP file. Another learned of the break-in from emails about failed sudo attempts on the server. None of the reports show the attacker gaining root ^[28]. Observed shell names followed the pattern /apps/richdocumentscode/shx*.php, and the attacker checked them repeatedly with ?c=id ^[32].

The attacker's first command decoded a one-line PHP web shell into the app's folder and tried to send the server's uname -a output to a webhook.site address. On one server the attacker then used the shell to search for credential stores and cryptocurrency wallets, including *.kdbx, wallet.dat and keystore.json files ^[26]. The reviewed requests showed no commands that archived, uploaded or copied out files. The reporting administrator still wrote that "the confidentiality and integrity of application data and secrets available to the web server account must be treated as potentially affected" ^[27].

Patched servers still draw attempts. After updating to 26.4.303, one administrator logged another attempt on September 14 from a second IP address, with a payload of the same kind. The CODE server it started carried the attack text in its startup options, and no new shell file appeared ^[29]. The output "looks scary but should be harmless," mmeeks replied ^[30].

Cisco's check cannot clear a box

Cisco's test is one command on the appliance, grep "System Security" system_logs. It returns one of three messages: a suspected compromise indicator, a scan that did not complete, or no indicator found. Cisco says to run it on every member of a cluster ^[7]. The Hacker News reports that a clean result is not proof, because an attacker with root could remove or hide evidence, and that operators should also check firewall and network logs outside the device for unexpected uploads to external IP addresses or downloads from malicious ones ^[8]. The advisory does not say what the scan looks for, how many devices were attacked, or whether attackers got root on any of them ^[9][4].

Order matters. For a virtual appliance that shows signs of compromise, Cisco's guidance is a rebuild with new credentials, and it warns that upgrading a compromised instance destroys the forensic data and logs. There is no workaround ^[10]. In our view the check has to run before any upgrade, since the upgrade removes the logs the check reads ^[7][10].

Patch status is harder to read than it looks. The AsyncOS fix has been shipping since September 14 in 15.5.5-014 and 16.5.0-780, builds from a hardening release that Cisco now says covered this flaw. A Content Scanner Tools update, version 25.3.0.5525 or later, installs without a software upgrade or a restart ^[3]. A 16.0 gateway on 16.0.4-302, the build that fixed September's SQL injection flaw, is not fixed for this one, because 16.0 has no fixed build. For a gateway that stays on 16.0, the scanner version shown by contentscannerstatus is the only confirmation the advisory offers ^[6].

Exposure takes two conditions: the File Reputation service enabled and assigned to a mail policy, and a Content Scanner Tools version earlier than 25.3.0.5525 ^[2]. The attacker needs no login, only an email with a crafted attachment sent through the gateway ^[1].

Administrators of Cisco's managed Secure Email Cloud gateways may lack the command-line access the check needs, and Cisco has already deployed the fixed scanner there. Cisco contacted customers whose devices showed "indicators of possible compromise" and says it is engaged in remediation and recovery ^[5].

Palo Alto: three addresses and no start date

CISA added CVE-2026-0322 and the Cisco flaw to its Known Exploited Vulnerabilities catalog and requires federal civilian agencies to prioritize fixes by October 17, 2026 ^[11]. Palo Alto Networks scores its flaw at CVSS 8.6 ^[12], below Cisco's 9.8 ^[1]. The gap in score is smaller than it looks in outcome, since both flaws end in root on the device ^[1][12].

The Palo Alto flaw sits in the PAN-OS management interface and needs an authenticated attacker with network access. No special configuration is required. It affects PA-Series and VM-Series firewalls and Panorama; Cloud NGFW and Prisma Access are not affected ^[12]. The vendor's own page lists severity High and suggested urgency Highest, and says the risk is greatest when the management interface is reachable from external IP addresses ^[13].

The hunting material is thin. Palo Alto Networks said it has seen "very limited exploitation" and did not elaborate on the nature of the activity, who is behind it, or when it began ^[14]. It published three addresses geolocated to the U.S. and assessed as linked to exploit attempts: 66.42.72[.]14, 208.83.239[.]114 and 149.248.47[.]234 ^[15]. Without a start date there is no stated point to search back to. The flaw needs a login, so we'd expect a useful lookback to cover successful authentications to the management interface as well as traffic from those three addresses.

Signature coverage is partial by the vendor's own account. Threat IDs 510046 and 510047 give limited coverage and need SSL decryption ^[16]. Palo Alto's FAQ explains the limit: "while known attack patterns can be identified using the current Threat ID, variations may exist that cannot currently be detected." ^[17] No known workarounds exist ^[18]. The mitigation is to cut exposure. "You can reduce the risk of exploitation by restricting access to a jump box that is the only system allowed to access the management interface," Palo Alto Networks said ^[19].

What an intruder keeps after the entry is closed

Unit 42's Fortinet report shows the case where the stolen material outlasts the patch. Unit 42 investigated an intrusion against a telecommunications organization in September 2024 that began with CVE-2024-47575 against a central FortiManager appliance ^[34]. From that appliance the attackers exfiltrated an archive holding running configurations for more than 500 managed FortiGate firewalls, ciphertext credentials, and encoded cryptographic trust material that included private keys ^[35]. Patching the FortiManager afterwards would not change what was already in that archive.

The attackers also exploited CVE-2025-61624 to deploy PEERSTITCH, a memory-resident ARM64 malware. It leaves no persistent binary on disk, opens no listening ports and starts no outbound connections. It communicates through traffic generated by legitimate processes on the infected host, and Unit 42 says that makes it resistant to conventional endpoint and network detection ^[36].

The sources on the Cisco, Palo Alto and Nextcloud flaws describe no implant of that kind. Unit 42 examined only the provider's environment. It did not examine the client networks whose firewalls the provider managed, and it says the exposure it describes there is configuration and credential material, not confirmed intrusion ^[37].