Today’s Joke: Microsoft Wants to Protect Your Linux Machines

If you needed a laugh with your morning coffee, Computer Sweden just ran a piece on Microsoft’s latest security announcement: Microsoft Defender now supports Linux desktops in public preview.

The pitch is that organizations already running Microsoft Defender on their Linux servers can now manage their developers’ Ubuntu, Debian, Fedora, or RHEL workstations through the exact same security platform—provided, of course, that they pay up for a Microsoft Defender for Endpoint Plan 2 or an enterprise Microsoft 365 E5/E7 license.

Reading that premise stops you in your tracks before you even get to the workstation part. Why would anyone in their right mind put Microsoft Defender on a Linux server in the first place?

From "Linux is a Cancer" to Running the Datacenter on It

To appreciate the irony of Microsoft selling Linux security software, you have to remember how we got here.

A long time ago, Microsoft alternated between pretending Linux did not exist and treating it as a mortal enemy. In October 1998, a series of leaked internal strategy memos—famous across the industry as the Halloween Documents—revealed that Microsoft engineers privately recognized Linux and open-source software as a direct threat to Windows Server, outlining strategies to undermine open standards through proprietary extensions ("Embrace, Extend, and Extinguish").

Three years later, in June 2001, then-CEO Steve Ballmer dropped all pretense in an interview with the Chicago Sun-Times, declaring:

"Linux is a cancer that attaches itself in an intellectual property sense to everything it touches."

For years, Microsoft fought tooth and nail against the open-source ecosystem. And then reality intervened—inside their own datacenters.

It started early: when Microsoft bought Hotmail in late 1997, they discovered that the world’s largest webmail service handled its massive incoming traffic on FreeBSD and Apache, and Microsoft spent years painfully trying to force it onto Windows NT and IIS. By the time the cloud era arrived, Windows simply could not compete as the backbone of hyperscale networking and server infrastructure.

To handle the massive incoming traffic hitting Azure datacenters without choking, Microsoft had to build SONiC (Software for Open Networking in the Cloud)—a network operating system built on Debian Linux—to run the border routers and spine-and-leaf switches across its own fleet. Soon after, Linux overtook Windows as the majority operating system running inside Azure virtual machines.

Next came the desktop capitulation. To keep developers from abandoning Windows laptops altogether, Microsoft bolted WSL (Windows Subsystem for Linux)—including an actual, Microsoft-compiled Linux kernel—straight into Windows.

Look at the trajectory:

1. Ignore Linux and call it a cancer.
2. Quietly rely on Linux in your own datacenters to route incoming traffic and keep your cloud alive.
3. Ship a Linux kernel inside Windows so developers stop leaving.
4. Try to sell proprietary Microsoft security agents back to the Linux ecosystem.

A Hard "No": The CVE Track Record of Microsoft’s Security Tools

Even if you set history aside, you only have to look at the vulnerability record of Microsoft’s security tooling over the years to reach a verdict. From us, it is a hard NO.

An endpoint security agent is not a harmless background utility. By design, it runs with the highest privileges on the machine (SYSTEM on Windows, root on Linux) and automatically inspects, unpacks, and parses untrusted network traffic, archives, and binaries. When that security tool is poorly engineered, it does not protect the server—it becomes the primary attack vector.

Look at the CVEs that have targeted Microsoft Defender and its related guardrails over the years:

• CVE-2017-0290 (The MsMpEng RCE Era): Google Project Zero researcher Tavis Ormandy demonstrated that a flaw in Microsoft’s Malware Protection Engine (mpengine.dll) allowed full Remote Code Execution as SYSTEM merely by having Defender scan a specially crafted file. An attacker did not need a user to click anything; an incoming email or a file sitting in a web directory was enough for the antivirus engine itself to hand over the machine.
• CVE-2021-1647 & CVE-2021-24092: Actively exploited zero-day memory corruption in the Defender engine, alongside a local privilege escalation vulnerability in Defender that sat undiscovered in production for twelve years.
• CVE-2025-26684 (Defender for Linux mdatp Root Escalation): You do not even have to look at Windows to see what happens when you put Defender on Linux. Last year, researchers disclosed a local privilege escalation flaw specifically in Microsoft Defender for Endpoint on Linux (mdatp). Microsoft’s agent included a Python helper script (/opt/microsoft/mdatp/conf/scripts/open_files.py) running as root to scan for vulnerable Java processes. The script blindly executed unverified binaries named java found in process paths—meaning a low-privileged local user could plant a fake java binary and wait for Microsoft Defender to execute it as root.
• CVE-2026-33825 ("BlueHammer") & This Week’s Patch Tuesday: Earlier this year, the BlueHammer exploit chain abused race conditions in Defender’s signature update mechanism to gain SYSTEM privileges and dump the SAM database. And as we covered two days ago in The Zero-Day Lottery, Microsoft’s 1,413-patch October 2026 release included active bypasses of Windows Defender Application Control (CVE-2026-108398) and SmartScreen (CVE-2026-96951).

Installing a closed-source agent with that pedigree as root on a hardened Linux server is not risk mitigation. It is importing Windows problems onto a machine that didn't have them.

Why We Only Trust Open-Source Security

There is no shortage of proven, native, open-source security tooling built specifically for Linux. Between kernel-enforced Mandatory Access Control (AppArmor and SELinux), nftables, cryptographic isolation with WireGuard, eBPF and auditd telemetry, Wazuh, Suricata, Fail2ban, and our own autonomous 150ms egress tripwires, a Linux operator already has every primitive required to lock down a host at the kernel boundary.

More fundamentally, closed-source security is something we do not trust.

When a vendor ships a proprietary binary blob that demands root access and hooks into your kernel or filesystem, you are forced to take their marketing department's word that the code is sound. You cannot audit how it parses untrusted inputs. You cannot verify what telemetry it exfiltrates. And when it introduces a local privilege escalation bug like CVE-2025-26684, you cannot fix it yourself.

When we have the source code, two critical things change:

1. Our own tools can audit the defense. When the defensive stack is open source, we can point our own static analyzers, fuzzers, and local security models directly at the source code of the tools protecting our servers. Finding a weakness in a defense layer is orders of magnitude faster and more reliable when you have the source tree in front of you instead of reverse-engineering a stripped proprietary binary.
2. Thousands of independent eyes beat one vendor silo. An open-source security tool is scrutinized continuously by hundreds—even thousands—of independent security firms, kernel maintainers, academic researchers, and adversarial auditors worldwide. Every line of parser logic and privilege handling is debated in public.

Security through obscurity dies the moment an attacker points a GPU cluster at a binary. Real trust comes from transparency: open source code that thousands of security engineers have tried to break, audited in the daylight, and verified down to the syscall.

Keep Microsoft Defender on the Windows machines that desperately need it. Our Linux servers are doing just fine without it.