A CVSS 10.0 in a perimeter VPN appliance, autonomous AI agents breaching banks, and a third-party notification platform turning into an attack vector against a major retailer. Today’s stories share a common thread: the controls defenders assumed were in place - patched appliances, human-only threat models, trusted integrations - are the exact assumptions under attack.

In the News

SonicWall SMA1000 SSRF Hits CVSS 10.0 - Hotfix Available Now

SonicWall disclosed a maximum-severity server-side request forgery vulnerability in its SMA1000 series SSL VPN gateways. The flaw allows an unauthenticated attacker to craft requests that the appliance forwards to internal services - effectively turning the VPN gateway into a proxy for reaching systems that should never be internet-accessible. No CVE ID has been assigned yet, but SonicWall released hotfixes and rated the vulnerability CVSS 10.0.

The SMA1000 product line has been targeted by threat actors before. SonicWall appliances appeared in CISA’s Known Exploited Vulnerabilities catalog multiple times in 2024-2025, and the combination of always-on internet exposure and slow enterprise patching cycles makes these devices high-value targets. Any organization running SMA1000 gateways should apply the hotfix immediately. Organizations that cannot patch within 48 hours should restrict management interface access to trusted IPs and monitor for anomalous outbound requests originating from the appliance.

The broader strategic question is whether internet-facing SSL VPN concentrators belong in a modern architecture at all. ZTNA and SSE architectures eliminate the always-listening attack surface these appliances create. Every CVSS 10 in a VPN appliance is another data point for that migration conversation.

What defenders should do: Apply the SonicWall hotfix immediately. If patching is delayed, restrict management interface access and monitor appliance logs for SSRF indicators - unexpected outbound connections to internal IP ranges originating from the VPN gateway process.

AI Agents Breach South Korean Banks - 68,000 Records Exposed

South Korean financial regulators confirmed what threat modelers have been anticipating: autonomous AI agents were used to breach multiple banks, exposing approximately 68,000 customer records. A Chinese cybersecurity tool has been linked to the operation. This is the first publicly confirmed case of AI-agent-driven initial access in the financial sector.

The operational distinction matters. This is not AI-generated phishing or AI-assisted code review. These were autonomous agents performing reconnaissance, credential testing, and data exfiltration without continuous human direction. The attack cadence - rapid, systematic, non-linear - produces traffic patterns that differ from hands-on-keyboard operators. Traditional signature-based detection is not built to flag the difference between a fast human and an autonomous agent, but behavioral analytics that baseline session velocity, API call patterns, and credential reuse timing can surface the anomaly.

For financial services defenders, the immediate action is reviewing authentication controls for API endpoints and implementing continuous session validation. AI agents exploit the gap between initial authentication and session expiry - long-lived tokens and broadly scoped API keys are the attack surface.

What defenders should do: Audit API endpoint authentication and token lifetimes. Implement behavioral analytics that baseline session velocity and flag non-human request patterns. Enforce continuous trust evaluation on all privileged sessions. MITRE ATT&CK techniques to map: T1078 (Valid Accounts), T1106 (Native API), T1119 (Automated Collection).

ASOS Confirms Breach via Compromised Notification Platform

UK fashion retailer ASOS confirmed a data breach after attackers compromised a third-party push notification platform and used it to send hijacked in-app messages to customers. The threat actors also claim to have exfiltrated data from ASOS’s Snowflake-hosted data lake. The full scope of customer data exposure has not been disclosed, and the incident is still unfolding.

This is a supply-chain compromise in the purest sense - not a vulnerability in ASOS’s own code, but in a trusted integration that had direct access to the customer communication channel. The notification platform compromise gave attackers a credible delivery mechanism (messages appeared to come from the ASOS app), while the alleged Snowflake exfiltration represents a separate data-access failure. The Snowflake angle echoes the 2024 Snowflake campaign attributed to UNC5537, where attackers targeted customer Snowflake environments using stolen credentials from infostealer malware.

What defenders should do: Audit all third-party integrations that have push or messaging access to customer-facing applications. Enforce least-privilege API scoping on cloud data warehouse connections. Review Snowflake audit logs for anomalous query patterns and credential access from unexpected IP ranges.

Defender Action Items

  • SonicWall SMA1000: Apply vendor hotfix immediately. Restrict management interface to trusted IPs if patching is delayed. Monitor for SSRF indicators in appliance logs.
  • Atlassian Data Center (CVE-2026-21589, CVSS 9.3): Patch all 8 affected products - Jira, Confluence, Bitbucket and five others. Enforce WAF rules blocking path traversal on Atlassian endpoints.
  • AI agent threat model: Audit API token lifetimes and scoping. Implement behavioral analytics baselines for session velocity. Enforce continuous session validation on privileged endpoints.
  • Third-party integration audit: Review all services with push notification or messaging access to customer-facing apps. Enforce least-privilege on Snowflake and other data lake connectors.
  • Phishing-resistant MFA: Fake AI chatbot portals are intercepting MFA codes via browser-in-browser attacks. FIDO2 and passkeys are the only controls immune to real-time proxy-based interception.

Detection Spotlight

Behavioral detection for AI-agent-driven credential testing differs from traditional brute-force rules. AI agents tend to distribute attempts across multiple accounts with variable timing - avoiding lockout thresholds - while maintaining unnaturally consistent session metadata. The following Splunk SPL query identifies API authentication attempts with high account diversity from a single source IP within a short window, which is characteristic of automated credential testing:

index=auth_logs sourcetype=api_auth action=login
| bin _time span=5m
| stats dc(user) as unique_accounts, count as total_attempts, values(user) as targeted_users by src_ip, _time
| where unique_accounts > 15 AND total_attempts > 50
| eval ratio=round(unique_accounts/total_attempts, 2)
| where ratio > 0.2
| sort -unique_accounts
| table _time, src_ip, unique_accounts, total_attempts, ratio, targeted_users

This catches sources testing many accounts rather than hammering one - the ratio filter (unique accounts / total attempts > 0.2) separates distributed agent behavior from single-account brute force. Tune the unique_accounts threshold for your environment. False positive sources: legitimate SSO federation services and load balancers, which should be whitelisted by IP.

References

Subscribe to it-learn Brief

Get it-learn Brief in your inbox (Mon–Fri) - Daily cybersecurity news, SE angles, and detection queries.