Walk into a board meeting with a slide showing 1,200 critical vulnerabilities and 44 internet-facing assets, and you will likely see polite acknowledgment rather than meaningful discussion. The question that follows tends to cut through quickly: what does this mean for the business?

Boards allocate capital based on financial exposure, not vulnerability counts. A list of findings describes workload, but directors are responsible for revenue protection, liability, and risk to the balance sheet. When security reporting remains technical, it sits outside the way investment decisions are made elsewhere in the organization. The issue is less about communication and more about framing the problem in terms the business already understands.

From severity to risk

CVSS measures theoretical severity, but it does not measure business risk. A high score indicates that a flaw could be dangerous, yet it does not tell you whether the vulnerability is reachable in your environment, whether exploit code exists, or whether it is likely to affect revenue in the near term. It answers a useful engineering question, but it does not answer the question the board is asking.

That question is about likelihood and impact. Most enterprise risk frameworks define risk in those terms, and that is how financial decisions are made. The gap becomes clear when two vulnerabilities appear similar on a dashboard but carry very different consequences. A high-CVSS issue on a segmented lab system may present little business risk, while a moderately severe vulnerability on an internet-facing production system with active exploit activity can expose regulated data and revenue streams.

What is often missing in that comparison is threat context. Understanding how attackers behave, which vulnerabilities they are exploiting, and where access paths actually exist changes how risk is interpreted. Active Risk in InsightVM brings those elements together by combining exploit telemetry, attacker behavior, and asset context to estimate the likelihood that a vulnerability will be used. When that likelihood is paired with business impact, the conversation shifts toward exposure rather than severity.

From CVSS scores to financial exposure

Prioritization alone does not translate into board-level decisions. Knowing what is most likely to be exploited is necessary, but it is not sufficient when the goal is to justify investment.

FAIR provides a way to bridge that gap. The model defines risk as a combination of how often a loss event is likely to occur and how much that event would cost. In practical terms:

Annualized Loss Exposure (ALE) = Loss Event Frequency × Probable Loss Magnitude

Active Risk informs the likelihood side of that equation by grounding it in observed attacker behavior and exploit activity. FAIR converts that likelihood into financial terms, allowing security teams to describe exposure in a way that aligns with how capital is allocated.

Instead of reporting that a set of vulnerabilities is “high risk,” the discussion becomes more concrete. A team might say that a group of issues represents several million dollars in annualized exposure across systems tied to revenue. That is a number that can be evaluated alongside other business risks, rather than interpreted as a technical signal.

A practical example

Consider two vulnerabilities identified during a scan. The first is a CVSS 9.8 issue on a segmented guest Wi-Fi router. It is severe from a technical standpoint, but it has no access to sensitive data, no path into production systems, and no evidence of active exploitation.

The second is a vulnerability with a moderate CVSS score on an internet-facing customer database. Public exploit code exists, and the system stores regulated data tied directly to revenue and compliance obligations.

On a scanner dashboard, the first may appear more urgent. When viewed through a financial lens, the second carries greater risk.

Assume an annual probability of exploitation of 20 percent for the database scenario. If the potential impact includes $750,000 in incident response, $1.2 million from several days of business interruption, $600,000 in legal and regulatory costs, and $1 million in customer churn and reputational damage, the total loss for a single event is $3.55 million.

Applying the FAIR model results in approximately $710,000 in annualized exposure. That figure reflects the risk carried by that single vulnerability on a production system.

By contrast, even if the Wi-Fi router vulnerability had a 5 percent probability of exploitation and a $50,000 impact, the resulting exposure would be around $2,500. Both findings may appear critical in a technical report, but only one represents a material financial concern.

This is where Active Risk and FAIR work together. One identifies where attackers are likely to act, and the other expresses the consequence in financial terms. The combination changes how vulnerabilities are evaluated and how priorities are set.

Visualizing exposure across your environment

Once risk is expressed in financial terms, the next step is to understand how that exposure is distributed. Boards tend to think in terms of portfolios rather than individual issues, and the same principle applies to cybersecurity.

In most environments, exposure is not evenly spread. A relatively small number of systems and vulnerabilities account for a large portion of potential loss. Internet-facing services, systems tied to revenue, and assets with known exploit activity often sit at the higher end of that distribution.

This creates a practical way to focus effort. Rather than attempting to address every vulnerability equally, teams can identify where exposure is concentrated and reduce risk in those areas first. In many cases, addressing a small number of issues can significantly reduce overall exposure, particularly when those issues sit on systems that are both reachable and business-critical.

A before-and-after view helps make this visible. If an organization reduces modeled exposure from several million dollars to a substantially lower figure through targeted remediation, the result can be explained in terms of reduced downside risk rather than increased patching activity. Over time, tracking that change shows whether investments are producing measurable outcomes.

Making risk actionable

By the time exposure is expressed in financial terms, the discussion in the boardroom has already shifted. The focus moves away from counts and severity toward risk, trade-offs, and acceptable levels of exposure.

One of the first issues that arises in that context is the assumption that risk should be driven to zero. In practice, eliminating all exposure is neither achievable nor economically sensible. Reducing risk always involves trade-offs, and those trade-offs become clearer when expressed in financial terms.

If an organization has already reduced exposure significantly, but further reduction requires a disproportionate increase in cost, the decision becomes one of balance. The question is no longer why risk still exists, but whether the remaining exposure aligns with the organization’s tolerance.

The same logic applies when discussing budget. Requests framed in operational terms, such as additional headcount or tooling, are difficult to evaluate in isolation. When those requests are tied to measurable reductions in exposure, the relationship between cost and benefit becomes clearer.

For example, if additional resources reduce several million dollars of modeled exposure at a fraction of that cost, the investment can be assessed alongside other initiatives using the same financial lens. At that point, the discussion is no longer about capacity. It is about risk reduction.

Putting security in business terms

Reducing exposure also affects how the organization is perceived externally. Cyber insurance underwriting, for example, increasingly considers factors such as attack surface, exploit availability, and remediation speed. Demonstrating that exposure is measured and reduced over time can influence how risk is priced.

