CVE-2026-106173: Fortinet FortiSIEM Unauthenticated RCE — Detection, Hunting, and Remediation Guide

Public exploit code is now circulating for CVE-2026-106173, a critical path traversal vulnerability in Fortinet FortiSIEM carrying a CVSS score of 9.4. The flaw allows an unauthenticated, remote attacker to execute arbitrary code or commands on the FortiSIEM appliance simply by sending specially crafted requests containing path traversal sequences. No credentials, no user interaction, no insider access — just network reachability to the FortiSIEM management interface.

This is about as bad as it gets for the SOC. FortiSIEM sits at the nerve center of your monitoring stack: it aggregates logs, holds credentials for pulling data from endpoints and network devices, and often has broad network visibility by design. A compromised SIEM is a compromised SOC — an attacker who owns it can blind your detection capability, harvest stored credentials, and use the appliance as a pivot point into the rest of the environment. Fortinet products are also perennial favorites of both ransomware operators and state-sponsored actors; historically, PoC release for critical Fortinet flaws is followed by mass scanning and in-the-wild exploitation within days, sometimes hours.

If FortiSIEM is in your environment and its management interface is reachable from anything other than a tightly restricted management VLAN, treat this as an active incident-response scenario, not a routine patch cycle.

Technical Analysis

Affected Product

• Product: Fortinet FortiSIEM (physical, virtual, and cloud-deployed appliances — Supervisor, Worker, and Collector roles)
• Vulnerability type: Path traversal (CWE-22) leading to unauthenticated remote code execution
• CVE: CVE-2026-106173
• CVSS v3.x score: 9.4 (Critical)
• Authentication required: None
• Attack vector: Network — specially crafted HTTP/HTTPS requests to the FortiSIEM web/service interface

