CRITICAL: Fortinet FortiSIEM CVE-2026-106173 Gets Public RCE Exploit

There is a special kind of irony in the security tool becoming the security problem, and Fortinet keeps finding new ways to serve it. This week the target is FortiSIEM, the platform that is supposed to be watching everything else on your network. Horizon3.ai published a working proof of concept on October 20 for CVE-2026-106173, a critical path traversal flaw that lets an unauthenticated attacker write arbitrary files to a FortiSIEM appliance and turn that write into remote code execution within about a minute. Fortinet patched it on October 13, so the fix has been sitting there for a week. The difference now is that anyone with a terminal and a GitHub account can exploit it.

If you run FortiSIEM 7.5.0, stop reading after this paragraph and go patch. Then come back for the details.

What Fortinet Disclosed

Fortinet published advisory FG-IR-26-180 on October 13, 2026 under the plain title "Arbitrary file write in grpc phQueryMaster." The company rates the flaw at CVSS 9.4 and classifies it as CWE-22, improper limitation of a pathname to a restricted directory. The NVD entry currently shows a base score of 9.8, which is the raw base score supplied by Fortinet as the CNA, while the 9.4 figure in the advisory factors in temporal metrics. Either way, you are looking at a critical rating, and either way, no credentials are required.

According to the advisory, FortiSIEM 7.5.0 is vulnerable and the fix is in version 7.5.1 or later. FortiSIEM 7.6 and the FortiSIEM Cloud service are listed as not affected. Fortinet credits the discovery to Gwendal Guégniaud of its own Product Security team, so this is one of those cases where the vendor found its own bug and fixed it quietly, right up until an outside research shop reversed the patch and published the recipe.

There is one wrinkle worth flagging. The CVE record itself lists a broader range, covering FortiSIEM 7.0.0 through 7.4.2, and recommends that those older branches move to 7.6.0 or above. The advisory table only mentions 7.5. Fortinet has not explained the mismatch, and until it does, I would treat any FortiSIEM 7.x deployment that is not already on 7.6 as potentially exposed. Assuming you are safe because your version number is not on a table is how incident reports get written.

How the Exploit Works

The vulnerable component is phQueryMaster, which exposes a gRPC service on TCP port 27918. Horizon3.ai researcher Zach Hanley found that the service happily accepts connections without requiring a client certificate. In other words, the mutual TLS that you might assume protects internal SIEM plumbing simply is not enforced, and any client that can reach the port can talk to it.

The bug lives in the SendQueryResult RPC. When the service receives a query result, it builds a file path by dropping an attacker supplied query identifier straight into a directory string under the query results folder. There is no validation. Feed it traversal sequences and the write escapes the intended directory and lands wherever you point it. Horizon3 summed it up bluntly, noting that the FortiSIEM gRPC QueryResultReq handler "processes untrusted metadata without proper path validation."

The service does try to append its own result suffix to the filename, which would normally make overwriting a specific system file awkward. The attacker gets around that with the oldest trick in the book. A null byte embedded in the query identifier truncates the path at the operating system level, the suffix vanishes, and the write hits the exact file the attacker named. Even better for the attacker, the overwritten file keeps its original owner and permissions, so nothing looks obviously out of place from a quick directory listing.

From there, code execution is almost boring. Horizon3's proof of concept overwrites /opt/charting/redishb.sh, a Redis health check script that a cron job executes every 60 seconds. Replace the script, wait a minute, and your payload runs with whatever privileges that cron job enjoys. No user interaction, no login, no phishing email, no clever social engineering. Just a reachable port and a few crafted packets.

Exploitation Status and Why It Matters

As of this writing, Fortinet says it is not aware of exploitation in the wild, and CVE-2026-106173 is not in the CISA Known Exploited Vulnerabilities catalog. That is the good news, and I would not get comfortable with it.

Consider the track record. When Hanley published his previous FortiSIEM research on CVE-2025-64155 back in January, exploitation attempts showed up in the wild within days. Fortinet products are a perennial favorite for both ransomware affiliates and state sponsored groups, and anyone paying attention to this past month has watched Fortinet gear get hammered repeatedly. A fully weaponized, publicly documented, unauthenticated RCE against a SIEM is the kind of gift attackers do not leave unopened for long.