The same applies during customer due diligence. Being able to explain where risk exists, how it is prioritized, and how it has been reduced provides evidence of maturity. It shows that security is being managed deliberately rather than reactively.

Aligning to risk tolerance

Productive board discussions tend to end with agreement on acceptable levels of exposure. Without a financial view, every issue can appear urgent. With it, prioritization becomes more grounded.

Leadership can evaluate whether the level of risk being carried is consistent with business objectives, and whether further investment is warranted. That shifts vulnerability management from a process focused on volume to one focused on where exposure is concentrated and how it can be reduced most effectively.

Clear exposure, clearer decisions

Vulnerability management has often been treated as an operational activity centered on patching and scanning. When combined with threat context and financial modeling, it becomes part of enterprise risk management.

Instead of reporting how many vulnerabilities exist, security leaders can describe how much exposure the organization carries. Instead of focusing on activity, they can show how targeted actions reduce risk over time. That framing aligns cybersecurity with the same decision-making process used across the rest of the business.

When exposure is clear, decisions become clearer. Leadership can determine where to accept risk, where to transfer it, and where to invest in reduction. The conversation with the board moves away from technical detail and toward measurable impact, which is where security becomes part of strategy rather than an isolated function.

SQL Server: zero-day remote EoP

SQL Server often goes several months in a row without any mention on Patch Tuesday. Today, however, all versions from the latest and greatest SQL Server 2025 back as far as SQL Server 2016 SP3 receive patches for CVE-2026-21262, a SQL Server elevation of privilege vulnerability. This isn’t just any elevation of privilege vulnerability, either; the advisory notes that an authorized attacker can elevate privileges to sysadmin over a network. The CVSS v3 base score of 8.8 is just below the threshold for critical severity, since low-level privileges are required.

Microsoft is aware of public disclosure, so while they assess the likelihood of exploitation as less likely, it would be a courageous defender who shrugged and deferred the patches for this one. Most SQL Server admins and security teams concluded many years ago that exposing SQL Server directly to the internet was not a good idea. Then again, popular search engines for internet-connected devices describe tens of thousands of SQL Server instances, and they can’t all be honeypots.

What could an attacker do as SQL Server sysadmin? Beyond exfiltrating or interfering with the database itself, the obvious target is xp_cmdshell, which allows direct callouts to the underlying OS. The good news is that xp_cmdshell is disabled by default as far back as SQL Server 2005; the bad news is that anyone acting as SQL Server sysadmin can enable it in seconds. At that point, the attacker is acting with the full privileges of the security context under which SQL Server runs, which is ideally a purpose-built account designed with least privilege in mind. If you want to hear some hair-raising stories, you have only to ask any incident response veteran if they’ve ever seen it set up differently.

Anyone paying for Extended Security Updates (ESU) for SQL Server 2014 or SQL Server 2012 may be forgiven for wondering why there’s no security update for those venerable versions of the world’s most widely deployed closed-source database product. We can hope that the vulnerability described by CVE-2026-21262 was introduced in newer codebases only.

.NET: zero-day DoS

Attackers fond of low-effort denial of service attacks against .NET applications will be checking out CVE-2026-26127 today. Microsoft is aware of public disclosure. While the immediate impact of exploitation is likely contained to denial of service by triggering a crash, opportunities for other types of attacks might emerge during a service reboot. Alternatively, if a log forwarder or security agent is impacted, even for a brief period of time, an attacker might carry out an attack in that moment hoping to evade detection under cover of this artificial darkness. Even if a low-skilled attacker simply causes downtime, in some contexts that could be enough to cause an SLA breach or loss of revenue, or at the very least cause a bleary-eyed defender to get paged in the middle of the night.

Authenticator: QR code impersonation

Microsoft Authenticator mobile app users on both iOS and Android should update to the latest version to prevent exploitation of CVE-2026-26123, which involves a malicious app disguising itself as Microsoft Authenticator. Exploitation succeeds when the malicious app receives enough information to impersonate the user.

Authenticator-type apps are often installed on a personal device, but it's not unusual for them to provide multi-factor authentication (MFA) codes for production services in a bring-your-own-device context. This is as good a time as any for defenders to consider how well their mobile device management policy covers app choice enforcement and patching for MFA apps.

The CVSS v3 base score of 5.5 might appear unremarkable, and exploitation requires user interaction, since the user must install the malicious app in the first place. However, exploitation could begin via an attacker-controlled link, or even a malicious QR code that drives users to the malicious app, and a motivated attacker with a physical presence near the user base might well consider this option.

According to Khaled Mohamed, the researcher who discovered this vulnerability, the legitimate Microsoft Authenticator app did not previously register itself as the handler for deep links into its own custom URL scheme. A malicious app could exploit this gap by simply registering itself as the default handler. He further notes that in this scenario, a user of a mobile device with a malicious app installed only needs to click a generic “Open link” dialog, rather than expressly selecting the malicious app each time. This means that the Microsoft advisory is perhaps too optimistic about how much user interaction is required to trigger exploitation.

Microsoft ranks this vulnerability as important on their proprietary severity scale. The advisory also provides a brief peek behind the curtain, since the executive summary notes that “Cwe is not in rca”. The weakness listed on the advisory is CWE-939: Improper Authorization in Handler for Custom URL Scheme.

Microsoft lifecycle update

There are no significant Microsoft product lifecycle changes this month, unless you are responsible for a Microsoft SQL Server 2012 Parallel Data Warehouse instance, which moves beyond extended support as of March 31st. It would be wise not to count on a last-minute extension, since Microsoft has already granted a six month reprieve.

Summary charts

Summary tables

Apps vulnerabilities

Azure vulnerabilities

Developer Tools vulnerabilities

ESU vulnerabilities

Microsoft Office vulnerabilities

Open Source Software vulnerabilities

SQL Server vulnerabilities

System Center vulnerabilities

Windows vulnerabilities

Zero-Day Vulnerabilities: Publicly Disclosed (No known exploitation)

Update history

• 2026-03-16: updated section on CVE-2026-26123 to include researcher commentary.