How the Attack Works (Defender's View)

Path traversal flaws in web-facing services are mechanically simple: the application accepts user-controlled input in a request path or parameter and fails to properly canonicalize and validate it before passing it to a filesystem operation. By injecting sequences such as ../, URL-encoded variants (%2e%2e%2f, %2e%2e/, ..%2f), or double-encoded forms (%252e%252e%252f), the attacker escapes the intended web root or application directory and reaches arbitrary filesystem locations.

In this case, the traversal chain culminates in code or command execution — typical escalation paths for this class of bug on Linux-based appliances like FortiSIEM include:

1. Writing attacker-controlled content to a location that is subsequently executed (e.g., a web-accessible directory, a cron-watched path, or a location loaded by an application service such as the Java/GlassFish or Phoenix components FortiSIEM runs).
2. Reading sensitive files (configurations, credential stores, SSH keys) that enable follow-on execution.
3. Triggering a backend component that processes the traversed path in an unsafe command context.

The observable fingerprints defenders should care about:

• Inbound: HTTP requests to the FortiSIEM interface (TCP 443) containing traversal sequences in the URI or parameters, especially encoded variants that may evade naive filtering.
• On the appliance: Web or application service processes (httpd/apache, java for GlassFish/application services, FortiSIEM Phoenix services) spawning unexpected child processes — shells (bash, sh, dash), interpreters (python, perl), downloaders (curl, wget), or post-exploitation tooling.
• Filesystem: New or modified files in web roots, /tmp, /var/tmp, /dev/shm, and application directories; unexpected cron entries or systemd units for persistence.
• Outbound: Egress connections from the FortiSIEM appliance to unfamiliar external IPs — reverse shells, C2, or payload staging.

Exploitation Status

• Public proof-of-concept: CONFIRMED. Researchers have released working PoC exploit code, which dramatically lowers the bar for exploitation and historically correlates with rapid weaponization.
• Active exploitation: With public PoC available for an unauthenticated RCE in a perimeter-reachable Fortinet product, assume scanning and opportunistic exploitation are underway or imminent. Check CISA's Known Exploited Vulnerabilities (KEV) catalog daily — Fortinet CVEs with public PoC are frequently added quickly, which triggers binding remediation deadlines for federal agencies and is a strong triage signal for everyone else.
• Patch status: Fortinet has released a fix. The PoC release followed the patch — the classic "patch diffing" pattern where researchers reverse the vendor fix to build the exploit. Unpatched appliances are the only targets; the patch kills the bug.

Detection & Response

Detection strategy here has three layers: (1) catch traversal attempts at the network/web layer, (2) catch post-exploitation behavior on the appliance itself (service processes spawning shells), and (3) hunt retroactively for compromise on appliances that were exposed before patching.

SIGMA Rules

---
title: FortiSIEM Path Traversal Exploitation Attempt - CVE-2026-106173
id: 4f2a9c31-7b8d-4e5f-a1c2-9d3e5f7a1b02
status: experimental
description: Detects HTTP requests containing path traversal sequences targeting FortiSIEM web interfaces, consistent with CVE-2026-106173 exploitation attempts.
references:
  - https://thehackernews.com/2026/10/critical-fortisiem-flaw-gets-public.html
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/10/10
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri|contains:
      - '../'
      - '..\\'
      - '%2e%2e'
      - '%252e%252e'
      - '..%2f'
      - '..%5c'
      - '%c0%ae'
  selection_target:
    dst-port:
      - 443
      - 8443
  condition: selection_uri and selection_target
falsepositives:
  - Rare; legitimate application traffic should not contain raw or encoded traversal sequences in URIs
level: high
---
title: FortiSIEM Application Service Spawning Shell or Downloader
id: 8c1d4e62-3a5b-4f79-b2e1-6c8d0a4f9e53
status: experimental
description: Detects FortiSIEM web/application service processes (httpd, java, GlassFish, Phoenix components) spawning shells, interpreters, or download tools — a strong post-exploitation indicator for unauthenticated RCE such as CVE-2026-106173.
references:
  - https://thehackernews.com/2026/10/critical-fortisiem-flaw-gets-public.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/10
tags:
  - attack.execution
  - attack.t1059.004
  - attack.t1105
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|contains:
      - 'httpd'
      - 'apache'
      - 'java'
      - 'glassfish'
      - 'phoenix'
  selection_child:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/dash'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - FortiSIEM health-check or maintenance scripts spawned by application services — baseline and tune per environment
level: critical
---
title: Suspicious File Writes in Ephemeral Directories on Linux Appliances
id: 1e7b3d94-5c2f-4a68-9d4b-2f6a8c1e7b35
status: experimental
description: Detects executable or script content written to world-writable/ephemeral directories commonly used for payload staging after exploitation of Linux-based appliances like FortiSIEM.
references:
  - https://thehackernews.com/2026/10/critical-fortisiem-flaw-gets-public.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/10
tags:
  - attack.defense_evasion
  - attack.t1036
  - attack.t1105
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|startswith:
      - '/tmp/'
      - '/var/tmp/'
      - '/dev/shm/'
  selection_ext:
    TargetFilename|endswith:
      - '.sh'
      - '.py'
      - '.pl'
      - '.elf'
      - '.so'
      - '.jsp'
  condition: selection_path and selection_ext
falsepositives:
  - Legitimate administrative scripting during maintenance windows
level: medium

KQL (Microsoft Sentinel / Defender)

FortiSIEM forwards its own logs — and front-end traffic is often visible at upstream firewalls, WAFs, or load balancers — into Sentinel via CEF/Syslog. This query hunts for traversal sequences in requests destined for FortiSIEM infrastructure and correlates with suspicious process execution telemetry from the appliance.

// Hunt 1: Path traversal sequences in requests to FortiSIEM management interface (CEF/Syslog)
let TraversalPatterns = dynamic(["../", "%2e%2e", "%252e%252e", "..%2f", "..%5c", "%c0%ae"]);
union isfuzzy=true (CommonSecurityLog), (Syslog)
| where TimeGenerated > ago(14d)
| where isnotempty(RequestURL) or isnotempty(SyslogMessage)
| extend RequestData = coalesce(RequestURL, SyslogMessage)
| where RequestData has_any (TraversalPatterns)
| where DeviceAddress in (FortiSIEM_Hosts) or DestinationIP in (FortiSIEM_Hosts) or RequestData has "phoenix"
| project TimeGenerated, SourceIP, DestinationIP, RequestData, DeviceProduct, Facility, Severity
| order by TimeGenerated desc;

// Hunt 2: Shell/downloader spawned by FortiSIEM services (if appliance syslog forwards process events, or EDR on a Linux collector)
Syslog
| where TimeGenerated > ago(14d)
| where SyslogMessage has_any ("bash", "/bin/sh", "curl", "wget", "nc ", "python")
| where SyslogMessage has_any ("httpd", "java", "glassfish", "phoenix")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;

Replace the FortiSIEM_Hosts watchlist reference with a Sentinel watchlist containing your FortiSIEM Supervisor/Worker/Collector IPs. If you don't have one yet, build it today — you should know exactly where your SIEM infrastructure lives before an attacker finds it for you.

Velociraptor VQL

If you have Velociraptor deployed on FortiSIEM collectors (or can push it during IR), this artifact hunts for the post-exploitation process tree and recent payload staging.

-- FortiSIEM CVE-2026-106173 post-exploitation hunt:
-- shells/downloaders spawned by web/application services + recent files in staging dirs
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE (CommandLine =~ '/(bash|sh|dash|python|perl|curl|wget|nc|ncat)'
   AND (Exe =~ 'httpd|apache|java|glassfish|phoenix'
        OR CommandLine =~ 'httpd|java|phoenix'))
   OR Exe =~ '/tmp/|/var/tmp/|/dev/shm/'

-- Companion: enumerate recently modified files in staging directories
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=['/tmp/*', '/var/tmp/*', '/dev/shm/*'])
WHERE Mtime > now() - 86400 * 7
  AND NOT IsDir
