Microsoft Defender Update Might Disable Linux Protection

Microsoft identified two Defender update problems on July 27. As part of its response, Microsoft says version 101.26052.0011 and later fixes the FIPS-mode issue. Releases 101.26042.0000 through 101.26042.0009 could disable protection on some Linux hosts after an upgrade or reinstall followed by a reboot.

In the separate FIPS path, the update could fail to install and leave the earlier package in place on some Red Hat Enterprise Linux (RHEL) 8 and 9 systems using Federal Information Processing Standards (FIPS) mode. FIPS mode enforces approved cryptography.

For the Microsoft Defender for Endpoint (MDE) Linux extension, automatic updates are enabled by default when either of the two Defender for Servers paid plan tiers runs through Microsoft’s Defender for Cloud management service with the endpoint integration enabled. Microsoft withdrew the listed releases and recommends 101.26042.0011 for deployments that have not upgraded.

Under the automatic-update setting, administrators can receive an affected build without selecting it manually. Microsoft lists the affected builds and symptoms but does not identify the disabled-service cause. Its product details do not attribute either failure to exploitation, a vulnerability, or an outside attack.

Nor do the listed versions establish that every system experienced a failure; they define which machines require inspection.

How Automatic Updates Created the Operational Risk

Defender’s Linux role has broadened since Microsoft added endpoint detection and response in 2020 and expanded support to unmanaged devices in 2021. On managed Linux servers, service status is material to protection rather than merely to update compliance. Centralized management can deliver the MDE Linux extension without an administrator choosing each build, so a completed deployment job does not establish that protection remains active.

Rebooting distinguishes the disabled-service path from an ordinary installation check. A machine could accept an affected 101.26042 build, restart, and then operate with active protection impaired until remediation. Users need both the installed version and the post-reboot service state: version inventory identifies machines that may be exposed, while a service check verifies that the security control is running.

In contrast, FIPS-enabled RHEL devices face a different outcome. Platform version 101.26042.x could fail to install on some systems, leaving the previous Defender version in place. Installing an affected build successfully and finding the service disabled after reboot is a separate failure, so administrators must not apply one replacement number to both paths.

Because Microsoft has not disclosed the cause, observable checks are more useful than causal speculation. A normal-looking deployment record cannot verify the running security control; only the installed version and service status can distinguish a completed repair from a machine that still needs attention. Version-based inspection also avoids treating the affected range as a count of outages, which Microsoft has not provided.

Which Builds Administrators Need to Check

For the disabled-service path, systems awaiting the update should use 101.26042.0011 because Microsoft withdrew the affected builds from its normal production channel. Machines that already installed a listed build need the associated remediation and a post-reboot service check. For the installation path, version 101.26052.0011 and later fixes the FIPS-mode failure on affected RHEL 8 and 9 systems; administrators should confirm that it installed instead of leaving the prior version in place.

A separate Message Center notice says Microsoft paused build 101.26052.0009 on RHEL 8 and 9. Microsoft’s separate pause is not one of the two remediation paths, and its similar version number should not be confused with the 101.26052.0011-or-later FIPS fix. Routine deployment prerequisites remain separate from the failures: Microsoft lists 2 GB disk and 1 GB RAM as minimum system requirements.

Both Linux paths also differ from a separate earlier Defender update failure that falsely flagged Windows certificates. After immediate remediation, Microsoft recommends keeping Defender for Endpoint within the latest three platform versions, and each release expires after nine months. Administrators can close each case only after installing 101.26042.0011 for the disabled-service path or 101.26052.0011 or later for the FIPS path and confirming that active protection remains running after reboot.