Windows/Office triple trouble: zero-day security feature bypass vulns

All three of the publicly disclosed zero-day vulnerabilities published today are security feature bypasses, and Microsoft acknowledges the same cast of reporters in each case.

CVE-2026-21510 describes a zero-day Windows Shell security feature bypass vulnerability which is already exploited in the wild. Not to be confused with PowerShell, most people will use the Windows Shell without ever learning its name or even really contemplating its existence. The Windows Shell is Microsoft’s term for the GUI interaction logic for the entire OS provided by explorer.exe and associated libraries and APIs.

CVE-2026-21510 provides an attacker with a way to dodge those pesky Smart Screen or other “are you sure?” prompts. The advisory sets out that “an attacker must convince a user to open a malicious link or shortcut file”. We could parse this wording more than one way, and while shortcut files with a .lnk extension are certainly a prime suspect here, it’s possible that .url files might also be a vector.

The venerable MSHTML/Trident web rendering engine is still present in Windows as a daily driver for Office and Explorer, many years after most people stopped using Internet Explorer.  Accordingly, every so often Microsoft has to patch another zero-day vulnerability in the browser it can’t quite bring itself to rip out of its flagship operating system. Today’s example is CVE-2026-21513, a security feature bypass which starts with the attacker convincing a user to open a malicious HTML file or shortcut file.

If good things come in threes, then perhaps CVE-2026-21514 makes security bypass zero-day vulnerabilities a good thing. Exploitation involves bypassing Object Linking & Embedding (OLE) mitigations by convincing the user to open a malicious Word document. The advisory only lists remediations for LTSC versions of Office and on-prem Microsoft 365 Apps for Enterprise, without mentioning the standard Microsoft 365 suite.

It’s curious that Microsoft has evaluated the attack vector for CVE-2026-21514 as local, because MSRC typically assesses any vulnerability which boils down to “remote attacker tricks user into opening malicious payload” as a remote attack, based on the location of the attacker. However, the advisory specifically calls out that “reliance on untrusted inputs in a security decision in Microsoft Office Word allows an unauthorized attacker to bypass a security feature locally.” It’s not clear whether this is a deviation from prior practice by MSRC, an inadvertent mis-assessment, or an unusual-but-correct assessment of an attack vector that relies on details which Microsoft has not made public. Happily, the Preview Pane is not a vector, which raises the bar slightly for an attacker, since the user must explicitly open the malicious file or web page.

Ultimately, although none of the advisories for CVE-2026-21510, CVE-2026-21513, or CVE-2026-21514 explicitly come out and say it, it’s likely that exploitation in each case involves tricking Windows into participating in another Mark-of the Web laundering scheme using flaws in old components.

Windows DWM: zero-day elevation of privilege

For the second month in a row, the Windows Desktop Windows Manager (DWM) is the site of an exploited-in-the-wild zero-day vulnerability. Last month’s CVE-2026-20805 was an information disclosure vulnerability, effectively a treasure map for threat actors seeking the otherwise obfuscated in-memory address of the kernel-space DWM process. The publication of zero-day elevation of privilege (EoP) vulnerability CVE-2026-21519 today very likely reflects MSTIC and MSRC working to thwart the same threat actor in both cases. As Rapid7 has noted in the past, initial access coupled with local elevation of privilege vulnerabilities is the staple diet of many successful attackers, so the lower CVSS v3 base score of 7.8 seen here versus a broadly equivalent remote code execution is not a sign to delay patching.

Remote Desktop Services: zero-day elevation of privilege

Remote Desktop Services (RDP) are designed to allow a duly authorized remote user to interact with the server, but CVE-2026-21533 allows an unauthorized local user to elevate privileges to SYSTEM. Every Windows Server product back as far as Server 2012 receives patches, so this one has been present for a while. It’s possible that today’s patches close off a long-running exploitation story for at least one threat actor.

RasMan: zero-day denial of service

Exploited in the wild, but perhaps of less concern is CVE-2026-21525, a local denial of service vulnerability in the Windows Remote Access Connection Manager (RasMan). Somewhat unusually for a local vulnerability, the advisory sets out that no privileges are required at all, so even a guest account can exploit this one. You have disabled those guest accounts, right?

Microsoft lifecycle update

There are no significant Microsoft product lifecycle changes this month.

Summary Charts

Summary Tables

Apps vulnerabilities

Azure vulnerabilities

Developer Tools vulnerabilities

ESU vulnerabilities

Microsoft Office vulnerabilities

Other vulnerabilities

Server Software vulnerabilities

SQL Server vulnerabilities

System Center vulnerabilities

Windows vulnerabilities

Zero-Day Vulnerabilities: Known Exploited

Critical Remote Code Execution/Elevation of Privilege

If you received an email with the subject “I LOVE YOU” and an attachment called “LOVE-LETTER-FOR-YOU.TXT”, would you open it? Probably not, but back in the year 2000, plenty of people did exactly that. The internet learned a hard lesson about the disproportionate power available to a university dropout with some VBScript skills, and millions of ordinary people suffered the anguish of deleted family photos or even reputational damage as the worm propagated itself across their entire Outlook address book.

In the quarter century since ILOVEYOU rampaged across global networks, cybersecurity has moved from a niche topic to an “everyone” problem, and many users are wary of all sorts of threats. In recent years, the increasing ubiquity and urgency of AI adoption across the business landscape has attracted the attention of both security researchers and threat actors.

Of course, recency bias and shiny object fixation are real. Even as AI and automation continue to drive down time to known exploitation (TTKE), an attacker who abuses a traditional exploit chain to achieve SYSTEM privileges on a sensitive server still has the keys to the kingdom.

Wormable remote code execution (RCE) vulnerabilities remain rare, but well over half of the 25 exploited-in-the-wild zero-day vulnerabilities published by Microsoft during 2025 provided attackers with elevation of privilege opportunities on Windows assets. Some of those flaws are older than the iPhone, let alone ChatGPT.

