Two control-plane zero-days in weeks from the same vendor, a sandbox appliance triple-exploit with sub-seven-day weaponization, and a Chinese espionage campaign that ran undetected for a year inside medical and defense networks. Today’s stories share a common thread: the infrastructure defenders trust most — management planes, security appliances, cloud email platforms — is exactly what attackers target first.

In the News

Cisco Patches Second SD-WAN Manager Zero-Day in Weeks

Cisco published an advisory confirming active exploitation of CVE-2026-20262, an arbitrary file write vulnerability in Catalyst SD-WAN Manager with a CVSS score of 6.5. An authenticated remote attacker can exploit the flaw to write arbitrary files and escalate privileges to root on the underlying operating system.

This is the second exploited SD-WAN Manager zero-day in recent weeks. The CVSS score is moderate, but the impact is not — SD-WAN Manager is the control plane that pushes policy to every edge device in the fabric. Compromise here means an attacker can modify routing policy, disable security controls, or pivot to any site in the SD-WAN overlay. The “authenticated” prerequisite lowers the bar less than it sounds: stolen service account credentials, compromised API tokens, or lateral movement from an already-breached endpoint all satisfy the requirement.

Organizations running Catalyst SD-WAN Manager should patch to the fixed release immediately. Beyond patching, this is a reminder that management plane segmentation is not optional — SD-WAN Manager interfaces should be reachable only from hardened jump hosts, not from general user VLANs. Monitor for unexpected file writes in /opt/ and /etc/ directories on the Manager appliance, and audit all administrative API token usage for anomalous source IPs.

What defenders should do: Patch CVE-2026-20262 immediately. Restrict SD-WAN Manager access to dedicated management networks. Audit API token and service account activity for anomalous access patterns.

Three FortiSandbox Flaws Exploited — One Patched Last Week

Defused Cyber reported active exploitation of three critical Fortinet FortiSandbox vulnerabilities over the past 24 hours: CVE-2026-39813 (CVSS 9.1, path traversal via the JRPC API), CVE-2026-39808, and CVE-2026-25089. One of these three was patched by Fortinet only last week — confirming that attackers are reverse-engineering patches and building exploits in under seven days.

FortiSandbox is deployed inline in many enterprise networks specifically to detonate and analyze suspicious files. An attacker who compromises the sandbox can bypass malware analysis entirely, or use the appliance’s trusted network position to pivot deeper into the environment. The path traversal in CVE-2026-39813 targets the JRPC API, which is exposed on the management interface by default in most deployments.

The patch-to-exploit timeline here is the headline. Security appliances are high-value targets precisely because they occupy trusted positions in the network — and the operational reality is that many organizations patch security infrastructure on the same monthly cycle as everything else. That cadence is no longer viable when weaponization happens in days.

What defenders should do: Patch all three FortiSandbox CVEs immediately. If patching requires a maintenance window, restrict JRPC API access to management-only networks as a compensating control. Review whether inline sandbox appliances are segmented from the rest of the production network.

Chinese APT Hid in Medical and Defense Networks for a Year via Google Workspace

Google Threat Analysis Group (TAG) disclosed that UNC6508, a China-nexus espionage group, compromised REDCap research servers at North American healthcare, higher education, and defense organizations to steal credentials. The attackers then used the compromised accounts to configure Google Workspace email forwarding rules — silently copying sensitive medical, military, and AI research email to attacker-controlled accounts for over twelve months.

The attack chain is straightforward and devastating in its simplicity. REDCap is a widely deployed research data capture platform in academic and healthcare settings; exposed instances provided the initial access vector. Once inside, UNC6508 did not deploy malware or exfiltrate data through custom C2 infrastructure. They configured native Google Workspace forwarding rules — a feature every user has access to — turning the organization’s own email platform into the exfiltration mechanism. Detection came from Google TAG, not from the victim organizations.

