Unauthenticated FortiSIEM path traversal flaw enables code execution via cron script

What happened

Fortinet disclosed a critical vulnerability in FortiSIEM on 13 October 2026 in advisory FG-IR-26-180. Tracked as CVE-2026-106173, the flaw affects version 7.5.0; the 7.5.1 release fixes it, while version 7.6 and FortiSIEM Cloud are untouched, according to a dev.to analysis of the bug. On 20 October, security researchers at Horizon3.ai followed the advisory with a technical breakdown and a working proof of concept, turning a vendor patch note into a working demonstration.

The vulnerable component is a service called phQueryMaster. It listens on TCP port 27918 and offers a gRPC interface that other FortiSIEM parts use to hand over query results. Reaching it requires no authentication, which is the detail that turns a file-handling mistake into a serious problem.

From file write to scheduled execution

As the dev.to write-up explains, phQueryMaster constructs a file path from a query identifier supplied by the caller, without checking it adequately. Two weaknesses stack: traversal sequences in the identifier steer the write outside the directory meant to hold results, and although the service appends its own text to the resulting filename, a NUL byte in the identifier cuts the path short from the operating system's point of view. The combined effect is a file write to whatever location the attacker picks.

Horizon3 points to /opt/charting/redishb.sh as the file worth overwriting. Cron executes that script once a minute with elevated privileges, so an attacker who replaces it gets their code run on the next tick.

Severity ratings differ slightly between catalogues: NVD records CWE-22 with a CVSS v3.1 base score of 9.8, while Fortinet's advisory gives 9.4. Both numbers matter less than the absence of authentication on the service.

Why the attack is hard to see

The proof of concept demands a degree of craftsmanship. Standard gRPC tooling and common HTTP libraries refuse header values containing NUL bytes, so an attacker has to assemble the gRPC message by hand. That raises the bar for who can pull this off, but it also places the malicious content inside an HTTP/2 frame body, where middleware and ordinary proxy logging may capture nothing suspicious.

Worse, there appears to be no log signature that confirms exploitation. Horizon3 reports finding no application log entries proving a successful attack, which pushes responders toward filesystem evidence instead.

Investigating an affected instance

For a FortiSIEM 7.5.0 deployment, the dev.to guide suggests starting with file timestamps under /opt/charting/, beginning with redishb.sh. A modification time inconsistent with neighbouring files, or with known patch activity, warrants a closer look. Horizon3 also names /opt/phoenix/bin/phLicenseTool as worth checking.

A mismatch is only a lead. Package upgrades, configuration management runs and support sessions all touch files, so the real question is whether the change appears in a change record or a package manager log.

Network evidence is thin but not absent: port 27918 should be reachable only from trusted SIEM components, so flow logs showing unexpected sources connecting there deserve review even when application logs look clean.

Reducing exposure

Upgrading to 7.5.1 or later is the fix. Where that has to wait, restricting TCP 27918 to the specific systems that genuinely need it, in both north-south and east-west directions, limits who can attempt the attack. The dev.to article cautions that collector architectures often require workers and collectors to reach the supervisor over that port, so long-standing permissive rules may grant far more access than the design requires.

File integrity monitoring on /opt/charting/ is a sensible compensating control, and arguably one that should have existed already, since cron runs privileged scripts from that directory.

Why it matters

A SIEM concentrates risk as much as it manages it: the platform stores credentials for everything it monitors and lives on the management network. This bug shows how the detection instrument becomes the target, because compromising the SIEM potentially compromises visibility and credentials across the whole estate.

It is also Horizon3's third FortiSIEM vulnerability, after CVE-2024-23108 and CVE-2025-64155, both in the phMonitor service, while this one sits in a separate gRPC service. The lesson the researchers draw is that hardening one daemon does not harden an appliance: each listening service forms its own boundary, and defenders need to enumerate all of them rather than patch only the one currently in the news.