A recent technical disclosure from Horizon3.ai details the mechanics behind CVE-2025-64155, a critical remote command-injection vulnerability affecting Fortinet FortiSIEM.
Public exploit code is now available, shifting this issue from theoretical risk to practical, real-world exposure. This post distills the research into a high-signal summary for defenders who need to understand what’s happening—and why it matters—without reading a full exploit walkthrough.
Original research and full technical disclosure:
Horizon3.ai — Three Years of Remotely Rooting Fortinet FortiSIEMPoC repository: https://github.com/horizon3ai/CVE-2025-64155
What Actually Went Wrong
At a high level, FortiSIEM exposed backend functionality that:
- Accepted attacker-controlled input
- Passed that input into OS-level commands
- Failed to properly sanitize or constrain it
- Executed those commands with elevated privileges
This is classic command injection—but in a uniquely dangerous context:
- No authentication required
- Network reachable
- Runs as a privileged service
- Resides on the security control plane
According to the research, this flaw (or closely related logic) persisted across multiple versions and years, meaning many organizations likely ran vulnerable code without realizing it.
Horizon3.ai summarizes the exploitation path as:
argument injection → file write → root code execution
How the Exploit Chain Works (High-Level)
1. Entry Point: Network-Reachable FortiSIEM Service
The proof-of-concept targets a FortiSIEM service that:
- Accepts remote input over TCP
- Passes attacker-influenced values into an OS-level operation
Fortinet advisories characterize the issue as OS command injection via crafted TCP requests, consistent with CWE-78.
2. Core Bug: Argument Injection Into a Privileged Command
This is not classic ; rm -rf / shell injection.
Instead, the exploit abuses argument/flag injection:
- Attacker input is treated as additional command-line arguments
- Those arguments alter how an internal tool or wrapper behaves
Why this matters:
- Developers may believe they are “not letting users run commands”
- Unsanitized input can still change command behavior
- No shell escape is required—only control over arguments the program already accepts
The attacker steers the program rather than breaking out of it.
3. Objective: Writing a File to a Sensitive Location
Per the PoC README, the exploit:
“abuses an argument injection to write a file to gain code execution as root.”
Conceptually, the chain is:
- Force a privileged FortiSIEM component to fetch or accept attacker-controlled content
- Write that content to disk
- Place it somewhere that will later be executed or loaded by a privileged process
This write-what-where outcome is common in appliance compromises, where services routinely run as root and manage system maintenance tasks.
4. Trigger: Scheduled Task Executes the Payload
The PoC notes that execution occurs after waiting approximately one minute, implying:
- FortiSIEM runs a recurring privileged task (cron or equivalent)
- The attacker-written file lands in a location:
- Executed directly by the task, or
- Indirectly executed via overwrite or inclusion
This is a key point:
The exploit is not a one-shot command execution. It leverages FortiSIEM’s own scheduled maintenance behavior to achieve execution and persistence.
5. Why the Result Is Root Access
The PoC explicitly results in root-level code execution.
This typically occurs because:
- The vulnerable service runs as root, and/or
- The scheduled task executing the payload runs as root (common on appliances)
No separate privilege-escalation vulnerability is required.
What This Means for Defenders
Network-Level Indicators (FortiSIEM Host)
- Unexpected outbound HTTP requests from FortiSIEM
- Connections to non-enterprise IPs or domains
- Outbound traffic aligning with minute-based scheduling intervals
- DNS lookups to domains the SIEM host does not normally resolve
Host-Level Indicators (FortiSIEM Appliance)
- New or modified files in:
- Cron directories
- Update or maintenance paths
- Service startup locations
- Scheduled task logs showing unfamiliar scripts or binaries
- Process tree anomalies:
- Cron or FortiSIEM services spawning shells or interpreters
- Unexpected use of
bash,sh,curl, orwget
Why This Is Easy to Miss
Many organizations do not deploy host-level EDR or telemetry on SIEM appliances.
If you rely solely on FortiSIEM’s own logs, a root-level attacker can suppress, modify, or erase evidence of compromise.
Real-World Impact
A successful attacker can:
- Execute arbitrary OS commands as root
- Establish persistent access on the SIEM host
- Read or manipulate SIEM logs and alerts
- Harvest stored credentials and API tokens
- Blind or alter detection and response workflows
- Use the SIEM as a trusted pivot point into the network
This is not just a host compromise—it is a loss of security visibility and trust.
Why FortiSIEM Is a High-Value Target
Attackers prioritize systems that offer:
- Broad visibility
- Stored secrets
- Trusted network positioning
FortiSIEM provides all three.
A compromised SIEM allows attackers to see what defenders see, learn how alerts trigger, suppress detection, and move laterally with confidence.
Bottom Line
CVE-2025-64155 is severe not because it is novel, but because it is fundamental:
- Unauthenticated
- Remote
- Command injection
- Root-level impact
- Public exploit code
- Targets a core security system
Once exploit code is public, exposure quickly becomes exploitation.
If FortiSIEM is deployed in your environment, this deserves immediate attention—not backlog prioritization.
Support the Project
If you find content like this useful and want to support continued research and publishing, consider using the link below:
- Thetis Pro FIDO2 Security Key, Two Factor Authentication NFC Security Key:
https://amzn.to/45bfOra - Review other CVEs that have come out as well! CVE-2026-0625: Actively Exploited RCE in Legacy D-Link DSL Routers
Don’t Miss out on a Post Subscribe today!
Leave a Reply
You must be logged in to post a comment.