#activeexploitation

Read Time:4 Minute, 6 Second

Researchers at Zscaler ThreatLabz have documented an active exploitation campaign against a critical, already-patched vulnerability in Citrix NetScaler ADC and NetScaler Gateway appliances, using a multi-stage technique that turns ordinary-looking web traffic into full remote code execution on devices that sit directly at the edge of corporate networks.

The vulnerability, tracked as CVE-2026-88771, allows an unauthenticated attacker to execute commands remotely. Citrix disclosed the flaw on September 27, 2026, and has since confirmed that appliances left unpatched since then are being actively targeted. The issue carries a severity rating of 9.8 under CVSS v3.1 and 9.5 under CVSS v4.0 — squarely in critical territory.

A Patient, Staged Attack ChainWhat makes this campaign notable isn’t just the severity score — it’s the care attackers took to avoid triggering an obvious, single-request exploit. According to Zscaler’s technical analysis, the attack unfolds in deliberate stages rather than one smash-and-grab request.

First, attackers send requests to common NetScaler web paths carrying a distinctive “INDEX:” marker along with encoded content hidden in the User-Agent header. On their own, these requests don’t execute anything — their purpose is simply to get attacker-controlled text written into the appliance’s web access logs, seeding the payload for later.

Once that groundwork is in place, the attackers send a second wave of authentication requests crafted to resemble an internal “Packet Processing Engine” failure message. A vulnerable Perl diagnostic script on the appliance later processes matching log entries — and because that script doesn’t safely handle attacker-controlled characters inside the forged failure message, any commands appended to the poisoned log entry can execute with the script’s own privileges. In effect, the exploit smuggles its real payload in two separate, innocuous-looking steps, which is precisely what makes it harder to catch with simple signature matching on a single request.

Web Shells and a FreeBSD ImplantOnce code execution is achieved, Zscaler observed the attackers attempting to create web-accessible files, enable PHP or Perl handling on the web server, and drop files named Nx_7508.php and Nx_7508.pl — classic web shell tooling designed to give attackers a persistent, remotely reachable foothold even if the original exploit path is later closed off.

In parallel, researchers saw attempts to download and execute a 64-bit FreeBSD binary named kw2-freebsd-x64-s11, giving the attackers a second, independent implant on the compromised appliance. Running two separate persistence mechanisms — a web shell and a native binary implant — is a hedge: even if defenders find and remove one, the other may survive.

Zscaler also noted that the infrastructure used to host the downloaded payloads has previously appeared in unrelated campaigns targeting Magento and Adobe Commerce installations via a different flaw (CVE-2026-75650, dubbed “StyleSmuggler”). The researchers are careful to frame this overlap as an investigative lead worth following, not confirmation that the same threat actor is behind both campaigns.

Why NetScaler Appliances Are a High-Value TargetNetScaler devices typically sit at the network edge, brokering remote access and application traffic for an entire organization — which makes a compromised appliance disproportionately valuable to an attacker compared with a single compromised workstation. A web shell buried on the device can provide a durable way back in long after the initial vulnerability is patched, which is why Zscaler stresses that patching alone will not undo an existing compromise.

Remediation StepsCitrix’s fixed builds, per the Zscaler report, are NetScaler ADC and Gateway 14.1-73.46 or later, and 13.1-64.29 or later, with corresponding FIPS builds at 14.1-73.46 FIPS or later and 13.1.37.283 or later for 13.1-FIPS and 13.1-NDcPP. Administrators should confirm the exact build applicable to their deployment before upgrading.

Because this campaign leaves artifacts behind even before a patch is applied, organizations should take the following steps rather than treating an update alone as sufficient remediation:

Preserve evidence before making changes — remote syslog data, technical support bundles, and any available core dumps.

Review authentication and web access logs for the telltale “INDEX:” User-Agent pattern, forged “pitboss PPE” failure messages, and unexpected appliance-initiated connections to unfamiliar external hosts.

Inspect the filesystem for unapproved web files and unexpected changes to web-server configuration.

If compromise is suspected, isolate the appliance while preserving forensic evidence, and rotate any credentials, tokens, or certificates the device had access to.

Apply the fixed NetScaler build promptly — but treat it as closing the door going forward, not as proof that any existing implant has been removed.

This is far from the first time NetScaler appliances have been targeted with web shells following a disclosed flaw, underscoring a recurring pattern in edge-device security: public disclosure of a critical vulnerability routinely triggers a race between defenders patching and attackers exploiting, and the window between the two is often measured in days, not weeks.

Read Time:3 Minute, 26 Second

