Hackers ramp up scanning of SonicWall firewall interfaces after 597,000-session spike

Security teams running SonicWall firewalls should review exposed management and SSL VPN interfaces after GreyNoise observed a major spike in scanning against SonicOS management APIs.

According to GreyNoise’s SonicWall scanning report, the activity rose sharply between May 9 and May 18, 2026. The largest spike came on May 12, when GreyNoise recorded about 597,000 sessions on its SonicWall SonicOS API Scanner tag.

The company said the May 12 total was the highest single-day volume for that tag in 90 days and about 46 times higher than the normal daily volume over the previous 30 days. GreyNoise stressed that the spike is an early warning signal, not proof that a new SonicWall vulnerability exists.

The scan volume resembles earlier SonicWall activity

The concern comes from a familiar pattern. GreyNoise said earlier spikes on January 18, January 30, and February 14 occurred before the February 24 disclosure of CVE-2026-0400, a SonicOS vulnerability later documented in the NVD record.

The timing does not prove that a new disclosure is coming. It does, however, give defenders a reason to harden exposed SonicWall infrastructure before scanning turns into credential attacks or exploitation attempts.

GreyNoise’s broader Ten Days Before Zero research found that surges in internet sensor activity preceded vulnerability disclosures by a median of 11 days across 33 CVEs and 16 vendor families. That makes scan volume a useful input for patch readiness, even when no advisory exists yet.

Signal	What GreyNoise observed
Observation window	May 9 to May 18, 2026
Peak date	May 12, 2026
Peak session count	About 597,000 sessions
Increase over baseline	About 46 times the previous 30-day daily average
Main target	SonicWall SonicOS management interfaces
GreyNoise position	Early warning signal, not a CVE prediction

Scanning focused on web management services

The activity appears highly concentrated. GreyNoise said nearly all observed requests used a Chrome 119 user-agent on Linux x86_64, matching the dominant fingerprint seen during the earlier January and February SonicWall scanning wave.

The same GreyNoise analysis said about 56% of sessions originated from networks announced in the Netherlands and about 44% from Ukraine. Together, those two countries accounted for more than 99% of the measured volume.

Ports 80 and 8080 carried almost all the scanning, which points to web-facing management or API surfaces rather than broad random probing. GreyNoise also said a single autonomous system, AS211736, accounted for roughly half of the total session volume.

Earlier SonicWall reconnaissance targeted SSL VPN checks

This is not the first time SonicWall infrastructure has drawn coordinated attention. In February, GreyNoise reported 84,142 scanning sessions against SonicWall SonicOS infrastructure between February 22 and February 25, 2026.

That earlier campaign focused heavily on determining whether SSL VPN was enabled. GreyNoise said 92% of those sessions probed one SonicOS REST API endpoint used to check SSL VPN status.

The February activity also included credential-testing behavior against NetExtender VPN client login paths. That matters because exposed VPN and firewall management services remain attractive initial access points for ransomware and hands-on-keyboard intrusions.

Observed pattern	Security meaning
Management API scanning	Attackers may be mapping exposed SonicOS services.
SSL VPN status checks	Attackers can identify devices where VPN access is active.
NetExtender login probing	Credential attacks may follow successful service discovery.
Concentrated user-agent fingerprint	The same tooling may be reused across campaigns.
ASN concentration	Traffic may come from organized scanning infrastructure.

No new SonicWall vulnerability has been confirmed

At the time of writing, the May spike has not been tied to a newly disclosed SonicWall CVE. Defenders should avoid treating it as confirmed exploitation, but they should not ignore it either.

The earlier CVE-2026-0400 case shows why the timing gets attention. The NVD entry for CVE-2026-0400 describes it as a post-authentication format string vulnerability in SonicOS that could allow a remote attacker to crash a firewall.

SonicWall customers should also monitor the SonicWall PSIRT advisory portal for new advisories. GreyNoise specifically recommended preparing to apply patches within 24 hours if SonicWall publishes a relevant disclosure.

What SonicWall administrators should do now

Administrators should first check whether SonicOS management interfaces or SSL VPN portals are exposed to the open internet. Public exposure increases the value of scanning because attackers can quickly build target lists.

Organizations should restrict SonicOS management API access and SSL VPN access to trusted IP ranges wherever possible. Admin portals should never remain broadly exposed unless a business requirement justifies the risk and compensating controls exist.

SonicWall’s own high-security firewall setup guidance includes administrative hardening steps such as enforcing password complexity, limiting login attempts, enabling lockout, and enabling enhanced audit logging. Those controls matter more when attackers actively scan perimeter devices.

• Remove public exposure from SonicOS management interfaces where possible.
• Restrict management API access to trusted administrative IP ranges.
• Restrict SSL VPN portals to known user networks where feasible.
• Require MFA for all SSL VPN users and administrators.
• Audit for unexpected administrator accounts created since May 1, 2026.
• Increase log retention for firewall management, VPN, and outbound activity.
• Prepare a rapid patch process for new SonicWall PSIRT advisories.

Logs can show whether a device was probed

Security teams should search firewall, reverse proxy, and edge logs for unexpected requests to SonicOS management and VPN paths. They should pay special attention to requests from suspicious infrastructure and sessions using the Chrome 119 on Linux x86_64 fingerprint described by GreyNoise.

The earlier GreyNoise reconnaissance report listed SonicOS REST API VPN status checks, management login paths, and NetExtender login endpoints as useful places to hunt for activity. Those same categories remain relevant during the current scanning wave.

Teams should also monitor for outbound activity from the firewall that does not match normal update, logging, or management behavior. A spike in inbound scanning does not prove compromise, but unusual outbound traffic can indicate later-stage activity.

Hunting area	What to review
Management access logs	Unexpected requests to SonicOS web management or API endpoints
SSL VPN logs	Failed logins, unfamiliar source networks, and unusual NetExtender activity
Administrator accounts	New or modified accounts created after May 1, 2026
Network telemetry	Outbound connections from firewall infrastructure that do not match known behavior
Patch status	Firmware versions compared with current SonicWall PSIRT guidance

Why early scanning signals matter

Edge devices often sit directly on the internet, so attackers can scan them quickly once a technique, endpoint, or vulnerability becomes interesting. That creates a short window between reconnaissance and exploitation.

GreyNoise’s Ten Days Before Zero report argues that defenders can use surge patterns to brief leadership, stage patches, and harden exposed systems before formal advisories arrive. The May SonicWall spike fits that defensive use case because it gives administrators a reason to prepare without waiting for a confirmed CVE.

The SonicWall PSIRT feed should become a high-priority watch item for teams with exposed SonicWall devices. If a new advisory appears, teams should already know which appliances face the internet, which interfaces are exposed, and who can approve emergency patching.

Defenders should treat the spike as a readiness test

The May 12 spike does not prove that attackers have a working SonicWall exploit. It does show that SonicOS management surfaces are receiving unusual attention at scale.

Organizations should use that signal to tighten access, review accounts, verify MFA, and confirm firmware readiness. The goal is to reduce exposure before a possible disclosure forces an emergency response.

Administrators should also apply hardening practices from SonicWall’s security configuration guidance, especially around administrative access, login protection, and audit logging. When perimeter devices draw concentrated scanning, basic management hygiene can decide whether reconnaissance becomes compromise.

FAQ