CVE-2025-25256

What it actually does

CVE-2025-25256 is an unauthenticated OS command injection vulnerability in Fortinet FortiSIEM. A crafted CLI request can cause FortiSIEM to pass attacker-controlled input to the underlying operating system without proper neutralization, allowing arbitrary command execution with the privileges of the affected FortiSIEM service. Because authentication is not required and FortiSIEM is commonly deployed as a high-value monitoring platform with broad network visibility, successful exploitation can lead to appliance takeover, payload staging, credential or log access, lateral movement support, and tampering with security telemetry.

Why it matters to the business

A successful attack can compromise a central security monitoring system, potentially disrupting alerting, hiding intrusions, exposing sensitive log data, and giving attackers a foothold in a privileged part of the network. The CVSS score is critical, EPSS is high at 0.60344, the issue is described as weaponized, and it has been public for 363 days, so unpatched internet-accessible or broadly reachable FortiSIEM systems should be treated as urgent exposure even though it is not currently listed in CISA KEV and is not specifically marked as ransomware-associated.

How an attack unfolds

An attacker first identifies a reachable FortiSIEM instance running an affected version: 7.3.0 through 7.3.1, 7.2.0 through 7.2.5, 7.1.0 through 7.1.7, 7.0.0 through 7.0.3, or versions before 6.7.9. The attacker then sends a specially crafted CLI request containing command metacharacters or command-substitution syntax that FortiSIEM fails to sanitize. When the vulnerable component processes the request, the injected operating-system command executes on the FortiSIEM appliance. In a real intrusion, the first command is commonly used to verify execution, retrieve a second-stage payload, create persistence, enumerate the host and network, collect logs or credentials, or disable/tamper with monitoring. The provided threat context references a RomCom campaign, but defenders should validate whether any observed activity is actually tied to this FortiSIEM issue rather than assuming attribution from CVE metadata alone.

How to fix it

Upgrade FortiSIEM to a fixed release immediately. Based on the affected version ranges, upgrade 7.3.x deployments to 7.3.2 or later, 7.2.x deployments to 7.2.6 or later, 7.1.x deployments to 7.1.8 or later, 7.0.x deployments to 7.0.4 or later, and 6.7.x or older deployments to 6.7.9 or later, preferably the latest supported Fortinet-recommended release. If immediate patching is not possible, restrict access to FortiSIEM management and CLI interfaces to trusted administrative networks only, block direct internet exposure, enforce VPN or bastion access, apply firewall allowlists, monitor for abnormal outbound connections from the appliance, and consider isolating the system until it can be upgraded. After patching, rotate credentials and secrets accessible to FortiSIEM if exploitation is suspected, and verify appliance integrity against a known-good baseline.

How to confirm the fix worked

Confirm the installed FortiSIEM version is no longer within the vulnerable ranges. Validate that management and CLI interfaces are not reachable from untrusted networks. Review vendor release notes or package metadata to confirm the fixed build is installed. Where safe and authorized, use a non-destructive vulnerability scanner or vendor-supported check to verify the command-injection condition is no longer present; do not run exploit payloads on production systems. Confirm compensating controls by testing that only approved administrative source IPs can reach FortiSIEM management services. After upgrade, review recent logs and process history for signs of pre-patch exploitation, because installing the fixed version does not remove attacker persistence or previously created artifacts.

Typical attack path

1. Discover a FortiSIEM appliance through internet scanning, network reconnaissance, or exposed management interfaces.
2. Fingerprint the FortiSIEM version or infer vulnerability from service behavior and patch level.
3. Send a crafted unauthenticated CLI request containing OS command injection syntax.
4. Execute a simple validation command such as id, whoami, uname, or a DNS/HTTP callback to attacker infrastructure.
5. Download or stage tooling using curl, wget, python, perl, bash, or similar utilities if outbound access is available.
6. Establish persistence or repeated access through scheduled tasks, modified scripts, added SSH keys, or deployed web shells/tools where possible.
7. Access or manipulate FortiSIEM logs and configuration to gather intelligence, steal credentials, suppress alerts, or cover tracks.
8. Use the compromised monitoring platform as a pivot point for internal reconnaissance and lateral movement.

How to detect it

Check whether exploitation already occurred by reviewing FortiSIEM application logs, web or management access logs, operating-system audit logs, shell history, process accounting, EDR telemetry, and network egress records from FortiSIEM appliances. Look for unauthenticated or unusual CLI requests followed by shell execution, commands containing metacharacters such as ;, |, &&, `, $(), or encoded payloads, and FortiSIEM service processes spawning /bin/sh, bash, curl, wget, python, perl, nc, ncat, socat, or openssl. Investigate outbound DNS, HTTP, HTTPS, or raw TCP connections from FortiSIEM to unfamiliar external hosts, especially shortly after suspicious management requests. Review file-system changes under FortiSIEM application directories, /tmp, /var/tmp, cron locations, systemd unit paths, SSH authorized_keys, and recently modified scripts. Also look for gaps, truncation, deletion, or unexpected rotation of FortiSIEM logs that may indicate anti-forensics. Because the supplied threat-actor context is not clearly specific to this vulnerability, use behavioral evidence and infrastructure indicators from confirmed incidents rather than relying on attribution labels alone.

• /opt/phoenix/log/
• /opt/phoenix/bin/
• /bin/sh -c
• bash -c
• curl http://
• curl https://
• wget http://
• wget https://
• python -c
• python3 -c
• perl -e
• nc -e
• ncat -e
• socat EXEC
• /tmp/
• /var/tmp/
• /etc/cron.d/
• /var/spool/cron/
• /etc/systemd/system/
• authorized_keys
• chmod +x /tmp
• chmod +x /var/tmp
• rm -f /opt/phoenix/log
• truncate -s 0
• ; id
• ; whoami
• ; uname -a
• && id
• && whoami
• `id`
• $(id)
• $(whoami)

What your security team should do

• Prioritize emergency patching of all FortiSIEM appliances because the vulnerability is unauthenticated, critical severity, high EPSS, and weaponized.
• Immediately inventory all FortiSIEM versions and identify any systems in the affected ranges: 7.3.0-7.3.1, 7.2.0-7.2.5, 7.1.0-7.1.7, 7.0.0-7.0.3, and before 6.7.9.
• Remove internet exposure and restrict FortiSIEM management/CLI access to trusted administrative networks while upgrades are being completed.
• Hunt for exploitation before and after patching, focusing on suspicious CLI requests, child shell processes, outbound callbacks, unexpected file writes, and log tampering on FortiSIEM hosts.
• If compromise is suspected, preserve forensic evidence, isolate the appliance, rotate credentials and API keys available to FortiSIEM, and rebuild from trusted media if integrity cannot be established.
• Add detections for FortiSIEM spawning shell or network utilities and for suspicious outbound traffic from FortiSIEM appliances to unknown destinations.
• Review security monitoring coverage gaps, because compromise of a SIEM can blind detection and incident response workflows.