CVE-2026-20245 is a local privilege escalation in Cisco Catalyst SD-WAN Manager. An authenticated local attacker uploads a crafted CSV through the tenant-upload feature and gets command execution as root, because the upload does not filter what is in the file.
The command is one line:
request tenant-upload tenant-list /home/admin/evil_tenant.csv vpn 0
And the payload appends a user to the system:
grep -q '^troot:' /etc/passwd || echo 'troot:x:0:0:root:/root:/bin/bash' >> /etc/passwd
A root account named troot — one character from the real thing, which is the point.
The chain, and why the CVE is the least of it
Mandiant traces the intrusion from late 2025 to April 2026 against service-provider SD-WAN infrastructure:
- Initial access via unauthorised peering connections, possibly through CVE-2026-20127 or CVE-2026-20182
- Theft or manipulation of the
vmanage-adminaccount - Changing the default
adminpassword - Exfiltrating configuration through the web interface
- CVE-2026-20245 for privilege escalation
- Creating the rogue troot root account
Steps one and two are the ones to sit with. Both CVE-2026-20127 and CVE-2026-20182 are peering authentication bypasses that are unauthenticated and remote, and both grant administrative privileges.
So the zero-day is the escalation, not the entry. The entry was two remote auth bypasses in the peering layer — the part of the system that exists to trust other network devices.
The cleanup is the professional part
After finishing, the actor:
- Deleted evil_tenant.csv and its backups
- Restored the original system configuration
- Ran a validation script to verify every indicator had been removed
That last item is what distinguishes this from most intrusions. The operator did not just tidy up; they wrote something to check the tidying worked.
If you are hunting this after the fact, you are looking for what a competent cleanup missed — the troot account, which had to stay for access to persist, and the network indicators the actor did not control.
Patch, precisely
Fixed releases:
| Branch | Fixed in |
|---|---|
| 20.9 | 20.9.9.2 |
| 20.12 | 20.12.7.2 |
| 20.15 | 20.15.4.5 and 20.15.5.3 |
| 20.18 | 20.18.3.1 |
| 26.1 | 26.1.1.2 |
Two 20.15 entries because there are two supported trains — check which you are on rather than taking the higher number.
Indicators
The malicious file:
/home/admin/evil_tenant.csv- SHA256
b82936f37648518425c7d3cf9e09eaffa41d7cdb3840f6a40287e3a108880f7b
Attacker IPs published by Mandiant: 126.51.108[.]152, 76.92.245[.]217, 207.190.37[.]94, 23.245.7[.]178, 153.186.231[.]233, 167.179.79[.]189, 45.32.38[.]160, 209.137.225[.]101.
The file hash is close to useless retrospectively — the actor deleted it. The IPs and the account are what survive.
Why service providers, and why you should care anyway
The confirmed targeting is service-provider SD-WAN infrastructure. That is a supply-chain position: whoever controls a provider's SD-WAN manager controls routing for every downstream customer of that provider.
Mandiant notes potential exposure across banks, retail, healthcare and technology services — not because those were targeted, but because they sit behind the infrastructure that was.
This is the same shape as the Polish CHP plant reached through a distribution operator's private APN: the compromise happened in shared infrastructure that none of the affected organisations owned or monitored.
What to do
- Check your version against the table, and check the branch, not just the number.
- Grep
/etc/passwdfor accounts you did not create, on every SD-WAN Manager instance.trootspecifically. - Audit the
vmanage-adminandadminaccounts — password change history and last-used. - Patch CVE-2026-20127 and CVE-2026-20182 too. They are the unauthenticated remote entry; the escalation is worthless without them.
- Ask your connectivity provider whether they were affected. If you buy managed SD-WAN, this is their patch to apply and your exposure.