Microsoft's decades-long commitment to backwards compatibility creates a conveyor belt supply of déjà vu vulnerabilities. Ultimately, the most pressing threats faced by defenders managing Microsoft estates remain essentially unchanged. Rather than a new wave of AI-related flaws, the chief danger stems from the towering tech debt within core Windows components.

A whirlwind tour of exploited-in-the-wild Microsoft vulnerabilities (2025 edition)

If we really want to know which Microsoft vulnerabilities will provide the most value to attackers in 2026, we should ask a threat actor. Since that might prove difficult to arrange, we’ll do the next best thing: review vulnerabilities exploited in the wild during 2025.

⠀

January: The great escape

The vast Microsoft ecosystem has something for everyone, whether customer or threat actor. Patch Tuesday January 2025 brought us a trio of exploited-in-the-wild Hyper-V kernel vulnerabilities. By September 2025, at least one plausible public proof-of-concept (PoC) for CVE-2025-21333 was published by a vulnerability researcher who apparently shares a name with a Kazakhstani Olympic gymnast. The only safe assumption is that a well-resourced threat actor could develop a private exploit far in advance of that.

Starting from a child VM or Windows Sandbox, exploitation first requires setting out a banquet of benign requests for the hypervisor, delivered via the Hyper-V Virtualization Service Provider (VSP). The goal: mass-allocating objects to arrange large swathes of hypervisor memory in a predictable pattern (aka “heap feng shui”). Next, the attacker sends a malicious request with an oversized buffer, which an unpatched VSP merrily copies into kernel memory, overwriting the header of the adjacent object, whose relative position is now easily surmised. Once the kernel subsequently references the artfully corrupted sibling object, execution as SYSTEM jumps to a portion of memory where the attacker has planted shellcode to exfiltrate a token. The compromised hypervisor could be anything from a developer laptop running a malicious container all the way up to enterprise private cloud infrastructure.

So far, January 2025 is the only time that Microsoft has ever published vulnerabilities in the Hyper-V VSP. Generally speaking, a significant degree of sophistication is required to develop successful exploits of this nature. This goes double if the name of the game is stealth and stability, since a wave of unexplained BSOD events on critical production infrastructure tends to attract blue team attention. Still, once a viable proof of concept hits the public internet, ransomware crews will fold it into their toolkits, and someone, somewhere, is either sitting on an unknown Hyper-V VSP exploit, or hard at work creating the next one.

February: Socket to me

It’s hard to imagine a modern computer without storage or networking capabilities. In fact, it’s hard to imagine a computer from several decades ago without storage or networking. Microsoft is now middle-aged, and that means that buried deep within your shiny new PC are a variety of architectural decisions and logic paths born in the 1980s. If this sounds far-fetched, take a minute to find yourself a fully-patched Windows 11 25H2 machine, and then try to rename any file or directory CON, NUL or PRN. I’ll wait.

Generally speaking, user-mode applications are prevented from wreaking havoc on the kernel through a careful separation of concerns. On Windows, when a user mode application wants to communicate over the network, it talks to WinSock, which in turn talks to the ancillary function driver (AFD), which sits on the kernel side, and coordinates with the kernel network drivers which handle the actual traffic. The AFD is a security boundary between user space and kernel space, and it must be universally accessible to local processes, because even a browser tab in a sandbox needs to make network calls. Any defect in the way AFD parses input from user space can thus provide a way to influence the kernel in unexpected ways. A number of advanced exploit development courses, including offerings from SANS and OffSec, cover AFD in detail.

⠀

⠀

Patch Tuesday February 2025 brought us CVE-2025-21418, which Microsoft credited to Anonymous. We don’t know whether the unnamed tipster provided evidence of exploitation in the wild, or whether Microsoft threat hunters subsequently tracked down their own trail of suspicious bread crumbs, but notorious threat actors such as North Korea’s Lazarus are known to be enthusiastic students of AFD exploits. With several high-profile zero-day vulnerabilities emerging from AFD from late 2024 onwards, it tracks that Microsoft subsequently published and patched a cluster of AFD vulnerabilities in the latter half of 2025.

March: File system shenanigans

Any defenders who had enjoyed a quieter start to the year were rudely awakened by Patch Tuesday March 2025, when six exploited-in-the-wild vulnerabilities all dropped at once. Exploitation of most of the zero-day vulnerabilities published in March starts with the user mounting a malicious Virtual Hard Disk (VHD) image or plugging in a malicious USB stick so that the attacker can exploit a weakness in a filesystem driver, including NTFS and FastFAT.

Remember that information security training which asked you to imagine finding a USB stick with an “IMPORTANT (CONFIDENTIAL)” label on the floor outside the office? The one which asked if you would A) plug the mystery stick into your work PC B) use your boss’ personal laptop in case the files are business critical C) try it in all the PCs in the office until someone asks you to stop or D) report it immediately to the security officer? This is why.

Meanwhile, the true villain of the month was almost certainly CVE-2025-24983, a no-user-interaction-required elevation of privilege vulnerability in the Win32 kernel subsystem. At the time, we pondered why Windows 11 and Server 2019 onwards didn’t receive patches for what looks like a fairly severe vulnerability, but since Microsoft is gradually reimplementing portions of the kernel in memory-safe Rust, we can hope that the vulnerability simply doesn’t exist in modern Windows.

April: Common Log File System driver vulns are quite common

If anyone ever corners you at a party and talks at length about the Ancillary Function Driver as a bounteous source of elevation of privilege vulnerabilities, you will probably have to concede that they are technically correct. While your options include “doing a lap” and then climbing out of the bathroom window, the power move here is to hold your ground, and point to the Common Log File System driver as a far richer vein of exploitable goodness.

As of Patch Tuesday April 2025, CLFS boasts almost twice the number of total vulnerabilities over the past five years vs. AFD, and more than double the number of known-exploited zero-day vulnerabilities. It really is the gift which keeps on giving.

⠀

⠀

It makes sense that something like the Ancillary Function Driver lives in kernel space. After all, something has to sit inside the perimeter to marshall all those network requests from dozens of Chrome tabs. What about the Common Log File System driver though?

