A crafted network packet can give an unauthenticated attacker code execution on a vulnerable FortiSIEM server. Fortinet’s October 13 advisory identifies 7.5.0 as affected by CVE-2026-106173; the vulnerable component is named grpc phQueryMaster.
Fortinet describes an improper restriction on a file path, classified as CWE-22. Crafted packets “may allow an unauthenticated attacker to execute unauthorized code or commands,” Fortinet says. The advisory rates the issue critical at 9.4 and marks it Known Exploited: No.
A file path reaches beyond its directory
Fortinet calls the issue an arbitrary file write in grpc phQueryMaster. A path-traversal failure means a filename can escape the directory the application intended to confine it to; Fortinet says specially crafted packets can take this flaw as far as unauthorized code or command execution. Fortinet says restricting access to TCP/27918 prevents the issue. Inventory routes to that port alongside the running FortiSIEM build.
That port should have a short list of legitimate clients. Trace the route from external networks and from workstation segments to the FortiSIEM server, including paths allowed by internal firewalls or overlays. Limit TCP/27918 to the client networks that actually need it while arranging the upgrade. For each approved network, identify the firewall rule or overlay policy that permits the route. A port block on the internet edge alone leaves internally reachable servers exposed to an attacker who already has a foothold in a permitted segment.
Older release records need a branch check
The current PSIRT table names FortiSIEM 7.5.0 as affected, 7.5.1 as the upgrade target, 7.6 as unaffected and FortiSIEM Cloud as unaffected. The Fortinet-authored CVE record also lists 7.0.0–7.0.4, 7.1.0–7.1.9, 7.2.0–7.2.7, 7.3.0–7.3.5 and 7.4.0–7.4.2 as affected, and still carries a Cloud upgrade recommendation. If you run one of those older branches, get Fortinet’s branch-specific status before treating it as clear; for Cloud, use the current PSIRT advisory’s explicit unaffected status rather than the CVE’s older solution text.
Fortinet credits Gwendal Guégniaud of its Product Security team with the internal discovery. If you suspect earlier access, preserve host and network records around connections to TCP/27918 and investigate file changes on that server as incident evidence.
Read back the build and port access
Identify FortiSIEM 7.5.0 servers and their paths to TCP/27918. Restrict that port to required clients, then upgrade affected 7.5.0 installations to 7.5.1 or later on the supported branch. Fortinet states, “Restricting access on tcp port 27918 prevents the issue.” Keep the restriction where operationally possible so a later service exposure does not reopen the same network route.
Read back the installed FortiSIEM build after the upgrade. From a network that should have no access, test connection to TCP/27918: it should fail there while required clients still connect. If retained traffic or host evidence suggests earlier unauthorized writes, investigate those changes separately from the patch job.