Researchers at Horizon3.ai have published a working proof-of-concept for CVE-2026-106173, a critical flaw that lets an unauthenticated attacker run code on Fortinet FortiSIEM 7.5.0. Fortinet issued the fix on 13 October, but now that exploit code is out, any unpatched SIEM reachable on TCP port 27918 is a target.
What happened
On 13 October 2026 Fortinet published advisory FG-IR-26-180. It describes a path traversal weakness (CWE-22) in FortiSIEM which, according to Fortinet, could let an attacker with no credentials run code or commands of their choosing by sending specially crafted packets. Fortinet rates the bug critical, with a CVSS v3.1 score of 9.4. Gwendal Guégniaud of Fortinet’s own product security team found it internally. When the advisory was published, Fortinet said the flaw was not known to be exploited, and there was no public exploit.
That changed on 20 October. Horizon3.ai published a technical deep dive and released proof-of-concept code on GitHub. Its chief attack engineer, Zach Hanley, wrote it up. Horizon3.ai knows FortiSIEM well: it has disclosed several earlier critical FortiSIEM bugs, including CVE-2023-34992, CVE-2024-23108 and CVE-2025-64155. All of those sat in the phMonitor service on TCP port 7900. This one is in a different component the firm says it had never examined.
The flaw was patched in the same Fortinet release that fixed 13 vulnerabilities across eight product lines, according to SecurityOnline. SecurityOnline says the other critical bug in that batch is an authentication bypass in FortiSandbox.
The affected release is narrow. Only FortiSIEM 7.5.0 is listed as vulnerable. The fix is 7.5.1 or later, and neither FortiSIEM 7.6 nor FortiSIEM Cloud is affected. Fortinet also gives a workaround: restricting access to TCP port 27918 prevents the issue.
The technical picture
The vulnerable code is in phQueryMaster, which runs a gRPC server on port 27918. According to Horizon3.ai, the service binds to every interface and doesn’t ask connecting clients for a certificate. Anyone who can reach the port can talk to it without logging in.
One of the remote procedures the service exposes, SendQueryResult, accepts streamed data and writes it to disk. It builds the destination path by string concatenation from values the client supplies, chiefly a “query-id” field, and doesn’t validate them. Directory traversal sequences let a caller choose where the file lands. The server then adds its own fixed file name to the end.
The second weakness gets around that. The server copies header values at whatever length the client declares, so a null byte can be placed in the middle of the query-id. When the path reaches the operating system, everything after the null byte is ignored, including the server’s own suffix. The attacker then controls the full file path. Horizon3.ai shows the primitive being used to overwrite a health-check script for the Redis service, which cron runs every 60 seconds. Once that script is replaced, the attacker gets code execution on the appliance within about a minute. Horizon3.ai also describes a two-request variant that creates a brand-new file with a chosen name.
The detection news is not good. Horizon3.ai said it found no application logs that clearly show exploitation. It suggests comparing modification times of recurring scripts against neighbouring files.
Why it matters for UK organisations
FortiSIEM isn’t a niche product. Fortinet kit is common in UK networks, and some smaller UK firms get their security monitoring from an MSSP that may run FortiSIEM on their behalf. A SIEM sits in a privileged position. It collects logs from domain controllers, firewalls, cloud tenants and endpoints, and it usually stores credentials or API keys so it can pull that data. If an attacker controls the SIEM, they can see what the defenders see, they may be able to reach every system feeding it, and they can quietly change or suppress the alerts meant to catch them.
Fortinet products are also a well-worn target: its edge and security appliances have featured in many past attack campaigns, often soon after patches and technical write-ups appeared. With a published root-cause analysis and working exploit code, an attacker doesn’t need much skill to adapt this one, even though no exploitation has been reported yet.
There is a compliance angle too. Cyber Essentials requires updates that fix high or critical vulnerabilities to be applied within 14 days of the update being released, and that clock runs from Fortinet’s release of 7.5.1 on 13 October, not from the publication of the exploit. Organisations certified or working towards certification should therefore have 7.5.1 in place by 27 October at the latest. The public exploit makes that deadline look generous.
Expert view
The version scope is the first thing to check. Only 7.5.0 is affected, so plenty of estates will turn out to be on an older or newer branch and can stop worrying.
The bigger lesson is about exposure. In my experience, security tooling is often the least segmented part of a network. SIEM collectors, log forwarders and management consoles end up on flat management VLANs, sometimes reachable from user subnets or a partner VPN, because “it’s the security box, it’s trusted”. When we test internal networks, monitoring platforms come up regularly as easy, high-value pivot points. A gRPC service listening on all interfaces with no client authentication is exactly the sort of thing a scoping exercise misses, because nobody remembers it is there.
Fortinet’s workaround is sensible, but it only helps if you know which hosts actually need to reach port 27918. If you can’t answer that from your firewall rule base in a few minutes, that is a finding in its own right.
Finally, don’t assume patching closes the case. The exploit can overwrite files in place while keeping their original owner and permissions, and exploitation may leave no clear trace in application logs. A box that sat unpatched and reachable since 13 October deserves a proper look before you trust its alerts again.
What to do now
- Identify your version. Confirm which FortiSIEM release you run, including any instances operated for you by an MSSP.
- Patch 7.5.0 to 7.5.1 or later. This falls under the Cyber Essentials security update management control, with a 14-day window that started when the fix was released on 13 October and ends on 27 October.
- Restrict TCP port 27918. Until you’ve upgraded, allow only the specific hosts that need the gRPC service and block it everywhere else, in line with the Cyber Essentials firewall control.
- Check for tampering. Review the modification times of cron-driven scripts on the appliance, including the Redis health-check script, and investigate anything that doesn’t match the surrounding files.
- Rotate secrets held by the SIEM if you find signs of compromise. That includes service accounts, API keys and collector credentials used to pull logs.
- Segment security tooling. Treat SIEM, logging and management platforms as tier-zero assets on restricted management networks that user and partner segments can’t reach.
Bottom line
CVE-2026-106173 is easy to fix. It affects a single release, a patch exists and the workaround is a firewall rule. The public exploit removes any reason to wait. Upgrade FortiSIEM 7.5.0 today, lock down port 27918, and check that the system watching your network hasn’t itself been altered.
Sources
- Fortinet PSIRT: FG-IR-26-180 Arbitrary file write in grpc phQueryMaster
- Horizon3.ai: CVE-2026-106173 Deep-Dive: FortiSIEM gRPC Path Traversal File Write RCE
- The Hacker News: Critical FortiSIEM Flaw Gets Public Exploit PoC for Unauthenticated Remote Code Execution
- SecurityOnline: Fortinet Patches Critical FortiSandbox and FortiSIEM Flaws Among 13 Vulnerabilities