It would be tempting to imagine that anything which simply handles log files shouldn’t need direct kernel access at all. When exploring this concept, it’s useful to understand that not only was CLFS designed a long time ago, when high performance in user mode was harder to achieve than it is today, but also that CLFS is much more than simply a means to interact with log files. CLFS is the home of still-essential building blocks like Transactional NTFS (TxF), first introduced almost 25 years ago in Windows Vista, which provides a means for applications to guarantee the integrity of data on disk.

For the past several years, Microsoft has strongly recommended that developers avoid the use of TxF, and while Microsoft is gradually providing modern alternatives to TxF functionality, essential Windows functions such as Windows Update still rely on it to manage critical file integrity. Moreover, CLFS is more than just TxF, and is so tightly integrated into Windows that it’s here to stay for the foreseeable future.

May: The month of expectation, wishes, hope, and classic Windows zero-days [1]

A few days after Patch Tuesday May 2025, Satya Nadella took to the stage at Microsoft Build 2025 to pitch his vision of the open agentic web, although exactly who this version of the future would be open to remains an open question, like: What if a cloud email service was vulnerable to a zero-click prompt injection attack, but could also now buy things with your credit card?

While critical reception for the open agentic web has been mixed, threat actors will be glad of the new attack surface. Meanwhile, defenders worried about in-the-wild exploitation were hard at work patching some more frequent fliers, including another pair of CLFS vulnerabilities and an MSHTML/Trident arbitrary code execution bug. That last one will be familiar to regular Patch Tuesday watchers, but it might come as a surprise to anyone who thought Internet Explorer had gone to live on a nice farm upstate years ago.

The Ancillary Function Driver made another appearance, although it couldn’t quite summon the same main character energy this time around. The May 2025 episode of “AFD vulns exploited in the wild” offered elevation to Administrator, rather than SYSTEM, and a lower exploit code maturity rating. We can always be grateful for small mercies.

[1]: With apologies to Emily Brontë.

June: I’m afraid I can’t let you do that, WebDAV

Windows archeologists and internet users of a certain age may remember WebDAV, a standard originally dreamed up to support interactivity on the web. It was employed by versions of Microsoft Exchange up to and including 2010 to handle interactions with mailboxes and public folders.

Surprising no-one, Windows still more or less supports WebDAV, and it was only a matter of time before that turned out to be a bit of a problem, in the form of CVE-2025-33053 published as part of Patch Tuesday June 2025. Microsoft acknowledged Check Point Research (CPR) on the advisory; CPR in turn attributes exploitation to an APT (Advanced Persistent Threat), which they track as the objectively cool-sounding Stealth Falcon, an established threat actor with a long-running interest in governments and government-adjacent entities across the Middle East and beyond.

June 2025 also saw the publication of CVE-2025-32711, a critical information disclosure vulnerability in Microsoft 365 Copilot. Microsoft is not aware of exploitation in the wild. The researchers named it EchoLeak, describing it as “the first real-world zero-click prompt injection exploit in a production LLM system,” although other researchers arguably got there first.

EchoLeak relies on hidden white-text-on-white-background instructions in an email, which are then ingested into the LLM via RAG (Retrieval-Augmented Generation) when the user asks an entirely pedestrian question (e.g. “Summarize my emails from the past two days”) which requires Copilot to scan the inbox. The malicious instructions have two parts: First, dig up some juicy info, and then retrieve an image from an attacker-controlled server with the sensitive data exfiltrated as a URL parameter.

EchoLeak circumvented Copilot’s Content Security Policy by making the request via a trusted Microsoft service: a now-patched Teams image preview proxy. History suggests that attackers will find other ways out of the walled garden. The Microsoft advisory makes a virtue of minimalism by providing almost no information about the nature of the vulnerability, although Microsoft is surely to be commended for assigning CVEs for cloud service vulnerabilities.

July: The call is coming from inside the intranet

When Patch Tuesday July 2025 came and went without a single exploited-in-the-wild vulnerability published, many people may have breathed a sigh of relief. Possibly this was a valid move, at least for anyone not responsible for a SharePoint instance.

SharePoint defenders will remember July as the month of ToolShell, an actively-exploited vulnerability chain in SharePoint which Microsoft published out of band ten days after Patch Tuesday. Out of band patches for Microsoft flagship products are rare, since they inevitably cause downstream disruption. Once MSTIC publicly attributes exploitation to two Chinese nation-state actors, that line has been crossed.

The vulnerability described by the out-of-band CVE-2025-53770 turned out to be a bypass for the patch introduced by CVE-2025-49704 earlier in the month, which was itself a response to a successful Pwn2Own Berlin entry from May.

August: It’s almost too quiet

Microsoft was not aware of exploitation in the wild for any of the vulnerabilities published as part of Patch Tuesday August 2025. SharePoint admins may have been dealing with the fallout from last month’s ToolShell and bracing for a possible repeat, but August might otherwise have made for an eerily quiet month. Still, the Windows implementation of Kerberos managed to cough up a publicly-disclosed elevate-to-domain-admin vulnerability.

Separately, we learned that simply saving a JPEG could be enough to hand an attacker RCE capabilities, because the internet never sleeps. If the vulnerable codepath had been within JPEG decoding, rather than encoding, this one could have been the biggest vuln of the year.

September: Almost too quiet, part 2

Patch Tuesday September 2025 was the second month in a row with no known-exploited vulnerabilities, but vuln spotters will appreciate that this month saw the publication of a fairly rare beast: a Microsoft vulnerability with a perfect(?) CVSS v3 base score of 10.0, albeit a cloud service vulnerability discovered by Microsoft and patched prior to publication. No customer action required, but also no customer verification possible, and since the impacted cloud service was Azure Networking, the blast radius could have been stupendous.

October: Dial M for exploitation

These days, there are plenty of seasoned IT professionals who don’t even know what a dialup modem negotiation song sounds like, simply because broadband has been around for that long. For younger readers, “broadband” is what we used to call “internet fast enough that you don’t have to wait to download a single email attachment”.

