The Password Was Restored, but the Device Had Gained Another Root: Cisco SD-WAN CVE-2026-20245

1 The password looked normal again, but the appliance had already told a different story

1.1 A short password change opened the fabric and then disappeared

In the early hours of March 7, 2026, a Cisco Catalyst SD-WAN Manager at a service provider accepted management activity from an unauthorized control-plane source. The operator behind that activity did not begin with a conspicuous web exploit. A new rogue peer created a path to the appliance, and an SSH session arrived under vmanage-admin, an internal high-privilege account used by Catalyst SD-WAN control components. From that session, the operator changed the password of the default admin account. The change was brief, instrumental, and designed to disappear into the device's final state.

The newly set password opened the management application on port 8443. Within seconds, the session authenticated through POST /j_security_check, enumerated WAN edge devices and controllers, and requested attached and running configuration data through the /dataservice API. When the collection was finished, the still-active SSH session changed the admin password back to its original value. An administrator arriving later could sign in with the familiar credential. A comparison limited to the current password or current user list would have missed the interval in which a second party had authenticated and read the fabric.

1.2 A month later, a Tenant CSV turned a product account into UID 0

A month later, the intrusion reached the operating system through a different route. An authenticated admin SSH session invoked what appeared to be a product maintenance command: request tenant-upload tenant-list /home/admin/evil_tenant.csv vpn 0. The command named a CSV and the device treated it as a tenant-placement upload. Its script log recorded the product handler and eventually reported that the tenant placement file had loaded successfully. The CSV also carried shell syntax that the privileged workflow failed to keep as inert data. That syntax copied system account files and appended a new account named troot with UID and GID zero.

Mandiant subsequently observed a successful su from admin to troot. The event closes a gap that often remains open in privilege-escalation reporting. The malicious row was written to /etc/passwd, produced a usable identity, and that identity was used. The operator then restored configuration and account files, removed the CSV and hidden backups, and ran a validation loop that checked whether the working files and the troot entry had disappeared. Service continuity and forensic cleanup were part of the same procedure.

CVE-2026-20245 connected the product's administrative authority to the underlying Linux superuser. A netadmin can legitimately manage the fabric; root can read, alter, and erase the platform that stores device identities, templates, certificates, routes, audit records, and operational secrets. In a centralized SD-WAN deployment, obtaining local root changes the investigation from a user-account incident into a control-plane trust incident.

2 One Linux host could speak with the authority of an entire fabric

2.1 Manager, Controller, Validator, and Edge devices carry different kinds of power

Catalyst SD-WAN separates functions that older WANs often performed independently on each router. The component formerly called vManage, now Catalyst SD-WAN Manager, provides the web application, API, templates, monitoring, and orchestration. The former vSmart, now Controller, distributes control policy and route information. The former vBond, now Validator, participates in device authentication and orchestration. WAN edge devices forward the actual site traffic. Cisco changed the product names gradually around the 20.12 generation, so current documentation, older commands, and live log messages still mix Catalyst, Viptela, vManage, vSmart, and vBond terminology.

That naming transition matters during collection. A team that inventories only “Managers” can miss a log or archive labeled vManage; one that searches only show control connections may overlook the Validator's show orchestrator connections equivalent. The case inventory should retain both the contemporary role and the historical product name for every node. It should also record hostname, system IP, serial, cluster membership, disaster-recovery pairing, deployment owner, exact running release, and every management address. A complete topology is a prerequisite for a complete admin-tech collection.

Peering creates a trusted control channel between SD-WAN components through device identity, cryptographic material, and a protocol handshake. Cisco log examples expose fields such as peer-type, peer-system-ip, public-ip, public-port, site-id, domain-id, and state. Once an unauthorized system is accepted as a peer, its traffic can approach internal management surfaces through a path the surrounding network may regard as part of normal control-plane operation.

2.2 vmanage-admin, admin, netadmin, and root are not interchangeable identities

The three accounts in this incident belong to three different layers. vmanage-admin served the internal control-component path and was used for SSH after rogue peering. admin represented the standard product administrator used for the web application and CLI. troot was an operating-system account created by the exploit. Cisco and Mandiant both state that the two default product accounts do not possess root shell access. CVE-2026-20245 matters precisely because it bridges that intended separation.

Control components are unusually attractive investigative targets because they combine centralized knowledge with limited endpoint-style telemetry. Many organizations deploy EDR to ordinary servers but cannot install the same agent inside a network appliance. Local storage and rolling logs may be modest, while the Manager can still expose device inventory, versions, templates, controller relationships, authentication settings, certificate references, routes, and VPN definitions. An attacker gains a broad operational map from a host that may retain less evidence than an employee laptop.

In a service-provider or multi-tenant environment, evidence determines reach. One compromised Manager may see several tenants, regions, clusters, or customer fabrics, while platform access alone leaves the set of changed tenant configurations unresolved. API objects, tenant and VPN identifiers, configuration revisions, task records, template attachments, and actual edge-device state identify which data was read, which changes propagated, and which tenants merely shared the platform.

3 Three periods share a victim and trust material, but not yet a proven operator

3.1 The earliest peers remain a hypothesis; March rules out the easiest explanation

From late 2025 through January 2026, Mandiant observed multiple unauthorized peering connections to SD-WAN Manager systems in the victim environment. CVE-2026-20127 and CVE-2026-20182 had not yet been publicly disclosed, and fixes were unavailable during part of that period. The two authentication bypasses were therefore plausible explanations. The public record supports a vulnerable-period hypothesis for those early connections without assigning either CVE to a specific session.

New rogue peering appeared in March. This time, the affected appliance ran a release that was not vulnerable to CVE-2026-20127, and Cisco confirmed to the investigation that the connection did not exploit CVE-2026-20182. Mandiant described stolen certificate material from an earlier compromise of the same device as another possible path. No public certificate, serial number, private-key event, or handshake transcript was published, so the certificate explanation remains a focused inquiry with unresolved status.

