CVE-2026-106173: Unauthenticated FortiSIEM gRPC path traversal allows remote code execution and now has a public proof of concept

CoeLab Real-World Impact: 79/100 — High. Editorial score v1.0. Evidence checked 2026-11-01T22:10:27.535859+00:00. CVSS and EPSS are separate measures, not this editorial score.

Rating breakdown: exploitation: 10, reachability: 25, consequences: 24, operational relevance: 20.

Who is affected

This vulnerability affects Fortinet's FortiSIEM, a security information and event management platform that many organizations use as the central point for log collection, correlation and alerting. Fortinet's CVE record lists the following version ranges as affected: 7.5.0, and all releases from 7.0.0 through 7.4.2 (the 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 branches). FortiSIEM 7.6 is not affected. Fortinet's advisory also states that FortiSIEM Cloud is not affected.

There is an important asymmetry between the two official sources that defenders should understand before they treat themselves as safe. The vendor advisory's version table calls out only 7.5.0 as affected and points to 7.5.1 as the fix, while the CVE record — published by Fortinet itself as the CVE numbering authority — marks the 7.0 through 7.4 branches as affected as well. If you run any FortiSIEM version below 7.5, you should not assume you are unaffected simply because the advisory's table is terse. The record's solution text references upgrades to FortiSIEM 7.6.0 or above, 7.5.1 or above, FortiSIEMCloud 25.4.1 or above, and FortiSOC 26.2.2 or above, but the advisory does not itemize a per-branch fix for the older 7.x branches. Treat older branch status as unconfirmed and verify your concrete upgrade path with Fortinet rather than inferring safety from silence.

Operationally, the population at risk is every deployment where the FortiSIEM gRPC listener is reachable from a network an attacker can touch. That includes internet-exposed appliances, but also — and more commonly — internal deployments where the event ingestion and query services accept traffic from broad internal network segments. A SIEM by design accepts log data from many sources, which increases the chance that its service ports reach further than administrators mentally model.

Real-world impact and exploitation evidence

The flaw is a path traversal (CWE-22) that Fortinet's advisory says allows an unauthenticated attacker to execute unauthorized code or commands via specially crafted packets, and Fortinet rates it 9.4 CRITICAL on CVSS v3.1 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — network reachable, low complexity, no privileges and no user interaction required for high impact across confidentiality, integrity and availability.

Independent research by Horizon3.ai, whose repository is tagged as an exploit reference in the CVE record, describes the mechanism behind those labels: the FortiSIEM gRPC QueryResultReq handler processes untrusted metadata without validating paths. By embedding path traversal sequences together with NUL-byte injection inside gRPC's HTTP/2 and HPACK encoding layers, an attacker can write arbitrary files to the appliance's filesystem. The published proof of concept turns that file-write capability into command execution — with an important detail for detection: the researcher notes execution is blind and delayed, because a cron job triggers the overwritten script, taking up to 60 seconds to run the attacker's command.

CISA's own enrichment in the CVE record classifies exploitation maturity as 'poc' (proof of concept, not confirmed mass exploitation), marks the flaw as automatable, and rates the technical impact as total. That combination matters: automation plus a public PoC means attackers can scan-and-exploit at scale without manual skill. At the same time, honesty about the evidence is required. EPSS currently estimates about a 1% probability of exploitation within 30 days (0.998%, 63rd percentile as of 2026-11-01), and the vulnerability is not flagged in CISA's KEV catalog in the intake evidence dated 2026-11-01. An exploit-tagged reference is not proof of active exploitation, and no vendor or researcher statement reviewed for this article confirms intrusions in the wild. The right reading is: no confirmed campaigns yet, but a working unauthenticated RCE chain for a security-critical appliance is public, and that situation historically degrades fast.

The real-world consequence profile is worse than a generic server compromise. FortiSIEM holds the organization's security telemetry. An attacker with code execution there can read logs they would rather keep invisible, tamper with or disable detection and alerting, and use a trusted central security box as a launch point into the rest of the estate — all while the defenders' primary visibility tool is the thing that is compromised.

Attack prerequisites

The attacker needs only network reachability to the FortiSIEM gRPC service, which listens on TCP port 27918 by default per the published proof of concept. No authentication is required, no user interaction is involved, and the CVSS vector confirms low attack complexity. The exploit is delivered inside the HTTP/2 framing of a normal-looking gRPC request, which means it can blend into legitimate event or query traffic on that port.

Two conditions therefore define exposure: whether TCP 27918 accepts traffic from untrusted networks, and whether the appliance runs an affected version. If the port is reachable only from tightly controlled segments, immediate risk drops sharply — that is exactly why the vendor's workaround below is effective. Because the resulting command execution is blind and deferred by a cron job window of up to about a minute, exploitation leaves less immediate feedback than typical interactive RCEs, so absence of obvious breakage is not reassurance.

