Microsoft Ships Urgent Fix for Defender on Linux Bug That Silently Disabled Endpoint Protection

Microsoft has issued a critical update for Defender for Endpoint on Linux after discovering that a series of recent platform builds could leave servers unprotected following a routine reboot. The defect, which affects versions 101.26042.0000 through 101.26042.0009, means that an apparently successful agent upgrade can turn into a silent protection gap the next time the machine restarts—a scenario that is particularly dangerous for automatically updated cloud workloads.

What went wrong—and which builds are dangerous

The problem is not a traditional security vulnerability but a software reliability failure with serious defensive consequences. In a July 27 advisory, Microsoft confirmed that "the Defender service might be disabled on some devices after an upgrade or reinstall, followed by a restart." The company pulled the offending builds from the production channel and published platform release 101.26042.0011 to resolve the issue. A later July build, 101.26052.0011, also contains the fix and adds a new antivirus_enforcement_level field to the mdatp health output, which helps administrators verify whether real-time scanning is active.

Here are the affected and fixed versions:

The bug affects all supported Linux distributions, not just one OS family. Microsoft specifically warns that organizations using Defender for Servers Plan 1 or Plan 2 through Defender for Cloud with endpoint integration enabled may have received the defective builds automatically. In those environments, the MDE.Linux extension is updated by default, meaning that vulnerable agents could have landed on servers without any manual installation step.

A separate but related flaw prevented the 101.26042.x branch from installing on Red Hat Enterprise Linux 8 and 9 systems running in FIPS mode. That issue, fixed in 101.26052.0011, did not disable existing protection but left machines stuck on older Defender versions. Administrators managing FIPS-enabled RHEL hosts should target 101.26052.0011 or newer as their upgrade path.

Why it matters: the reboot gap

The sequence is what makes this defect unusually treacherous. Imagine a typical patching cycle: a Linux sysadmin updates the Defender package via yum update mdatp or apt-get install --only-upgrade mdatp, sees the command complete successfully, and moves on. The server continues running and reporting telemetry. Weeks later, a kernel patch requires a reboot. After the restart, the mdatp service is dead—and nobody notices because no one expects a working agent to fail on boot.

Microsoft’s own wording—that the issue “might impact active protection on rebooted devices until remediation steps are taken”—does not guarantee that every system running a vulnerable build will experience the failure. But because the trigger appears to be restart-specific, and because server reboots are a regular part of IT operations, the risk cannot be ignored. A latent problem that activates only after a routine maintenance reboot is exactly the kind of regression that escapes immediate detection until it has spread widely across a fleet.

For security teams, the impact is not theoretical. A disabled endpoint agent means no real-time antivirus scanning, no file-behavior monitoring, and potentially incomplete endpoint detection and response telemetry. While other controls such as network monitoring or cloud workload protection may remain active, the host-level visibility gap is significant. In effect, a legitimate software update can produce the same defensive blind spot that attackers deliberately pursue when they try to kill endpoint agents.

For cloud-managed estates: automatic rollout amplifies exposure

Organizations using Microsoft Defender for Cloud with automatic agent deployment should take particular note. The MDE.Linux extension is designed to simplify onboarding and management by automatically updating the Defender agent across Azure, multicloud, and on-premises servers. That convenience, however, becomes a liability when a flawed build is shipped through the auto-update channel.

A server that received a vulnerable Defender build through cloud management may not have been touched by a local administrator at all. The package landed, installed, and began running. Only after the next planned (or unplanned) restart would the service fail. Because the update history might show a successful installation, and because the server reported healthy telemetry right up until the reboot, the failure can remain hidden until someone actively checks mdatp health.

Hybrid estates add another layer of complexity. Some Linux servers may be managed through Defender for Cloud, others through configuration management tools like Ansible or Puppet, and still others via manual package commands. Each management path could have its own reboot cadence, meaning the same vulnerable build could trigger failures at different times across the environment. Tracking down which devices are affected requires looking beyond the package version to actual service state.

The FIPS complication: tightly regulated environments hit too

For government contractors, defense agencies, and other organizations that require FIPS-validated cryptography, the secondary defect adds another wrinkle. On RHEL 8 and 9 with FIPS mode enabled, the 101.26042.x branch refused to install cleanly. That meant such systems could not move to the latest platform release, leaving them on older Defender builds indefinitely.

