CVE-2026-106173 (CVSS 9.8): Public PoC Drops for FortiSIEM Unauthenticated RCE — Patch or Block Port 27918 Now

A public, working exploit for a critical Fortinet FortiSIEM vulnerability landed on GitHub on October 20, 2026 — yesterday. That changes everything. What was a patch-at-your-pace advisory from October 13 is now a drop-everything emergency: any unauthenticated attacker anywhere on the internet can write arbitrary files to your FortiSIEM server, chain that into remote code execution, and silently own the very platform you depend on to detect them.

Tracked as CVE-2026-106173, rated CVSS 9.8 Critical, and catalogued under Fortinet’s own advisory FG-IR-26-180, this flaw lives in FortiSIEM’s internal gRPC query service. Horizon3.ai, the firm that discovered and documented it, released both a technical deep-dive and a PoC script (CVE-2026-106173.py) that requires only a target IP address and a command to execute. The barrier to exploitation just dropped to zero.

What Is FortiSIEM and Why Does It Make Such a High-Value Target?

Fortinet FortiSIEM is an enterprise security information and event management platform — the aggregation point for security logs, alerts, and compliance reports across an entire organisation’s infrastructure. Thousands of enterprises globally, including many in India’s BFSI, government, and critical infrastructure sectors, run FortiSIEM as the nerve centre of their SOC operations.

That centrality is precisely what makes it so dangerous to compromise. When an attacker gets remote code execution on your SIEM, they do not merely get one more server. They gain:

• Full visibility into every security event your organisation is generating
• The ability to delete, suppress, or falsify log data
• Credentials, API keys, and connection strings for every integrated data source
• A trusted pivot point — SIEMs are typically placed deep inside network segments with broad read access to production systems

This is why attackers specifically seek out SIEM and network management infrastructure. It is the ultimate blind-spot creator: once your SIEM is compromised, your SOC operators are effectively flying without instruments. For organisations that have invested in Fortinet’s Security Fabric — FortiGate, FortiAnalyzer, FortiAuthenticator — a FortiSIEM breach is not a peripheral incident. It is a core infrastructure compromise.

CVE-2026-106173: Technical Breakdown of the Exploit Chain

The Attack Surface: gRPC on Port 27918

FortiSIEM runs an internal gRPC service called phQueryMaster on TCP port 27918. This service is designed for node-to-node query traffic between FortiSIEM workers — it is internal plumbing, not a customer-facing interface. Critically, however, Fortinet did not require client-certificate authentication on this service, meaning any network-reachable client can connect to it without presenting credentials.

In principle, this is acceptable if port 27918 is properly firewalled from untrusted networks. In practice, many deployments expose it to at least the internal LAN — and some have it reachable from the internet. The Horizon3.ai PoC works as long as the port is reachable.

Stage 1: Path Traversal via Unsanitised query-id

The gRPC service exposes a remote procedure call named SendQueryResult. The handler for this RPC builds an output file path by concatenating an attacker-supplied query-id value directly into a directory string — /opt/phoenix/query/result/<query-id>-result-.dat — with no validation whatsoever.

An attacker supplying a query-id of ../../../../../../../tmp/evil walks the write out of the intended results directory and into any location on the filesystem where the FortiSIEM process has write access — which, given the service runs with elevated privileges, is nearly everywhere.

Stage 2: Null-Byte Injection to Strip the Forced Suffix

The server appends its own suffix (-result-.dat) to every filename, which would ordinarily prevent an attacker from writing to a specific filename needed for code execution (for example, a PHP webshell or an SSH authorized_keys file). Horizon3.ai defeated this control with a null-byte injection: by embedding a null byte (\x00) in the query-id field through gRPC’s HTTP/2 and HPACK encoding layers, the operating system’s open() call interprets the null byte as end-of-string and silently discards the server’s suffix.

Result: the attacker controls both the path (via traversal) and the filename (via null-byte truncation) of the file being written. Arbitrary file write becomes arbitrary code execution by overwriting a cron job, an SSH key, or a web-accessible script.

The Horizon3.ai PoC: What It Does

The public PoC published by Horizon3.ai is a Python script that accepts a target host, a port (defaulting to 27918), and an OS command. It:

1. Connects unauthenticated to the FortiSIEM gRPC service
2. Crafts a malicious QueryResultReq packet embedding both path traversal and null-byte sequences
3. Writes a file to an attacker-chosen location on the server
4. Triggers execution via an accessible entry point

The full root-cause analysis and exploit walkthrough are published on the Horizon3.ai Attack Research blog. The PoC repository is live on GitHub. Detection-evasion has not been built in — but nation-state actors will wrap this in hours, if they have not already.

Affected Versions at a Glance

FortiSIEM Version	Status	Action Required
7.6.0 and above	Not affected	No action needed
7.5.0	Vulnerable	Upgrade to 7.5.1 or above
7.4.0 – 7.4.2	Vulnerable	Upgrade to 7.6.0 or above
7.3.0 – 7.3.5	Vulnerable	Upgrade to 7.6.0 or above
7.2.0 – 7.2.7	Vulnerable	Upgrade to 7.6.0 or above
7.1.0 – 7.1.9	Vulnerable	Upgrade to 7.6.0 or above
7.0.0 – 7.0.4	Vulnerable	Upgrade to 7.6.0 or above
FortiSIEM Cloud	Not affected	No action needed

Source: Fortinet PSIRT Advisory FG-IR-26-180 | NVD CVE-2026-106173

