Cisco SD-WAN Manager: Actively Exploited File Overwrite (CVE-2026-20122)
Just saw the disclosure regarding Cisco Catalyst SD-WAN Manager (formerly vManage). Cisco has confirmed active exploitation in the wild for CVE-2026-20122.
While the CVSS score is 7.1, this is particularly nasty because it allows an authenticated, remote attacker to overwrite arbitrary files on the local file system. If an attacker already has a foothold (or valid credentials), this essentially gives them persistence or the ability to overwrite config files for full control.
If you are managing SD-WAN infrastructure, you need to treat this as critical, especially if your management interface is internet-facing.
Here is a quick check if you want to verify your current build version via CLI:
show version | include "Release"
Also, keep an eye on your system logs for any unusual file modification events or unexpected restarts of the vmanage process. We are currently hunting for IOCs related to this specific vector and looking for suspicious wget or curl commands originating from the management interface itself.
Has anyone observed specific Indicators of Compromise (IOCs) tied to this active exploitation yet, or is everyone still in the dark on the specific exploit kit being used?
We noticed some anomalies on our edge routers yesterday morning. Specifically, we saw configuration drift that didn't match our change logs. After patching, we ran this script to audit file integrity across the cluster:
find /data/local/ -type f -mtime -1 -ls
It turned up a few modified config files that we couldn't attribute to any admin account. I'd recommend checking file modification timestamps immediately if you can't patch right away.
As a baseline precaution, if you can't patch immediately, ensure strict ACLs on the management interface. There is no reason for the SD-WAN Manager UI (port 443) to be accessible from the entire internet. We've blocked all non-VPN access to ours. Arbitrary file overwrite often leads to RCE via SSH key replacement, so assume the worst if you see suspicious auth logs.
This feels like a precursor to ransomware attacks on network infrastructure. Overwriting arbitrary files usually means they are targeting the system configuration to disrupt connectivity or inject SSH keys for lateral movement. We've added a specific detection rule in our SIEM to look for consecutive failed auth attempts followed by configuration file writes.
Solid advice. Beyond integrity checks, hunting for recent file modifications on the manager itself is crucial. You can identify suspicious changes in the last 24 hours using:
find /data -type f -mtime -1
Has anyone correlated specific API endpoint hits in the access logs with these file events yet? That would help tighten the WAF rules while we patch.
Excellent hunting advice. Since this is a file overwrite via the API, you should also hunt for unusual PUT or POST requests in the web server logs, specifically those returning 200 OK status. Aggregating these by source IP can reveal the compromised credential source:
zcat /var/log/nginx/access.log.*.gz | grep -E "PUT|POST" | awk '$9 == 200' | awk '{print $1}' | sort | uniq -c
Since file overwrite is the core mechanism, attackers will likely target SSH keys for persistence. Verify that authorized_keys files haven't been modified unexpectedly, as this allows them to bypass the UI controls entirely later.
Run this to find changes in the last 24 hours:
find /home /root -name "authorized_keys" -mtime -1 -exec ls -l {} \;
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access