SonicWall SMA 1000 under active attack: CVE-2026-15409 and CVE-2026-15410

SonicWall has confirmed active exploitation of two vulnerabilities in Secure Mobile Access 1000 appliances. CVE-2026-15409 is an SSRF rated CVSS 10.0, while CVE-2026-15410 enables remote code execution and scores 7.2. Updating is necessary, but it may not be sufficient: an appliance could have been compromised before the fix was installed.

The vendor has published fixed builds, concrete log indicators and a recommendation for thorough forensic analysis. That distinction matters. “Patched” closes a vulnerability; it does not remove a web shell, revert malicious configuration or invalidate stolen credentials.

Builds covered by the notice

The advisory applies to SMA 1000 models 6210, 7210, 8200v and CMS across all supported hypervisors.

Branch	Builds identified as affected	Fixed build
12.4.3	03245, 03387, 03434	12.4.3-03453 or later
12.5.0	02283, 02624, 02800	12.5.0-02835 or later

Read the effective version from AMC/CMC on every appliance. Do not rely on a package filename in a repository, an approved change plan or a claim that “the latest hotfix was deployed”. One missed cluster node preserves a vulnerable attack surface.

Why SSRF and RCE on an access gateway matter

SMA sits at the boundary between the Internet and remote access to the organisation. SSRF may let an attacker make requests in the appliance’s context and reach resources that are not externally visible. RCE provides a path to execute code on the gateway.

Combining these vulnerability classes with the role of a VPN appliance creates risk beyond the failure of one device:

• access to internal management services;
• manipulation of routing or authentication configuration;
• theft of credentials and TOTP material;
• persistence through altered files or configuration after patching;
• lateral movement from a trusted network position.

This does not mean every vulnerable SMA has been compromised. It means confirmed exploitation requires evidence-led hunting rather than an assumption of safety.

Indicators published by SonicWall

The vendor identifies several patterns that should be checked immediately:

• in extraweb_access.log, an HTTP 200 response for requests to /_api_/login or /__api__/logout;
• in the same log, /wsproxy requests returning 101 with a suspicious host parameter;
• in ctrl-service.log, “hotfix removal” entries containing a traversal-style name;
• in /var/lib/unit/conf.json, unexpected /__api__/login and /__api__/logout routes.

Treat these IOCs as a starting point. Absence of the exact string does not rule out attack: an adversary can change a path, remove a log or use a different sequence. Expand analysis to administrative sign-ins, configuration exports, file changes, unusual outbound connections and identities created during the exposure period.

Patch or full rebuild?

Where there is no evidence of compromise and telemetry is sufficient to support that conclusion, update the appliance, verify the build and run functional and security tests. Where IOCs are present or logs are incomplete, the safer path is to reimage physical hardware or redeploy the virtual appliance from a trusted image.

For confirmed indicators, SonicWall also directs customers to change user and administrator passwords and reset TOTP tokens. That is appropriate: rebuilding the appliance does not invalidate authentication data that may already have been captured.

Configuration backups require scrutiny as well. The vendor prefers a backup from before the stated hotfix period; if none exists, it recommends a careful integrity audit. Restoring unverified configuration may recreate an attacker’s persistence mechanism.

A 24-hour response plan

Hours 0–2

1. Identify every SMA 1000 appliance, build and exposure path.
2. Preserve logs, configuration and disk evidence before making changes.
3. Restrict management access and unnecessary publication.
4. Begin searching for vendor-published indicators.

Hours 2–8

1. Deploy fixed builds where no compromise indicators exist.
2. Isolate appliances with indicators and prepare a reimage or redeployment.
3. Reset secrets that may have passed through a compromised system.
4. Inspect destination systems reachable from the SMA segment.

Hours 8–24

1. Test remote access, MFA, routing and authorisation policies.
2. Confirm every node runs a fixed build.
3. Monitor new logins, devices and remote sessions.
4. Record evidence and the rationale for deciding that patching or rebuilding was sufficient.

A wider lesson for the access surface

Internet-facing security gateways are both a control and a high-value target. They need independent monitoring, tightly restricted administration, off-appliance logs and a rehearsed clean-build procedure. If an organisation cannot rapidly deploy a trusted gateway, the incident lasts as long as uncertainty about the old appliance’s integrity.

Use the SMA response as an opportunity for a broader IT security audit: validate segmentation, administrative paths, MFA, log retention and every internal destination the gateway can reach.

Primary and government sources: SonicWall — SMA 1000 Series affected by multiple vulnerabilities, SonicWall PSIRT — SNWLID-2026-0008, Canadian Centre for Cyber Security — AV26-699.