Active Exploitation Detected: FortiSandbox JRPC Flaws (CVE-2026-39813)
Just saw the alert from Defused Cyber regarding active exploitation of Fortinet FortiSandbox. It looks like attackers are chaining three vulnerabilities: CVE-2026-39813, CVE-2026-39808, and CVE-2026-25089.
The critical one here is CVE-2026-39813 (CVSS 9.1), which is a path traversal flaw in the FortiSandbox JRPC API. Given the active exploitation status in the last 24 hours, if you have these appliances exposed—even just to management interfaces—you need to check logs immediately.
Since the JRPC API handles critical analysis tasks, spotting malicious traffic can be difficult. I'd recommend checking for anomalous POST requests that might be attempting directory traversal.
Here is a quick snippet to hunt for suspicious API calls on the appliance:
# Hunt for unusual JRPC API traffic in access logs
zcat /var/log/nginx/access.log.*.gz | grep "rpc" | grep "POST" | awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn | head -20
If you see anomalous source IPs or weird traversal attempts (like `../`), assume compromise.
Is anyone seeing specific IOCs for these yet, or is it mostly generic scanning behavior at this stage?
Thanks for the heads-up. We saw a spike in anomalous JRPC traffic on our honeypot about 12 hours ago. The requests look like they're trying to break out of the chroot environment using that path traversal bug.
For those using the Elastic Stack, try this KQL query to spot the traversal attempts:
destination.port:443 AND url.path:*rpc* AND url.query:*..%2F*
Patch ASAP, especially if your sandbox isn't fully isolated from the rest of the network.
This is a nightmare for patch management. FortiSandbox often requires offline update packages for air-gapped networks. These appliances frequently sit on the edge with excessive trust.
We're blocking external access to the JRPC API at the firewall level as a temporary mitigation until we can schedule downtime. It breaks some remote management features, but it's better than risking an RCE chain.
Yuki raises a valid point about the patching lag. For those stuck waiting for offline packages, focus on detection controls to satisfy your auditors. You need to verify if the JRPC interface was actually touched. If you're reviewing raw logs, hunt for the specific traversal strings targeting the API endpoint:
grep "POST /api/rpc" /var/log/fortisandbox/access.log | grep -E "\.\./"
This helps confirm if the vulnerability was triggered before you could block it.
Building on Omar's point about the breakout—once the chroot is bypassed, attackers often write payloads to memory-backed filesystems to avoid disk forensics. You should check /dev/shm and /tmp for suspicious binaries immediately.
If you have shell access, run this to find recently modified files:
find /dev/shm /tmp -type f -mtime -1 -ls
This simple step often reveals the webshell or loader before it obfuscates itself, giving you a concrete indicator of compromise for your reports.
Solid advice from Mike. To complement that file check, you should also verify active network sockets or suspicious process hierarchies, as these exploits often spawn reverse shells back to C2. If you have shell access, run this to spot unauthorized child processes:
ps -ef --forest | grep -E "(fortisandbox|nobody)" | grep -v grep
Identifying unexpected forks or distinct shell interpreters under the service account is a key indicator that the chroot breakout was successful.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access