What You Should Do Right Now — Sanjay Seth’s Expert Recommendations

With a working public PoC now available, the window between “patch advisory” and “active mass exploitation” has collapsed to hours. Here is the prioritised response plan I would walk any client through today:

Immediate (Within the Hour)

• Block TCP port 27918 externally — right now. Use your FortiGate, ACL, or cloud security group to deny all inbound traffic to port 27918 from any untrusted network. Fortinet’s own advisory confirms that “restricting access on TCP port 27918 prevents the issue.” This is your fastest risk reduction before you can patch.
• Audit your FortiSIEM version. Log into the FortiSIEM UI, go to Admin → System Configuration → System, and confirm your running version. Match it against the table above.
• Check exposure. Run nmap -sV -p 27918 <your-fortisiem-ip> from an external vantage point to confirm whether port 27918 is reachable from outside your trusted network segments.

Short-Term (Within 48 Hours)

• Apply the patch. Upgrade FortiSIEM to 7.5.1 if you are on 7.5.0. If you are on any version from 7.0 through 7.4, upgrade to 7.6.0 or above. Test in a non-production environment where possible, but do not let testing delay patching production.
• Threat-hunt for compromise indicators. Before patching, check for:
  • Unexpected files in /tmp, /var/tmp, or web-accessible directories
  • New or modified cron jobs, SSH keys, or startup scripts
  • Unusual outbound connections from the FortiSIEM host
  • Any gRPC traffic on port 27918 from unexpected source IPs in your network logs
• Rotate credentials. FortiSIEM holds API credentials for every integrated system. If you suspect any exposure window, rotate the service accounts FortiSIEM uses to query FortiGate, Active Directory, cloud platforms, and ticketing systems.

Strategic (This Month)

• Network-segment your SIEM. The FortiSIEM management interface and internal gRPC ports should never be reachable from general office or guest networks. Place FortiSIEM in a dedicated management VLAN with explicit allow-list rules. This is zero-trust network access applied to your monitoring infrastructure.
• Review all Fortinet product versions. CVE-2026-106173 is not an isolated incident — 2026 has seen critical flaws in FortiGate, FortiMail, and FortiSandbox. Run a full Fortinet product audit and ensure every component is current.
• Verify your SIEM’s integrity. Even if you were not exploited this time, this incident is a prompt to verify that your SIEM itself is covered by your integrity-monitoring and backup strategy. Who watches the watchmen?

Why a Compromised SIEM Is Uniquely Catastrophic for Indian Enterprises

India’s IT-GRC landscape operates under a tightening regulatory framework: SEBI’s cybersecurity circular, RBI’s IT risk guidelines, CERT-In’s 6-hour breach-reporting mandate, and the Digital Personal Data Protection (DPDP) Act all presuppose that organisations have functioning, reliable audit logs. A compromised SIEM that has been silently altering or deleting log data creates not just a security crisis but a compliance crisis.

Indian enterprises in BFSI, telecom, and critical infrastructure that rely on FortiSIEM for their regulatory audit trails should treat CVE-2026-106173 as a board-level issue, not a patching ticket. The downstream consequences of undetected log tampering can include regulatory findings, licensing risks, and — critically — an inability to prove the scope of any concurrent breach during an incident investigation.

It is also worth noting the persistence risk. Once an attacker has unauthenticated RCE on a FortiSIEM server, they can establish persistence through multiple channels — cron jobs, webshells, modified startup scripts — none of which patching alone will remove. If you have any doubt about whether your FortiSIEM was compromised before you patch, treat it as a forensic evidence-preservation scenario first and a patching scenario second.

Frequently Asked Questions

Does blocking port 27918 break FortiSIEM’s functionality?

Port 27918 is used for internal gRPC communication between FortiSIEM worker nodes in a distributed deployment. If you are running a single-node FortiSIEM deployment, blocking this port from external/untrusted networks will not affect functionality. In a multi-node (distributed) deployment, you should only block the port from untrusted networks; traffic between your own FortiSIEM nodes on your internal network should be allowed via a specific allow-list ACL rather than blocking the port entirely. Consult your network diagram before applying blanket blocks — and then patch immediately to remove the dependency on the workaround.

Is there evidence of active exploitation in the wild?

As of October 21, 2026, there are no publicly confirmed in-the-wild exploitation incidents. However, the Horizon3.ai PoC was published only yesterday (October 20), and history shows that with a working, public exploit for a CVSS 9.8 unauthenticated RCE, mass scanning and exploitation attempts typically begin within 24–72 hours. CISA has not yet added CVE-2026-106173 to its Known Exploited Vulnerabilities catalog, but that typically lags behind actual exploitation by days to weeks. Do not wait for KEV confirmation before acting.

My FortiSIEM is on version 7.4.x — do I need to jump directly to 7.6.0?

Yes. Fortinet’s advisory specifies that for version branches 7.0 through 7.4, the fix is to upgrade to FortiSIEM 7.6.0 or above. Version 7.5.1 only addresses the issue for the 7.5.x branch. Check with your Fortinet partner or Fortinet Support for the upgrade path from your specific version. FortiSIEM 7.6.x is not affected by this CVE.

We use FortiSIEM Cloud — are we affected?

No. Fortinet has confirmed that FortiSIEM Cloud is not affected by CVE-2026-106173. The vulnerability is specific to on-premises deployments. Cloud tenants should continue standard hygiene practices but do not need emergency action for this specific CVE.