This is a dwell-time and cloud email security story. The year-long dwell time is not a failure of endpoint detection — there was nothing on the endpoint to detect. It is a failure of identity governance and cloud configuration monitoring. Organizations using Google Workspace or Microsoft 365 must monitor for changes to email forwarding rules, mailbox delegation, and OAuth application grants as high-fidelity indicators of compromise. The initial access through REDCap also underscores the need to segment research infrastructure from production identity systems — MITRE ATT&CK techniques T1114.003 (Email Collection: Email Forwarding Rule) and T1078 (Valid Accounts) are the primary TTPs.

What defenders should do: Audit all email forwarding rules and mailbox delegation settings in Google Workspace and Microsoft 365. Implement alerting on new forwarding rule creation. Segment research platforms like REDCap from production identity infrastructure. Enforce phishing-resistant MFA on all accounts with access to sensitive research data.

DragonForce Ransomware Tunnels C2 Through Microsoft Teams Relays

DragonForce deployed custom malware designated “Backdoor.Turn” to tunnel command-and-control traffic through Microsoft Teams relay infrastructure. Because Teams relay domains are on corporate allow-lists and trusted by URL filters, firewalls, and proxy servers, the C2 communications are effectively invisible to perimeter-only network security controls.

This is a living-off-the-land technique applied to network infrastructure rather than host tools. Traditional indicators — suspicious domains, unusual ports, connections to uncategorized IPs — do not fire because the traffic goes to legitimate Microsoft infrastructure. Detection requires application-layer inspection: DNS-layer analytics that flag anomalous query patterns to Teams relay subdomains, TLS inspection that can examine payload characteristics, or EDR telemetry correlated with network flow data to identify the on-host Backdoor.Turn process communicating through Teams channels.

What defenders should do: Implement DNS-layer and application-layer inspection for SaaS relay traffic. Correlate EDR telemetry with network flow data to detect processes using legitimate SaaS relays for C2. Review Microsoft Teams external access and relay policies. MITRE ATT&CK technique T1090.004 (Proxy: Domain Fronting) and T1071.001 (Application Layer Protocol: Web Protocols) apply.

Defender Action Items

  • Cisco SD-WAN Manager: Patch CVE-2026-20262 to fixed release. Restrict management interface access to hardened jump hosts. Audit API token usage for anomalous source IPs.
  • Fortinet FortiSandbox: Patch CVE-2026-39813, CVE-2026-39808, and CVE-2026-25089 immediately. Restrict JRPC API to management-only networks. Segment inline sandbox appliances.
  • Google Workspace / Microsoft 365: Audit all email forwarding rules and mailbox delegation. Alert on new forwarding rule creation. Review OAuth application grants.
  • Microsoft Teams environments: Implement DNS-layer inspection for Teams relay traffic. Correlate EDR and network flow data for SaaS-tunneled C2 detection.
  • cPanel servers: Patch CVE-2026-54420 (LiteSpeed plugin) — CISA KEV deadline is June 18.

Detection Spotlight

UNC6508’s technique of configuring Google Workspace forwarding rules for exfiltration leaves a clear audit trail. The following Splunk SPL query identifies new or modified email forwarding rules in Google Workspace audit logs — a high-fidelity indicator when filtered against known-good automation accounts.

index=gws_audit sourcetype="google:workspace:admin"
  event.name="CREATE_FORWARDING_ADDRESS" OR event.name="CHANGE_EMAIL_SETTING"
| eval target_user=mvindex('event.parameters{}.value', 0)
| eval forwarding_address=mvindex('event.parameters{}.value', 1)
| where NOT match(forwarding_address, "@yourdomain\.com$")
| stats count earliest(_time) AS first_seen latest(_time) AS last_seen
    values(forwarding_address) AS external_forwards
    BY target_user, actor.email
| where count > 0
| sort - count

This query catches forwarding rules that send email to external addresses. False positives are low in most environments — legitimate external forwarding is rare enough that every hit warrants investigation. Tune the domain regex to match your organization’s primary and subsidiary domains. For Microsoft 365 environments, the equivalent signal is the Set-InboxRule or New-InboxRule operation in the Unified Audit Log with ForwardTo or RedirectTo parameters pointing to external addresses.

References

Subscribe to the it-learn Brief

Get the daily cybersecurity brief in your inbox every weekday morning — news, SE angles, and detection queries.