Your antivirus runs as SYSTEM, and that's the whole story

The headline writes itself: Microsoft’s own antivirus has two zero-days, both being exploited right now, both on CISA’s must-fix list with a federal deadline of June 3. The tool you deployed to watch the endpoint is the thing getting attacked. That reads like a betrayal, and it’s the take most of the coverage is running with.

It’s also the wrong place to put the emphasis. The more interesting detail is that neither of these bugs lets anyone in. They are not initial access. They are what an attacker reaches for after they’re already on the box. To understand why that keeps happening to security software specifically, you have to look at the one design decision underneath all of it.

The obvious read

CVE-2026-41091 is a local privilege escalation in the Malware Protection Engine, the scanner that runs as SYSTEM. CVE-2026-45498 is a denial-of-service that, per Malwarebytes, can crash or disable the engine on demand. CISA added both to its Known Exploited Vulnerabilities catalog in a batch dated May 20, on the basis of Microsoft’s own confirmation that they’re being used in attacks. Two weeks to fix, federal mandate, your security product is the vulnerability. Panic seems reasonable.

It isn’t, quite. The CVSS vector for 41091 is AV:L/AC:L/PR:L/UI:N, base score 7.8, per the NVD entry. The AV:L means local. The PR:L means the attacker already needs low-privilege code execution on the machine. This is a post-compromise escalation step, not a remote takeover. Someone has to phish a user, pop a browser, or otherwise land a foothold first. Then, and only then, does 41091 turn that foothold into SYSTEM. “Defender is remotely ownable” is not what the vector says.

The pattern

Here’s the part worth sitting with. The reason a parser bug in Defender is automatically a SYSTEM-level prize is that the scanner has to run as SYSTEM. The Malware Protection Engine, mpengine.dll running inside the MsMpEng.exe service, needs unrestricted filesystem access by design. It reads quarantined malware, inspects protected directories, and remediates infected paths that no ordinary user process can touch. You cannot scan everything if you’re sandboxed away from anything.

So the engine runs unsandboxed, as LocalSystem, evaluating untrusted input all day long. That’s not a configuration mistake. It’s the job. And it means every bug in the file-parsing path inherits the engine’s privilege by default. A flaw that would be a minor nuisance in a user-mode app becomes a direct route to SYSTEM the moment it lives in the scanner.

This is a class of bug, not an incident. Researchers flagged the structural problem nearly a decade ago, and the engine keeps producing variations on the same theme. The component isn’t unlucky. It’s positioned exactly where a bug does the most damage, doing exactly the kind of work that produces bugs.

The evidence

Walk the history. The clearest prior example is CVE-2017-0290, a type-confusion flaw in MsMpEng’s JavaScript interpreter, found by Project Zero’s Tavis Ormandy and Natalie Silvanovich and described at the time as the worst Windows remote code execution in recent memory. Because the engine scanned untrusted input automatically, the bug needed no user action to fire, and exploitation gave unauthenticated RCE at SYSTEM. The scanning was the trigger.

Then CVE-2023-36422, an untrusted-search-path elevation where MsMpEng loaded attacker-placed DLLs from unsecured directories. Same engine, same SYSTEM context, different parsing failure. And now 41091, which the NVD classifies as CWE-59, improper link resolution before file access. The canonical version of that bug: the engine operates on a file path without properly resolving a symbolic link, NTFS junction, or hardlink that a low-privilege attacker planted in a spot the scanner will visit. MsMpEng follows the link under its SYSTEM token and reads or writes a protected resource it should never have touched.

Three different parsing failures across three different years, JavaScript then DLL search path then link resolution, all landing in the same unsandboxed SYSTEM service. The specific bug changes. The blast radius doesn’t, because the blast radius is a property of where the code runs, not what the code got wrong.

The exact privileged operation MsMpEng performs against the link target in 41091, the write or delete or DACL abuse, isn’t public. Microsoft’s advisory is terse and no proof-of-concept had surfaced as of this writing. Worth flagging, because secondary coverage sometimes blurs in an earlier, separate Defender LPE that did have a leaked PoC and drew geolocated activity. That’s a different CVE. Don’t let the borrowed details inflate your read of this one.