The April privilege escalation has a different evidence density. A named administrative session, an exact CLI command, a path, a product script invocation, recovered CSV content, account-file entries, and a successful su event can be joined. Cisco assigned the defect CVE-2026-20245 and bug ID CSCwu18563, identified the required netadmin privilege, and confirmed that a crafted file could execute arbitrary commands as root on Controller, Manager, and Validator products. Mandiant reported the issue and documented its use in the victim environment.

Mandiant explicitly states that it is unclear whether the late-2025-to-January activity and the March rogue peering were conducted by the same threat actor. The April escalation sits inside the same broader incident response and follows documented administrative access, but it does not retroactively establish ownership of every earlier peer. Asset continuity and actor continuity are different propositions. The former supports a combined investigation; the latter still requires independent evidence.

The timeline keeps the three evidence periods on separate lanes. They still belong on the same case board because they touched the same fabric, appliances, and trust material; operator continuity retains a question mark until certificate fingerprints, SSH keys, infrastructure, procedure, or another independent feature connects the periods. That distinction affects customer notification, intelligence sharing, legal posture, and the time range used to hunt related infrastructure.

3.2 Five March requests turn “configuration theft” into a searchable sequence

The web sequence published by Mandiant begins with POST /j_security_check. The request returned HTTP 200, indicating that the newly changed admin credential created a working application session. Roughly half a second later, the same source requested GET /dataservice/system/device/vedges and received about 10 KB. Another second brought GET /dataservice/system/device/controllers and a response of roughly 15 KB. The rapid, ordered calls are consistent with purposeful topology enumeration; a casual dashboard visit would normally produce a broader and less compressed request pattern.

The session then requested /dataservice/template/config/attached/<Device ID> and received a successful response. A following request for /dataservice/template/config/running/<Device ID> returned HTTP 400. Both results matter. The successful calls demonstrate data retrieval; the failed call records the operator's attempt and target even when the platform did not provide the expected object. A hunt that keeps only 2xx responses removes reconnaissance and failed object probing from the sequence.

A normalized record should preserve source control-plane address, target Manager, port 8443, raw and UTC time, HTTP method, path template, concrete device ID, status, response bytes, user agent, authenticated account, session identifier, and REST tracing ID. The tracing ID can connect a web request to Manager application logs; the session can connect several endpoints; the concrete device ID links the retrieval to a customer or template. A short aggregation over those fields provides substantially more signal than independent alerts on common GET requests.

The password changes join SSH and web activity. The attacker used vmanage-admin in SSH to alter admin, authenticated to the application as admin, and later used the surviving SSH session to restore the original value. Usernames alone cannot connect the interfaces because the actor changed identities between them. Device, corrected UTC, source path, ConfD transaction, target account, web session, and operation window create the bridge. Where NAT separates the apparent SSH and HTTPS sources, bastion and firewall records become necessary.

The content exposure must be derived from the actual response or a release-matched reconstruction. Device lists can reveal system IPs, site identities, models, health, and versions. Controller lists describe fabric roles and management topology. Attached configuration binds devices to templates. Running configuration can contain more detailed interface, routing, VPN, authentication, and certificate references. The retrieved topology and version data alone can guide targeted follow-on access; any clear-text secret exposure requires confirmation from the captured response or a release-matched test.

Investigators should record the 400 response alongside the successful downloads and compare the same API behavior in a controlled system running the victim release. That comparison can establish which fields a 200 response would ordinarily return and why the observed request failed, while preserving the distinction between reconstructed product behavior and captured victim data. It also helps identify whether the operator retried the object through another endpoint later in logs that were not included in the public excerpt.

4 The flaw has a narrow entrance and a devastating exit: crafted file in, root commands out

Cisco describes CVE-2026-20245 as an input-handling weakness in the command-line interface of Catalyst SD-WAN control components. Controller, Manager, and Validator are affected regardless of a special feature configuration. Exploitation requires a locally authenticated attacker with netadmin privileges. Cisco scored it 7.8 with CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Successful exploitation permits arbitrary commands as root on the underlying operating system.

“Local” describes the point at which this CVE is exercised; it does not require the original attacker to stand beside the appliance. Rogue peering, stolen credentials, a compromised bastion, a management VPN, or a separate authentication bypass can deliver a remote operator into the required context. In the documented intrusion, control-plane access and default accounts supplied the prerequisite. Risk triage that reads only AV:L can therefore place a central network controller below less consequential internet-facing software for the wrong reason.

Cisco has not published source for the tenant CSV parser, the privileged wrapper, or the CSCwu18563 patch. No reliable report can name an internal function or produce a source-level diff from those materials. The public evidence chain is still strong: the CLI accepts a path and VPN; /var/log/scripts.log records vconfd_script_upload_tenant_list.sh -cli path ... vpn 0; the recovered CSV remnant contains shell operations against system files; and account plus su evidence confirms the resulting root identity.

Cisco classifies the weakness under CWE-116, improper encoding or escaping of output, and describes malicious data passing through an upload feature that did not filter it correctly. The payload shows shell syntax reaching a privileged execution context instead of remaining CSV data. The public record does not reveal the specific column, delimiter state, quote parser, command-construction function, or subprocess API. This report does not invent those missing internals. If a later advisory, binary patch, or legally obtained appliance image exposes them, the chain can be extended inward.

CVE-2026-20127 and CVE-2026-20182 occupy an earlier stage. Both are critical peering-authentication bypasses scored CVSS 10.0 that can yield an internal high-privilege, non-root account. CVE-2026-20245 is the authenticated local step from netadmin to root. Cisco's June remediation guide names the two bypasses as known ways an unauthenticated remote attacker can obtain the prerequisite for 20245, while separately preserving the valid-credential scenario. Patching only one stage leaves another route available.

NVD records a CISA SSVC assessment of active exploitation, no full automation, and total technical impact. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog. Those signals align with the observed incident and justify urgency, but they do not replace asset evidence. An internet-exposed, vulnerable controller with an authentication-bypass path has a short route to root; an isolated, fixed system without credential exposure does not. The same CVE label needs environment-specific reachability.