By this point, we all know where this is going: Windows still ships with modem capabilities well beyond their sell-by date, and someone found a good old elevation of privilege vulnerability. The vulnerable fax modem driver was developed almost 30 years ago by a long-defunct third party, and Microsoft has now taken uncharacteristically bold action by removing it from Windows altogether, perhaps recognizing that traditional landlines are no longer available at all in many places. Are there other fax modem drivers still lurking in Windows? You betcha.

Patch Tuesday October 2025 also marked the end of Windows 10, unless you count the cash-for-patches Extended Security Updates (ESU) program.

November: Kernel vuln? Popcorn time

Patch Tuesday November 2025 included an exploited-in-the-wild vulnerability in the Windows kernel itself. While the advisory was light with details, exploitation of CVE-2025-62215 led to elevation to SYSTEM, presumably via a complex bit of memory management three card monte. Those kernel Rust rewrites can’t come soon enough.

December: A cloud of suspicion

After a year filled with variations of the same old exploitable vulns, it might almost be refreshing to consider the altogether more modern-sounding exploited-in-the-wild vulnerability published on Patch Tuesday December 2025. CVE-2025-62221 describes an elevation of privilege vulnerability in the Windows Cloud Files Mini Filter Driver.

On Windows, a file or directory can contain a reparse point, a collection of user-controlled metadata designed to be interpreted by a file filter driver. An example would be a file which appears present in a local folder, but where the actual contents of the file are stored remotely on OneDrive. The user double-clicks on the file, the file filter driver intercepts the request, reads the metadata, and calls out to OneDrive, while the user gets the experience of opening the file as though it had been stored locally. Of course, the file filter driver needs kernel access to perform its duties. Find an exploitable flaw in the way a file filter driver parses the metadata, and you can trick it into doing things like overwriting protected system files.

What’s next?

Everything gets faster, including bad things

As Rapid7 has observed repeatedly, time to known exploitation for widely-exploited vulnerabilities has been shrinking year-on-year. By 2022, the time to exploitation after public disclosure for some of the most notable security vulnerabilities was as low as 24 hours. With exploit development now widely augmented by automation and AI, there is every reason to suppose that the window will continue to shrink further.

Threat actors will stay best friends with elevation of privilege vulns

A wormable unauthenticated RCE vulnerability remains the scariest scenario, but mercifully these are historically rare. The one-two combo of minimally-privileged initial access and local privilege escalation presents a much more clear and present danger in most modern threat models. Sure, you could parachute in from a helicopter, abseil down from the roof, and crawl through an air vent to steal the diamond, but why bother when you could simply tailgate a delivery driver, and then distract a maintenance worker while you swipe their all-access keycard?

AI is here to stay, but tech debt is the real killer

In 2026, Microsoft will regularly publish AI-related vulnerabilities, and AI-wielding threat actors will hammer Microsoft’s cloud services. Blue teams managing significant Windows estates will still spend more time worrying about on-prem vulnerabilities where the root cause is a classic software engineering snafu.

Final thoughts

Arguably the biggest takeaway from 2025 is that the more things change, the more they stay the same. The scariest Microsoft vulnerabilities tend to emerge from the same few familiar places: core Windows components with codebases older than many of the humans who rely on them.

Microsoft’s wildly successful business model is founded on a decades-long insistence on ironclad backwards compatibility. Why? Enterprise customers with deep pockets and deeper catalogues of ancient business applications. These retro capabilities come at a high price: a supervolcano of tech debt potentially unmatched in all of human history, and a seemingly endless supply of sort-of-new but depressingly familiar vulnerabilities.

For anyone responsible for defending a significant Microsoft footprint in 2026, tomorrow’s biggest problem remains today’s secrets exposed by yesterday’s software design choices.

Beyond the practical need to replace a tool, Kenna’s exit raises a bigger question for security leaders: what should vulnerability management look like moving forward? 

Not just a tool change

For many organizations, Kenna wasn’t “just another scanner”. Before their acquisition by Cisco in 2021, Kenna Security helped pioneer a shift away from chasing raw CVSS scores and toward prioritization based on real-world risk, influencing how many teams approach risk-based vulnerability management. Security teams invested years building workflows, reporting, and executive trust around that model. 

That’s why this moment feels different. Replacing Kenna isn’t about checking a feature box, it’s about protecting the integrity of the progress teams have already made while using this moment to elevate programs past traditional vulnerability management.

Security leaders are rightly cautious. No one wants to: 

• Rush into a short-term replacement vs. a platform that suits current and future needs

• Trade proven prioritization for untested promises 

• Disrupt remediation workflows that engineering teams finally trust 

At the same time, few teams believe traditional vulnerability management – isolated scanners, static scoring, endless ticket queues – is sufficient on its own anymore. 

So where does that leave you? 

“Risk-based vulnerability management is dead” doesn’t tell the full story

In response to Kenna’s end-of-life, much of the market has rushed to frame this as the end of risk-based vulnerability management (RBVM) altogether. The message is often loud and binary: RBVM is outdated, jump straight to exposure management.

In practice, that framing doesn’t match how security programs actually evolve. 

Most organizations are not abandoning vulnerability management. They are expanding it:

• From on-prem to hybrid and cloud

• From isolated findings to broader attack surface context 

• From vulnerability lists to exposure-driven decisions 

• From static to continuous

The mistake is assuming this evolution requires a hard reset, or that exposure management is completely separate and not part of that evolution.  

For CISOs and hands-on leaders alike, the smarter question is: how do we preserve what works today, while building toward what we know we’ll need tomorrow?

What Kenna customers should prioritize next 

As you evaluate what comes after Kenna, the right decision comes down to which platform can consistently deliver security outcomes and measurable risk reduction: 

Continuity without disruption

Your team already understands risk-based prioritization. The next platform should strengthen that muscle, not force you back to severity-only thinking or one-dimensional scoring models that ignore business context and threat intelligence. 

See risk clearly across on-prem, cloud, and external environments

Risk doesn’t live exclusively on-prem or in the cloud. Vulnerability data needs to reflect the reality of modern environments – endpoints, cloud workloads, external-facing assets – without fragmenting visibility. It needs to build on what teams already have by supporting findings from a broad range of existing tools and services, so risk can be understood in one place instead of scattered across platforms. 

