EDR for Linux: How to Protect Linux Servers and Workstations

EDR for Linux protects the systems quietly running most of the internet, and most businesses treat it as an afterthought behind Windows. Linux powers your web servers, your cloud infrastructure, and increasingly your hypervisors, yet gets a fraction of the endpoint security budget Windows receives. That gap is exactly where attackers have been focusing.

Why Linux security has become urgent, even though it powers most of the internet quietly

Linux runs the infrastructure most businesses never think about protecting directly: as of May 2026, Linux powers 61.1% of websites with an identifiable operating system, roughly half of global cloud workloads, and 100% of the world’s top 500 supercomputers. Linux endpoint security has become urgent precisely because this quiet dominance made Linux systems an efficient, high-value target that historically received far less protection than Windows desktops.

This scale matters because a single compromised Linux server, a web-facing application, a cloud instance, a hypervisor, often controls far more downstream infrastructure than a single Windows workstation ever would. Attackers have noticed this asymmetry: server EDR coverage still lags meaningfully behind desktop EDR adoption across most business environments, even though the servers now represent the higher-value target.

The coverage gap nobody talks about: why your EDR stack may be blind to Linux

Most business security stacks were built Windows-first and extended to Linux as an afterthought, creating a real coverage gap where Linux servers, containers, and hypervisors run with lighter monitoring than desktop endpoints receive. This gap persists specifically because Linux systems are often managed by different teams, DevOps or platform engineering, than the security team overseeing desktop EDR.

This organizational split is the root cause worth naming directly. Desktop EDR rollout typically falls under IT or security, with clear ownership and a standard deployment process across every laptop. Linux servers frequently sit under a separate infrastructure or platform team, provisioned through automation pipelines that were never built with endpoint agent deployment as a default step. The result: a business can have excellent EDR coverage on every employee laptop while running dozens of internet-facing Linux servers with no equivalent monitoring at all, a gap that shows up starkly during incident response when the compromised system turns out to be exactly the unmonitored server nobody thought to check first. If your organization tracks EDR coverage as a single percentage across “all endpoints,” break that number down by platform specifically, since a strong blended average frequently hides a genuinely unprotected Linux fleet sitting underneath it. Ask your team directly: what percentage of our Linux servers, not just desktops, run an active, monitored EDR agent right now?

Why kernel CVE numbers exploded (and what that means)

Linux kernel CVE disclosures jumped roughly tenfold in 2024, to 3,529, and reached 5,530 in 2025, numbers that look alarming until you know the real cause: the Linux kernel team became its own CVE Numbering Authority in 2024 and began registering CVEs far more aggressively, including for minor fixes that previously went untracked.

Metric	Figure
Kernel CVEs in 2024	3,529 (up ~1,117% from prior years)
Kernel CVEs in 2025	5,530 (28% increase over 2024)
Critical-severity CVEs, 2024	148, up from 87 in 2023
Total kernel CVEs since 1999	20,000+

Longtime kernel maintainer Greg Kroah-Hartman has been explicit about this being a transparency improvement, not a quality regression: Linux topped the 2026 first-half CVE charts with 2,308 disclosures, ahead of Google, Microsoft, and Apple, and he’s openly framed that leadership position as a positive sign of rigorous, public disclosure rather than evidence the kernel is somehow less secure than competitors reporting far fewer CVEs. The honest takeaway for anyone doing CVE-based patch prioritization: don’t panic at the raw count increase, but do treat the underlying trend seriously, high-severity CVEs (CVSS 7.0-8.9) still made up 42% of 2024’s total, and critical flaws are now occurring roughly once every 2.5 days. The volume changed because the process changed. The underlying risk from any individual critical vulnerability did not shrink just because there are more disclosures surrounding it.

eBPF rootkits: the modern evolution of a threat you already know

eBPF rootkits represent the newest generation of Linux rootkit, evolving from older kernel-module-based implants into stealthier techniques that hijack the very telemetry pipeline modern security tools depend on, rather than trying to hide individual malicious actions one at a time.

Elastic Security Labs traced this generational shift clearly: early rootkits used shared-object hijacking, later generations used loadable kernel modules, and the current generation, with named examples like TripleCross, Boopkit, and RingReaper, abuses eBPF, a kernel feature originally built for legitimate observability and packet filtering. The specific technique matters: rather than hiding a malicious process from detection tools, a modern eBPF rootkit intercepts the function that feeds monitoring data into the security tool’s buffer, filtering or dropping the relevant events before they ever reach the detection engine. The malicious activity still happens on the system, but the monitoring tool never receives the record that would trigger an alert. This is a fundamentally different attack surface than classic rootkits, and it specifically targets the runtime monitoring approach many modern Linux EDR and observability tools, including Falco and Tetragon, rely on. Defenders should specifically audit for unexpected eBPF programs attached to systems where eBPF tooling isn’t normally deployed, since an unrecognized program hooked into a tracepoint is a strong compromise indicator most standard log review would miss entirely.