4.1 “Local” describes the final step, not the attacker’s journey to the appliance

The CVSS vector for CVE-2026-20245 describes the instant at which the vulnerable function is used. At that instant, the operator is authenticated locally and holds a low privilege relative to root. The vector does not describe the beginning of the intrusion. In the documented case, a rogue control-plane relationship and product accounts supplied the earlier movement. In another deployment, the prerequisite could arrive through a leaked SSH key, shared operations credential, compromised bastion, vendor session, or administrator workstation.

The shortest exposure model combines internet-reachable control components with an unpatched peering bypass. CVE-2026-20127 or CVE-2026-20182 can provide an internal high-privilege, non-root identity without prior authentication; 20245 can then convert that identity into operating-system root. The two stages turn a nominally local escalation into a compact remote chain. Evidence collection, port restriction, and fixes for both the bypass and escalation belong in one coordinated maintenance operation.

A second model has already fixed both authentication bypasses but still carries credential or certificate risk. Cisco's June guide is explicit that closing the known unauthenticated paths does not remove exposure to an attacker who holds valid credentials. A configuration export, shared secret, surviving web session, or stolen peer certificate can preserve access. In this model, the 20245 upgrade, credential rotation, certificate review, and session revocation remain coupled.

A third model places the control plane behind a management network reached only by a shared bastion, a third-party network operations center, or automation. The path is longer but shifts the entry problem into identity and the operations supply chain. An ACL that permits only the bastion cannot distinguish an approved engineer from an adversary operating through the same host. The inventory must name who can initiate SSH, NETCONF, web, API, and peer connections and where each credential is stored.

A fourth model still runs an affected release but is genuinely isolated and has no evidence that a valid credential escaped. Its immediate priority can be lower than an exposed, reachable controller, but it must still move to a supported fixed release because the next identity compromise would make the vulnerable path available again. A lower priority should be supported by tested network, identity, and version conditions with a review date. “It is inside the network” is not a tested condition.

A useful operational predicate is reachable entry ∧ netadmin obtained ∧ affected release ∧ upload path available → root. Each term receives a data source and last-verification time. An unknown term leaves exposure undetermined. Teams can close different parts through segmentation, bypass fixes, credential controls, and release upgrades, and the remaining route stays visible to both network and security owners.

The file arrived as a maintenance artifact, but its first concern was how to put the device back. The recovered payload did not begin by creating troot. It first inspected /usr/share/viptela/vbond_vsmart_tenant_list and tested whether the file contained a value redacted from the public report. Depending on existence and that condition, it wrote present or absent into /home/admin/.orig_vbond_vsmart_tenant_list.state. When a restorable original existed, it copied the file with cp -a to a hidden backup under the admin home directory.

if tenant_list exists and condition matches:
    echo absent  > .orig_vbond_vsmart_tenant_list.state
elif tenant_list exists:
    echo present > .orig_vbond_vsmart_tenant_list.state
    cp -a tenant_list .orig_vbond_vsmart_tenant_list
else:
    echo absent  > .orig_vbond_vsmart_tenant_list.state

The state file answers a subtle rollback question. A backup alone can restore prior content, but it cannot distinguish “the original file existed” from “the original state was absence.” The one-word marker let the cleanup code either put an original file back or remove the new file. It also gives investigators semantic evidence: the hidden file names and the present/absent branch are artifacts of a planned prepare-modify-restore sequence, not arbitrary administrator copies.

Two further commands copied /etc/passwd and /etc/shadow to .orig_passwd and .orig_shadow. The leading dots hide the files from a default directory listing but not from metadata, a complete listing, an admin-tech archive, or file-system recovery. Mandiant did not recover the complete contents of these backups, so their IOC hashes are unknown. “Not recovered” must not be rewritten as “never created,” because the payload itself records the creation commands.

The account addition used an idempotent guard. A grep for a line beginning troot: ran before each append, avoiding duplicate entries when the exploit was repeated. The passwd row was troot:x:0:0:root:/root:/bin/bash: name troot, shadow-managed password, UID zero, GID zero, descriptive field root, home /root, and a Bash login shell. Linux authorization follows the numeric UID. A different display name does not make this account less privileged than root.

cp -a /etc/passwd /home/admin/.orig_passwd
cp -a /etc/shadow /home/admin/.orig_shadow

grep -q '^troot:' /etc/passwd ||
  echo 'troot:x:0:0:root:/root:/bin/bash' >> /etc/passwd

grep -q '^troot:' /etc/shadow ||
  echo 'troot:<hash>:19000:0:99999:7:::' >> /etc/shadow

The shadow row carried a password hash that Mandiant appropriately redacted. Its operational importance comes from the actor's knowledge of a credential that let the existing admin session perform a successful su to troot. Had the evidence ended with a passwd diff, analysts could still ask whether execution completed or whether the account could authenticate. The successful su event establishes actual use of the newly created identity.

The payload's care around the tenant list reveals an availability objective. Leaving the product file corrupted could create errors, reloads, or administrator attention. Saving original state, attaining root, restoring business files, and validating cleanup reduced that risk. Exploitation and operational discipline were implemented together. That sequence is useful for detection because it is more stable than the filename: preparation, privileged account change, use, restore, deletion, and validation form a behavioral signature.

4.2 Linux ignored the name troot and obeyed its UID 0

In /etc/passwd, a username is primarily a login and display label. Kernel permission checks use the numeric UID. The payload set the third field of the troot row to zero, so processes launched under it received superuser authority. GID was also zero, the home directory was /root, and the login shell was /bin/bash. A hunt that checks only whether the username is literally “root” will miss this account class; every UID 0 row must be compared with an approved baseline.

Passwd and shadow carry complementary state. Passwd stores public account attributes and an x marker indicating that the password verifier lives in shadow. Shadow stores the verifier and aging fields. Adding only a passwd row might still create risk through keys or another authentication path, but this payload updated both databases and supplied a verifier controlled by the operator. The later successful su demonstrates that authentication through the new entry worked.

