1,531,046 Internet-Reachable iSCSI Endpoints and Only 521 Confirmed Fingerprints

A ZoomEye query for port 3260 returns 1,531,046 results. The same index, asked for the iSCSI application by fingerprint rather than by port, returns 521. Two questions about the same protocol, run on the same day, and the answers differ by more than three orders of magnitude.
That gap is the subject of this article. It is not a contradiction. It is what happens when a port number is used as a proxy for a service.

The measurement

Two queries were run on 27 September 2026 against the global ZoomEye index, counting hosts rather than banners.
The first was port="3260", the default port for iSCSI, the protocol that carries SCSI commands over TCP so that a server can present block storage to a client across a network. It returned 1,531,046.
The second was app="iSCSI", an application-level fingerprint. It returned 521.
iSCSI matters because of what it carries. A target that accepts an iSCSI session is presenting block storage. Depending on authentication and on what LUNs are mapped, a client that can establish a session may be able to read and write the volumes behind it. There is no application layer mediating the access, no row-level permission, and no web front end recording who did what.

Reading the gap honestly

The most likely explanation for the difference is the least dramatic one. Port 3260 is not exclusive to iSCSI. Other services use it, and some of the 1,531,046 responses will belong to something else entirely, whether by configuration choice, by coincidence, or because a middlebox answered on its behalf.
Application fingerprinting is stricter. It looks for protocol-specific behaviour in the response, which is why it returns far fewer results. The 521 figure is closer to "hosts that behaved like iSCSI when asked" than the port count is.
Neither number is the count of vulnerable systems. The port count overstates iSCSI presence and says nothing about authentication. The fingerprint count understates the total population, because fingerprinting depends on the service answering in an identifiable way, and hardened or filtered deployments may not, including configurations where an initiator reaches a target through an authenticated portal rather than directly.
The honest answer to "how many iSCSI targets are exposed" is that this measurement brackets it, and that neither end of the bracket is a vulnerability count.

Why the 521 still deserve attention

An exposed block storage endpoint is not a website with a login page. Several properties make it a serious finding when it is reachable from an untrusted network.
Authentication is optional in practice. iSCSI supports CHAP, but deployments frequently rely on network isolation instead, on the reasoning that the storage network is not routable from anywhere that matters. That reasoning holds until a firewall rule changes or a host is added to the wrong VLAN.
When authentication is absent, an initiator that can reach the target can attempt discovery and may be able to map and attach LUNs. At that point the access is at the block layer, which means file system permissions recorded on the volume do not apply to an attacker writing to the raw device. File system journals, logs and access control records are all inside the thing being modified.
The failure is also quiet at the application layer, because there is no application layer. Detection depends on network telemetry and on storage-side audit, not on web logs.

What this implies for defenders

Do not treat a port scan as a service inventory. A scan that reports 3260 open tells you a port answered. It does not tell you the protocol, the product, the authentication configuration, or whether the endpoint is a real array, a hypervisor's software target, or a network device that happens to have the port open. The 1,531,046 against 521 comparison is a concrete illustration of how far apart those two claims can be.
Do treat exposed storage protocols as a priority class. Where iSCSI is genuinely in use, it should sit on a dedicated network segment that has no route from general-purpose networks, with CHAP or better configured even when isolation exists, and with initiator and target names restricted so that an unauthorised initiator cannot attach. Where the exposure is accidental, close the port.

Limitations

Both figures are host counts from a single index on a single day. ZoomEye's coverage depends on what is routable and how services respond to probes. This article does not claim that any of the 1,531,046 hosts are vulnerable, does not claim that any of the 521 lack authentication, and does not present either figure as a count of exploitable systems. The reasonable use of these numbers is as a ratio, illustrating how much a port-based estimate can diverge from a fingerprint-based one.

References

• ZoomEye, port="3260" and app="iSCSI", queried 27 September 2026: https://www.zoomeye.org/