Attackers are exploiting a critical command-injection vulnerability in the Collabora Online Built-in CODE Server app for Nextcloud, and compromised administrators have reported finding web shells on their servers. The flaw, tracked as CVE-2026-110447, can let a remote, unauthenticated attacker execute operating-system commands as the web server account.

The vulnerability affects versions of the richdocumentscode app earlier than 26.4.303 and carries a CVSS v4 score of 9.2. The GitHub Advisory Database records exploitation during September and October 2026, while an October 3 community warning described unexpected web shells discovered on affected Nextcloud systems. No public report has attributed the activity to a named group or established the total number of compromised servers.

A command injection in the built-in document serverThe vulnerable code is in proxy.php, which supports operation of Collabora’s bundled document server inside a Nextcloud deployment. A specially crafted request can cause the server to pass an attacker-controlled operating-system command for execution. The weakness is classified as CWE-78, the standard category for improper neutralization of commands.

No account or victim click is required, but exploitation has an important precondition: the built-in CODE server must not be running when the malicious request reaches the vulnerable path. That situation can occur during a container restart, an application upgrade or recovery after a crash. Routine operational transitions can therefore create the window an attacker needs.

Successful commands execute with the web server user’s privileges rather than automatically receiving root access. That limitation does not make the outcome harmless. The application account may be able to read or alter sensitive web content, access configuration material, disrupt the service or install a web shell that preserves remote command access after the initial exploit.

The affected scope is specific—but disabling is insufficientCVE-2026-110447 affects the Collabora Online Built-in CODE Server app, not every Nextcloud or Collabora installation. Standalone Collabora Online servers are outside the affected scope. The vulnerability also uses a different attack path from CVE-2025-66208, meaning the fix for that earlier issue does not protect against this one.

Administrators should upgrade richdocumentscode to version 26.4.303 or later. If upgrading is not possible, the vulnerable app should be removed. Simply disabling the app does not block exploitation. Organizations still running end-of-life Nextcloud 29 or earlier should upgrade the broader Nextcloud installation or remove the affected component.

Identify every internet-reachable Nextcloud instance and inventory its installed app version.

Upgrade to richdocumentscode 26.4.303 or newer, or fully remove the component.

Do not rely on toggling the app off as a compensating control.

Review web roots and writable directories for unexpected PHP files or recent modifications.

Preserve logs and suspicious artifacts before cleanup so investigators can reconstruct activity.

Patching does not remove an existing web shellBecause exploitation has already been observed, exposed organizations need to treat this as both a vulnerability-management and incident-response problem. Updating closes the known entry point, but it does not erase a payload already written to disk, revoke a stolen secret or undo changes made through a shell.

Responders should examine web-server access and error logs around restarts, upgrades and crashes; compare application files with known-good packages; inspect recently created or modified PHP files; and look for child processes or outbound connections launched by the web server account. Any confirmed compromise should trigger credential rotation for secrets accessible to that account and a broader assessment of lateral movement.

Teams should be cautious about restoring only the visibly altered file. A web shell is evidence that the attacker obtained a command channel, and additional persistence may exist elsewhere. Rebuilding from a trusted image may be safer than piecemeal cleanup when the integrity of the host cannot be established.

The narrow condition required for exploitation may sound reassuring, but internet-facing services restart frequently enough that determined scanning can catch the vulnerable state. With real-world exploitation and backdoors already reported, administrators should prioritize the fixed app version and complete a compromise review without waiting for more detailed attribution.

Read Time:3 Minute, 18 Second

Attackers have moved from probing to successful compromise of vulnerable Plex Media Server installations, using a recently published exploit chain to deploy cryptocurrency-mining malware. The activity was captured against a research honeypot on October 17, providing direct evidence that exposed servers are being targeted in the wild.

The attacks center on Plex2Shell, a public proof-of-concept that links four security flaws into an unauthenticated remote-code-execution path. Once access is gained, the intruders download additional programs, including the widely abused XMRig miner. Follow-up observations also found a bandwidth-sharing proxy process, suggesting compromised systems may be monetized in more than one way.

Four flaws combine into one serious attack pathPlex2Shell is significant because it does not rely on a single mistake. The chain combines CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656. It begins with server-side request forgery, allowing a remote attacker to make the Plex server send crafted internal requests.

Those requests can reach internal functionality, obtain owner-authorized behavior, and write a file to a location selected by the attacker. The last step abuses Plex’s handling of an unsigned codec to load attacker-controlled code. No valid user login is needed when the full chain succeeds.

The public exploit documentation identifies Plex Media Server releases before 1.43.3.10828 as vulnerable and lists 1.43.3.10861 as the corrected build. Although the technique supports both Windows and Linux, the observed attacks hit a Linux Plex deployment running in Docker. NAS users deserve particular attention because Plex has warned that some appliances require manual updates.