What’s attacking Linux right now: webshells, brute force, and ESXi ransomware

Three attack categories dominate current Linux threat activity: webshells account for roughly half of all Linux malware exploits targeting web servers, brute-force SSH campaigns remain a persistent baseline threat, and ransomware targeting VMware ESXi hypervisors has grown explosively, from 3% to 25% of encryption events across 2025 alone.

The ESXi trend deserves particular attention because of a structural gap most businesses don’t realize exists: many EDR and antivirus products don’t run on ESXi at all, since it’s an appliance-style hypervisor system rather than an ordinary Linux or Windows host with a conventional file system agents can install on. This is exactly why ransomware groups shifted strategy toward hypervisors specifically, encrypting a single ESXi host encrypts every virtual machine running on it simultaneously, in one move, without needing to move laterally through dozens of individual servers first. Average ransom demands against ESXi servers reached $5 million in 2024, reflecting that leverage directly. Recent attacks have exploited both older vulnerabilities like CVE-2024-37085, which manipulated Active Directory group membership to gain administrative control over domain-joined ESXi hosts, and a 2025-2026 zero-day chain that let attackers escape virtual machine isolation entirely. If your business runs VMware ESXi, confirm explicitly whether your current security stack provides any monitoring at the hypervisor layer itself, not just the virtual machines running on top of it, since that’s precisely the blind spot this attack category exploits.

A real, major example: the XZ Utils backdoor

The XZ Utils backdoor, tracked as CVE-2024-3094, was a near-miss supply chain attack rated the maximum CVSS score of 10.0, discovered before widespread deployment, that would have given attackers a hidden way into a huge share of Linux-based systems through a trusted, widely used compression library.

A contributor who had spent years building trust within the XZ Utils open-source project quietly inserted a sophisticated backdoor into the library, which many Linux distributions bundle by default, discovered only by chance when a developer noticed unusual SSH login latency during routine performance testing. Had it gone undetected longer, the backdoor would have given attackers remote code execution on an enormous number of Linux systems, since XZ Utils sits deep in the dependency chain of core system components most administrators never think to audit directly. This incident is the clearest recent proof that open-source trust chains, not just software vulnerabilities, are now a legitimate, sophisticated attack target on Linux, and it should shape how businesses think about dependency auditing, not just patch management.

Open source options: Wazuh and the free Linux EDR landscape

Wazuh is the most widely adopted free, open-source security platform combining EDR-style host monitoring with SIEM capability, offering file integrity monitoring, rootkit detection, active response, and native compliance mapping to frameworks like PCI DSS and HIPAA, entirely without licensing cost.

Tool	Best For
Wazuh	Full XDR/SIEM platform, compliance mapping, active response
osquery	Lightweight, SQL-based endpoint querying
Velociraptor	Deep forensic investigation and incident response

Wazuh has passed 10 million annual downloads and recently added local threat-hunting capability, running under a GPL-2.0 license with no feature gating on the open-source core, meaning the same detection and response capability commercial customers get, minus managed cloud hosting, is available at zero licensing cost. This makes it a genuinely credible option for businesses that can’t justify enterprise per-endpoint EDR pricing across a large Linux fleet, though it requires more hands-on infrastructure management than a fully managed commercial platform, someone needs to run and maintain the Wazuh server and indexer components yourself. For a business already comfortable managing Linux infrastructure, that trade-off, engineering time instead of licensing fees, is often a reasonable one.

What does this look like for a small Linux fleet without a platform team?

Start with Wazuh’s free tier on your highest-value Linux systems first, internet-facing web servers and any hypervisor infrastructure, rather than attempting fleet-wide deployment immediately without the operational capacity to maintain it.

Prioritize coverage by exposure, not just server count: a public-facing web application server handling customer data needs monitoring before an internal build server does. Enable file integrity monitoring and active response from day one, since these two features alone catch a meaningful share of the webshell and brute-force activity covered earlier, without requiring deep tuning to start delivering value. Cyber Security Solutions Ltd helps smaller teams stand up exactly this staged Wazuh deployment, starting with the highest-exposure systems and expanding coverage as the team’s operational capacity grows, rather than promising full fleet coverage on day one and quietly under-delivering on maintenance later.

Conclusion

EDR for Linux closes a gap most businesses don’t realize exists until an incident exposes it, since the servers and hypervisors running quietly in the background often carry more risk than the desktops getting most of the security budget. Audit your Linux and ESXi coverage specifically, not just your blended endpoint percentage, and start with the highest-exposure systems if resources are limited. If you want help auditing or deploying Linux EDR across your infrastructure, Cyber Security Solutions Ltd can walk through it with you at cybersecuritysolutionsltd.com.