Most vulnerability coverage starts with a CVE and works backward to the exploitation. This post does the opposite, because that is how the May 2026 SonicWall story actually unfolded. Between May 9 and May 18, 2026, GreyNoise observed a pronounced spike in scanning of SonicWall SonicOS management interfaces, peaking on May 12 at approximately 597,000 sessions tagged to its SonicWall SonicOS API scanner activity. That is roughly 46 times the typical daily volume on that tag and the largest single-day total in the preceding 90 days.
The reason this matters is a documented precedent. Earlier in 2026, three scanning spikes on the same tag each preceded the disclosure of CVE-2026-0400, a SonicOS denial-of-service vulnerability published on February 24, 2026. GreyNoise was careful, and we will be too: three observations is a precedent, not an established cadence, and correlation is not causation. But for defenders, a 46x surge of targeted recon against a class of internet-facing firewalls is actionable on its own terms, regardless of whether a fresh CVE drops next week.
This is a threat-intelligence post, not a single-CVE deep dive. The subject is how to read mass scanning of edge appliances as an early-warning signal, what the May 2026 SonicWall surge specifically looked like, and what to do when your perimeter is the thing being measured by an adversary.
TL;DR
- May 9-18, 2026: GreyNoise recorded a major scanning surge against SonicWall SonicOS management interfaces, peaking May 12 at ~597,000 sessions, about 46x the typical daily baseline and the largest single-day total on the tag in 90 days.
- The pattern echoes three earlier-2026 spikes that each preceded the February 24, 2026 disclosure of CVE-2026-0400, a post-authentication format-string denial-of-service (CWE-134) in SonicOS that lets a remote authenticated attacker crash affected firewalls.
- The scanning was highly uniform: ~99% used a single user-agent (Chrome 119 on Linux x86_64), ~56% originated from networks announced in the Netherlands and ~44% in Ukraine, with a single ASN (AS211736) carrying roughly half the volume, targeting ports 80 and 8080.
- GreyNoise explicitly framed the correlation as a precedent, not a rule — do not treat "spike implies imminent CVE" as fact.
- The defensive takeaway is independent of whether a new CVE lands: get SonicOS management interfaces off the public internet, patch to current, and watch for the recon-to-exploitation transition.
- Mass scanning of a vendor's edge fleet is a collection signal: someone is building or refreshing a target list. Treat it as a prompt to harden, not as a reason to panic.
What happened
GreyNoise, which operates internet-wide sensors that classify and tag scanning behavior, published an analysis of a SonicWall SonicOS scanning surge observed between May 9 and May 18, 2026. The May 12 peak reached approximately 597,000 sessions on its SonicWall SonicOS API scanner tag, described as the largest single-day total recorded on that tag in the previous 90 days and roughly 46 times the typical daily volume.
The activity was notably homogeneous, which is itself a fingerprint. Per GreyNoise: approximately 99% of requests carried a single browser user-agent string (Chrome 119 on Linux x86_64); approximately 56% of sessions originated from networks announced in the Netherlands and 44% in Ukraine; a single autonomous system, AS211736, carried roughly half of total session volume; and the scanning targeted ports 80 and 8080 (HTTP). Homogeneity at that level indicates a coordinated, automated campaign from a small infrastructure footprint, not diffuse background noise.
The reason GreyNoise flagged it is the historical pattern. Three documented spikes on the same tag in Q1 2026 (on January 18, January 30, and February 14) preceded the February 24, 2026 disclosure of CVE-2026-0400, occurring 37, 25, and 10 days ahead of it respectively. The May surge resembles those waves. GreyNoise's framing is the responsible one: this is "a precedent, not an established cadence, and not a definitive rule." As of the analysis, no new SonicOS CVE had been confirmed as the driver of the May activity.
Technical analysis: the appliance and the precedent CVE
CVE-2026-0400 is the anchor of the precedent, so it is worth understanding even though it is not, on its own, a catastrophic bug. Per NVD (published February 24, 2026), it is a post-authentication format-string vulnerability (CWE-134) in SonicWall SonicOS that allows a remote attacker to crash affected firewall appliances. The flaw arises when user-controlled input is processed as a format-string argument; an authenticated attacker can supply input containing format specifiers that vulnerable functions in SonicOS mishandle, producing a denial-of-service condition. Reporting lists numerous SonicWall TZ-series devices among those affected (TZ80, TZ270, TZ370, TZ470, TZ570, TZ670, TZ680, and related W/P variants).
Two properties of CVE-2026-0400 are relevant to reading the scanning. First, it is post-authentication, which means a crash requires valid credentials to the management interface, so the bug alone is not a mass-exploitation primitive. Second, it is a DoS, not an RCE. Neither property explains a 597,000-session recon wave on its own. That is the analytical tension: the scale of the scanning is larger than what CVE-2026-0400's own severity would justify, which is exactly why a recurrence of the pattern raises the question of whether attackers are mapping the fleet ahead of something new.
What does mass scanning of a firewall's management interface actually accomplish? Several things, none of which require a working exploit:
- Target enumeration. Identify which SonicOS appliances are internet-reachable, on which ports, and at which versions (often fingerprintable from response headers and login-page artifacts).
- Version triage. Build a list of devices on vulnerable builds so that the moment a usable exploit exists, the operator can go straight from list to action.
- Capacity and reachability testing. Confirm which hosts respond, which are behind WAFs or geo-blocks, and which expose the management plane directly.
# ILLUSTRATIVE characterization of the observed campaign — not exploit code.
Tag: SonicWall SonicOS API Scanner (GreyNoise)
Window: 2026-05-09 to 2026-05-18
Peak: 2026-05-12, ~597,000 sessions (~46x daily baseline)
User-Agent: ~99% "Chrome 119 / Linux x86_64" (single string)
Geography: ~56% NL-announced networks, ~44% UA-announced networks
ASN: AS211736 ~= 50% of session volume
Ports: 80, 8080 (HTTP)
The uniform user-agent and the concentration in a single ASN tell you this is one operator (or one toolkit) running a focused collection sweep. That is the kind of activity that precedes either a new disclosure or a renewed campaign against an already-known bug.
What detection looks like
You do not need GreyNoise's global vantage to act on this; you can detect the same campaign hitting your own edge.
- Management-plane access attempts from the internet. Any inbound connection to a SonicOS management interface (HTTPS admin, or HTTP on 80/8080) from a public source is a finding. Alert on it, then ask why it is reachable at all.
- User-agent and ASN clustering. Flag bursts of requests sharing a single user-agent (e.g., the Chrome 119 / Linux x86_64 string) from a narrow set of ASNs. Cross-reference source IPs against the Netherlands/Ukraine-announced ranges and AS211736 noted in the campaign.
- Login-page and version-probe patterns. Repeated GETs of login pages, firmware-fingerprinting paths, and management API endpoints from non-administrative sources indicate enumeration.
- The recon-to-exploitation transition. The signal that matters most is a change in shape: scanning that suddenly starts including POST bodies, authentication attempts, or crafted parameters against management endpoints. That transition is the moment collection becomes attack.
- Availability symptoms. For the CVE-2026-0400 precedent specifically, watch for unexplained SonicOS reboots or management-plane crashes, which would indicate the DoS being triggered against an authenticated session.
What to do Monday morning
- Remove SonicOS management interfaces from the public internet. This is the single highest-impact action and it neutralizes the entire class of management-plane scanning. Bind administration to a management VLAN or VPN; do not expose HTTP/HTTPS admin on 80/8080/443 to the world.
- Patch SonicOS to a current, fixed release. Apply the latest SonicWall firmware per the relevant PSIRT advisories (including the fix for CVE-2026-0400). Patching closes the precedent bug and reduces what a future exploit can chain against.
- Rotate administrative credentials and enforce MFA. Because CVE-2026-0400 and similar bugs are post-authentication, credential strength and MFA on the management interface are direct mitigations against the recon-to-exploitation step.
- Geo- and ASN-restrict management access where it must be remote. If administration must traverse the internet, restrict source IPs and consider blocking the ASNs/regions seen in the campaign as a temporary measure while you move admin behind a VPN.
- Stand up the early-warning loop. Subscribe to GreyNoise tags (or equivalent ISP/threat-intel feeds) for your edge vendors and wire them to your detection so a future surge becomes a ticket, not a surprise.
- Pre-stage the response. Treat the scanning as advance notice. Have the patch tested, the inventory current, and the change window pre-approved so that if a CVE does follow the pattern, you are deploying within hours.
Why this keeps happening
Internet-exposed firewall management interfaces are a self-inflicted, evergreen target. Administrators expose them for legitimate convenience (remote management of distributed sites, MSSP fleets, small offices without VPN infrastructure), and attackers know it. The result is a steady-state population of reachable management planes that any operator can enumerate cheaply with commodity infrastructure. A 597,000-session sweep from a single ASN costs the attacker very little and yields a fresh, version-tagged target list.
The deeper pattern is the industrialization of the recon-to-exploitation pipeline. Mass scanning is now a routine precursor: build the list first, weaponize second, and execute against the pre-built list the moment an exploit exists. That is why scanning surges are a leading indicator worth tracking even when they cannot be tied to a specific new CVE. The window between "exploit available" and "exploit used against you" collapses to near-zero when the adversary already knows your appliance is reachable and unpatched.
SonicWall, like Ivanti, Citrix, and the rest of the edge-appliance cohort, sits at the intersection of high value (it is the perimeter), high exposure (it is internet-facing by design), and operator-driven misconfiguration (management interfaces exposed for convenience). The vendor can patch bugs, but it cannot make customers stop exposing the management plane. That is the part defenders own.
The structural fix
You cannot defend an attack surface you have not inventoried, and you cannot prioritize a scanning surge you never see. The defensible posture pairs a current inventory of every edge appliance and its exposed services with an early-warning feed that turns a scanning spike into a triaged action. Reachability analysis helps you separate "appliances on a vulnerable build" from "appliances on a vulnerable build with the management plane actually reachable from the internet," which is the population an adversary's scan is actually building. A disciplined zero-day response loop lets you pre-stage the patch and change window during the recon phase, so that when the exploit appears you are closing the gap in hours rather than discovering your exposure for the first time. None of this stops attackers from scanning, but it shortens the dwell time between their collection sweep and your hardened, patched perimeter.
What we know we don't know
- Whether a new SonicOS CVE drives the May surge. As of GreyNoise's analysis, none was confirmed. The pattern is suggestive, not deterministic; GreyNoise itself calls it a precedent, not a rule.
- The operator's identity and intent. The infrastructure concentration (single ASN, single user-agent) points to one coordinated campaign, but attribution is not public.
- Whether the scanned hosts are being actively exploited. Enumeration is confirmed; exploitation against the enumerated population is not established.
- The full affected-version set for any forthcoming CVE. If a new disclosure follows the pattern, its scope is unknown until SonicWall publishes.
References
- GreyNoise, "A New SonicWall Scanning Spike Echoes the Pattern That Preceded CVE-2026-0400": https://www.greynoise.io/blog/sonicwall-scanning-spike-echoes-pattern-preceded-cve-2026-0400
- NVD / SentinelOne vulnerability database, "CVE-2026-0400: SonicWall SonicOS DOS Vulnerability": https://www.sentinelone.com/vulnerability-database/cve-2026-0400/
- SonicWall PSIRT, Security Advisory SNWLID-2026-0004: https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0004
- SonicWall, "Gen 7 and newer SonicWall Firewalls — SSLVPN Recent Threat Activity": https://www.sonicwall.com/support/notices/gen-7-and-newer-sonicwall-firewalls-sslvpn-recent-threat-activity/kA1VN0000000RDG0A2
- Cyberpress, "Hackers Actively Scan SonicWall Firewalls, 597K Sessions Seen": https://cyberpress.org/actively-scan-sonicwall-firewalls/
Internal reading: