Fortinet says FortiSIEM 7.5.0 has a critical flaw that an unauthenticated attacker may use to run code. The fix is 7.5.1 or above. Until you upgrade, restrict access to tcp port 27918. A public proof of concept has been online since 20 October, so treat this as urgent.
The flaw is CVE-2026-106173, Fortinet advisory FG-IR-26-180, published on 13 October 2026. Fortinet scores it 9.4 and its own product security team found it. Our CVE-2026-106173 page holds the dated record.
Which Versions Does Each Source List?
Fortinet and NVD do not agree on the affected versions. Read both before you decide that an older release is safe.
| Item | Fortinet advisory | NVD record |
|---|---|---|
| Affected | 7.5.0 only | 7.5.0, plus 7.0.0 to 7.4.2 in the affected list |
| Fix | 7.5.1 or above | Not stated in the record |
| Not affected | 7.6 and FortiSIEM Cloud | Not stated in the record |
| Score | CVSSv3 9.4 | CVSS 3.1 9.8 |
| Exploited | Known Exploited: No | CISA SSVC entry: exploitation poc |
NVD still marked the record “Awaiting Analysis” when we read it on 24 October. If you run an older 7.x release, ask Fortinet support and apply the port restriction below at once.
- Find your versionRead the FortiSIEM version your own console reports and compare it with the table.
- Restrict tcp port 27918This is Fortinet’s workaround. Allow only the hosts that must reach it, then test from outside your network.
- Upgrade 7.5.0 to 7.5.1 or aboveFortinet lists 7.6 and FortiSIEM Cloud as not affected.
- Look for changed filesCompare the modified times of two files listed below with their neighbours.
- Check your exposureSearch your external scan results for tcp 27918 on public addresses.
What Is Behind Port 27918?
Horizon3.ai, a security company, published a deep-dive on 20 October. It says the phQueryMaster service listens on tcp/27918 and runs a gRPC server that does not ask clients for a certificate. In its words, “any remote client can connect to the gRPC service on port tcp/27918 unauthenticated”. That is why Fortinet’s workaround is a network rule and not a setting inside the product.
On the attack surface side, a SIEM collects logs from across a company. A reachable management port on it deserves a firewall rule whatever the version.
Has Anyone Used It Against Real Systems?
Fortinet’s advisory says Known Exploited: No. The flaw was not in the CISA Known Exploited Vulnerabilities catalog in its 23 October release.
Exploit code is public, though. Horizon3.ai put a proof of concept on GitHub on 20 October at 12:29 UTC, and our search found three more repositories for the CVE id by 23 October. We read their READMEs as data. We did not run them and do not link them. The Horizon3.ai attack team announced its deep-dive on X on 20 October. It says the work covers an arbitrary file write in a gRPC service that leads to remote code execution.
- Public proof of conceptYesHorizon3.ai repository on GitHub, plus three more repositories by 23 October20 Oct, 12:29 UTC
- Posts on XYesHorizon3.ai attack team announced its deep-dive; Italy’s national CSIRT warned a proof of concept is online20-21 Oct
- Dark web chatter (THANOS)UnknownTelegram channels and a Russian-language forum re-shared public material; not verified20-24 Oct
- CISA KEV listingNot seenNot in the catalog’s 23 October release23 Oct
- Vendor says exploitedNot seenFortinet advisory: Known Exploited: No13 Oct
- NVD against the advisoryUnknownNVD also lists 7.0.0 to 7.4.2; Fortinet lists 7.5.0 onlyread 24 Oct
Italy’s national CSIRT warned on 21 October that a proof of concept exists:
Open the post on X (@csirt_it, 21 October).
Our THANOS dark web search found Telegram channels that collect hacking tools passing on the Horizon3.ai repository link from 21 October, and a Russian-language forum reposting a news article about the proof of concept the same day. These posts are not verified, and they re-share public material.
How Can You Tell Whether Someone Got In?
Horizon3.ai says it found no application logs that would reveal exploitation. It advises comparing the modified times of these two files with the files around them:
/opt/charting/redishb.sh/opt/phoenix/bin/phLicenseTool
A file whose time does not match its neighbours is a reason to open an incident. Log your findings before you rebuild. Fortinet products have seen file-write bugs before, such as the FortiMail zero-day, and a path traversal in the Fortinet CLI. Next step: check the version today, close the port, then schedule the upgrade through your patch management process.