FortiSIEM vulnerability demonstrated in public RCE PoC
The FortiSIEM vulnerability tracked as CVE-2026-106173 can allow an unauthenticated attacker to run code or commands on an affected system, and cybersecurity researchers have now published a proof-of-concept (PoC) showing how the attack works. A PoC is demonstration code that confirms a security flaw can be exploited. The vulnerability has a Common Vulnerability Scoring System (CVSS) rating of 9.4, placing it in the critical severity range.
Fortinet released patches last week and advises users of FortiSIEM 7.5.0 to upgrade to version 7.5.1 or later. FortiSIEM 7.6 is listed as not affected. Organisations operating the vulnerable version should treat the public availability of the technical method as a reason to prioritise the upgrade, particularly if the relevant service can be reached by systems that should not have access to it.
The flaw is a path traversal vulnerability, which means attacker-controlled input can direct software outside the folder where it is supposed to store a file. According to Horizon3.ai, an unauthenticated attacker can connect to FortiSIEM's gRPC service on TCP port 27918. gRPC is a method that applications use to communicate with one another, while a TCP port is a numbered network entry point used by a particular service. Specially prepared packets can then be used to overwrite a file outside the intended directory.
Horizon3.ai traced the unsafe behaviour to the QueryResultReq handler and a function named SendQueryResult(). The handler processes metadata supplied through gRPC without adequately checking the resulting file path. The user-controlled query-id value is passed into the path construction process, allowing directory traversal sequences such as ../ to move upward through folders and reach another location on the file system. The specially prepared data is carried through HTTP/2 and HPACK, the protocol and compression format used for the connection.
Path traversal alone does not give the attacker complete control over the destination file name. FortiSIEM automatically adds a name in the form result--0-0-.dat, with the final identifier generated from a counter controlled by the server. That behaviour would ordinarily limit the attacker to choosing a directory while leaving the program to determine the actual name of the written file.
The PoC gets around that restriction by placing a NUL byte inside the query-id value. A NUL byte is a special zero value that many operating-system functions interpret as the end of a string. When the affected code passes the completed path to the file-opening function, the operating system ignores the automatically appended characters that follow the NUL byte. An attacker can therefore place the desired destination name immediately before that terminator and cause the write to land on that exact path.
Horizon3.ai demonstrated the technique against /opt/charting/redishb.sh, an existing shell script used to perform health checks on the Redis service. A cron job, which is a scheduled task on the system, runs that script every 60 seconds. Replacing its contents turns the arbitrary-file-write capability into remote code execution because the altered script is subsequently run by the scheduled job. Horizon3.ai also found that overwriting an existing file preserves its original owner and permissions. A second variant uses two requests to create a new file with an exact attacker-chosen name.
For hosting providers, businesses and IT teams, the key question is whether any managed security environment still runs FortiSIEM 7.5.0 and whether TCP port 27918 is reachable from an untrusted network. The attack does not require an account, so ordinary login controls do not address the vulnerable request handling. Updating to 7.5.1 or later removes the need to rely solely on surrounding network restrictions, while FortiSIEM 7.6 is not affected according to the published version guidance.
Organisations that need help reviewing security-sensitive systems and upgrade planning can use AEU-I for security-first IT, infrastructure and consulting. Regardless of who manages the deployment, the practical priority is to identify affected installations, apply the corrected release and confirm that access to the gRPC service is limited to systems that genuinely require it.