Honeypot records mining and proxy payloadsThe researcher first saw exploitation traffic from 45.194.92[.]222, with later attempts associated with 91.92.40[.]202 and 176.65.139[.]228. Requests reached the /player/timeline/subscribe endpoint and referenced internal Plex services through an sslip.io hostname. The traffic also used a Python urllib user agent, a detail defenders may find useful when reviewing logs.

After the test environment was allowed to communicate outbound, it retrieved files from 217.60.194[.]116. Analysis of packed and unpacked samples led to an XMRig cryptocurrency miner. The compromise therefore consumes processor resources, raises operating costs, and may degrade media-server performance even if the attacker does not immediately pursue data theft.

A later update revealed a process named myawesomeproxy and traffic tied to proxystream[.]st. Such software can resell a victim’s internet connection as a residential proxy. That creates a second risk: malicious or abusive traffic may appear to originate from the victim’s public IP address. The evidence does not yet identify the campaign operator or connect it conclusively to a named botnet.

What Plex administrators should do nowOrganizations and home users should treat any internet-accessible, unpatched Plex server as potentially exposed. Updating is the priority, but a patch alone cannot remove malware that arrived before the upgrade. Administrators should combine remediation with a focused compromise review.

Install the latest Plex Media Server release and confirm the version actually running.

Check NAS appliances and containers for images or packages that did not update automatically.

Review the Plex process tree for unfamiliar child processes, miners, proxy clients, and download tools.

Search network telemetry for the reported IP addresses, unusual DNS lookups, and sustained outbound connections.

Rebuild a compromised container from a trusted image and rotate credentials or tokens it could access.

Published packet captures can help defenders develop behavioral detections, but fixed indicators should not be the only line of defense. Attackers can rapidly replace domains, ports, filenames, and hosting infrastructure. Alerts for Plex spawning shells or download utilities, unexpected codec files, abnormal CPU usage, and new proxy processes are more durable.

The campaign is another reminder that a media server can become an attractive foothold when it is reachable from the internet. Plex users should reduce unnecessary exposure, keep deployments current, and investigate rather than merely rebooting when unexplained resource spikes appear.

Read Time:3 Minute, 27 Second

Palo Alto Networks has disclosed an actively exploited PAN-OS vulnerability that can give a privileged attacker root-level code execution on affected firewalls. The flaw, tracked as CVE-2026-0322, targets the management interface and has received a CVSS 4.0 score of 8.6. The company describes observed exploitation as very limited, but has assigned its highest remediation urgency and advises customers to upgrade without delay.

The disclosure matters because a firewall is a central enforcement point for network traffic. Root access to the appliance can give an intruder exceptional visibility and control, potentially allowing configuration changes, persistence, or interference with security monitoring. Palo Alto Networks has not attributed the activity or said how many organizations were targeted.

How the PAN-OS flaw worksCVE-2026-0322 is a code-injection weakness classified as CWE-94. Exploitation requires network access to the PAN-OS management interface as well as an authenticated account with high privileges. A successful attacker can execute code as root without further user interaction.

Those prerequisites make this different from an unauthenticated internet-wide compromise. However, they do not make the issue harmless. Stolen administrator credentials, an insider, or an attacker who has already established a foothold could use the bug to turn limited access into full control of a security appliance. Internet-exposed management interfaces face the clearest risk.

Affected platforms include PA-Series hardware firewalls, VM-Series virtual firewalls, and Panorama on virtual systems or M-Series appliances. Palo Alto Networks says Cloud NGFW and Prisma Access are not affected. No unusual configuration is required for a vulnerable installation to be exposed to the weakness.

Fixed releases and affected branchesCustomers should consult the vendor advisory for the exact upgrade path for their branch. Fixed releases identified by Palo Alto Networks include:

PAN-OS 12.2.4;

PAN-OS 12.1.10-h2;

PAN-OS 11.1.16-h3;

PAN-OS 10.2.18-h12;

selected 11.2 hotfixes, including 11.2.4-h22, 11.2.7-h21, 11.2.10-h15, and 11.2.13-h3.

The vendor says there is no workaround that eliminates the flaw. Restricting the management interface to trusted internal addresses and reaching it through a hardened jump host can reduce exposure, but those controls are not substitutes for installing a corrected build.

Before upgrading, operators should back up the current configuration and follow the normal high-availability sequence so paired devices do not lose protection at the same time. Afterward, verify the reported software version, confirm that policy synchronization and traffic processing are healthy, and record the change in the asset inventory. Any appliance that cannot be patched immediately should have management access reduced to the narrowest possible set of source addresses and monitored continuously until remediation is complete.

