Vulnerabilities
FortiSIEM CVE-2026-106173: public exploit, patch 7.5.0
A public exploit turns an unauthenticated FortiSIEM 7.5.0 file write on TCP 27918 into code execution. Fixed version, workaround and file checks.
Fortinet fixed a critical flaw in FortiSIEM, its security information and event management (SIEM) platform, on October 13. CVE-2026-106173 (advisory FG-IR-26-180) is a path traversal bug in the phQueryMaster service: anyone who can reach TCP port 27918 can write files on the appliance without logging in, and turn that into running their own commands. Fortinet scores it CVSS 9.4, while CSA Singapore and NVD-based trackers list 9.8. Only FortiSIEM 7.5.0 is affected; 7.6 and FortiSIEM Cloud are not.
On October 20, Horizon3.ai published a technical write-up and a working proof of concept on GitHub, so building an exploit no longer takes reverse engineering. Fortinet's advisory marks the flaw as not known to be exploited, and none of the reporting we checked, including CSA Singapore's alert of October 22, describes attacks so far. If you run 7.5.0, upgrade now rather than wait for that to change.
How it works
On 7.5.0, the phQueryMaster process, which handles query results, runs a gRPC server on TCP 27918, bound to all interfaces. gRPC is a remote procedure call protocol that runs over HTTP/2. According to Horizon3.ai, the server never asks the caller for a client certificate, so any host that can reach the port can call its methods.
The vulnerable method is SendQueryResult on the phoenixSvc service. It accepts a stream of QueryResultReq messages and saves their contents to disk, using values from the request headers to decide where. One of those values, query-id, is appended to the /query/result/ directory with no validation. Put ../ sequences in it and the write lands in any directory you choose; the handler even creates the directory if it is missing.
The server then appends its own file name, in the form result-<source IP>-<period start>-<period end>-<id>.dat, where the id is a counter the client cannot set. That would limit the bug to dropping .dat files. The catch is that the handler copies header values using the length the client declares, so a null byte inside query-id survives. When the path reaches the operating system, the null byte ends the string and the server's suffix is dropped. The file is written to the exact path that came before the null byte, with the streamed request bytes as its content.
Horizon3.ai's chain targets /opt/charting/redishb.sh, a Redis health check script that cron runs every 60 seconds. Overwriting an existing file keeps its owner and permissions, so the script still runs on schedule, now with the attacker's commands. Their proof of concept is blind: the operator sends one request and waits up to a minute for cron to fire. Common gRPC libraries and curl refuse null bytes in headers, which is why the researchers built the HTTP/2 frames by hand. The published proof of concept includes that frame-building code.
What attackers are doing
Nothing confirmed yet. Fortinet found the bug internally, credited to its own product security team, and lists it as not known to be exploited. CSA Singapore's alert notes the public proof of concept but does not report attacks, and the coverage from The Hacker News and Expert Insights says the same. CVE-2026-106173 was not in CISA's Known Exploited Vulnerabilities (KEV) catalog when we checked.
That only describes what has been reported. The public exploit is a single Python script that takes a target address and a command, so the effort needed to attack an exposed 7.5.0 node is now small.
What to do
1. Upgrade 7.5.0 to 7.5.1 or later
Fortinet's advisory lists one affected release, 7.5.0, and one fix: upgrade to 7.5.1 or above. Upgrade every node in the deployment, since each one that runs phQueryMaster exposes the port. FortiSIEM 7.6 and FortiSIEM Cloud need no action for this CVE.
2. If you cannot upgrade today
Fortinet's workaround is to restrict access to TCP port 27918, which the advisory says prevents the issue. Fortinet does not say which hosts need the port, so before you block, look at your firewall or flow logs for the systems that talk to FortiSIEM on 27918 today and allow only those FortiSIEM nodes. Check too that the port cannot be reached from user networks, guest networks or the internet. Expert Insights gives the same advice for systems that cannot be updated straight away.
3. Check whether you were already hit
Horizon3.ai says it found no application log entry that reveals exploitation, so the evidence is on the file system:
- Compare the modified time of
/opt/charting/redishb.shwith the files around it. A recent change that does not match an upgrade you did is a red flag.ls -l --time-style=full-iso /opt/charting/shows the times side by side. - Look for other scripts and binaries whose timestamps stand out from their neighbours, which is the broader check Horizon3.ai and Expert Insights both suggest.
- Read the current contents of
redishb.sh. It should be a short Redis health check, not a download or a reverse shell.
4. If something changed
Assume the SIEM is compromised. A SIEM holds the event history for your whole estate and, in most deployments, credentials to pull logs from servers, network devices and cloud accounts. Isolate the node, rebuild it on 7.5.1 or later, and rotate the credentials FortiSIEM uses for collection. Then review what the attacker could have read or altered in stored events while they had access, because a tampered SIEM can hide activity elsewhere.
The wider lesson
Node-to-node ports on security appliances are often left reachable from every subnet because only the product is expected to use them. Here that port accepted unauthenticated requests and wrote their contents to disk. Deployments that already allowed 27918 only between FortiSIEM nodes had a far smaller exposure on October 20. Keep a list of which hosts need each management and internal service port, and enforce it in the firewall when the appliance is installed.
Our attack surface management work finds exposed management and service ports like 27918 before attackers do, and our security operations team can help check a SIEM for signs of tampering. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.
Sources: Fortinet PSIRT advisory FG-IR-26-180, Horizon3.ai deep dive, Horizon3.ai proof of concept, CSA Singapore alert AL-2026-153, The Hacker News, Expert Insights, Daily Security Review.