Customizable remediation workflows

Prioritization only matters if it leads to action. Look for platforms that help security and IT teams collaborate, track ownership, and measure progress without creating more friction. 

A credible path forward

Exposure management is valuable only when it’s grounded in accurate data, operational context, and day-to-day usability. Security teams are already drowning in findings across tools, and without context that explains what matters and why, exposure management adds more noise instead of helping teams make decisions and reduce risk. That noise shows up in familiar ways: duplicate findings aren’t reconciled, conflicting risk scores between tools, unclear ownership for remediation, and long lists of issues with no clear path to action.

Why this moment favors steady platforms, not big bets

Kenna’s exit creates pressure, but pressure shouldn’t drive risky or forced decisions. Security leaders are accountable not just for vision, but for outcomes, such as: 

• Are we reducing real risk this quarter? 

• Can we explain prioritization decisions to the board? 

• Will this platform still support us two or three years from now? 

This is where vendor stability, roadmap clarity, and operational proof start to matter more than bold claims. 

The strongest next steps are coming from platforms that already deliver visibility across hybrid environments, mature, threat-informed vulnerability prioritization, and integrated remediation workflows that teams actually use. From there, exposure management becomes an evolution, not a leap of faith. 

A measured path forward

Kenna’s EOL doesn’t signal the end of risk-based vulnerability management. It signals that security programs are ready to expect more from it. For security leaders this is an opportunity to reaffirm what has worked in your program, close real visibility and workflow gaps, and choose a platform that supports both near-term continuity and long-term growth.

The goal isn’t to chase the next trend. It’s to make a confident, practical decision – one that protects today’s outcomes while positioning your team for what’s next. 

Looking ahead

If you’re navigating what comes after Cisco Kenna, the most important step is understanding your options early, before timelines force rushed decisions. Explore what a confident transition can look like and how teams are approaching continuity today while preparing for exposure management tomorrow. 

Explore a confident path forward.

Windows DWM: exploited-in-the-wild information disclosure

The Windows Desktop Windows Manager (DWM) is a high value target for vulnerability researchers and threat actors, and CVE-2026-20805 is the latest in an occasional series of exploited-in-the-wild zero-day vulnerabilities to have emerged from it. DWM is responsible for drawing everything on the display of a Windows system, which means it offers an enticing combination of privileged access and universal availability, since just about any process might need to display something. In this case, exploitation leads to improper disclosure of an ALPC port section address, which is a section of user mode memory where Windows components coordinate various actions between themselves.

The CVSS v3 score of 5.5 evaluates to medium severity, which wouldn’t typically scream “patch me first”, but Microsoft evaluates CVE-2026-20805 as important on their proprietary severity scale, and information disclosure vulnerabilities by their very nature tend to end up with lower CVSS scores, since there’s no direct impact on integrity or availability. Also, Microsoft information disclosure vulnerabilities very rarely end up marked as exploited in the wild; any that do are very likely to be part of a longer exploit chain. In this case, it’s likely that the improperly disclosed memory address gives an attacker a starting point in the hunt for the in-memory address of the DWM process, sidestepping Address Space Layout Randomization (ASLR), and greatly increasing the chance of developing a stable elevation of privilege exploit for DWM rather than a flakey blue screen of death generator.

Windows Agere modem driver: publicly disclosed elevation of privilege

Back in October 2025, Microsoft removed a specific modem driver ltmdm64.sys from all versions of Windows, after it was implicated in CVE-2025-24052, an exploited-in-the-wild elevation of privilege vulnerability. Today sees another couple of modem drivers removed from Windows for a broadly similar reason: Microsoft is aware of functional exploit code for an elevation of privilege vulnerability in a very similar modem driver, tracked as CVE-2023-31096. That’s not a typo; this vulnerability was originally published via MITRE over two years ago, along with a credible public writeup by the original researcher. Today’s Windows patches remove agrsm64.sys and agrsm.sys. All three modem drivers were originally developed by the same now-defunct third party, and have been included in Windows for decades. These driver removals will pass unnoticed for most people, but you might find active modems still in a few contexts, including some industrial control systems.

Two questions remain: how many more legacy modem drivers are still present on a fully-patched Windows asset, and how many more elevation-to-SYSTEM vulnerabilities will emerge from them before Microsoft cuts off attackers who have been enjoying living off the land[line] by exploiting an entire class of dusty old device drivers? Although Microsoft doesn’t claim evidence of exploitation for CVE-2023-31096, the relevant 2023 write-up and the 2025 removal of the other Agere modem driver have provided two strong signals for anyone looking for Windows exploits in the meantime. In case you were wondering, there is no need to have a modem connected; the mere presence of the driver is enough to render an asset vulnerable.

Secure Boot: critical security feature bypass

Today sees the publication of CVE-2026-21265, which is a critical security feature bypass vulnerability affecting Windows Secure Boot. Fifteen years is a very long time indeed in information security, but the clock is running out on the Microsoft root certificates which have been signing essentially everything in the Secure Boot ecosystem since the days of Stuxnet. Microsoft issued replacement certificates back in 2023, alongside CVE-2023-24932 which covered relevant Windows patches as well as subsequent steps to remediate the Secure Boot bypass exploited by the BlackLotus bootkit.

Once the ancient 2011 certificates expire later this year, Windows devices that do not have the new 2023 certificates can no longer receive Secure Boot security fixes. When updating the bootloader and BIOS, it is essential to prepare fully ahead of time for the specific OS and BIOS combination you’re working with, since incorrect remediation steps can lead to an unbootable system.

Microsoft lifecycle update

Visual Studio 2022 LTSC 17.10 reaches end of support today, so now is a good time to upgrade to a newer minor version. Dynamics CRM 2016 (also known as Dynamics 365) also reaches end of life. There are no other significant Microsoft product lifecycle changes this month.

Vulnerabilities by Product Family

Azure vulnerabilities

Developer Tools vulnerabilities

ESU vulnerabilities

Microsoft Office vulnerabilities

SQL Server vulnerabilities