ORDER BY Mtime DESC

Remediation / Verification Script

Run this on the FortiSIEM Supervisor (and Workers/Collectors as applicable) via SSH to verify version, confirm exposure of the management interface, look for indicators of traversal-based exploitation, and check for suspicious service child processes. This is a triage script, not a substitute for patching.

#!/bin/bash
# CVE-2026-106173 FortiSIEM triage — run as root on Supervisor/Worker nodes
echo "=== FortiSIEM Version ==="
cat /opt/phoenix/config/version.txt 2>/dev/null || rpm -qa | grep -i phoenix | head -5

echo "=== Listening services (exposure check) ==="
ss -tlnp | grep -E ':(443|8443|22)\b'

echo "=== Traversal attempts in web access logs (last 7 days) ==="
find /var/log /opt/glassfish -name '*access*' -mtime -7 2>/dev/null | while read -r f; do
  grep -Ea '(\.\./|%2e%2e|%252e%252e|\.\.%2f|%c0%ae)' "$f" 2>/dev/null | tail -20
done

echo "=== Suspicious child processes of web/app services ==="
ps auxf | grep -E '(httpd|java|glassfish|phoenix)' | grep -E '(bash|sh$|curl|wget|nc |python|perl)' | grep -v grep

echo "=== Recently modified files in staging directories ==="
find /tmp /var/tmp /dev/shm -type f -mtime -7 -ls 2>/dev/null

echo "=== Persistence check: cron and systemd ==="
crontab -l 2>/dev/null; ls -la /etc/cron.d/ 2>/dev/null
systemctl list-units --type=service --state=running | grep -viE 'phoenix|glassfish|httpd|sshd|cron|rsyslog|systemd' | head -20

echo "=== Recent outbound connections ==="
ss -tnp state established | grep -vE ':(22|443|514|6514)\b' | head -30
echo "=== Triage complete. If any traversal hits or suspicious processes found, isolate and escalate to IR. ==="

Remediation

1. Patch immediately. Apply the fixed FortiSIEM release documented in Fortinet's PSIRT advisory for CVE-2026-106173. Pull the advisory directly from the source: Fortinet PSIRT Advisories — fortiguard.fortinet.com/psirt. Follow Fortinet's documented upgrade path for your current release train — do not skip intermediate upgrade steps if the advisory requires them. Verify Supervisor, Workers, and Collectors are all upgraded; an unpatched node is an unpatched environment.

2. Restrict management interface exposure — today, regardless of patch status. The FortiSIEM web interface should never be reachable from the internet or from general user networks. Enforce ACLs/security groups limiting TCP 443 access to a dedicated management VLAN and named administrator jump hosts. If your FortiSIEM interface is internet-exposed right now, you should assume it has already been scanned and likely probed — treat it as potentially compromised.

3. Monitor CISA KEV. If CVE-2026-106173 is added to the Known Exploited Vulnerabilities catalog, federal agencies face a binding remediation deadline under BOD 22-01 — and private-sector organizations should treat the KEV due date as their own SLA. Check daily until it either appears or exploitation reporting confirms otherwise.

4. Hunt retroactively. Patching closes the door; it does not evict an attacker who already walked through it. Run the detection queries above against at least the last 30 days of logs (longer if the appliance was exposed before the patch was released). Look specifically for: traversal sequences in access logs, service-spawned shells, new local accounts, unexpected SSH keys in /root/.ssh/authorized_keys and application user homes, and cron/systemd persistence.

5. Rotate credentials if any indicator of compromise is found. FortiSIEM stores credentials for WMI/SSH log collection, API integrations, and device polling. A compromised Supervisor means every one of those secrets must be considered burned — rotate domain service accounts, local device credentials, SNMP strings, and API tokens.

6. If compromise is confirmed, rebuild rather than clean. For an unauthenticated RCE on a central security appliance, the defensible IR position is a clean rebuild from known-good media on the patched version, with credential rotation and config restore from pre-exposure backups. Attempting surgical removal of implants from a compromised SIEM leaves you guessing about what you missed.

7. Verify egress controls. FortiSIEM appliances should have tightly scoped outbound rules: Fortinet update/licensing servers, your threat intel feeds, and little else. Any other egress from the appliance is an anomaly worth paging on.

Key Takeaways for the SOC

• Unauthenticated RCE + public PoC + Fortinet perimeter product = emergency change window, not next patch Tuesday.
• The SIEM is a tier-zero asset. Put it in your asset inventory with that classification, and protect its management plane accordingly.
• Patch and hunt in parallel. These are complementary actions, not alternatives.
• If your FortiSIEM interface is internet-reachable, that finding is its own incident.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub