CISA KEV Adds Plex2Shell RCE, Siemens DLL Sideloading and SiteGuard Command Injection

The six products are very different from each other. Even so, all three vendors' stories come back to the same problem: software that already had a fix was still left unpatched.

The six additions​

CISA's alert describes each entry this way:

CISA's alert does not give affected version ranges or per-CVE exploitation details. The vendors and outside researchers do, and that information is covered below.

Quick summary: four of the six CVEs belong to a single Plex attack chain. The other two are separate vendor incidents, each with a confirmed fix.

Plex2Shell: four CVEs, one attack chain​

The four Plex entries are not four separate campaigns. Researchers combine them into one exploit chain called "Plex2Shell." In a Plex2Shell write-up, the researcher Main explains that four CVEs that, linked together, give an attacker unauthenticated remote code execution on a Plex Media Server.

The chain works in three main steps:

• It starts with SSRF. According to the Plex2Shell repository, the chain starts with server-side request forgery, which tricks Plex into sending requests chosen by an attacker. The Hacker News reports that CVE-2026-96652 abuses the "/player/timeline" endpoint, where a "protocol" parameter is inserted into a player URL without validation. That lets an attacker force the Plex server to POST to a destination of their choice.
• It steals a token. The chain first steals the server owner's admin token. With that token in hand, the attacker runs commands on the host as the Plex service user.
• It ends with code execution. The final stage abuses the loading of an unsigned codec to execute code.

Sources disagree on one detail. SentinelOne's vulnerability entry says that, for CVE-2026-96652 by itself, an attacker authenticated with any valid X-Plex-Token value can coerce the Plex server to issue HTTP POST requests to arbitrary destinations. The Hacker News calls the same SSRF unauthenticated. Daily Security Review reports that the full chain gets around this question: because the first step captures a credential instead of requiring one, the attacker never needs an account on the target server.

Timeline: patched in September, exploited in October​

According to Daily Security Review, Main reported the bugs to Plex in July. On September 1, Plex warned users running versions 1.43.2 and earlier. Main then published the write-up and proof-of-concept code on October 16, and the first exploitation appeared in the honeypot the next day.

That makes about six weeks between the Plex advisory and attacks in the wild, and roughly one day between the public exploit and the first attack.

The observed payloads are typical of opportunistic attacks. Exploitation seen from October 17 onward involved a Docker-based cryptominer (xmrig) and later a proxy tool called myawesomeproxy. The proxy tool routes traffic through the victim's home IP. A hijacked home server can therefore end up carrying someone else's malicious traffic. That costs you more than electricity.

Which Plex version fixes it?​

Most reporting names 1.43.3.10861 as the fixed build. SentinelOne lists the affected products as Plex Media Server versions prior to 1.43.3.10861. CybersecurityNews notes a small discrepancy: the repository identifies versions before 1.43.3.10828 as vulnerable and lists 1.43.3.10861 as fixed. If you are on 1.43.3.10861 or later, you are past both numbers.

Windows users should not assume this is only a Linux problem. Although the exploit supports Linux and Windows targets, the reported honeypot activity involved a Linux-based Plex deployment running in Docker.

The exposure numbers vary widely by source. One trending summary claims hundreds of thousands of servers still exposed worldwide. Another post cites one report earlier in September counted more than 36,000 Plex servers exposed to the internet. Neither number is confirmed here. Either way, there are plenty of targets.

Plex checklist​

1. Check your version. In the Plex web app, open Settings and look at the server's version under its general information. You need 1.43.3.10861 or later.
2. Update and restart. Then confirm the new version is actually running.
3. Look for signs of compromise. A community tool for checking for compromise recommends that if something turns up, you copy Logs/, Preferences.xml and the flagged files somewhere safe. After that, stop Plex, kill the flagged processes, delete the planted .so files (or the whole Codecs/ dir, which Plex re-downloads), and remove TranscoderH264Options from Preferences.xml. That tool is written for Linux paths, but the idea applies anywhere: look for unexpected codec files and odd transcoder settings.
4. Assume the admin token is compromised if the server was exposed and unpatched after October 16. Sign out of all devices and change the Plex account password.
5. Rethink exposure. Does your media server really need to be reachable from the whole internet?

Quick summary: the four Plex CVEs are one RCE chain. A fix has been available since September, attacks started October 17, and Windows hosts are within the exploit's reach.

Siemens Software Center: a signed program used as a loader​

CVE-2026-110936 is the entry most directly aimed at Windows PCs. In an October 19 notice, Siemens ProductCERT confirmed active exploitation of what it calls a DLL side-loading vulnerability. Siemens says it fixed the issue in version 4.0.9.8, published advisory SSA-580366 on October 15, and that existing installations update automatically the next time they start.