While an older functioning agent is better than a disabled one, version drift is still a concern. Endpoint security agents need regular platform and engine updates to maintain compatibility with new kernels, distributions, and threat-detection logic. A deployment failure that blocks updates can quietly widen the security posture gap over time. Microsoft’s fix in 101.26052.0011 ensures that FIPS-enabled RHEL servers can now receive the latest Defender platform, bringing them back into the normal update stream.

How we got here: Defender’s growing Linux footprint

Defender for Endpoint on Linux has evolved from a lightweight sensor into a full-featured endpoint protection platform. It now provides real-time antivirus, EDR, vulnerability management, behavioral monitoring, and centralized investigation—all integrated with Microsoft Defender XDR and Sentinel. Microsoft’s architectural shift from Auditd to eBPF-based sensors has improved performance but also introduced new failure modes that surface only under specific kernel and configuration conditions.

This is not the first time Defender on Linux has required an urgent fix. In January 2026, Microsoft corrected a bug where real-time scanning of the /dev/watchdog device could trigger unexpected system reboots on hardware with a watchdog enabled. In April, the company patched an SELinux policy cleanup issue that affected upgrades on some RHEL-based systems. Each incident is distinct, but together they illustrate the challenge of building a low-level security agent that must operate across a diverse Linux ecosystem.

The automatic update channel—one of Defender’s strongest selling points—also concentrates risk. A single problematic release can reach thousands of servers before anyone notices. This incident underscores the need for staged deployment rings, health monitoring, and post-reboot validation, even for software that is supposed to protect everything else.

No evidence of exploitation has been disclosed, and Microsoft has not assigned CVE identifiers to these defects. The reboot issue is a reliability bug, not a remotely exploitable vulnerability. Still, the defensive impact is real, and security teams should treat any interval during which Defender was stopped on a production server as a potential monitoring gap.

What you need to do right now

For any organization running Defender for Endpoint on Linux, the following steps are essential:

1. Inventory your Linux Defender versions. Use your package manager or the Defender portal to identify all devices running builds 101.26042.0000 through 101.26042.0009. Commands differ by distribution:
   - RHEL/CentOS: sudo yum list installed mdatp
   - SUSE: sudo zypper info mdatp
   - Ubuntu/Debian: sudo apt list --installed mdatp

2. Update to a fixed build. For most environments, 101.26052.0011 or later is the safest bet because it addresses both the reboot defect and the FIPS installation issue. Use the standard upgrade commands:
   - sudo yum update mdatp (RHEL/CentOS)
   - sudo zypper update mdatp (SUSE)
   - sudo apt-get install --only-upgrade mdatp (Ubuntu/Debian)

3. Verify that the service is running after a controlled reboot. Package version alone is insufficient. After updating, reboot a representative set of test systems and confirm the service starts automatically:
   - service mdatp status should show active (running).

4. Check real-time protection and enforcement mode. Run mdatp health and look for real_time_protection_enabled: true. In build 101.26052.0011 and later, you can also query the antivirus_enforcement_level field directly:
   - mdatp health --field antivirus_enforcement_level

5. Audit the Defender portal for anomalies. Look for Linux devices that went offline, stopped reporting telemetry, or changed health state around recent reboot windows. The portal can reveal fleet-wide patterns, but local verification remains critical because a failed agent may be unable to reliably report its own status.

6. Review the potential monitoring gap. If any critical servers ran without active Defender protection for a period, consider conducting a retrospective security review. Look for privilege escalations, new user accounts, unusual outbound connections, or modified systemd services that occurred while the agent was down.

For servers managed through Defender for Cloud, prioritize devices that have been rebooted since receiving a vulnerable build. Also check FIPS-enabled RHEL hosts for failed installation attempts and upgrade them directly to 101.26052.0011.

Looking ahead: smarter rollout hygiene for endpoint agents

Microsoft has fixed the immediate bugs, but the episode leaves a larger operational lesson. Endpoint agents that can silently disable themselves after a reboot are a reminder that update automation, while necessary, must be paired with validation. Organizations should consider adopting staged deployment rings for Defender updates, including a representative set of Linux kernels, FIPS-enabled hosts, SELinux-enforcing systems, and cloud-managed servers. Validating agent health after a controlled reboot in that ring can catch regressions before they hit the full production fleet.

Microsoft’s addition of the antivirus_enforcement_level field is a step in the right direction. More granular health visibility into the agent’s operational mode will help administrators detect subtle failures faster. For now, the most important action is to patch immediately, verify that protection is truly active, and not assume that a successful package install means a server is safe.