Windows vulnerabilities

Why this research matters

MFPs are everywhere, often overlooked, and frequently underprotected. Many organizations deploy them without password changes, patch cycles, or network segmentation. Attackers notice. Because MFPs are attached to networks and can carry sensitive data, compromise can enable credential theft, data leakage, and lateral movement within the network.

The report tracks how long-standing and emerging weaknesses continue to affect MFP security. It highlights common risk areas such as weak authentication and limited patching practices, among others, that leave devices open to misuse or compromise. As these printers have grown more connected and feature-rich, the potential impact of a single vulnerable device has increased, especially when linked to core business systems or identity services.

The study also examines broader exposure trends across the enterprise landscape. Thousands of MFPs remain directly accessible from the internet, and vulnerability data shows that many models have faced serious flaws in recent years. Beyond technical issues, organizational processes like inconsistent patch management and poor decommissioning practices often allow sensitive data and credentials to linger on devices long after their use.

Penetration testing data collected by Rapid7 and Raxis confirms that these risks are not theoretical. Many organizations still deploy MFPs with default settings, leaving them open to credential theft and data access that can help attackers move deeper into the network.

The report introduces Praeda-II, a community tool designed for pentesters, auditors, and IT teams who need fast visibility into vulnerable printers, to identify risks in MFPs across modern models.

See the research

If your organization relies on networked printers, this research offers the insights you need. Read Understanding Multifunction Printer (MFP) Security within the Enterprise Business Environment to learn about key risks and practical steps to strengthen your printer security program.

Windows Cloud Files minifilter: zero-day EoP

Microsoft has evidence that attackers are already making full use of CVE-2025-62221, a zero-day local elevation of privilege (EoP) vulnerability in the Windows Cloud Files Mini Filter Driver leading to SYSTEM privileges. File system filter drivers, aka minifilters, attach to the system software stack, and intercept requests targeted at a file system, and extend or replace the functionality provided by the original target. Typical use cases include data encryption, automated backup, on-the-fly compression, and cloud storage.

The Cloud Files minifilter is used by OneDrive, Google Drive, iCloud, and others, although as a core Windows component, it would still be present on a system where none of those apps were installed. Microsoft ranks CVE-2025-62221 as important rather than critical, since an attacker would need to have an existing foothold on the target system, but since it’s already exploited in the wild and leads to SYSTEM privileges, all but the most optimistic blue team threat models will surely treat CVE-2025-62221 as a top priority for remediation.

PowerShell: zero-day RCE

Under normal circumstances, PowerShell does a decent job of looking out for the unwary end user, and will wait for confirmation or even outright block unexpected attempts to run code from the internet that isn’t signed by a trusted publisher. Windows Mark-of-the-Web (MotW) functionality tracks files that were downloaded from the internet, but CVE-2025-54100 is a zero-day vulnerability which allows attackers to sidestep security controls that rely on MotW by the simple expedient of relying on code execution before the file is ever written. Microsoft is aware of public disclosure.

The Windows security updates published today address CVE-2025-54100 by altering the default functionality of Invoke-WebRequest in PowerShell 5.1 so that it will prompt the user, instead of simply executing potentially malicious code as it processes the full Document Object Model of the requested remote resource. Scripts that rely on the impacted functionality may hang indefinitely when encountering the new prompt, unless updated to pass the -UseBasicParsing parameter to Invoke-WebRequest, since this explicitly avoids the potential for script execution. PowerShell 7 avoids all of this by moving beyond dependency on the legacy MSHTML/Trident engine, which used to power Internet Explorer. However, PowerShell 5.1 is what’s installed by default with a fresh Windows installation, even for Server 2025 and Windows 11 25H2, because Microsoft has a hard time telling enterprise customers that continuing support for legacy business applications comes with an ever-increasing security cost.

Copilot: zero-day

The GitHub Copilot for Jetbrains plugin promises users that they can take control of their code using Copilot Edit Mode. Unfortunately, an attacker exploiting CVE-2025-64671 will be aiming to do something very similar. Microsoft is aware of public disclosure. In this scenario, cross-prompt injection, where an attacker hides malicious instructions inside a malicious file or within MCP server data, can lead to arbitrary command execution, where unsafe commands sneak past security boundaries while appended to safe, allowlisted commands. This issue is by no means specific to Copilot or Jetbrains; as the original researcher points out, this is an example of an entire class of vulnerabilities, where the addition of agentic AI to an IDE extends and alters the attack surface. Other well-known IDE vendors have assigned CVEs and/or published patches for broadly similar issues.

Office: two critical no-click RCEs

Microsoft Office is widely deployed, and it’s a rare Patch Tuesday when it doesn’t receive at least a few security updates. Two Office RCEs are particularly noteworthy this month. The advisory FAQs for both CVE-2025-62554 and CVE-2025-62557 mention that the Preview Pane is a vector, so a user who scrolls past a malicious email in Outlook or a sketchy file in Explorer could trigger exploitation without doing anything obviously wrong. However, it gets worse, because even receiving a specially-crafted email could trigger exploitation, without any requirement that the user open, read, or click on the malicious link within it. CVE-2023-23397, a widely-discussed critical Outlook vulnerability from some two-and-a-half years ago shares these characteristics. In that case, Microsoft detected in-the-wild exploitation by a Russia-based threat actor targeting government, military, and critical infrastructure targets in Europe. While there’s no suggestion that either of the vulnerabilities patched today necessarily result in NTLM hash disclosure in the same vein as CVE-2023-23397, the potential for exploitation without the need for any user interaction is a serious concern.

Microsoft lifecycle update

There are no significant Microsoft product lifecycle changes this month. Visual Studio 2022 LTSC 17.10 will reach end of life in January.

Summary charts

Summary tables

Azure vulnerabilities

Browser vulnerabilities

Mariner vulnerabilities

Microsoft Office vulnerabilities

Open Source Software vulnerabilities

Open Source Software Mariner vulnerabilities

Other vulnerabilities

Server Software ESU vulnerabilities

Windows vulnerabilities

Windows ESU vulnerabilities