According to Siemens, the attackers did not modify Siemens' program. They paired a genuine, validly signed copy of Siemens Software Center with their own malicious DLLs in the same folder. Version 3.5.8.7, the latest at the time, loaded helper files from its own folder without checking them. Siemens attributes the activity to a "Romulus multi-platform ClickFix campaign." It also says it knows of no breach of its own systems, products or update channel. Those attribution and incident details come from Siemens and have not been independently confirmed.

Warning signs Siemens lists:

• "Siemens Software Center" in startup apps or Task Scheduler on a PC that never had it installed
• A SM Software Provisioning Service folder under AppData\Local\Programs
• activate.bak or statinfosta.DB sitting next to SiemensSoftwareCenter.exe
• An FTSuite folder containing ftc.uml under AppData\Local
• Network connections to 96.62.218[.]59

What Siemens tells defenders to do:

• Block 96.62.218[.]59, wizardexpensive[.]com and 2.27.248[.]127. The last one, an inactive distribution point for AllMyBasic.msi, is still worth searching for in logs, because machines that downloaded from it may still be infected.
• Look for SiemensSoftwareCenter.exe running from AppData\Local\Programs and launched by msiexec.
• If you find it, isolate the PC, stop the process first, remove the startup entry and scheduled task, then reset passwords.
• Detect on folder location and behavior, not on the file's hash. The executable is genuine, so allowlisting by signature or fingerprint will treat it as legitimate.

Siemens also gives SHA-256 hashes for the malicious files: AllMyBasic.msi (f4d7c5321bb0d1bda439304a753bcf9b467b98ca53c7e9493b9c2c3451092e4a) and archive.dll (3fdcc7d7d049a89711fb31fb236940a1c5a09d899143ffd20c3c41fb1f2cf491).

Its advice to ordinary users is simple: never paste a command from a web page into Win+R, the Run box or PowerShell. A real "I am not a robot" check never asks you to do that.

Quick summary: update to 4.0.9.8 or later, hunt by file path and parent process rather than by hash, and remind users that a real CAPTCHA never asks them to run a command.

SiteGuard Server Edition: save evidence before you patch​

CVE-2026-106931 is an OS command-injection flaw in the statistics function of SiteGuard Server Edition, a web application firewall from Japan. In its October 14 advisory, EG Secure Solutions confirms the flaw is being exploited. It affects customers running version 2.20 or later with statistics enabled, and statistics is enabled by default. A successful attack can run arbitrary OS commands as root or SYSTEM. The vendor scores it CVSS 4.0 8.5 and CVSS 3.0 7.8.

Affected and fixed builds:

There is one exception: IIS versions 3.10 through 4.00 Update 4 are not affected. For customers who cannot upgrade, the vendor offers a patch that replaces the files used by the statistics function, including for some versions that are no longer supported. Customers with support contracts were notified on September 29.

The order of steps matters here. EG Secure warns that updating or patching may erase traces of an attack. Before you remediate, download and keep the diagnostic information from the web console (Diagnostic Information → Download Diagnostic Information). Patching first could wipe out the evidence you need to tell whether the server was already compromised.

Quick summary: save diagnostics first, then patch. Windows admins running the IIS edition should check which version range they are in.

What BOD 26-04 means for everyone else​

CISA's alert says Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," sets vulnerability-management requirements for Federal Civilian Executive Branch agencies. It requires agencies to prioritize rapid remediation of KEV-listed CVEs on publicly exposed assets where exploitation gives the attacker full control of the asset, while lower-risk vulnerabilities can wait. It also sets expectations for when agencies must check whether a system was compromised before it was patched. The directive is binding only on those federal agencies, but CISA encourages all organizations to prioritize KEV entries.

Those two ideas, "publicly exposed" and "check for prior compromise," apply directly to this batch. Exposed Plex servers, internet-facing SiteGuard servers, and PCs running a trojanized copy of Siemens' signed program all belong to the "patch it, then investigate it" category.

From a practitioner's point of view, a KEV listing tells you a flaw is being exploited. It is not a remediation plan. You still need to:

1. Search your asset inventory for each product (unofficial home Plex servers on the corporate network count).
2. Confirm exact versions against each vendor's guidance.
3. Patch, while preserving evidence where the vendor asks you to.
4. Hunt for the published indicators covering the period before you patched.

Plex was patched on September 1 and attacked on October 17. Siemens shipped its fix days before publishing indicators. EG Secure told its contract customers two weeks before its public alert. In all three cases the fix existed before it was widely deployed.