ZoomEye's SonicWall SMA fingerprint returns 7 records against Shadowserver's several hundred

A fingerprint hit needs two conditions to hold at once. The appliance has to present a banner the scanner can positively identify, and it has to present it on a port the scanner checked ^[5][6]. An appliance that fails either condition never appears in the seven. The write-up's own checklist also defines the unit: one record is one observed service on an address, and that is not the same as one distinct organization ^[10]. So the seven is a count of positively identified services, and the post says of it, "It would be a mistake to read that as reassurance" ^[8].

The 416 fails in the other direction. A free-text search for the product string also matches pages and services that mention SonicWall SMA without exposing an identifiable appliance interface ^[5]. Same dataset, same collection day, and the two methods disagree by a factor of about 59 ^[16].

The Shadowserver Foundation counted several hundred SMA1000 instances exposed to the public internet during the disclosure window, working from observed traffic and scanning activity instead of banner matching ^[4][6]. The post does not give Shadowserver's exact figure. Take several hundred as somewhere between 300 and 900 and the gap against the fingerprint count runs from about 43 times to about 129 times ^[17].

The facet is the part of this method that produces work assignments, and the post demonstrates it on a different product class: app="Modbus" returned 9,820 records, with Cyprus at 3,986, the United States at 916, and Sweden at 898 ^[11]. The SonicWall population got no equivalent country breakdown. Those three countries hold 5,800 of the 9,820 records, or 59 percent ^[18].

Timing matters more than any of the three totals. SonicWall published advisory SNWLID-2026-0016 on September 1, 2026, and CISA's Known Exploited Vulnerabilities catalog additions are dated September 2 ^[13][12]. The collection timestamp on all three ZoomEye figures is 2026-09-20, which is 19 days after the advisory ^[19][2], and one timestamp shows no trend. The post recommends re-running the query after remediation to confirm exposure actually decreased, and calls that the step most often skipped ^[14].

In my view the inventory diff is the usable output here. Exposure data answers a question a vulnerability scanner cannot: whether a vulnerable system is reachable by someone with no authorized path into the network ^[15]. That question is answered per address, against your own asset list. The post calls the fingerprint count the more conservative and more defensible figure for exposure assessment ^[7]. Used as a floor under a list you already have, it is.