An su event differs from a fresh SSH login. It changes identity inside an existing admin terminal, so the network layer does not see a new connection and the target account does not authenticate from a new source IP. The investigator needs to connect the auth event's originating user, target, terminal, process, and time back to the original admin SSH session. A query for “troot login from an IOC address” can miss the only successful use in the public record.

Restoring passwd and shadow removes the current account but does not automatically terminate a root process already running, an open shell, an installed service, a cron entry, an authorized key, a replaced library, or a modified configuration. Public reporting confirms troot and cleanup; it does not claim those additional persistence methods were observed. They still belong in the examination because the attained authority made them possible. Results should distinguish no finding from insufficient evidence.

The restore method changes the residual evidence. Replacing both files with the original backups can produce byte-for-byte equality with a trusted pre-incident copy, while an intermediate append and su remain true. Removing one line in place can leave changed inode or ctime behavior. Preserve current files and metadata before comparison, and retain the trusted reference used. A current hash is one observation in the state sequence, not a history of the file.

The account inventory should extend above and beside Linux. Export product users and roles, AAA or TACACS identities, SSH authorized keys, API tokens, web sessions, certificate identities, and cluster-internal accounts. vmanage-admin, admin, and troot belong to internal component communication, product administration, and the operating system respectively. Treating all three as one “administrator” obscures the very privilege transition the exploit performed.

These linked records, not one spectacular log line, carry the path from peer to root. The first row of the chain explains management access. A control-connection event supplies peer role, system IP, public address and port, site, domain, protocol, and state. An SSH event supplies vmanage-admin, source, authentication method, and public-key fingerprint. A ConfD rollback supplies the actor that changed admin, its transaction ID, path, and later restoration. Web and API logs supply authentication, resource endpoints, response status and size, session, and tracing identifier.

The second row explains the CVE. Command history preserves the request tenant-upload invocation. The script log records the concrete handler, input path, and VPN. File-system remnants supply the CSV and hidden backups. Passwd and shadow supply the UID 0 identity. Authentication records supply the successful transition from admin to troot. When ordered by device and corrected time, these artifacts show data entering a product function and authority emerging in the Linux account database.

Time must be normalized before the join. Cisco documents that Manager task and administration logs use UTC, while system syslog, exported file timestamps, upstream collectors, and legacy formats can differ. Mandiant's examples include both ISO 8601 and traditional syslog form. Each source should retain raw time, assumed zone, NTP state, and measured skew before a separate UTC value is produced. Sorting visible strings can reverse the actual password, web, and rollback order.

Source IP alone is not a session identifier. Service providers use NAT, shared bastions, and management networks where several administrators appear under one address. SSH key fingerprint, authentication method, process ID, terminal, web session, REST tracing ID, ConfD transaction, and recorded bastion session can separate them. When an artifact lacks one of these fields, the case should label the connection as temporal or inferred instead of silently writing the inference into raw evidence.

Hashes serve two distinct purposes. SHA-256 over an admin-tech bundle, exported log, or recovered file establishes the integrity of the investigative copy. The published hash of evil_tenant.csv is also a threat indicator for cross-environment matching. One is chain-of-custody metadata; the other is content intelligence. Hidden files whose contents were not recovered should carry an explicit unavailable-content state, not an empty hash or the CSV hash copied into their row.

The attacker’s cleanup checklist became the defender’s search inventory. The operator's validation loop checked five paths: the malicious CSV, the tenant-list backup, its state marker, the passwd backup, and the shadow backup. For each path, it printed PRESENT with ls -ld output or ABSENT. It then looked for troot in the system account files and checked whether the production tenant list existed. Each check corresponds to an earlier state transition in the payload.

The cleanup therefore had three layers. Working files were deleted to remove direct indicators. Configuration and account files were restored so that a current-state review would look normal. A separate validation pass verified that the cleanup had achieved the intended result. The last layer is especially revealing: the operator did not assume every restore or removal succeeded. If its output survived in a terminal transcript, command history, or remote audit source, an ABSENT result would itself document interest in a highly specific malicious object.

Final state answers “what is present now,” not “what occurred during the interval.” A clean passwd file does not negate the previous troot append or successful su. A password equal to its original value does not negate two change transactions. A correct tenant list does not erase the product script invocation. ConfD rollback, authentication logs, rolling script logs, file-system metadata, and upstream copies preserve edges between states that the current configuration cannot show.

File recovery should preserve inode, owner, group, mode, size, mtime, ctime, extended attributes, and allocation state. A disk image, working copy, and exported recovered object each receive their own hash. If the appliance cannot support a full image, the examiner should document the admin-tech, SCP, platform export, or TAC-assisted method and its limitations. Repeatedly grepping or attempting recovery on the live system can change access times, caches, and unallocated space.

After a reboot or log rollover, upstream evidence becomes more important. Central syslog, AAA or TACACS, bastion records, management firewalls, reverse proxies, configuration archives, NetFlow, and hosted-service audit may retain history the appliance has lost. The case board should record each source's retention deadline. By June, late-2025 peer logs may already have disappeared locally; certificate registration, connection history, backups, and network evidence may be the only remaining route.

5 The final state lied, so the investigation followed events instead of snapshots

Directly observed public evidence includes the upload command, script line, recovered CSV fragment and hash, troot account content, successful su, HTTP paths, and cleanup validator. These prove that specific activity occurred in the victim environment. The public article redacts sensitive values and does not release a disk image, so this review does not claim independent possession of the original victim artifacts. It reproduces the logic available in the published evidence.

Vendor-confirmed facts include affected products, the netadmin prerequisite, CVSS, CWE, fixed releases, absence of a workaround, TAC workflow, and exploitation awareness. Cisco also confirmed that the March device was unaffected by 20127 and that its connections did not use 20182. Those statements constrain the technical model. They do not expose the proprietary implementation, so they cannot support invented function names or an internal patch diff.