What defenders should investigatePalo Alto Networks linked three IP addresses to threat activity and limited exploit attempts: 66[.]42[.]72[.]14, 208[.]83[.]239[.]114, and 149[.]248[.]47[.]234. Security teams should search firewall management and upstream network logs for connections involving those addresses, while remembering that attackers can change infrastructure and that an indicator match is not required for compromise.

Defenders should also review administrator logins, unexpected configuration changes, newly created accounts, unusual processes, and management traffic from hosts that do not normally administer the appliance. Where possible, compare local evidence with independent logging because an attacker operating as root may be able to alter records on the device.

Priorities for firewall ownersOrganizations should inventory every physical firewall, virtual instance, and Panorama deployment, including disaster-recovery and lab systems that may still be reachable. Confirm the running version rather than relying on asset records, then apply the vendor-recommended fixed release. Management access should be limited to a small group of dedicated administrative systems protected with strong authentication.

Finally, teams should treat patching and compromise assessment as parallel tasks. Installing an update closes the known route but does not prove that earlier exploitation did not occur. Because the vulnerable component protects the network itself, any suspicious evidence deserves a broader incident-response review of credentials, configurations, and traffic that passed through the device.

Read Time:3 Minute, 18 Second

Cisco is warning customers that attackers are actively exploiting a critical zero-day in Secure Email Gateway appliances. Tracked as CVE-2026-76519, the vulnerability can be triggered by a specially prepared email attachment and may allow an unauthenticated attacker to write arbitrary files and execute commands with root privileges.

The flaw carries a CVSS score of 9.8. Cisco says its security response team learned of exploitation in October 2026, but public information does not identify the attackers or quantify the number of compromised systems. The combination of remote access, no login requirement, and root-level impact makes the issue an urgent operational and incident-response concern.

A malicious attachment can reach the applianceThe weakness is located in the Advanced Malware Protection feature, commonly called AMP. When File Reputation is enabled, affected software does not safely process certain email attachments. An attacker can send a crafted file through the gateway, causing the appliance to write data in an unsafe manner and potentially run commands as root.

The attack path is notable because it does not depend on a recipient opening the attachment or clicking a link. Processing by the gateway itself is the entry point. Root access gives an adversary control over the underlying operating system and may allow evidence to be hidden or deleted.

Both physical and virtual Secure Email Gateway appliances are affected only when two conditions are present: File Reputation is enabled and assigned to a mail policy, and the Content Scanner Tools package is older than 25.3.0.5525. Cisco Secure Email and Web Manager and Secure Web Appliance are not affected by this vulnerability.

Updates are available without a restartCisco lists AsyncOS 15.5.5-014 and 16.5.0-780 as corrected releases. Customers on the 16.0 branch should migrate to a fixed version, and Cisco recommends that installations older than 16.5 move to 16.5.0-780.

Supported, licensed AsyncOS systems can also receive the fix through Content Scanner Tools package 25.3.0.5525 or later. This package update does not require a complete AsyncOS upgrade or an appliance restart. Administrators who disabled automatic updates can request the package with the contentscannerupdate command and should verify the installed version afterward.

There is no workaround. Automatic updating may already have delivered the corrected scanner, but organizations should confirm that result instead of assuming it. Cisco says the fix has been deployed to Secure Email Cloud Gateway, so customers of that hosted service do not need to install it themselves.

Checking for signs of compromiseAdministrators can review incoming and outgoing mail policies to determine whether File Reputation is active. The contentscannerstatus command reports the installed Content Scanner Tools version. Cisco also recommends searching system logs for “System Security” events and checking every member of an appliance cluster.

A message indicating suspected compromise should trigger incident response. An incomplete security scan should be escalated to Cisco’s Technical Assistance Center. Importantly, a clean scan cannot conclusively rule out an intrusion because attackers with root control may remove local traces.

Independent telemetry is therefore essential. Network and firewall logs should be reviewed for unexpected uploads from the gateway, downloads from unfamiliar infrastructure, abnormal outbound connections, and administrative activity that does not match normal operations. Evidence should be preserved before rebuilding or making extensive changes.

Patch and investigation must happen togetherSecurity teams should identify every gateway, validate its configuration and scanner package, and update vulnerable systems immediately. They should also assess the period before remediation, because applying the package prevents future use of the known flaw but does not establish whether a system was already accessed.

Email security appliances occupy a trusted position and process untrusted data continuously. That makes this zero-day especially serious: the defensive control becomes the attack surface. Organizations finding suspicious artifacts should involve Cisco TAC and their incident-response team, rotate exposed administrative credentials, and validate the appliance before returning it to normal service.