Post cover image

November 2, 2026

Port Scans Outnumber SSH Brute Force 4 to 1 in Shared Abuse Reports

What 30 days of shared abuse data shows about who is attacking your servers

By isIPsafe

5 min read

The assumption that did not hold

Port scans, not SSH brute force, are the largest category in the last 30 days of reports to isIPsafe: 973,716 port-scan reports against 246,570 for SSH, roughly four to one.

SSH password guessing gets most of the attention in security writing, so it is easy to assume it dominates what servers actually see. The live statistics from isIPsafe, a free database where server owners report the IP addresses that attack them, say otherwise.

This article walks through what the data shows, why it matters, and what you can do about it this week. It also says plainly where the data is thin, because a number you cannot trust is worse than no number.

What 30 days of reports show

Three patterns stand out in the last 30 days of reports on isIPsafe's public statistics page.

Reconnaissance outweighs password guessing. Port scans (973,716 reports), web spam (925,469) and bad web bots (913,736) each outnumber SSH reports (246,570) by a wide margin. One report can carry several categories, so these counts overlap and should not be added together.

The most-reported networks are large clouds. Google (AS396982, 21,827 addresses), DigitalOcean (21,409) and Microsoft (11,032) lead the list of reported networks. That does not make those providers malicious. It shows that attackers rent the same on-demand infrastructure everyone else does, so blocking "bad hosting companies" is no longer a strategy on its own.

New bugs become scanning campaigns within weeks. CVE-2026-39364, a file-disclosure flaw in the Vite development server, was published in April 2026. By August, F5 Labs recorded 807 session-grouped attacks and about 32,000 raw events against exposed Vite servers, compared with 1,732 Vite-related file-read events over the previous three months. That is close to a twentyfold rise over the three-month total, and more than fifty times an average month of that baseline. The requests went after .env files, AWS and Azure credentials and Terraform state. A Cloud Security Alliance research note reads that as credential theft being the main goal, rather than general reconnaissance. A request for /.env was also among the recent entries in isIPsafe's live feed at the time of writing.

For scale, isIPsafe's monthly threat report counts 1,331,851 reports covering 248,653 addresses in October 2026, with Google's network the most reported.

None

Why it matters

Attackers share far more than defenders do, and that gap is the real problem. Wordlists, exploit kits and lists of vulnerable hosts circulate freely. The address that probes one server at 3am will probe thousands more before lunch, and each owner finds that out alone.

Cost is the other half. A scan costs almost nothing and runs around the clock, so volume is huge and most of it is noise. Reading logs by hand cannot keep up, and automation without good data either misses real attackers or blocks innocent people.

Shared reputation data changes the economics. When one server reports an address, everyone else can check it before trusting it, or block it before it arrives. The score also gets more reliable with every independent report, because an address that several unrelated servers flag is harder to dismiss than a single complaint.

What to do this week

Five steps, in order of urgency. None of them needs a new product.

  1. Find your exposed development servers. Check whether any Vite dev server is reachable from outside a trusted network, including through container port mappings and cloud security groups. Update to Vite 7.3.2, 8.0.5 or later, as F5 Labs recommends.
  2. Test your own site for leaked config files. Request /.env and similar paths from outside your network. If a file comes back, remove public access first, then treat everything in it as compromised.
  3. Rotate secrets that could have been read. For any server that was reachable while unpatched, rotate the values in local .env files, AWS and Azure credentials and Terraform state, then review your cloud API call history.
  4. Automate bans for repeat offenders. A tool such as fail2ban handles password guessing and web probes without anyone reading logs.
  5. Use shared data at the edge. Check unknown addresses before trusting them, and load a high-confidence blocklist into your firewall or proxy so known attackers never reach a login page.

How isIPsafe fits

isIPsafe is a free, shared database that lets you check, report and block abusive IP addresses. The data in this article comes from it, so here is what it does and what it does not.

Check. Look up any IP address, network or hostname and get an abuse confidence score from 0 to 100, with report counts, attack categories and the owning network. The score counts independent reporters from the last 30 days, older reports fade, and an address needs several independent reports to reach the default blocklist threshold of 75.

Report. A free API key (email only) lets you send attackers in with one curl command, one extra line in fail2ban, or ready-made setups for nginx, Apache, Postfix, Dovecot, Windows RDP and others. Bulk CSV upload takes up to 10,000 rows.

Block. The blocklist downloads in nine formats, including ipset, nftables, nginx, Apache, MikroTik and STIX 2.1.

Connect. The integrations page lists more than 60 setups, from Cloudflare, pfSense and AWS WAF to Splunk, Wazuh and MISP. There is a REST API with an OpenAPI spec, and an MCP server so assistants such as Claude, Cursor and VS Code can look up addresses directly. The v2 API follows AbuseIPDB's format, so switching usually means changing the base URL and the key.

Plans, as listed on the pricing page:

  • Anonymous: free, 400 lookups a day, no reporting and no blocklist download
  • Free account: free with email sign-in only, 10,000 lookups a day, reporting, and the full blocklist up to 10 times a day
  • Enterprise: quoted per customer, with unlimited lookups, reporting and downloads

The free tier is for protecting your own systems. Building a product on the data, or reselling it, needs the Enterprise licence.

What this data can and cannot tell you

Treat these numbers as a sample, not a census of the internet. Five limits matter:

  • The dataset is young. isIPsafe's monthly threat reports currently start in October 2026, so a 30-day window covers most of what it has collected so far.
  • The reporter base is still small. The mix of categories reflects the servers that report, and what their tools detect and choose to send, as well as what attackers do.
  • Counts are reports, not attackers. One report can carry several categories, and the same address can be reported many times.
  • Country and network show who owns an address, not necessarily where the attacker sits.
  • A listed network is not a guilty network. Cloud providers rank high because attackers rent from them, not because the providers are the source.

The direction of the findings is consistent with what other researchers report, such as the Vite scanning surge. The exact ratios will move as more servers contribute.

Try it, and report what you see

The most useful first step is to look up the addresses already in your logs. Check a few at isIPsafe (the first 400 lookups a day need no account), and if you run fail2ban, nginx or Postfix, add the one-line reporting setup so the next server gets its warning earlier. The list is only as good as the reports in it.

Sources (all read on 2 November 2026)