Strong joins arise where independent artifacts share device, time, session, transaction, path, or account. Temporary admin password changes, web authentication, configuration API calls, and restoration form one such join. Tenant upload, script invocation, file content, account changes, and successful su form another. Redacted session values can reduce the precision of the public join without making the entire sequence speculative.

Hypotheses include whether an early peer used 20127 or 20182, whether March access relied on stolen certificate material, and whether the two peering periods had one operator. Mandiant's language preserves possibility and uncertainty. Those hypotheses should guide searches for certificates, keys, and infrastructure, but should not be placed in a confirmed-IOC column or repeated as attribution.

Negative evidence has levels too. A complete, externally retained log covering the event window with no match carries more weight than an admin-tech archive whose retention begins later. A normal current file on a root-compromised appliance carries little exclusion power by itself. Every “not found” should specify source, time coverage, integrity, and whether the attacker could have modified it.

The three evidence labels improve external communication. A notice can state that exploitation of 20245 and creation of UID 0 are confirmed, while the early peer entry method and cross-period actor remain under investigation. Readers know which actions are mandatory and which judgments may evolve. Later evidence upgrades one row without forcing the institution to retract an overconfident narrative.

5.1 An unfamiliar peer needs addresses, certificates, roles, and local topology

Cisco instructs customers to validate every control-connection peering event, with particular attention to vManage peers. An unfamiliar public address is a starting point, not the complete decision. Hosted infrastructure, disaster recovery, maintenance, and provider address changes can create legitimate new connections. Validation should compare the event time with change windows, public IP ownership, system IP assignment, expected peer type, site and domain, repeated source behavior, and a named operational owner.

For CVE-2026-20182, Cisco also documents show control connections detail and history checks. A connection that is up while expected challenge-ack counters are absent should be taken to TAC. Controller and Manager use the control-connections command; Validator uses the orchestrator-connections equivalent. Investigators should preserve the entire connection stanza. Protocol, peer personality, system IP, private and public endpoints, session ID, uptime, and directional statistics give the zero counter its context.

Mandiant published eight IP addresses with descriptions that should survive ingestion. 126.51.108[.]152 was associated with a rogue device connection and CVE-2026-20245 exploitation; the other seven were described as rogue device connection sources. A hit should open a case association, but it should not automatically label every event as 20245 exploitation. Address reuse, shared hosting, NAT, and observation time all affect interpretation.

An IOC record should retain normalized and defanged forms, source report, exact description, first and last relevant time, ingestion date, and confidence. Analysts should compare the event time with the period in which the report associated the address. A current scan from an address that changed owners months later is not the same as a peer connection during the intrusion. Conversely, a connection that predates public reporting can be valuable even if the device no longer resolves or responds.

The topology baseline should have historical depth. The current Devices screen only shows what is registered now. Configuration archives, certificate databases, and connection history can show when a system IP first appeared and whether it was ever authorized. Joining certificate serial, subject, issuer, fingerprint, validity, device role, organization, registration event, and network address can expose an IP change under the same certificate or a certificate change under the same system identity.

Preserve state before removing an unknown peer. Deleting enrollment, revoking a certificate, or restarting a controller stops access but changes the evidence. If operational risk demands immediate isolation, an outer ACL may contain the source while connection detail, certificate, route, and session data are collected. When the appliance itself must be changed, record the exact command, operator, time, intended effect, and post-change result so response activity is not mistaken for attacker modification.

5.2 Authentication, rollback, scripts, and command history belong in the same window

The first high-value pattern in /var/log/auth.log is Accepted publickey for vmanage-admin from. A full line can expose time, device, sshd process, account, source address and port, authentication method, key type, and SHA-256 fingerprint. The source should be compared with approved controller and bastion addresses, while the key fingerprint is checked independently. A familiar address presenting an unregistered key remains suspicious.

Keyboard-interactive or PAM logins also matter because the public example includes admin using that method. Query successful and failed events, not only public-key acceptance. A failed series followed by success can indicate credential discovery; a direct success from a new source may indicate known credentials. Connect the session to terminal, process, account changes, and any subsequent su. Retain upstream AAA evidence where local root could have altered the appliance copy.

The second pattern is two password changes targeting admin within a short period. Mandiant's illustrative lines are fifteen minutes apart; a production rule should learn the local distribution from historical changes because that one example is not a universal threshold. Look for a change followed by successful 8443 authentication, configuration retrieval, and restoration. A legitimate rotation usually has a ticket, named operator, one durable value, and planned verification. A temporary value creates a different state shape.

/var/confd/rollback/ supplies a configuration-layer record. Cisco's and Mandiant's example header includes creator vmanage-admin, date, Via: netconf, delta type, rollback number, transaction ID, and hostname; the body reaches system/aaa/user admin/password. Export adjacent rollbacks in order. The same transaction may also touch logging, certificates, interfaces, or AAA policy, and the later restoration can be proven without exposing the actual password.

On releases 20.9 and later, Cisco recommends a broad search for vconfd_script_upload_.*\.sh in /var/log/scripts.log*. Before 20.9, equivalent entries live in /var/log/tmplog/vdebug*, and older files may be packaged in /var/log/vdebug_<timestamp>.tar.gz. A query against a nonexistent modern path on an older appliance is not a clean result. Every active, cluster, DR, and role-specific node needs the release-appropriate search.

# Release 20.9 and later
zgrep -E "vconfd_script_upload_.*\.sh" /var/log/scripts.log*

# Releases before 20.9: active and rolling logs
zgrep -E "vconfd_script_upload_.*\.sh" /var/log/tmplog/vdebug*

# Releases before 20.9: compressed archives
for f in /var/log/vdebug_*.tar.gz; do
  tar -xOf "$f" var/log/tmplog 2>/dev/null |
    grep -E "vconfd_script_upload_.*\.sh"
done

