On 13 October 2026, Fortinet's monthly PSIRT release included FG-IR-26-180, a Critical path traversal in FortiSIEM tracked as CVE-2026-106173. The advisory says an unauthenticated attacker may be able to execute unauthorized code or commands via specially crafted packets, through an arbitrary file write in the gRPC service phQueryMaster. Fortinet scores it CVSS 9.4.
The fix is simple to state for one version. The harder part is that Fortinet's advisory and the CVE record Fortinet filed disagree on which versions are affected. If you run FortiSIEM 7.4 or older, you need to make a decision with incomplete information, and the workaround in the advisory gives you a sensible way to do that.
What's affected
From the Fortinet advisory:
| Version | Status | Solution |
|---|---|---|
| FortiSIEM 7.6 | Not affected | Not applicable |
| FortiSIEM 7.5 | 7.5.0 affected | Upgrade to 7.5.1 or above |
The advisory also states that FortiSIEM Cloud is not affected, and that "Restricting access on TCP port 27918 prevents the issue." Fortinet lists the issue as discovered internally (credited to Gwendal Guégniaud of the Fortinet Product Security team) and not known to be exploited. Its CVSS vector, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:H/RL:O/RC:C, includes a temporal exploit code maturity of High.
The CVE record for CVE-2026-106173, published by Fortinet as the CNA the same day, lists a wider range as affected:
- 7.5.0
- 7.4.0 through 7.4.2
- 7.3.0 through 7.3.5
- 7.2.0 through 7.2.7
- 7.1.0 through 7.1.9
- 7.0.0 through 7.0.4
The record gives no fixed versions for the 7.0 through 7.4 lines, and the advisory's table does not mention them at all. At the time of writing, the advisory shows a single revision, its initial publication on 13 October. We cannot tell from public information which of the two is correct.
How to check if you're exposed
First, list every FortiSIEM node you run (supervisor, workers and collectors) and its version, from the GUI or your asset records. Then check whether port 27918 is reachable from places it should not be.
From a host on each network segment that can route to FortiSIEM:
nmap -Pn -p 27918 fortisiem-super.example.internal fortisiem-worker1.example.internal
On each FortiSIEM node, see whether anything listens on the port:
ss -ltnp | grep 27918
Then review the firewall rules in front of FortiSIEM. A SIEM tends to accept traffic from large parts of the network because agents and collectors send it logs, so broad inbound rules are common. Those rules are exactly what this workaround needs you to narrow.
Finally, CISA's enrichment on the CVE record marks the issue as automatable with total technical impact. That combination, plus no authentication, is why the reachable surface matters more than the CVSS number.
What to do now
- Upgrade FortiSIEM 7.5.0 to 7.5.1 or later. This is the only fix Fortinet's advisory names.
- On 7.4 and earlier, apply the workaround now. Restrict TCP port 27918 so only the FortiSIEM nodes that need it can reach it. Given the conflicting version data, treat these lines as potentially affected until Fortinet clarifies.
- Ask Fortinet support directly for the affected status and fixed builds for your version, quoting both FG-IR-26-180 and the CVE-2026-106173 record. Keep the answer with your vulnerability ticket.
- Consider moving to 7.6, which the advisory lists as not affected, if your upgrade plans allow it.
- Review the rest of the 13 October release. Fortinet also published advisories for FortiManager (FG-IR-26-177, CVE-2026-106171) and FortiSandbox (FG-IR-26-179, CVE-2026-106172) that day.
- Watch the advisory for revisions. Re-check FG-IR-26-180 and the CVE record weekly until the ranges match.
Why it matters
Most vulnerability tooling trusts the CVE record's affected version data, because it is machine readable. Most humans trust the vendor advisory, because it is the official guidance. When they disagree, one of the two audiences is working from wrong information. A scanner that reads the CVE record will flag your FortiSIEM 7.4 node, and a human reading the advisory may close the ticket as a false positive.
The way through is to treat the disagreement itself as a finding: apply the cheap mitigation everywhere the wider range applies, fix where a fix exists, and record why you made each call. Machine readable advisories such as CSAF and VEX exist precisely so that vendors can state affected and not affected status in a form tools can consume, and so that conflicts like this get noticed.
Try it yourself
Pull the CVE record JSON for CVE-2026-106173 from the CVE Services API and compare its affected block with the table in FG-IR-26-180. Then do the same for the last three advisories that touched your most important appliance. Count how many disagree.
curl -s https://cveawg.mitre.org/api/cve/CVE-2026-106173 | jq '.containers.cna.affected'
Click through it at your own pace, or open it full screen.
Quick check
Which FortiSIEM version does Fortinet's advisory say fixes CVE-2026-106173?
FortiSIEM 7.5.1 or above, for the 7.5 line. 7.6 is listed as not affected, and FortiSIEM Cloud is not affected.
What is the workaround?
Restrict access to TCP port 27918. Fortinet's advisory says this prevents the issue.
Why should FortiSIEM 7.4 users act even though the advisory does not list 7.4?
The CVE record filed for CVE-2026-106173 lists 7.0.0 through 7.4.2 as affected, with no fixed versions. Until Fortinet reconciles the two, restricting port 27918 is a low cost way to cover the gap.