There is also the matter of what a SIEM actually is. FortiSIEM ingests logs from firewalls, domain controllers, endpoints, cloud tenants, and just about everything else in the environment. It frequently holds service account credentials so it can poll devices, and it often sits in a privileged network segment with reach into places most systems cannot touch. Compromising it gives an attacker a map of the network, a stash of credentials, and the ability to tamper with the very telemetry defenders rely on to spot an intrusion. If you wanted to blind a security team before deploying ransomware, owning the SIEM is a remarkably efficient way to do it.

Horizon3 also noted that it found no application logs that clearly record the attack. So the system designed to tell you when something bad happens will not necessarily tell you when something bad happens to it. Let that one sink in.

Who Is Exposed

The organizations at greatest risk are those running FortiSIEM 7.5.0 with port 27918 reachable from anything other than tightly controlled management hosts. That port should never be exposed to the internet, but experience says some of them are, and internet scanning services will have them catalogued by lunchtime. Internal exposure matters just as much. An attacker who already has a foothold on a workstation through a phishing payload or a compromised VPN account can pivot to the SIEM if the network is flat, and plenty of networks are flatter than anyone wants to admit.

Managed service providers deserve a specific mention here. MSPs and MSSPs that operate FortiSIEM in multi tenant arrangements are effectively holding a key ring for every client feeding logs into the platform. A single compromised collector or supervisor node in that model is not one breach. It is a supply chain incident with your name on it.

What To Do Right Now

The fix is straightforward. Upgrade FortiSIEM 7.5.0 to version 7.5.1 or later. If you are on any older 7.x branch, plan a move to 7.6.0 or later given the CVE record's broader version range, and do not wait for Fortinet to clarify the discrepancy before you start scheduling it.

If you cannot patch today, Fortinet's own workaround is to restrict access to TCP port 27918 so that only the FortiSIEM components that genuinely need it can connect. Do this at the host firewall and at the network layer if you can. There is no FortiGuard IPS virtual patch for this one, so network segmentation is your only stopgap.

Detection is trickier because, as noted, the application does not log the attack in any useful way. Horizon3 recommends checking file modification timestamps on scripts that cron executes, specifically /opt/charting/redishb.sh and /opt/phoenix/bin/phLicenseTool. Look for files whose timestamps do not match their neighbors or that changed outside a known maintenance window. Compare the content of redishb.sh against a known good copy from a clean install of the same version. On the network side, review flow logs or firewall logs for any connections to port 27918 from hosts that are not part of your FortiSIEM cluster, especially anything that originated outside your management network. Also look for unexpected outbound connections from the FortiSIEM appliance itself, since a reverse shell or beacon from your SIEM to an unknown address is about as clear a signal as you are going to get.

If you find evidence of tampering, treat it as a full compromise. Rotate every credential FortiSIEM stores for device polling and integrations, assume the attacker has seen your log data and network topology, and review logs from other sources for gaps or anomalies during the window when the SIEM may have been under someone else's control. Rebuilding the appliance from a known good image is the safest path, since a patched but already backdoored system is still a backdoored system.

Finally, use this as a prompt to audit the exposure of every management and data plane port on your security appliances. FortiSIEM is far from the only product that assumes its internal services will only ever hear from friendly neighbors. Attackers know that, too.

The Bigger Picture

Fortinet deserves partial credit here. The company found the bug internally, shipped a fix, and published a clear workaround. That is how coordinated security is supposed to work. The gap between that patch and a public exploit was exactly one week, which is about how long many organizations take just to read the advisory, never mind schedule a maintenance window for the SIEM that nobody wants to touch because it took six months to tune.

That one week window is the new normal. Exploit developers and attackers alike now diff patches within hours, and the advisory itself is effectively a treasure map. If your patch cadence for security infrastructure is measured in months, the math no longer works in your favor. Treat the tools that watch your network with the same urgency you would treat an internet facing VPN, because to an attacker they are equally valuable and often far less defended.

MSP Angle

Every client running Fortinet security stack components is a natural conversation this week, and an exposure audit of security appliance management ports is an easy, high value assessment to offer while the headline is fresh. For clients running their own SIEM, this is also a strong opening to pitch a managed SOC or co managed SIEM service where patching, segmentation, and integrity monitoring of the platform itself are part of the contract rather than an afterthought.