A match is not automatically malicious. Tenant-list upload, vSmart serial-number upload, and ZTP chassis-number upload are legitimate operations with similar log forms. For each result, retain script name, input path, VPN, time, device, and raw line, then reconcile it with a ticket, source file, operator, command history, and hash. The filename malicious.csv in Cisco documentation is an example, not a universal indicator.

show history can add the original CLI command, but its capacity and persistence are limited. Export it before further activity and compare it with bastion transcripts, shell history, or terminal auditing. Absence in the history does not prove a command did not run. Search for tenant uploads, su, operations on hidden backups, account-file changes, and the validation loop's PRESENT/ABSENT checks. The strongest finding connects command, script, file, account, and authentication sources.

6 Evidence has to survive the cleanup before it can explain what happened

6.1 Collect every control component before the first upgrade changes the scene

Cisco places evidence collection at the beginning of its June 2026 remediation workflow and documents request admin-tech as the CLI entry. All Controllers, Managers, and Validators must be represented, including cluster members and disaster-recovery counterparts that appear healthy. Controllers should generate admin-tech sequentially, one appliance at a time. For this TAC workflow, Cisco directs customers to include Log and Tech; Core is not required for the initial advisory analysis. A bundle from only the visibly affected Manager cannot describe fabric-wide peer and command state.

Each archive needs a manifest: contemporary and legacy role name, hostname, system IP, serial, cluster and DR relationship, exact booted release, management address, collection start and end in UTC, device-local time, NTP status, command, collector, output name, size, and SHA-256. Sequential Controller collection creates a time span across the set; the manifest makes that span visible if activity or log rollover continues while acquisition is in progress.

Cisco's initial analysis for 20245 focuses on a specific upload entry in the script log of each control component. The vendor also warns that the underlying command is legitimate and that the log does not distinguish normal from malicious use. A TAC match therefore starts a contextual review that needs corroboration from identity, file, account, and session evidence. TAC can evaluate known product indicators and guide remediation, while a broader incident-response team examines identity, network, configuration, file-system, and customer scope.

A clean TAC result is bounded by the packages submitted and the retention inside them. An archive whose earliest script log begins in May cannot answer whether an April upload occurred. An omitted DR node remains unassessed. Every negative conclusion should state the node list, artifact list, earliest and latest event time, rollover behavior, and search pattern. This makes “no indicator found” a reproducible statement instead of a blanket certificate of health.

Cisco provides manual verification where a customer cannot share admin-tech, but labels it preliminary and asks that the documented results still go to TAC. The manual process must select the correct log path for each release and run on every component. It should preserve full command output and the files' covered time. In an environment with suspicious activity, targeted grep cannot substitute for authentication, peer, rollback, file-system, and upstream acquisition.

Collection order should still account for volatility. Record active sessions, process state, peers, certificates, routes, and connections before a restart. Copy rolling logs and small high-value artifacts before a lengthy diagnostic task if rollover is imminent. When immediate containment is unavoidable, preserve the ACL or route change that performed it and list the remote sources still available. Evidence-first does not mean ignoring operational safety; it means making each necessary change visible.

6.2 Normalize clocks and identities before joining these linked records

Correlation begins with time and device identity. A peer record keeps raw time, normalized UTC, zone assumptions, NTP state, device, role, system IP, public and private endpoints, site, domain, session, and certificate fingerprint; an SSH record adds account, source, authentication method, key fingerprint, process, and terminal. The raw message, source file, and line offset remain intact, while any inferred year or clock correction is recorded separately rather than overwriting evidence.

Password events identify actor, target account, ConfD transaction, and rollback number; web and API events preserve method, path template, concrete Device ID, status, response bytes, session, and trace ID. Those fields can prove that a password was restored and connect one web login to an ordered set of configuration requests and customer objects without placing restricted secret values in the ordinary analysis index.

The Tenant-upload side retains CLI command, script name, input path, VPN, operator, and result, then joins them to file inode, ownership, times, hash, recovery method, and the account's UID, GID, shell, and authentication state. Every normalized event carries a case ID, source-artifact SHA-256, collection time, and parser version. An unrecovered hidden backup is explicitly marked content_available=false, avoiding the false implication that it was empty or never created.

7 A patch closes the upload flaw; recovery rebuilds trust across every branch and node

Cisco's June combined remediation baseline covers both CVE-2026-20245 and the concurrent CVE-2026-20262 and advances each supported train: 20.9.9.1 and earlier move to 20.9.9.2; 20.12.7.1 and earlier move to 20.12.7.2; 20.15.4.4 and earlier move to 20.15.4.5; 20.15.5.2 and earlier move to 20.15.5.3; 20.16, 20.17, and 20.18.x move to 20.18.3.1; and 26.1 moves to 26.1.1.2. Cisco-hosted clusters have a separate fixed 20.15.507 release. No workaround replaces the upgrade.

These branches do not obey a single string comparison. Release 20.15.4.5 and 20.15.5.3 are fixed, while the apparently greater 20.15.5.2 remains affected. Asset systems need train, maintenance release, patch, deployment type, and component role, followed by Cisco Software Checker and compatibility guidance. An unlisted or end-of-maintenance train should migrate to a supported fixed release selected from Cisco guidance; a nearby version number is insufficient evidence.

The June baseline is also one patch beyond several May authentication-bypass fixed points. For CVE-2026-20182, examples include 20.9.9.1, 20.12.7.1, 20.15.5.2, 20.18.2.2, and 26.1.1.1. A system that completed the May emergency work can still be vulnerable to 20245. Keeping each CVE as a separate column in the asset table explains why “we patched last month” does not close the new advisory.

Acquire admin-tech first, then upgrade, then read the running version from each appliance. A package uploaded to the Manager, a completed orchestration task, or a console showing a target release does not prove that every member booted the fixed image. Validate cluster health, peer connections, certificate state, management login, API, template synchronization, and external log delivery. Paused, DR, and later rejoining members deserve explicit checks.

Patching stops future use of the vulnerable code but does not restore exported trust. In a confirmed or likely compromise, review local accounts and rotate credentials, SNMP community strings, TACACS secrets, VPN pre-shared keys and certificates, and trusted SSH keys according to the actual configuration exposure. Cisco identifies these hygiene activities separately because software state and trust state require different acceptance evidence.