The DoS, 45498, carries its own honest caveat: the two scoring authorities disagree. NIST scored it 7.5 with a network vector; Microsoft scored it 4.0 with a local one. Microsoft is authoritative on its own product, so the network-exploitable reading is unconfirmed. But the gap itself is the signal. A network-reachable way to silence Defender is a categorically different problem from a local one, and until that’s resolved you’re scoping against a question mark, not an answer.

What this means for prioritization

Treat the engine update like a kernel patch that happens to ship faster and quieter. The fix is engine build 1.1.26040.8 and platform build 4.18.26040.7, corroborated across Bleeping Computer, Help Net Security, and CSO Online citing MSRC. These ride the daily signature-update channel out of band, no Patch Tuesday wait, no reboot. The installer stops the services, swaps the build, and restarts in place.

For internet-connected endpoints pointed at Microsoft Update, that means most of your fleet is effectively self-healing inside roughly 48 hours. That’s the good news, and it’s why the panic framing overshoots. The actual exposure isn’t “every Windows machine.” It’s a narrower, knowable set.

The real exposure is the managed and isolated fleet. Per Microsoft’s update-management documentation, WSUS-managed endpoints will not deploy the engine or platform update until an administrator approves it. Configuration Manager and Intune with a Software Update Point inherit the same gate. Air-gapped and network-restricted environments have it worse: with no path to Microsoft Update or WSUS sync, the engine simply doesn’t move unless someone seeds an internal UNC share or stages the package by hand. The “Defender updates itself” reputation holds right up until the update channel is obstructed, and in a lot of enterprises it’s deliberately obstructed.

So the prioritization call is narrow and concrete. If your endpoints pull from Microsoft Update, confirm the new build landed and move on. If they go through WSUS, ConfigMgr, or an air-gapped staging process, the clock is real and the update is waiting on a human. Check the engine version, not just whether definitions are current, because the engine and platform packages can be approved separately from signatures. Microsoft says both bugs are being exploited in the wild, with no attribution, no victimology, and no confirmed PoC, so the urgency is the KEV listing itself, weighted toward the fleet where delivery isn’t automatic.

What to watch

Two things would change the shape of this. First, whether anyone resolves the 45498 scoring split toward the network vector. If it lands at network-reachable, a remotely triggerable way to crash Defender stops being an evasion convenience and becomes its own initial-stage problem. Second, whether a confirmed attack chain emerges that pairs the DoS with the LPE: blind the scanner, then stage the symlink for the escalation without the engine interfering. The logic is obvious enough that someone will try it, but no public source documents it yet, and the gap between “obviously possible” and “observed” is exactly where overconfident analysis goes wrong.

The durable takeaway isn’t about these two CVEs. It’s that the scanner runs as SYSTEM because the job demands it, which means the next one of these is already in the pipeline, somewhere in the parsing path, waiting for a researcher. Patch this batch, and then watch the engine version the way you watch the kernel build. That’s the line we draw in the daily digest: a bug in your security tool isn’t a special case, it’s the same priority math with a higher floor on the impact. The sentinel runs with the keys to the building. That’s the point of it, and it’s the problem with it.

Sources

• Microsoft Defender vulnerabilities exploited in the wild (CVE-2026-41091, CVE-2026-45498) | Help Net Security — 2026-05-21
• NVD — CVE-2026-41091 — 2026-05
• NVD — CVE-2026-45498 — 2026-05
• Microsoft Defender vulnerabilities are being exploited in the wild | Malwarebytes — 2026-05
• CISA — Adds Seven Known Exploited Vulnerabilities to Catalog — 2026-05-20
• Microsoft rushes emergency fix for critical antivirus bug | InfoWorld — 2017-05
• CVE-2023-36422: Windows Defender Privilege Escalation | SentinelOne Vulnerability DB — 2023
• Microsoft Warns of Two Actively Exploited Defender Vulnerabilities | The Hacker News — 2026-05
• Microsoft warns of new Defender zero-days exploited in attacks | Bleeping Computer — 2026-05
• Microsoft patches two zero-day flaws in Defender | CSO Online — 2026-05
• Manage how and where Microsoft Defender Antivirus receives updates | Microsoft Learn — 2026-04-13