We are deliberately not publishing exploit payloads, target lists or weaponization details here. The chain is documented in the researcher's own technical analysis, including indicators of compromise, which defenders should review directly.

Actions and fixes

Upgrade first. Fortinet's advisory instructs affected 7.5.0 deployments to upgrade to FortiSIEM 7.5.1 or above; 7.6 is not affected, so moving to the 7.6 branch also resolves the issue. The CVE record's solution text additionally references FortiSIEMCloud 25.4.1 or above and FortiSOC 26.2.2 or above for the other named product lines. For organizations on the 7.0–7.4 branches, which the CVE record lists as affected but whose per-branch fixes the advisory table does not itemize, open a support case with Fortinet to confirm the supported upgrade path before assuming any version is safe.

If you cannot patch immediately, implement the vendor's documented workaround: restrict access on TCP port 27918 so that only trusted sources can reach the gRPC service. This is a real mitigation, not a checkbox — the attack is unauthenticated and network-delivered, so removing network reachability removes the attack path. Audit firewall rules and security groups for this port specifically; a SIEM's ingestion role often means the port is open far more widely than intended.

Fortinet's advisory marks 'Virtual Patch: No', so do not count on an IPS signature as a substitute for either action. After patching, review logs around port 27918 traffic and hunt for anomalous gRPC requests, unexplained file writes or suspicious cron activity, since the delayed-execution pattern means successful exploitation may not announce itself. The Horizon3 research post publishes indicators of compromise that can seed those hunts.

Uncertainty and what could change

Three uncertainties materially affect this story. First, fix coverage for the 7.0–7.4 branches is not spelled out in the advisory's version table; the affected-versus-fixed picture for those branches could be clarified by a future advisory revision, and we will treat any such revision as a reason to re-examine. Second, exploitation status is a moving target: EPSS is low today and KEV does not list this CVE per our 2026-11-01 intake evidence, but both are refreshed continuously, and a KEV addition or an EPSS spike would change the urgency picture even though the vulnerability itself is unchanged.

Third, the severity assessment rests partly on the researcher's description of the chain (NUL-byte injection through HPACK metadata, arbitrary file write, cron-triggered execution). We verified the proof of concept exists and is tagged as an exploit reference on the official CVE record, and we verified Fortinet's own impact statement, but we have not independently tested the exploit and publication policy forbids doing so. If Fortinet or other researchers revise the technical analysis, details may shift.

Finally, note the evidence timeline explicitly: Fortinet reserved the CVE on 2026-10-06 and the record was first published 2026-10-13 alongside the initial advisory. The record was updated on 2026-10-21, when CISA's enrichment added the 'poc' and 'automatable' classifications — a meaningful signal that arrived a week after the fix was already available. None of this is a new vulnerability discovered now; what is current is the public proof of concept and the hardened assessment of exploitability. Patching decisions should assume that public exploit availability, not disclosure date, is the clock that matters.

Sources and evidence date

This analysis draws on four primary or first-party sources, all retrieved on 2026-11-02: Fortinet's PSIRT advisory FG-IR-26-180 (affected versions, fix, workaround and Cloud status; advisory timeline shows initial publication 2026-10-13), the official CVE record for CVE-2026-106173 maintained by Fortinet as the numbering authority (affected version ranges, CVSS 3.1 vector and score of 9.4, solution text, and the record's publication date of 2026-10-13 and update date of 2026-10-21), CISA's ADP enrichment within that record (SSVC assessment timestamped 2026-10-13, record enrichment updated 2026-10-21), and the Horizon3.ai proof-of-concept repository with its linked technical analysis (attack chain description and default port).

Supplementary context comes from FIRST EPSS (score 0.998%, 63rd percentile, dated 2026-11-01) and our intake evidence dated 2026-11-01, which showed no KEV catalog entry at that time. Version numbers, dates and vendor statements above are reported exactly as the sources state them; where the advisory and the CVE record disagree in detail — the affected-branch table — we have shown both rather than smoothing over the difference.

Primary-source links

https://fortiguard.fortinet.com/psirt/FG-IR-26-180

https://www.cve.org/CVERecord?id=CVE-2026-106173

https://github.com/horizon3ai/CVE-2026-106173

https://horizon3.ai/attack-research/cve-2026-106173-deep-dive-fortisiem-grpc-path-traversal-file-write-rce/

AI-assisted research and drafting, with a separate model editorial review. CoeLab ratings are editorial judgments, not a substitute for checking your own versions and vendor advisories. Methodology: https://thecoelab.com/blog/security/methodology