7.1 The exported fabric becomes the list of credentials, certificates, and templates to reset

Begin with the original API responses if they survived, or the closest release-matched backup and request logs. For every object, retain device, endpoint, parameters, HTTP result, response hash, and field list. Classify device identities, system IPs, controller relationships, sites and domains, routes and VPNs, templates, management addresses, AAA settings, certificate references, SNMP, TACACS, pre-shared keys, SSH keys, and automation accounts. Whether a secret appears in clear text must be decided from the actual release and response.

Next build a secret-to-consumer map. One TACACS key may be embedded in controller state, edge templates, and an external AAA service. A control certificate may be consumed by registration, peer authentication, and disaster-recovery nodes. An automation identity may serve backups, monitoring, and CI. Each item receives an owner, storage location, consumers, revocation method, rotation order, maintenance dependency, and acceptance test. Changing only the visible Manager value can leave the old material valid elsewhere.

Active sessions form a separate inventory. Changing admin or vmanage-admin passwords does not necessarily revoke established SSH, web, or API sessions; replacing a certificate does not necessarily terminate an already established control connection. Enumerate each class, use the supported invalidation mechanism, and watch upstream firewalls for retries from the old source. Old credential rejection, old certificate registration failure, and old session invalidation should each produce retained evidence.

Review propagation from the control plane to edge devices. Cisco notes limited cases where exploitation resulted in configuration changes pushed to edges. Compare Manager audit logs, task history, template attachment and detachment, CLI diffs, configuration revisions, and edge running state. Focus on management ACLs, routes, DNS, AAA, certificates, tunnels, software, and scripts. A currently correct template does not exclude an intermediate change that was later restored.

Every closure statement needs an object and a test. “Certificates rotated” should identify old serials, revocation state, new serials, deployed nodes, failed old registration, and expected peer count. “Accounts clean” should include UID 0 inventory, passwd and shadow verification, product and AAA users, active sessions, and login tests. “No edge change” should cite tasks, revisions, edge diffs, and the reviewed time range.

The completed identity inventory avoids both extremes. It does not assume every string in the fabric was exposed simply because the Manager was accessed, and it does not limit rotation to the two visible default accounts. The collected endpoint and configuration fields decide how far the trust reset extends. Conservative operational action can remain broader than the public factual statement as long as the distinction is documented.

7.2 Edge scope comes from tasks, revisions, and running state—not controller intent

CVE-2026-20245 directly affects control components; Cisco IOS XE edge routers are not listed as vulnerable products under this advisory. A root compromise of Manager, Controller, or Validator can still influence edges through legitimate product capabilities: read configuration, modify a template, change policy, schedule a task, or reach trust material. Scope statements should separate directly affected product, observed control-plane access, confirmed edge changes, and potential effects still under investigation.

Build an edge baseline with device ID, system IP, site, model, release, attached template, last task, certificate, controller peers, and configuration hash. Compare activity during the incident with edge logs, running configuration, and external backups. Management ACLs, AAA, DNS, NTP, tunnels, routes, policy, software, and certificates deserve focused review. “Traffic kept flowing” is an availability observation, not a configuration-integrity finding.

Cisco identifies secure factory reset and re-onboarding as an option where an edge compromise is suspected, using factory-reset all secure. This is a disruptive customer decision, not a universal first step. Evidence strength, appliance forensics, redundancy, trusted rebuild sources, and required security assurance should drive it. Preserve configuration, certificate, logs, and any obtainable storage evidence before executing a destructive reset.

Re-onboarding must use a clean trust source. Reapplying an unreviewed backup, old certificate, or compromised automation to a fresh device simply reintroduces uncertainty. Define the fixed controller, controlled certificate issuance, reviewed templates, rotated AAA, trusted image, and independent management path that constitute the clean source. After enrollment, verify peer identity, configuration diff, log delivery, and expected traffic before restoring full service.

Where no edge modification is found, document the exact evidence and window instead of stating that edges were “unaffected” without qualification. A complete task and configuration history offers more assurance than a short rolling log. If history is incomplete, the report can still say that no change was found in the sources reviewed and identify the missing period. That qualification makes later evidence easier to incorporate.

Detection should follow four state sequences instead of alerting on each legitimate action in isolation: an unfamiliar peer followed by vmanage-admin SSH; a temporary password followed by web login, configuration reads, and restoration; a product upload script followed by a UID 0 account and su; and finally restore, deletion, and validation. The table places each sequence beside its minimum join fields and escalation conditions.

Every rule needs release and environment context. Pre-20.9 script logs live in different paths, hosted and on-premises systems have different approved sources, and Tenant, serial, or chassis uploads may be legitimate maintenance. Build local baselines for peers, certificates, accounts, directories, and API clients, then make each alert name the expectation it violated. Published IPs, filenames, and hashes remain high-specificity leads, not substitutes for the behavioral chain.

8 Recovery ends when every component rejects the old path and the fabric tells the same story

