Security information and event management platforms occupy an uncomfortable position. They hold credentials for everything they monitor, they sit on the management network, and their job is to notice when something else has been compromised. FortiSIEM CVE-2026-106173 makes that position the subject of the attack rather than the instrument of detection.
Fortinet published FG-IR-26-180 on 13 October 2026. Horizon3.ai published technical analysis and a proof of concept on 20 October. The vulnerable version is FortiSIEM 7.5.0; version 7.5.1 fixes it, and 7.6 and FortiSIEM Cloud are unaffected.

Mechanism

The defect is in the phQueryMaster service, which listens on TCP port 27918 and exposes a gRPC interface. The service accepts query results from other components and constructs a file path from a caller-supplied query identifier, without adequate validation.
Two weak points combine. Path traversal sequences in the identifier move the write outside the intended results directory. The service appends its own text to the end of the generated filename, which would ordinarily constrain where the file can land, but a NUL byte in the identifier truncates the path as the operating system sees it. The result is a write to a path the attacker nominates.
Turning file write into execution depends on finding a file that something else runs on a schedule. Horizon3 identifies /opt/charting/redishb.sh as the high-value target: cron executes it every 60 seconds with elevated privileges. Overwrite the script and the next tick runs the attacker's content.
NVD records the vulnerability as CWE-22 with a CVSS v3.1 base score of 9.8. Fortinet's own advisory scores it 9.4. Neither score matters as much as the fact that no authentication is required to reach the gRPC service.

The details that change the response

Crafting the request is not trivial. General-purpose gRPC tooling and common HTTP libraries reject header values containing NUL bytes, so the attacker has to build the gRPC message manually. That raises the skill floor and also means the ordinary web-proxy logs on the path may record nothing unusual, because the malicious content is inside an HTTP/2 frame body rather than in a header some middleware validated.
There is no documented log signature that reliably identifies exploitation. Horizon3 states plainly that it found no application log entries that confirm a successful attack. When the primary detection method is unavailable, the investigation has to work from filesystem state instead.

Investigating a FortiSIEM 7.5.0 instance

The useful starting point is file timestamps in /opt/charting/, with /opt/charting/redishb.sh first. Compare the modification time of that script against other files in the same directory and against known patch times. A script whose timestamp does not match its neighbours deserves examination.
Horizon3 also flags /opt/phoenix/bin/phLicenseTool as worth checking.
One caution belongs with that technique. A timestamp mismatch is a lead, not a conclusion. Package upgrades, configuration management runs, and support sessions all touch files. The question is whether the change is accounted for, and the answer usually lives in a change record or a package manager log rather than in the timestamp itself.
Network-side evidence is limited but not empty. Port 27918 should not be reachable from anything except trusted SIEM components. Flow logs showing connections from unexpected sources to that port are worth reviewing even when the application logs are clean.

Reducing the exposure that remains

Upgrade to 7.5.1 or later. Where the upgrade has to wait, restrict TCP 27918 to the specific systems that need it, in both north-south and east-west directions.
That second point is where many environments will find the real work. A SIEM collector architecture often requires workers and collectors to reach the supervisor over that port, and a permissive rule added years ago to make collection work may now allow far more than the architecture needs.
Monitoring file integrity on /opt/charting/ is a reasonable compensating control. It is also a control that should have existed before this advisory, because the directory contains scripts that cron executes with privilege.

What this incident says about the class

Horizon3 notes that this is the third FortiSIEM vulnerability it has published, after CVE-2024-23108 and CVE-2025-64155. The earlier two were in the phMonitor service. This one is in a separate gRPC service.
That history is the part worth carrying forward. Hardening one daemon on an appliance does not harden the appliance. Each listening service is its own boundary, and a management platform that exposes several of them needs the whole set enumerated rather than the currently fashionable one patched.

References

  • Fortinet advisory FG-IR-26-180, 13 October 2026

  • Horizon3.ai, technical analysis and PoC for CVE-2026-106173, 20 October 2026

  • NVD entry for CVE-2026-106173, CVSS v3.1 9.8, CWE-22

  • The Hacker News, "Critical FortiSIEM Flaw Gets Public Exploit", October 2026

  • FreeBuf, analysis of the FortiSIEM gRPC path traversal, 21 October 2026