Defensia Research

What is actually being exploited on production Linux servers

Name: What is actually being exploited on production Linux servers
Creator: Defensia
License: https://creativecommons.org/licenses/by/4.0/

Defensia agents read the logs of the Linux servers they protect. This page publishes what those agents measured over the last 7 days — attack volume, unique attacking addresses and the countries they came from — together with the method and the blind spots. Every figure is our own measurement. None of it is a republished advisory feed, and none of it comes from a honeypot.

Measured 2026-10-24 01:46 UTC over the window 2026-10-17 → 2026-10-24 (UTC). Machine-readable export.

52,591

Unique attacking addresses

Distinct source IPs seen attacking monitored servers in 7 days.

185

Source countries

Geolocated country of origin for those addresses.

50,899

Exploitation attempts

Requests matching an exploitation signature, from 5,969 distinct addresses.

The shape of the data: wide, not deep

Across exploitation attempts, this dataset records 0.117 unique attacking addresses for every event — roughly one distinct source for every 9 records. On the narrower CVE-attributed population it is 0.333, about one source for every 3 records. That is a statement about the dataset's shape rather than its size: it is wide rather than deep. A great many distinct sources, each leaving few records behind.

The shape follows from where the sensors sit. An agent on a working production server is hit by whatever is sweeping the internet broadly at that moment — a scanner walks an address range, probes a host once or twice, and moves on. These are not well-known targets that a small set of actors return to repeatedly, so records accumulate sideways across many sources instead of piling up behind a few. That makes the data a reasonable instrument for which addresses are attacking right now, and a poor one for how many times a given payload fired.

Two of the four populations have much lower ratios, and the reason is worth stating rather than hiding: all detections (0.018) and credential brute force (0.101). Both are dominated by high-repetition traffic. A crawler identifying itself on every request, or one host working through a password list, produces an enormous number of records from a single address. Those two ratios measure repetition, not reach, and the export flags each population accordingly — so a reader can tell which ratios describe breadth before quoting one.

The four populations, counted separately

"Events" means four different things below and the difference is large. A figure from one row is not interchangeable with a figure from another, so each is defined in full and counted on its own. If you quote a number from this page, quote the row it came from.

All security detections

all_detections

Every hostile or automated request and connection the agents flagged, excluding agent telemetry and ban mirrors. Mostly automated crawling and credential guessing.

Events: 2,865,776
Unique source IPs: 52,591
Source countries: 185
IPs per event: 0.018

Credential brute force

credential_brute_force

Repeated authentication failures against SSH, FTP, mail and WordPress logins.

Events: 75,962
Unique source IPs: 7,662
Source countries: 145
IPs per event: 0.101

Exploitation attempts

exploitation_attempts

Requests whose URI matched an exploitation signature. Includes matches against generic probe classes that are not tied to one CVE.

Events: 50,899
Unique source IPs: 5,969
Source countries: 119
IPs per event: 0.117

CVE-attributed exploitation

cve_attributed_exploitation17 distinct CVEs

The subset of exploitation attempts carrying a specific CVE identifier. This is the exact population the exploitation aggregation reads.

Events: 2,849
Unique source IPs: 949
Source countries: 43
IPs per event: 0.333

Of the exploitation attempts matched in this window, 5.6% carry a specific CVE identifier. The rest matched generic probe classes that are not tied to one vulnerability. That is why the CVE-attributed row is counted on its own, and why the exploitation-attempt total must not be read as a count of CVEs. The CVEs behind that row are listed here, with per-CVE figures.

Method

An agent runs on each monitored server and reads the logs the host already writes — web server access logs, authentication logs, mail logs. Requests are matched against exploitation signatures derived from public exploitation templates and from web application firewall rule sets. A match records an event with the source address, the geolocated country, the request URI and the user agent. Figures on this page are counted over one fixed window with one query, and the window end is the measurement timestamp above.

What this dataset cannot tell you

Request bodies are never seen

The agent reports the request URI and the user agent. It does not transmit POST bodies, and it reports the raw log line for only a minority of events. Any vulnerability exploited through a request body or a header is invisible to this dataset by construction, not by omission — and that is most of the published exploitation corpus. Roughly two thirds of the Nuclei template library describes exploitation we could not observe in any URI.

One known exploitation form per signature

Each signature encodes the exploitation path that its source template carried. An attacker using a different encoding, a different parameter or a different path for the same vulnerability is not matched. Signature coverage counts vulnerabilities for which one known form is covered, never vulnerabilities that cannot be exploited past us.

Most matched exploitation carries no CVE label

Signatures also match generic probe classes — environment-file reads, configuration probes, shell lookups — that are not tied to a single CVE. Those dominate the matched volume. The CVE-attributed population is published separately above, with its own counts, and the attribution rate is in the export. Do not read the exploitation-attempt total as a CVE count.

These are production servers, not honeypots

Every sensor is a server doing real work for someone, so the dataset answers "is this being exploited against live applications" rather than "has anyone tried this payload anywhere". The trade-off runs both ways and is worth stating plainly: a honeypot logs everything aimed at it, including novel attacks against software nobody here runs, and it can safely let an exploit complete to see what comes next. We cannot. We see only what is aimed at software our customers actually run, and we see it only up to the point the agent blocks it.

Counts are of records, and records can repeat

An event is one detection, not one distinct attack. A scanner walking fifty paths on one server produces fifty events. This is why the unique-address and country figures carry the meaning here and the event totals are context: a volume figure can be inflated by a single noisy source, and a distinct-address count cannot.

Ban mirrors are excluded

When the platform records a block it also writes an event so the block appears in the customer timeline. Those mirror a detection that was already counted — about 3% of records in this window — and every figure here excludes them. Any Defensia figure quoted elsewhere that does not say so is higher than it should be.

The sensor network

What the sensors are: Production Linux servers running the Defensia agent, which reads the web, authentication and mail logs already on the host.
What the estate looks like: Hosts at multiple independent hosting providers, on internal corporate networks and in public cloud. Linux distributions span the Debian, Ubuntu, RHEL-derivative (AlmaLinux, Rocky, CloudLinux) and Alpine families, from releases years past end of life to current ones, running Nginx and Apache, and serving several thousand live domains between them.
What is not in it: No honeypots, no emulated services, no third-party feed. Every record is traffic that arrived at a server somebody depends on.
How many sensors?: We do not publish the number of monitored servers. It is a direct measure of the size of the business and would stay published forever, while adding nothing a reader needs: the figures here are counts of attacking addresses and of attacks, and none of them is per-server. Where a server count would be the natural unit we publish a share of monitored servers instead.

Citing this data

The figures above are exported as JSON at /research/data.json, with the same window, the same measurement timestamp and the same population definitions, plus the method limits. Published under CC BY 4.0 — use the numbers, name the window. Journalists and researchers who need a cut we do not publish, or a figure checked against a specific date, can ask: contact.

Defensia (2026-10-24). "What is actually being exploited on production Linux servers".
Window: 2026-10-17 to 2026-10-24 (7 days).
https://defensia.cloud/research — data: https://defensia.cloud/research/data.json

See this traffic hitting your own servers

Everything above was measured by the Defensia agent on production Linux servers. It reads your logs, detects exploitation attempts and blocks the source. Free for 1 server.

Get started free