1. First two hours: name an incident lead, freeze unnecessary control-plane changes, and record trusted UTC plus NTP state. Restrict management and control ports at an outer firewall to registered controllers and bastions, preserving the before-and-after ACL. If a rogue peer remains active, export connection detail, certificate, route, and session state before deciding whether operational risk requires immediate termination. Preserve troot and related state until high-value evidence is secured, then proceed with reboot or upgrade decisions.
2. Two to eight hours: collect admin-tech from every Controller, Manager, and Validator, running Controller collection sequentially. In parallel, preserve auth, scripts or vdebug, ConfD rollback, command history, web and API, audit, users and UID 0, /home/admin metadata, and upstream identity and network records. Hash each original and create the manifest as acquisition happens. Small rolling logs can take priority over a long diagnostic job if they are about to disappear.
3. 8–24 hours: create separate timeline lanes for late 2025 through January, March, and April. Join peers, SSH, password transactions, web sessions, API objects, upload commands, scripts, files, and su. Match the eight published IPs and CSV hash while searching for renamed files and other UID 0 identities. Open the Cisco Severity 3 TAC case with the CVE and advisory IDs in the title and provide all component bundles.
4. 24–72 hours: upgrade every node to the appropriate fixed branch after preservation. Verify the booted release, cluster health, and control connections. Cover CVE-2026-20127, CVE-2026-20182, CVE-2026-20245, and other applicable June advisories as one compatibility-tested plan. Rotate credentials, secrets, keys, and certificates according to the exported-configuration inventory; revoke sessions; and compare edge tasks and state.
5. After 72 hours: monitor for retries using old sources, certificates, sessions, and credentials. Complete edge rebuilding where evidence warrants it, restore external logging, and convert the case queries into durable analytics. The final record keeps confirmed facts, strong joins, candidate explanations, and unrecoverable gaps separate, with distinct recovery states for software, identity, certificates, configuration, edge devices, and evidence.

Each operational task needs an acceptance definition. “Inventory all control components” means every active, DR, hosted, and role-specific node has hostname, system IP, role, exact release, cluster, exposure, and owner, with counts reconciled to fabric and provider records. “Upgrade complete” means every node boots a fixed release and passes peer, login, API, template, and log tests. “Trust restored” means old identities and sessions fail and every rotated consumer works with the new material.

8.1 Acceptance tests close the former path without replaying the destructive payload

In an isolated lab or a vendor-supported test environment, begin with a normal tenant CSV and confirm that the fixed release still completes the business workflow and emits the expected script records. Follow with a safe negative sample containing a deliberately invalid delimiter or quoting sequence and a harmless sentinel objective. The fixed system should reject the input before any sentinel changes. Preserve the sample, expected error, before-and-after hash, command output, and logs.

Production acceptance combines version proof, a normal Tenant CSV upload, log review, and account-file integrity. The negative corpus runs only in an isolated lab or vendor-supported environment, where inert invalid characters exercise the repaired parser while a designated sentinel file proves that input stayed data. Cisco TAC can advise on release-specific validation when no public unit fixture exists.

Test peer-certificate acceptance separately from the tenant upload. A controlled node with an unregistered or revoked certificate should fail to establish a peer and should produce an alertable event. A legitimate peer should complete the expected challenge and connect. Preserve full control-connection detail, certificate identity, and counters. The old rogue system IP should be absent, and the firewall should show that unauthorized sources cannot reach management and control ports.

Identity acceptance covers old passwords, SSH keys, web sessions, API tokens, and certificates. Each old item must fail; each new item should work only from an approved path and at the intended privilege. The UID 0 inventory should contain only approved accounts, and no troot row or unknown equivalent should remain. Central authentication logging must receive both the failed old tests and the successful approved tests with correct source and time.

Configuration acceptance compares a trusted pre-incident baseline, the preserved pre-remediation snapshot, and the post-remediation state. Every difference has a ticket and owner. Edge running state matches reviewed templates, with no unexplained ACL, route, AAA, DNS, tunnel, software, or certificate change. Admin-tech bundles and manifests remain readable and hash-valid after the operational work, so the upgrade has not destroyed the ability to revisit the case.

Hardening begins by making the control plane difficult to reach and noisy to use. At the network layer, restrict management and control ports with explicit ACLs, security groups, or firewalls. Cisco advises on-premises deployments to permit ports 22 and 830 only from known controllers and management sources, with other control-component traffic limited to specified hosts. Place web administration on a dedicated management path or controlled bastion, disable unnecessary HTTP and FTP services, and give every internet exposure a documented business reason and owner.

At the identity layer, reduce routine use of default and shared accounts. Named administrators authenticate through centralized AAA with appropriate approval and strong authentication; local admin becomes a monitored break-glass identity. SSH keys and certificates have owners, expirations, rotation, and revocation. Automation credentials do not double as human credentials. CLI, NETCONF, API, and configuration-export privileges are separated where the product model permits.

At the peer layer, maintain a two-sided device and certificate inventory. Every system IP maps to role, serial, certificate fingerprint, issuer, validity, public and private address, site, domain, and provider owner. Enrollment, replacement, and revocation require a change record. Current and historical control connections are exported regularly, and unknown vManage peers or challenge anomalies enter a jointly owned network-and-security analyst queue.

At the logging layer, forward authentication, vconfd, script, Manager audit, web API, and control-connection events to a system that appliance root cannot rewrite alone. Normalize time and monitor NTP health, forwarding gaps, parsing failure, and log volume. Retention should cover the longest likely interval from initial access to public disclosure and internal discovery. This case crossed many months; a few weeks of local history would not answer its earliest question.

8.2 The product failed where data crossed into commands; recovery succeeds where evidence becomes proof

The technical core is compact. A netadmin submitted a crafted file to a Catalyst SD-WAN control component; the privileged upload path failed to preserve that input as data; account databases changed; and a UID 0 identity was used. Proprietary functions remain unpublished, but the command, script, payload, account, and authentication fields provide a complete external chain.

The incident expands that core into a control-plane story. Rogue peering exposed management access, a temporary password enabled application collection, and the CSV crossed into root. Cleanup restored a convincing final state while leaving different fragments in rollback, authentication, scripts, API logs, file systems, and upstream systems. The ability to join those fragments determines whether the event can still be proven.

Fixed releases and an explicit Cisco workflow are available. Organizations can preserve evidence, patch all components, reset credentials and certificates according to the exported configuration, review edge propagation, and turn peer and log baselines into durable controls. The positive operational lesson is that centralized systems also provide centralized places to measure identity, configuration, and trust when those places are instrumented deliberately.

Two conclusions should remain together: April's crafted-CSV-to-root chain is confirmed by incident evidence; actor continuity between the late-2025-to-January and March peering periods remains unresolved. The first supports immediate action. The second directs continued collection without overstepping the record. Precision at both edges is what makes the report useful after the headline has passed.