Anthropic’s Project Glasswing has sparked plenty of discussion about what AI might soon do for vulnerability discovery, but the more useful question for most security teams is how to prepare for, and more importantly seize the opportunity of, what comes next.
As we wrote in our earlier blog, What Project Glasswing Means for Security Leaders, AI is becoming more capable of finding software flaws. The pressure that follows lands on the teams responsible for deciding what matters, validating risk, assigning ownership, and getting remediation moving across environments that were already hard to manage. We believe that the organizations that will benefit most from the next wave of AI will be the ones that understand their environment well enough to use these emerging AI models with intent, rather than layering them onto immature processes and hoping that speed alone will solve the backlog.
What this moment means for security teams
The number of publicly tracked software vulnerabilities has broken records almost every year over the last decade, while supply chain risk has continued to rise. Most teams were already feeling the strain of more findings than they could process cleanly. The Common Vulnerabilities and Exposures (CVE) program, the standard system for identifying and tracking known vulnerabilities, recorded 48,185 disclosures in 2025, a 20% increase over 2024, with roughly 40% of those disclosed vulnerabilities rated high or critical.
The pace in 2026 was already working out to hundreds of new CVEs per day when those figures were cited. That tells you something important about the current environment: the challenge has not necessarily been a lack of findings, but instead converting a growing stream of findings into measurable risk reduction.
The reality is that very few organizations are going to hand a model free rein over their most sensitive environments the minute those capabilities become more widely available. Trust will be built in stages: early adoption is much more likely to focus on backlog reduction, triage support, patch testing, and repetitive lower-tier remediation work that consumes time without carrying the same level of operational risk as the most critical systems in the business. That is a more realistic starting point, and it leads to a more useful question. Before teams apply AI more broadly, they need to understand their environment well enough to use it intentionally.
Establish the foundation before layering in AI
The promise from Project Glasswing and almost every other AI-powered security initiative is quite similar: leverage AI to identify patterns, summarize risk, suggest fixes, and speed up repetitive work. Regardless of technology, success still depends on how well an organization understands its environment, the context around each finding, and the process used to act on it.
A model can generate more output than a team ever could on its own, but that output becomes noise if the organization cannot answer basic questions about scope, ownership, criticality, and exposure. Teams need a clear, continuously updated picture of the environment before they can decide where AI should be applied, what should remain human-led, and which parts of the backlog are safe to push through more automated workflows.
The AI landscape is already shifting fast, and it will keep shifting, which is why this moment should prompt a more preemptive and resilient strategy rather than another round of tooling hype. Chasing each new capability as it arrives will inevitably force teams to keep reorganizing around the latest announcement. A stronger path is to get the foundation right first – understand the environment, the attack paths, and the assets that matter most; but most importantly, establishing the process and the people behind making these decisions. Then use AI where it meaningfully improves speed, consistency, and focus.
Why Attack Surface Management should be part of that foundation
A strong foundation starts with visibility. Security teams need a live picture of what exists in the environment, what is exposed, how assets connect to one another, and which systems carry the greatest business impact if something goes wrong. That is where Attack Surface Management becomes central. Rapid7’s approach through Surface Command is built around a continuous view of the attack surface across the digital estate, which helps teams understand where exposures sit and how they relate to internet-facing, business-critical, or otherwise high-impact systems.
That matters for AI adoption just as much as it matters for day-to-day security operations. Teams cannot apply AI strategically if they are guessing about which parts of the environment are lower priority, which assets belong to which owners, or where a newly disclosed flaw could create real business risk. A better view of the attack surface gives organizations the context they need to segment the problem properly. That makes it far easier to start with the right use cases, whether that is backlog reduction in lower-impact systems, targeted prioritization of exposed assets, or faster triage where the risk picture is already well understood.
Ownership is part of that foundation too. Remediation slows down when no one can quickly identify who owns the affected application, environment, or workflow. Security teams already lose time there today, and AI will only make that bottleneck more visible if it starts surfacing issues faster than organizations can assign them. Attack Surface Management helps turn that ambiguity into something more actionable by tying exposure to environment context and likely ownership.
How Vulnerability and Exposure Management turns visibility into action
Once the environment is understood, teams still need a way to move from findings to outcomes. That is where Vulnerability and Exposure Management becomes the operating layer that keeps the work grounded.
The biggest value here is not simply collecting more vulnerability data. It is targeted prioritization and validation. When a disclosure lands, teams need to know whether the issue affects an exposed asset, whether there is evidence of exploitation or attacker interest, whether the impacted system is business-critical, and whether existing controls already reduce some of the risk. That is the kind of context that helps organizations decide what deserves immediate attention and what can be handled through a normal remediation cycle.
This is where artificial intelligence can help move remediation forward faster. Instead of asking teams to manually connect exploit signals, asset criticality, and vulnerability intelligence on their own, AI can distill that context directly in the remediation workflow. That makes it easier to understand why an issue matters, what the likely impact is, and what to do next, which shortens the gap between discovery and a confident decision on how to respond.
We expect most organizations to use AI to assist with, or in some cases take over, lower-tier triage, backlog cleanup, summary generation, and patch support in areas where the workflow is already established and the blast radius is more manageable. Human experts still stay closest to the most critical business logic, the most sensitive environments, and the most complex remediation paths. That is a practical adoption model, and it only works when the organization already has enough structure in place to know where those boundaries are.
Curated vulnerability intelligence changes the quality of decisions
That kind of deliberate adoption only works when teams can make better decisions, faster. Security teams need more than severity scores and a long list of CVEs. They need enough context to understand what matters, what can wait, and where action will reduce real risk fastest. As Rapid7 outlined in The Power of Curated Vulnerability Intelligence, the goal is to identify the vulnerabilities that actually matter and give teams enough context to act with confidence.
That intelligence provides a form of validation that most teams need badly as disclosure volume rises. It helps answer whether a finding is tied to active attacker interest, whether proof-of-concept activity is public, whether the asset is exposed, and whether delaying a patch creates unacceptable risk. It also supports the decisions that happen in the gap between discovery and full remediation. When a patch is delayed because of change controls, testing constraints, or lack of a vendor fix, teams still need to reduce exposure. Curated intelligence helps them decide whether to use segmentation, access restrictions, configuration changes, added monitoring, or virtual patching while the longer-term fix is being worked through.
That is one of the clearest ways Rapid7 helps customers move from data to outcomes. Intelligence is fused into the workflow so teams can prioritize with more precision and validate their actions against real threat context, not just generalized scores.
How runtime and remediation fit into the broader AI story
There is another part of this story that matters as organizations think more seriously about AI-driven security operations. As AI shapes the way teams handle exposures earlier in the lifecycle, context of application at runtime matters more too.
To make that foundation complete, organizations need to look beyond static posture and bring runtime validation into the picture. When teams can identify which vulnerabilities and misconfigurations are actively exploitable in production, and map sensitive data and identity access to real-world attack paths, they get a much clearer view of actual risk. Security teams need to understand what is vulnerable, how systems behave when live, and where unusual activity may suggest a problem is moving toward exploitation. With that runtime context in place, teams can spend less time chasing theoretical vulnerabilities and more time focusing on the exposures that are actively creating risk in live environments.
That connection between exposure, intelligence, remediation, and runtime behavior is where AI starts to become genuinely useful rather than simply impressive. It supports a more intentional model of security decision-making, one that narrows the gap between what is found, what matters, and what happens next.
What security leaders should do now
This is a good time for security leaders to step back and ask a more disciplined set of questions.
Do we understand our environment well enough to direct AI toward the right problems?
Can we clearly separate higher-risk, higher-impact assets from the parts of the backlog that are mostly operational drag?
Is threat intelligence embedded in how we interpret findings, or are we still depending too heavily on raw severity?
Can we identify ownership fast enough for AI-assisted triage to result in meaningful action?
Are compensating controls part of the plan when remediation cannot happen immediately?
Those questions shape the quality of everything that follows.
Glasswing creates a real opportunity for security teams that are ready to use AI with more intention. AI can move work forward faster, reduce manual drag, and absorb classes of issues that currently consume time without improving outcomes. The teams that benefit most will not be the ones that rush to apply new models everywhere. They will be the ones that understand their environment, have a clear view of their attack surface, have mature enough workflows to apply AI where it makes sense, and can measure whether the actions taken actually reduced exposure.
Rapid7’s approach to building resilience is grounded in those same needs. Attack Surface Management provides the environmental foundation, Vulnerability Management drives prioritization and action, curated vulnerability intelligence strengthens validation and decision-making, AI-generated remediation insights compress the time from discovery to the next step, and runtime security adds context where live behavior matters. Together, those pieces help customers build a security program that is ready for AI rather than constantly reacting to it.
Microsoft is publishing 167 vulnerabilities on April 2026 Patch Tuesday. Microsoft is aware of exploitation in the wild for one of today’s vulnerabilities, and public disclosure for one other. Microsoft evaluates 19 of the vulnerabilities published today as more likely to see future exploitation. So far this month, Microsoft has provided patches to address 80 browser vulnerabilities, which are not included in the Patch Tuesday count above.
Increasing volumes of vulnerabilities
Regular Patch Tuesday watchers will know that these vulnerability totals are significantly higher than usual, especially the browser numbers. Late last week, Microsoft published patches to resolve more than 60 browser vulnerabilities in a single day, which is a new record in that very specific category.
It might be tempting to imagine that this sudden spike was tied to the buzz around the announcement a week ago today of Project Glasswing, but this is not the case. Edge is based on the Chromium engine, and the Chromium maintainers acknowledge a wide range of researchers for the vulnerabilities which Microsoft republished last Friday. This reflects a significant industry-wide uptick in the volume of vulnerability reports over the past few weeks. A safe conclusion is that this increase in volume is driven by ever-expanding AI capabilities. We should expect to see further increases in vulnerability reporting volume as the impact of AI models extend further, both in terms of capability and availability.
SharePoint: zero-day spoofing
When everything is changing rapidly, it can be tempting to look to familiar things for comfort. SharePoint admins should start by addressing CVE-2026-32201, an exploited-in-the-wild spoofing vulnerability. The advisory doesn’t offer much detail, but does mention CWE-20: Improper Input Validation and low impact to confidentiality and integrity, with no impact to availability. Of course, the greatest attacker impact is typically achieved by chaining together multiple vulnerabilities that by themselves might not seem so bad.
Ever-increasing novel AI capabilities in offensive cybersecurity now appear to provide real competition for all but the most elite human researchers; if it was ever valid to suppose that a vulnerability with a CVSS v3 base score of 6.5 was unlikely to cause much pain, it’s certainly not a safe defensive assumption in 2026. Patches are available for all supported versions of SharePoint, including SharePoint 2016, which moves beyond extended support on July 14, 2026.
Defender: zero-day elevation of privilege
Microsoft Defender receives a patch today for CVE-2026-33825, a local privilege escalation vulnerability for which Microsoft is aware of public disclosure. Successful exploitation leads to SYSTEM privileges, so this is certainly worth patching sooner rather than later. Microsoft points out that no action should be required to install this update, since the Microsoft Defender Antimalware Platform automatically updates by default. A further silver lining is that systems that have disabled Microsoft Defender are not in an exploitable state. Hopefully, any such system is running a suitable third-party replacement for Defender’s capabilities.
Windows [I don’t like] IKE: zero-day pre-auth RCE
The Windows Internet Key Exchange (IKE) Services Extensions is the site of CVE-2026-33824, a critical unauthenticated remote code execution vulnerability. Exploitation requires an attacker to send specially crafted packets to a Windows machine with IKE v2 enabled, which could enable remote code execution. Vulnerabilities leading to unauthenticated RCE against modern Windows assets are relatively rare, or we’d see more wormable vulnerabilities self-propagating across the internet. However, since IKE provides secure tunnel negotiation services, for instance for VPNs, it is necessarily exposed to untrusted networks and reachable in a pre-authorization context. It’s hard to imagine this turning into a rampaging internet-wide worm, but there’s plenty of scope for initial access abuse, so this IKE vulnerability is still yikes.
The advisory does contain a section with potential mitigations for anyone unable to patch immediately, which center on least-privilege restriction of relevant UDP traffic. This same portion of the advisory also furnishes a helpful link to the definition of the word “mitigations” in the MSDN glossary. All versions of Windows back as far as Server 2016 and Windows 10 1607 LTSC receive patches.
The advisory credits both the WARP and MORSE (Microsoft Offensive Research & Security Engineering) teams at Microsoft. MORSE appears in Acknowledgements over the past few years, but today marks the first explicit mention of WARP in a Microsoft security advisory Acknowledgements section; we can speculate that WARP is an internal designator for the Microsoft Windows Enterprise Security Team.
Security leaders rarely struggle to produce data. The challenge is turning that data into something the board can use to make decisions.
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.
As organizations scale their cloud infrastructure, maintaining proper lifecycle management of Amazon Machine Images (AMIs) is a critical component of their security and risk management goals. AMIs provide the essential information required to launch Amazon Elastic Compute Cloud (Amazon EC2) instances, however; they present security and compliance challenges if not tracked and managed throughout their lifecycle. This blog post explores how organizations can meet their evolving security and compliance requirements by managing potential vulnerabilities across the AMIs deployed throughout their AWS environment.
At the end of 2024, AWS announced lineage supportfor Amazon EC2, providing source details for your AMIs. With this lineage information, you can trace copied or derived AMIs back to their original source. The source AMI information is available for AMIs that were created using specific API commands like CreateImage, CopyImage, and CreateRestoreImageTask. If the AMI was created using a different API command, the ID and AWS Region of the source AMI don’t appear, which can create visibility gaps that potentially impact security and compliance efforts.
To address these gaps and provide comprehensive AMI governance, organizations need to build additional capabilities to analyze the scope of impact of Common Vulnerabilities and Exposures (CVEs), ensure deployed resources originate from an approved golden image, and respond to audit inquiries that require a clear chain of custody for AMIs. A well-designed solution should also help track and enforce approved AMI creation patterns across all accounts and AWS Regions. The AMI lineage solution described in this post is designed to help you manage your organization’s AMI hierarchy and lifecycle, including tracking AMI origins and usage throughout its AWS environment. By implementing this solution, your security teams can quickly understand the scope of impact when security vulnerabilities are discovered, help ensure compliance with organizational policies, and maintain better visibility into their AMI estate.
The solution in this blog post uses Amazon Neptune, a high-performance graph database, along with native AWS security services to maintain a comprehensive view of AMI relationships and enable proactive security monitoring. With the solution in place, you can enforce controls on AMI sourcing, including validation of marketplace AMIs through service control policies (SCPs), and maintain compliance with organizational and regulatory requirements throughout the AMI lifecycle.
Solution overview
AMI Lineage provides a comprehensive governance solution that uses AWS security services and Neptune to create and maintain a hierarchical graph representation of their AMI relationships. This solution helps security and compliance teams understand the complete history of their AMIs including where they originated from, enforce organizational policies such as requiring all AMIs to be encrypted, and rapidly assess security impacts across their organization. The solution integrates core AWS services with security and governance capabilities. The core components of the solution in the security tooling account are:
Neptune: A purpose-built, high-performance graph database securely stores and manages the AMI relationship data.
AWS Lambdafunctions serve as the processing engine for the solution. They process AMI lifecycle events (such as CreateImage, CopyImage, DeregisterImage), evaluate them against compliance rules, and update the Neptune graph database. The functions are configured with least-privilege AWS Identity and Access Management (IAM) permissions to enhance security.
Amazon API Gateway provides secure REST endpoints for lineage queries and security assessments. Authentication is handled using a combination of API keys and IAM roles to help ensure that only authorized users and systems can access the data.
From a governance perspective, this solution provides comprehensive AMI origin validation to help ensure AMIs come from approved sources, including the validation of AWS Marketplace AMIs against a list of trusted vendors. Lifecycle management capabilities enforce AMI retention policies and deprecation processes. Compliance monitoring tracks adherence to organizational and regulatory requirements, while security event scope assessment capabilities quickly identify affected resources when security vulnerabilities are discovered. A detailed audit trail maintains a complete history of AMI creation, modification, and usage patterns.
Architecture
The AMI Lineage solution follows AWS security best practices with a multi-account deployment architecture designed to maximize security while maintaining operational efficiency. The architecture distributes responsibilities across three primary account types: an organization management account, a centralized security tooling account, and multiple member accounts.
This architectural approach helps ensure that sensitive operations and data remain centralized in the security tooling account while enabling distributed monitoring and policy enforcement across the organization. The clear separation of concerns enhances security while maintaining the scalability needed for large-scale AWS deployments.
Figure 1: AMI Lineage solution architecture and workflow
The workflow and architecture shown in figure one includes the following:
Policy enforcement: Theorganization management account is the central point for control. It uses AWS Organizations to enforce SCPs that prevent non-compliant AMI actions across the member accounts.
Event capture: When an AMI lifecycle event (like CreateImage or CopyImage) occurs in a member account, a local Amazon EventBridge rule captures it.
Centralized processing: The event is securely forwarded from the member account’s EventBridge to the central EventBridge in the security tooling account.
Data ingestion and analysis: A Lambda function is triggered in the security tooling account. This function processes the event, analyzes it for compliance, and updates the Neptune graph database with the new AMI relationship data. AWS Security Hub and Amazon GuardDuty in the security tooling account also receive and analyze findings from member accounts.
Query and visualization: Security teams query the lineage data through a secure API Gateway endpoint. By doing this, they can to visualize AMI hierarchies, investigate security findings from Security Hub, and assess the scope of impact for a given AMI.
The organization management account serves as the central control point for policy enforcement and organizational oversight. This account hosts SCPs that prevent non-approved AMI usage across the organization and manages organization-wide EventBridge rules that capture AMI events from member accounts. Cross-account trust policies configured in this account enable secure communication between the management account and the security tooling account.
Additionally, the management account establishes Security Hub in delegated administrator mode, designating the security tooling account as the centralized security administrator for the organization. From the security tooling account, Security Hub can be then configured to aggregate all Regions down to one core Region for easier evaluation by security personnel.
The security tooling account acts as the central hub for AMI lineage processing and storage. This account hosts the Neptune graph database cluster with encrypted storage, helping to ensure that AMI relationship data is securely maintained. Lambda functions running in this account process events, handle API requests, and evaluate compliance with least-privilege permissions. API Gateway provides secure REST endpoints for lineage queries and security assessments. Security Hub custom insights and findings are centralized here in the security tooling account as the Security Hub delegated administrator account, along with Amazon Simple Notification Service (Amazon SNS) topics for notifications and alerts. The Amazon Virtual Private Cloud (Amazon VPC) infrastructure supporting these services is also deployed in the security tooling account, providing network-level isolation and security.
The solution enables distributed monitoring and enforcement by deploying lightweight components into each member account across the organization. Each member account includes AWS Config rules for continuous compliance monitoring, cross-account IAM roles to enable secure access from the security tooling account, and local EventBridge rules that forward AMI-related events to the central processing system.
Security and compliance integration extends throughout the solution. IAM manages least-privilege access control and permissions across components. AWS CloudTrail records API activity for audit trails and compliance reporting, while Security Hub centralizes security findings and compliance status across your AMI estate. GuardDuty provides threat detection for AMI-related activities. SCPs enforce organization-wide controls on AMI creation and usage patterns, and AWS Config tracks AMI configuration changes and evaluates compliance rules.
How it works
The AMI Lineage solution operates through a continuous monitoring and automated response system that maintains comprehensive visibility into your AMI landscape. When AMI lifecycle events occur in your organization, EventBridge rules capture these activities, including creation, copying, modification, and deregistration events. Lambda functions in the security tooling account are then called upon to process these events with appropriate security controls and update the Neptune graph database in real-time, while CloudTrail logs provide a comprehensive audit trail of AMI-related activities.
The system tracks critical security and compliance metadata that forms the foundation of effective AMI governance. This includes:
Source AMI information and validation status to help ensure lineage integrity
Creation method and timestamp data for comprehensive audit trails
Cross-Region and cross-account relationships to understand the full scope of AMI distribution
Instance launch history with security context to track usage patterns
AMI state changes including deprecation and deregistration for lifecycle management
Compliance status along with policy violations to maintain organizational standards.
Security teams use this comprehensive data through secure API calls to visualize complete AMI hierarchies and relationships, providing clear insight into how AMIs are related across your infrastructure. The compliance of your AMI estate is continuously tracked through a combination of services:
Detection: AWS Config rules deployed in member accounts check for policy violations (for example, incorrect tags and public permissions).
Aggregation: These findings, along with vulnerability data from services like Amazon Inspector, are aggregated in AWS Security Hub.
Correlation: Lambda functions in the security tooling account correlate this information with the lineage data in Neptune. Because of this correlation, you can see not just that an AMI is non-compliant, but also its entire downstream impact. When security events like CVE findings are discovered, teams can quickly assess the scope of impact across their entire AMI estate. The solution monitors AMI usage patterns for security anomalies and enforces governance controls through automated policy checks.
The solution provides robust automated policy enforcement capabilities that operate continuously to maintain security and compliance. The system helps ensure that only approved AMIs with verified lineage history can be used to launch new instances, automatically blocking attempts to use non-compliant images. SCP controls on AMI creation and usage are enforced organization-wide, preventing unauthorized AMI operations before they can impact your environment. When policy violations are detected, the system can trigger automated responses to security events and maintain compliance with organizational standards through real-time enforcement.
Implementation
Before deploying the AMI Lineage solution, you need to establish the proper security and governance foundation across your organization. Your AWS Organizations management account requires administrative permissions, and your organization must be enabled with all features to support the policies used in this solution. You will also need a dedicated security tooling account to host the solution’s core components, with cross-account IAM roles configured to allow secure access. Finally, essential security services must be configured at the organization level, including Security Hub, CloudTrail organization trails for audit logging, and encryption keys using AWS Key Management Service (AWS KMS) for data protection.
The complete AMI Lineage solution is available as open source code in the AWS Samples repository. You can clone the repository and follow the deployment instructions. The repository includes the necessary AWS CloudFormation templates, Lambda functions, and deployment scripts referenced in the following phases.
Deployment
The deployment process follows a five-phase approach that builds security and compliance capabilities progressively:
Security foundations
Security controls
EventBridge rules
Core infrastructure
Compliance and monitoring
Phase 1 – Establishing security foundations
The first phase establishes the security foundation by configuring AWS Organizations security services. This involves enablingSecurity Hub in the management account and designating the security tooling account as the delegated administrator, enablingnullGuardDuty with the security tooling account configured as thenulldelegated administrator, and enabling an organizational wide CloudTrail trail for audit logging.
# In Organization Management Account:
# Enable Security Hub and set security tooling account as delegated admin
aws securityhub enable-organization-admin-account \
--admin-account-id <security-tooling-account-id>
# Enable GuardDuty organization with security tooling account as admin
aws guardduty enable-organization-admin-account \
--admin-account-id <security-tooling-account-id>
# Create organization trail with encryption aws cloudtrail create-trail \
--name ami-lineage-trail \
--s3-bucket-name <your-secure-bucket> \
--is-organization-trail \
--kms-key-id <your-kms-key-id> \
--enable-log-file-validation
Phase 2 – Security controls
The second phase deploys base security controls through organization-wide SCPs. These policies enforce AMI governance controls by preventing the use of non-approved AMIs and helping to ensure that proper tagging and approval workflows are followed.
The third phase deploys organization-wide EventBridge rules from the management account to capture AMI events across member accounts and forward them to the security tooling account for processing. These rules listen for specific API calls captured by CloudTrail.
An example of the event pattern used to capture CreateImage and CopyImage events looks like this:
{
"source": ["aws.ec2"],
"detail-type": ["AWS API Call via CloudTrail"],
"detail": {
"eventSource": ["ec2.amazonaws.com"],
"eventName": [
"CreateImage",
"CopyImage",
"RegisterImage",
"DeregisterImage"
]
}
}
# In Organization Management Account:
# Deploy organization EventBridge rules
cd deployment-scripts/organization
./deploy-organization-resources.sh
Phase 4 – Core infrastructure
The fourth phase focuses on core infrastructure deployment in the security tooling account. This is where the primary processing and storage components are deployed, following security best practices by centralizing sensitive operations in a dedicated account.
# Switch to Security Tooling Account context
# Deploy Neptune cluster with encryption in security tooling account
cd deployment-scripts/shared
./deploy-shared-resources.sh
This deployment script handles multiple components in the security tooling account. The Neptune cluster deployment includes encryption and VPC configuration to help ensure secure storage and access to AMI lineage data. Lambda functions are deployed with security controls and configured with VPC attachment, which allows for secure Neptune access in the VPC, appropriate IAM roles with least-privilege permissions, and environment variables for secure configuration. API Gateway provides secure REST endpoints for external access to AMI lineage data and security assessments.
Phase 5 – Compliance and monitoring
The fifth phase establishes comprehensive compliance and monitoring capabilities across member accounts. AWS Config rules are deployed to continuously monitor AMI compliance across your organization, while EventBridge rules forward AMI events to the central processing system.
# In each Member Account:
# Deploy AWS Config Rules and monitoring capabilities
cd deployment-scripts/child-account
./deploy-child-account-resources.sh
After deployment, thorough verification helps ensure that security configurations are properly implemented. This includes validating IAM permissions to help ensure least-privilege access, testing security controls to verify SCP enforcement, validating encryption settings acrosscomponents, and confirming that the security tooling account is properly configured as the Security Hub delegated administrator.
Using AMI Lineage
When deployed, AMI Lineage provides security operations and compliance monitoring capabilities through its API hosted in the security tooling account and automated monitoring systems. Security teams can query and receive complete AMI security relationships to understand the full context of AMIs in their environment.
When investigating AMIs, the system provides detailed security context including source validation information that confirms:
Whether AMIs come from marketplace sources or trusted accounts
Compliance status that shows patch levels and policy adherence
Vulnerability status with CVE findings and scan results
Comprehensive lineage data showing the complete chain of AMI relationships and approval history
# Get complete security context for an AMI (API Gateway in Security Tooling Account)
curl -X GET "https://<api-gateway-id>.execute-api.<region>.amazonaws.com/v1/api/v1/ami/ami-1234567890abcdef0/security-context?include_compliance=true" \
-H "x-api-key: <your-api-key>"
For security impact assessments, such as when a new CVE is discovered, the solution provides a powerful scope of impact analysis. By querying the API with a specific finding, security teams can rapidly determine every affected resource across their entire organization that stems from a compromised or vulnerable AMI. Using that information, they can understand the full scope of their exposure and begin remediation. See Security best practices in Amazon API Gateway for helpful considerations while using API Keys.
This analysis returns impact information including:
Affected AMIs in the lineage chain
Running instances requiring immediate remediation
Affected AWS accounts and regions for coordinated response
Associated auto-scaling groups and launch templates that need updates
Compliance impact assessment for regulatory reporting
Detailed remediation steps prioritized by risk level.
Compliance monitoring operates continuously through automated assessment capabilities that evaluate your AMI estate against organizational policies and regulatory requirements. Teams can generate comprehensive compliance reports that show adherence to security standards across their entire infrastructure.
The solution provides security automation and remediation through configurable automated responses to security events. Security Hub, operating in delegated administrator mode from the security tooling account, can be configured to automatically respond to findings by stopping instances using AMIs with critical vulnerabilities, quarantining instances launched from unapproved sources, and sending immediate notifications for high-severity findings.
Security visualization and reporting capabilities, centralized in the security tooling account, provide real-time dashboards showing:
Compliance status across the organization
Scoping visualization for rapid decision-making
AMI approval workflow status for process monitoring
Patch compliance metrics for maintaining security posture
Automated remediation activity logs for audit purposes
Custom security reports tailored to specific organizational needs.
For security investigations and audit purposes, the solution maintains a queryable audit trail that provides a complete history of AMIs, including creation and modification events, security scanning results and findings, approval workflow history, and compliance status changes over time.
# Query comprehensive audit history (Security Tooling Account API)
curl -X GET "https://<api-gateway-id>.execute-api.<region>.amazonaws.com/v1/api/v1/ami/ami-1234567890abcdef0/lineage?direction=both&depth=10" \
-H "x-api-key: <your-api-key>"
Clean up
To decommission the AMI Lineage solution, use the following steps to prevent dependency errors. The process is the reverse of the deployment.
(Optional) Back up your data. Before you begin, export critical data for your audit and compliance records. This includes generating final compliance reports from the API or creating a final snapshot of the Neptune database (you will be prompted to do this when you delete the cluster).
Run cleanup in member accounts. Sign in to each participating member account and run the cleanup script from the deployment files. This removes the local EventBridge rules, AWS Config rules, and cross-account IAM roles.
# In each Member Account
cd deployment-scripts/child-account
./cleanup-child-account-resources.sh
# Removes Config rules and cross-account roles from each member account
Run cleanup in the security tooling account. Sign in to your security tooling account and run the cleanup script. This decommissions the core solution, including the API gateway, Lambda functions, Neptune cluster, and the associated VPC.
# Clean up security tooling account
cd deployment-scripts/shared
./cleanup-shared-resources.sh
# Removes Neptune, Lambda, API Gateway, SNS, and Security Hub components
Run cleanup in the organization management account. Sign in to your organization management account to remove the organization-level resources.
Run the cleanup script to remove the organization-wide EventBridge rules.
# Clean up organization management account
cd deployment-scripts/organization
./cleanup-organization-resources.sh
# Removes SCPs, EventBridge rules, and cross-account trust policies
In the AWS Organizations console, detach and delete the AMI-Governance-Controls SCP.
In the Security Hub and GuardDuty consoles, remove the security tooling account as the delegated administrator.
Delete final data and encryption keys. After the solution’s infrastructure is removed, you can delete the remaining assets.
In the organization management account,schedule the deletion of the KMS keys you created for encrypting the solution’s data.
Conclusion
In this blog post, we showed you how you can use the AMI Lineage solution to build a comprehensive approach to tracking the complete history of your AMIs from creation to decommissioning. By storing this data in an Amazon Neptune graph database, you can build a hierarchical view of the relationships between your EC2 instances and the AMIs they were launched from. You learned how that data can be used to improve security response and remediation and assist in auditing and compliance activities.
The solution uses AWS Organizations to provide preventative controls to help ensure that only approved AMIs are used and integrates AWS security services like Amazon GuardDuty, AWS Security Hub, and AWS Config to add additional layers of security monitoring and management. Finally, you saw how the solution can be used during a security event or when new CVEs are published, so that you can rapidly discover which systems are affected and automate responses based on those findings.
While this solution provides powerful capabilities, it’s important to consider the operational and cost aspects. The core components, particularly Neptune, have associated costs that will scale with the size of your AMI estate. We recommend implementing cost monitoring and alerts as part of your deployment. Furthermore, because the solution is event-driven, you should plan a one-time backfill process to ingest your organization’s existing AMI history into the graph database. For organizations that require this level of granular control and visibility, these operational considerations are offset by the significant gains in security posture and compliance automation.
AMI Lineage transforms AMI governance from a manual, error-prone process into an automated, comprehensive security capability that scales with your organization’s growth. By implementing this solution, your organization can gain the visibility, control, and automated response capabilities needed to maintain a strong security posture while enabling rapid, secure deployment of infrastructure across its AWS environment.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Microsoft is publishing 77 vulnerabilities this March 2026 Patch Tuesday. Microsoft is aware of public disclosure of two of today’s vulnerabilities, but without evidence of exploitation in the wild for any (yet), so there are no Microsoft additions to CISA KEV today. Earlier in the month, Microsoft provided patches to address nine browser vulnerabilities, which are not included in the Patch Tuesday count above.
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. The legitimate Authenticator app could be installed on a personal device, but often provides multi-factor authentication (MFA) codes for production services in a bring-your-own-device context. Typically, users can choose their own authenticator app. Accordingly, defenders should 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 is unremarkable, and exploitation requires user interaction, since the user must select the malicious app as the handler for the sign-in flow. 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. 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.
Microsoft is publishing 55 vulnerabilities this February 2026 Patch Tuesday. Microsoft is aware of exploitation in the wild for six of today’s vulnerabilities, and notes public disclosure for three of those. Earlier in the month, Microsoft provided patches to address three browser vulnerabilities, which are not included in the Patch Tuesday count above.
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.
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.
⠀
Chart 1: Exploited-in-the-wild Microsoft vulnerabilities, by vulnerable component
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.
⠀
Chart 2: Windows AFD vulnerabilities timeline, 2021-2025
⠀
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.
⠀
Windows CLFS vulnerabilities timeline, 2021-2025
⠀
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 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.
Cisco’s announcement that it will sunset Cisco Vulnerability Management (Kenna) marks a clear inflection point for many security teams. With end-of-sale and end-of-life timelines now defined, and no replacement offering on the roadmap, Kenna customers face an unavoidable decision window.
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.
Microsoft is publishing 114 vulnerabilities this January 2026 Patch Tuesday. Today’s menu includes just one vulnerability marked as exploited in the wild, as well as two vulnerabilities where Microsoft is aware of public disclosure. There are no critical remote code execution or elevation of privilege vulnerabilities. So far this month, Microsoft has already provided patches to address one browser vulnerability and around a dozen vulnerabilities in open source products, which are not included in the Patch Tuesday count above.
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 occasionalseries 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.
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.
Microsoft is publishing a relatively light 54 new vulnerabilities this December 2025 Patch Tuesday, which is significantly lower than we have come to expect over the past couple of years. Today’s list includes two publicly disclosed remote code vulnerabilities, and a single exploited-in-the-wild vulnerability. Three critical remote code execution (RCE) vulnerabilities are also patched today; Microsoft currently assesses those as less likely or even unlikely to see exploitation. During December, Microsoft has already patched 14 browser vulnerabilities and more than 80 vulnerabilities in open source products, which are not included in the Patch Tuesday count above.
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.
A denial-of-service vulnerability exists in github.com/sirupsen/logrus when using Entry.Writer() to log a single-line payload larger than 64KB without newline characters.
Microsoft is publishing 66 new vulnerabilities today, which is far fewer than we’ve come to expect in recent months. There’s a lone exploited-in-the-wild zero-day vulnerability, which Microsoft assesses as critical severity, although there’s apparently no public disclosure yet. Three critical remote code execution (RCE) vulnerabilities are patched today; happily, Microsoft currently assesses all three as less likely to see exploitation. Five browser vulnerabilities and a dozen or so fixes for Azure Linux (aka Mariner) have already been published separately this month, and are not included in the total.
Windows GDI+: critical 0-day RCE
Faced with a fresh stack of Patch Tuesday vulns, there are a few different ways to prioritize our analysis. Do we start with vulns exploited in the wild? Pre-authentication RCEs? The vuln with the highest CVSS base score? The vuln which is likely to affect just about every asset running Microsoft software? Any of these are sensible avenues of approach, and today, all roads lead to CVE-2025-60724. As the advisory notes, in the worst-case scenario, an attacker could exploit this vulnerability by uploading a malicious document to a vulnerable web service. The advisory doesn’t spell out the context of code execution, but if all the stars align for the attacker, the prize could be remote code execution as SYSTEM via the network without any need for an existing foothold. While this vuln almost certainly isn’t wormable, it’s clearly very serious and is surely a top priority for just about anyone considering how to approach this month’s patches.
The weakness underlying CVE-2025-60724 is CWE-122: Heap-based buffer overflow, a concept which celebrated its 50th birthday several years ago. As the authors of the original 1972 paper noted: “If the code makes use of an internal buffer, there is a possibility that a user could input enough data to overwrite other portions of the program’s private storage.” Regarding computer security in general, they opined that “this problem is neither hopeless nor solved. It is, however, perfectly clear […] that solutions to the problem will not occur spontaneously, nor will they come from the various well-intentioned attempts to provide security as an add-on to existing systems.”
Office: critical ACE
Once again, we find ourselves wondering: “when is remote code execution really remote?” CVE-2025-62199 describes a critical RCE vulnerability in Microsoft Office, where exploitation relies on the user downloading and opening a malicious file. The attacker is remote, and that’s enough to satisfy the definition, even if the action is taken on the local system by the unwitting user. Anyone hoping that the Preview Pane is not a vector will be sadly disappointed, and this certainly increases the probability of real-world exploitation, since there’s no need for the attacker to craft a way around those pesky warnings about enabling dangerous content. Just scrolling through a list of emails in Outlook could be enough.
Visual Studio: critical RCE
Some attacks are straightforward, with only a single step needed to reach the finish line. Others, like Visual Studio critical RCE CVE-2025-62214, require that the attacker execute a complex chain of events. In this case, exploitation demands multi-stage abuse of recent advances in Visual Studio AI development capabilities, including prompt injection, Agent interaction, and triggering a build. The advisory doesn’t describe the context of code execution. If the prize is simply code execution on an asset in the context of the user, there’s no obvious advancement for the attacker, since exploitation already requires code execution on the asset by the attacker or the targeted user. The brief description of the attack chain does mention that the attacker would need to trigger a build. On that basis, possible outcomes might include execution in an elevated context, or compromised build artifacts, although the advisory does not provide enough information to be certain either way.
SQL Server: critical EoP
SQL Server admins should take note of CVE-2025-59499, which describes an elevation of privilege (EoP) vulnerability. Although some level existing privileges are required, successful exploitation will permit an attacker to run arbitrary Transact-SQL (T-SQL) commands. T-SQL is the language which SQL Server databases and clients use to communicate with one another. Although the default configuration for SQL Server disables the xp_cmdshell functionality which allows direct callouts to the underlying OS, there’s more than one way to shine a penny, and the only safe assumption here is that exploitation will lead to code execution in the context of SQL Server itself. Patches are available for all supported versions of SQL Server.
Microsoft lifecycle update
Following the sweeping lifecycle changes seen in October 2025, Microsoft is taking it fairly easy this month. The only significant transition today is the end of support for Windows 11 Home and Pro 23H2. Unlike the demise of Windows 10, this much smaller change won’t affect most people; a small number of older CPUs might not make the cut, since Windows 11 24H2 introduces a requirement for a couple of newer CPU instruction sets. Microsoft provides lists of compatible Intel, AMD, and Qualcomm CPU series.
An issue was discovered in libarchive bsdtar before version 3.8.1 in function apply_substitution in file tar/subst.c when processing crafted -s substitution rules. This can cause unbounded memory allocation and lead to denial of service (Out-of-Memory crash).
Microsoft is addressing 67 vulnerabilities this June 2025 Patch Tuesday. Microsoft has evidence of in-the-wild exploitation for just one of the vulnerabilities published today, and that is reflected in CISA KEV. Separately, Microsoft is aware of existing public disclosure for one other freshly published vulnerability. Microsoft’s luck holds for a ninth consecutive Patch Tuesday, since neither of today’s zero-day vulnerabilities are evaluated as critical severity at time of publication. Today also sees the publication of eight critical remote code execution (RCE) vulnerabilities. Two browser vulnerabilities have already been published separately this month, and are not included in the total.
Windows WebDAV: zero-day RCE
Remember the WebDAV standard? It has been seven years since Microsoft has published a vulnerability in the Windows implementation of WebDAV, and today’s publication of CVE-2025-33053 is the first zero-day vulnerability on record. Originally dreamed up in the 1990s to support interactivity on the web, WebDAV may be familiar to Exchange admins and users of a certain vintage, since older versions of Exchange, up to and including Exchange Server 2010, supported WebDAV as a means for interacting with mailboxes and public folders.
It will surprise no one that Windows still more or less supports WebDAV, and that turns out to be a bit of a problem. Microsoft acknowledges Check Point Research (CPR) on the advisory; CPR in turn attributes exploitation of CVE-2025-33053 to an APT, which they track as Stealth Falcon, an established threat actor with a long-running interest in governments and government-adjacent entities across the Middle East and the surrounding area.
Curiously, the Microsoft advisory does not mention that the Windows implementation of WebDAV is listed as deprecated since November 2023, which in practical terms means that the WebClient service no longer starts by default. The advisory also has attack complexity as low, which means that exploitation does not require preparation of the target environment in any way that is beyond the attacker’s control. Exploitation relies on the user clicking a malicious link. It’s not clear how an asset would be immediately vulnerable if the service isn’t running, but all versions of Windows receive a patch, including those released since the deprecation of WebClient, like Server 2025 and Windows 11 24H2. On Server 2025, for instance, it’s still possible to install the WebDAV Redirector server feature, which then causes the WebClient service to appear.
SMB client: zero-day EoP
Publicly disclosed elevation of privilege (EoP) zero-day vulnerabilities that lead to SYSTEM are always going to be worth a closer look, and CVE-2025-33073 is no exception. The advisory sets out that the easiest path to exploitation simply requires the user to connect to a malicious SMB server controlled by the attacker. It’s not entirely clear from the advisory whether simply connecting is enough to trigger exploitation, or whether successful authentication is required, since there is currently conflicting language in two separate FAQ entries with almost-identical titles: “How could an attacker exploit this/the vulnerability?” It may well be that Microsoft will come back around and clarify this wording, but in the meantime the only safe assumption is that fortune favours the attacker.
Windows KDC Proxy: critical RCE
The Windows KDC Proxy Service (KPSSVC) receives a patch today for CVE-2025-33071, which describes a critical unauthenticated RCE vulnerability where exploitation is via abuse of a cryptographic protocol weakness. The good news is that only Windows Server assets configured as a Kerberos Key Distribution Center Proxy Protocol server — happily, this is not enabled as standard configuration for a domain controller — and exploitation requires that the attacker win a race condition. The bad news is that Microsoft considers exploitation more likely regardless, and since a KDC proxy helps Kerberos requests from untrusted networks more easily access trusted assets without any need for a direct TCP connection from the client to the domain controller, the trade-off here is that the KDC proxy itself is quite likely to be exposed to an untrusted network. Patching this vulnerability should be top of mind for affected defenders this month.
Office preview pane: trio of critical RCEs
Microsoft expects that exploitation of three Office critical RCE vulns patched today is more likely. CVE-2025-47162, CVE-2025-47164, and CVE-2025-47167 share several attributes: each was discovered by prolific researcher 0x140ce, who topped the MSRC 2025 Q1 leaderboard, and each includes the Preview Pane as a vector, which always ups the ante for defenders. Admins responsible for installations of Microsoft 365 Apps for Enterprise — also confusingly referred to as “Microsoft 365 for Office” in the advisory FAQ — will have to hang on, since patches for today’s vulnerabilities aren’t yet available for that particular facet of the Microsoft 365 kaleidoscope.
Microsoft lifecycle update
June is a quiet month for Microsoft product lifecycle changes. The next batch of significant Microsoft product lifecycle status changes are due in July 2025, when the SQL Server 2012 ESU program draws to a close, along with support for Visual Studio 2022 17.8 LTSC.
Microsoft is addressing 77 vulnerabilities this May 2025 Patch Tuesday. Microsoft has evidence of in-the-wild exploitation for five of the vulnerabilities published today, and these are already reflected in CISA KEV. Separately, Microsoft is aware of existing public disclosure for two vulnerabilities published today. This is now the eight consecutive Patch Tuesday on which Microsoft has published zero-day vulnerabilities without evaluating any of them as critical severity at time of publication. Today also sees the publication of six critical remote code execution (RCE) vulnerabilities. Six browser vulnerabilities have already been published separately this month, and are not included in the total.
Windows Scripting Engine: zero-day RCE
In the majority of cases, the CVSSv3 base score provides a solid sense of the severity of a vulnerability. Sometimes, however, even a correct CVSS assessment can disguise the potential impact of a specific vulnerability. This arguably the case with CVE-2025-30397, a zero-day RCE vulnerability in the Windows Scripting Engine with a healthy but unremarkable CVSSv3 base score of 7.5. Microsoft is aware of exploitation in the wild. It’s certainly not the worst of the worst — we save that level of alarm for pre-authentication RCE with no requirement for user interaction — and Microsoft assesses attack complexity as high, which is arguably correct. And yet…
The advisory FAQ for CVE-2025-30397 explains that successful exploitation requires an attacker to first prepare the target so that it uses Edge in Internet Explorer Mode, and then causes the user to click a malicious link; there is no mention of a requirement for the user to actively reload the page in Internet Explorer Mode, so we must assume that exploitation requires only that the “Allow sites to be reloaded in Internet Explorer” option is enabled. Users who are most likely to require Internet Explorer compatibility mode in 2025 are surely users at enterprise organizations, where critical business workflows still depend on applications from the dinosaur days when Internet Explorer ruled the roost. No doubt the concept of a plan for migration of all of these applications exists, buried several layers deep in a dusty backlog, but Microsoft would hardly be offering IE compatibility mode until at least 2029 if it didn’t know that a huge swathe of its customer base demands it.
If the pre-requisite conditions are already conveniently in place on the target asset thanks to a well-meaning corporate IT policy, attack complexity is suddenly nice and low. If this vulnerability didn’t have that requirement for environment preparation, the CVSS base score would then be 8.8, which is as close to critical as you can get without actually stepping over the line. As Rapid7 has previously noted on a number of occasions, the MSHTML/Trident scripting engine is still present in Windows; this is true even for assets which have only ever run versions of Windows released well after the end of support for Internet Explorer 11 back in June 2022.
Common Log File System: zero-day EoPs
Neither CVE-2025-32701 nor CVE-2025-32706 are the first zero-day vulnerabilities in the Windows Common Log File Driver System; indeed, they are the latest members of an ongoingdynasty where exploitation typically leads to elevation of privilege to SYSTEM. Credit where credit is due: recent disclosures by Microsoft’s own Threat Intelligence Center (MSTIC), including this month’s CVE-2025-32701, demonstrate that Microsoft is putting serious effort into detecting and rooting out CLFS exploitation. Of course, since Microsoft is aware of exploitation in the wild, we know that someone else got there first, and there’s no reason to suspect that threat actors will stop looking for ways to abuse CLFS any time soon.
Windows Desktop Window Manager: zero-day EoP
If proof were needed that elevation of privilege to SYSTEM will never go out of style, today sees the publication of CVE-2025-30400, which is a zero-day vulnerability in the Windows Desktop Window Manager (DWM). As it happens, tomorrow marks the one-year anniversary of CVE-2024-30051, a previous zero-day EoP vulnerability in DWM.
Visual Studio: zero-day RCE
Today, all current versions of Visual Studio 2022 and 2019 receive patches for CVE-2025-32702, a zero-day RCE where exploitation requires the user to download and open a malicious file. There is nothing obviously remarkable about this, although Microsoft is aware of public disclosure. As usual for a malicious file/link vuln, the word Remote here refers to the location of the attacker, even though exploitation is set in motion by local user action.
Ancillary Function Driver for Winsock: zero-day EoP
Regular Patch Tuesday watchers will recognize the Ancillary Function Driver for Winsock, which is the site of CVE-2025-32709, an elevation of privilege vulnerability for which Microsoft is aware of exploitation. In something of a break with tradition for Patch Tuesday zero-day EoP vulnerabilities, exploitation only leads to administrator privileges rather than all the way to SYSTEM, but no attacker is going to waste too many cycles feeling sad about that.
Defender for Identity: situationally-ironic zero-day spoofing
Today sees the publication of CVE-2025-26685, a zero-day spoofing vulnerability in Microsoft Defender for Identity. The advisory provides puzzle pieces which don’t by themselves add up to anything like a full explanation of the vulnerability; no action is required for remediation, but you can render yourself vulnerable if you insist by opening a case with Microsoft Support to re-enable the legacy NTLM authentication method.
However, the FAQ does offer a link to an article published yesterday: Configure SAM-R to enable lateral movement path detection in Microsoft Defender for Identity. This solid piece of documentation is part of the overall Defender for Identity administration guide, and explains that the lateral movement path detection feature can itself potentially be exploited by an adversary to obtain an NTLM hash.
Exploitation relies on achieving fallback from Kerberos to NTLM; the compromised credentials in this case would be those of the Directory Service Account for Defender for Identity. The new Defender for Identity sensor (version 3.x) is not affected by this issue as it uses different detection methods; at time of writing, the Defender for Identity What’s new? page doesn’t yet describe the 3.x release, but this will presumably receive an update soon.
Microsoft lifecycle update
The next batch of significant Microsoft product lifecycle status changes are due in July 2025, when SQL Server 2012 ESU program draws to a close, along with support for Visual Studio 2022 17.8 LTSC.
In April of 2025, Rapid7 discovered and disclosed three new vulnerabilities affecting SonicWall Secure Mobile Access (“SMA”) 100 series appliances (SMA 200, 210, 400, 410, 500v). These vulnerabilities are tracked as CVE-2025-32819, CVE-2025-32820, and CVE-2025-32821. An attacker with access to an SMA SSLVPN user account can chain these vulnerabilities to make a sensitive system directory writable, elevate their privileges to SMA administrator, and write an executable file to a system directory. This chain results in root-level remote code execution. These vulnerabilities have been fixed in version 10.2.1.15-81sv.
Rapid7 would like to thank the SonicWall security team for quickly responding to our disclosure and going above and beyond over a holiday weekend to get a patch out.
Vulnerability table
CVE
Description
Affected Service
CVSS
CVE-2025-32819
An authenticated attacker with user privileges can delete any file on the SMA appliance as root to perform privilege escalation to the administrator account. Based on known (private) IOCs and Rapid7 incident response investigations, we believe this vulnerability may have been used in the wild.
An authenticated attacker with user privileges can inject a path traversal sequence to make any directory on the SMA appliance writable by all users, including the nobody user. Any existing file on the system can also be overwritten with junk contents as root.
An authenticated attacker with administrator privileges can inject shell command arguments to upload a fully controlled file anywhere that the nobody user can write to.
These vulnerabilities were discovered by Ryan Emmons, Staff Security Researcher at Rapid7, and are being disclosed in accordance with Rapid7’s coordinated vulnerability disclosure policy.
Remediation
To remediate CVE-2025-32819, CVE-2025-32820, and CVE-2025-32821, SonicWall SMA administrators should update to the latest version, 10.2.1.15-81sv. For additional information, please see SonicWall’s advisory.
Rapid7 customers
InsightVM and Nexpose customers will be able to assess their exposure to CVE-2025-32819, CVE-2025-32820, and CVE-2025-32821 with an unauthenticated vulnerability check expected to be available in today’s (May 7) content release.
Analysis
The appliance tested was ”SMA 500v for ESXi” running version 10.2.1.14-75sv, the latest available at the time of research.
CVE-2025-32819
An attacker with access to a low-privilege SMA user account can delete any file as root. This vulnerability appears to be a patch bypass for a previously reported arbitrary file delete vulnerability. That original vulnerability was disclosed by NCC Group in 2021, and a patch was previously released in the 10.2.0.9-41sv and 10.2.1.3-27sv patch cycle. Rapid7 is not aware of any specific CVE assigned to this original vulnerability; the NCC Group blog post states that a CVE was not shared with them, and we didn’t see a clear 1:1 match on the SonicWall PSIRT page.
Based on our testing, the unauthenticated arbitrary file delete vulnerability disclosed by NCC Group was patched by adding an authentication check. However, that authentication check is satisfied with a valid low-privilege session cookie, so exploitation is still viable. An attacker can exploit this vulnerability with low privileges to elevate to SMA administrator. This can be chained with CVE-2025-32820 and CVE-2025-32821 to establish root-level remote code execution on the SMA research target running 10.2.1.14-75sv. Note: Based on known (private) IOCs and Rapid7 incident response investigations, we believe this vulnerability may have been used in the wild.
In /usr/src/EasyAccess/www/conf/httpd.conf, we observe that the /fileshare/sonicfiles web path is mapped to the sonicfiles.py Flask application.
Within sonicfiles.py, we find the function main_handler, which is a main function that enforces authentication checks and dispatches various “RacNumber” SMB operations. At [A], we see an authorization check being performed before the primary API functionality is reachable.
@application.route('/sonicfiles', methods=['GET', 'POST'])
@application.route('/', methods=['GET', 'POST'])
def main_handler():
#Get the required config if its not set
#application.get_config()
prog = 'fileexplorer'
'''Alternate method for CSRF
referrer = request.referrer
parsed_referrer = urlparse(request.referrer)
if((referrer is None) or (parsed_referrer.hostname != request.host)):
print("Referrer something is wrong")
return HttpErrorCode["NOT_PERMITTED_AUTH"]
'''
#set the log level to Debug when don't get the setting from SMA settings.
application.set_log_level(logging.DEBUG)
authResult = application.authorizationCheck() # [A]
if authResult:
response = make_response(str(HttpErrorCode["NOT_PERMITTED_AUTH"][0]))
response.headers['content-type'] = 'text/plain'
response.headers['Cache-Control'] = 'no-cache'
logger.info("::SONICFILES:: Authorization check failed {}".format(authResult))
return response, HttpErrorCode["NOT_PERMITTED_AUTH"][1]
racNum = request.args.get('RacNumber', RacNumber.RAC_INVALID, int)
if racNum is RacNumber.RAC_INVALID:
return 'Invalid invocation', 500
smbshare = FileShare(application)
[..SNIP..]
Let’s investigate what application.authorizationCheck is. It’s defined in pythonApi.py:
The self.get_connection_id function is depicted below. It fetches the swap cookie ([B]), which is the primary session cookie, then decodes it as base64 ([C]) and returns it.
Since the primary authorizationCheck function is a SWIG function implemented in native code, the decompiled cleaned up C for that is depicted below. It calls sessionGetAndRefresh ([D]), which queries the web application’s SQLite primary database on disk, to determine whether the provided session is an authenticated one. If it’s valid (and if the CSRF token matches when the ‘POST’ method is used), it returns a success code ([E]).
That establishes that any low-privileged user can call RacNumber functions via the sonicfiles API. In 2021, NCC Group outlined how the RAC_DOWNLOAD_TAR function (RacNumber=44) could be exploited with a path traversal for privileged arbitrary file deletion. That download_tar code does not appear to have been modified from what the NCC Group blog post shows, since the “/tmp” directory string is still unsafely concatenated with tainted web parameters ([F]); only the authentication check outlined above in main_handler appears to have been implemented as a fix.
We’ll start by creating a user named lowpriv with low user-level SMA privileges. This user account should not have access to any administrative functionality, and it will act as our victim account for exploitation. We’ll login to the SMA web service listening on port 443 and establish that we have access to this standard user account.
We’ll create two attacker-owned files as root to demonstrate the privileged arbitrary file delete.
Next, we’ll grab our lowpriv user’s session cookies and use them to perform the malicious file delete web request. The server will return a generic 500 code error response.
With our console root shell, we can see that the root-owned /tmp/rootfile file has been deleted.
This can be leveraged to delete the /etc/EasyAccess/var/conf/persist.db file, which is the primary web server SQLite database. When that happens, the system will reboot and reset the SMA administrator password to “password”. Based on known (private) IOCs and Rapid7 incident response investigations, we believe that this specific technique may have been used in the wild.
CVE-2025-32820
An authenticated attacker with user-level low privileges can inject a path traversal sequence to an arbitrary directory on the SMA appliance to make it world-writable. This can be chained with CVE-2025-32819 and CVE-2025-32821 to establish root-level remote code execution on the SMA research target running 10.2.1.14-75sv. Additionally, if a file path is provided, any existing file on the system can be overwritten with junk contents as root, creating a persistent denial of service condition.
Let’s investigate this now. In authentication_api/client/__init__.py, we observe authentication checks implemented in before_request ([G]).
This authorization_check function is similar to the one we previously looked at. However, this function is implemented in Python, within smaauthorize.py, instead of in a C shared library. Below, we can see this logic. The third parameter is called requireAdmin, and it defaults to True ([H]). In this case, though, the call within before_request explicitly states that low-privilege users should be allowed via the False parameter input. The authorization code queries the primary web SQLite database to determine whether the user’s swap session cookie exists in the database ([I]). If so, the request will succeed.
The NxPostConnectionScriptFileResource endpoint sounds promising, since it deals with file operations. Within nxpostconnectionscript.py, we find the API endpoint logic for POST requests. A file input parameter called upfile is expected ([J]). A sanitized file name is extracted using secure_filename (to prevent path traversal) and assigned to the tmp_file variable ([K]). Then, the file contents are stored in tmp_file’s location. A file operation command is also executed using os.system, with the tmp_file argument sanitized using shlex.quote to prevent command injection ([L]).
This is all handled well. However, while the tmp_file path was created safely, the application later needs to reference just the file name without the prepended /tmp directory. In order to do so, it defines a new filePath variable by directly concatenating the unsanitized file.filename string with a different directory path ([M]). This is then wrapped in shlex.quote, appended to the string “chmod 777 ”, and executed using os.system ([N]). No command injection is possible, since the command string is appropriately escaped. Despite this, shlex.quote does not remove path traversal sequences, so a relative traversal file name can be supplied by the attacker to execute “chmod 777” as root on any path of the attacker’s choosing.
@swagger.doc(postDocument)
def post(self):
post_reqparser = reqparse.RequestParser()
post_reqparser.add_argument('upfile', required = True, type = FileStorage, location = 'files') # [J]
args = post_reqparser.parse_args()
[..SNIP..]
# store file in /tmp for examination
file = request.files['upfile']
tmp_file = '/tmp/' + secure_filename(file.filename) # [K]
file.save(tmp_file)
fileSize = os.stat(tmp_file).st_size
if (fileSize > smaApi.MAX_SCRIPT_FILE_LEN or fileSize == 0):
cmd = "rm -rf {}".format(shlex.quote(tmp_file)) # [L]
os.system(cmd)
raise BadRequest(getMessage(API_ERR_CODE_CLIENT_FILE_SIZE_INVALID).format(int(smaApi.MAX_SCRIPT_FILE_LEN / 1024)))
# check dir exists or not and if not create it
if (not os.path.exists(smaApi.POST_SCRIPTS_DIR)):
cmd = "mkdir {}; chmod 777 {}".format(shlex.quote(smaApi.POST_SCRIPTS_DIR), shlex.quote(smaApi.POST_SCRIPTS_DIR))
os.system(cmd)
if (not os.path.exists(smaApi.POST_SCRIPTS_DESC_DIR)):
cmd = "mkdir {}; chmod 777 {}".format(shlex.quote(smaApi.POST_SCRIPTS_DESC_DIR), shlex.quote(smaApi.POST_SCRIPTS_DESC_DIR))
os.system(cmd)
# move file to its destination
cmd = "mv {} {}".format(shlex.quote(tmp_file), shlex.quote(smaApi.POST_SCRIPTS_DIR))
os.system(cmd)
filePath = smaApi.POST_SCRIPTS_DIR + '/' + file.filename # [M]
cmd = "chmod 777 {}".format(shlex.quote(filePath)) # [N]
os.system(cmd)
[..SNIP..]
Exploitation
This is a niche primitive, since we do not control the command being executed. Fortunately, making any directory world-writable is exactly what we need to weaponize CVE-2025-32821, our arbitrary low-privilege file write as nobody. We’ll perform a web request to the vulnerable API endpoint as the lowpriv user. In that request, we’ll set upfile to a relative traversal sequence into /bin, which is on the root user’s PATH.
Our pspy monitor logs two commands being executed as root. The first command’s file path is sanitized using secure_filename, but the second is only sanitized using shlex.quote, resulting in a traversal to /bin.
CMD: UID=0 PID=15082 | sh -c mv /tmp/bin /usr/src/EasyAccess/var/conf/postscripts
CMD: UID=0 PID=15083 | sh -c chmod 777 /usr/src/EasyAccess/var/conf/postscripts/../../../../../../../../../bin/
Exploitation is confirmed with our console root shell, which shows that the /bin directory is now world-writable.
CVE-2025-32821
An authenticated attacker with administrator privileges can inject shell command arguments with an escape sequence to upload a fully controlled file anywhere that the nobody user can write to. This can be chained with CVE-2025-32820 to establish root-level remote code execution on the SMA research target running 10.2.1.14-75sv. It’s also possible to copy existing files that the nobody user can read, such as /etc/passwd or the application’s SQLite database, to the web root directory for data exfiltration.
We’ll start by taking a look at the main function in /cgi-bin/importlogo.
After confirming the user is an authenticated administrator and the HTTP method is “POST”, the application checks for the presence of an integer parameter called updateFavicon ([O]). If this is set to “1”, and if the defaultFavicon parameter is “0”, the application will call FUN_0804a0f0 with the first argument set to a FILE pointer from the multipart form file parameter called favicon1 ([P]). After confirming some basic validation checks, such as file size, the FUN_0804a0f0 function will write the uploaded file to disk at /usr/src/EasyAccess/www/htdocs/themes/favicon1.ico. Next, the portalName POST parameter is fetched and passed through safeSystemCmdArg2 ([Q]). This is a security function that searches for command injection characters, such as $, \n, ;, |, <, >, ^, and `. If any of those characters are detected, the function will return a truncated string of the characters up to that point. Then, a format string is created with the sanitized portalName value to craft the shell command string cp -f /usr/src/EasyAccess/www/htdocs/themes/favicon1.ico /usr/src/EasyAccess/uiaddon/{portalName_VALUE}/favicon.ico ([R]) and the command is executed via system_s_quiet ([S]), which is a wrapper for system that runs in the context of nobody.
Note that the provided portal name is not validated as a legitimate web portal name at any point in the code path thus far–it’s checked against valid portal names if updateFavicon is not set. So, we don’t need to provide a valid portal name. Additionally, although the portal name is sanitized for command injection characters, it is not sanitized for path traversals, it is not URL encoded, and hash symbols are not truncated. As a result, an attacker can provide a portalName value with a traversal sequence to a different file path, followed by a space and a hash symbol to escape “/favicon.ico”.
The result is that the attacker can upload their own fully controlled file and exploit the limited command injection to write it with any file name they’d like to any directory that nobody can write to.
Exploitation
We can perform the web request depicted below to exploit this arbitrary file write.
As expected, the test.txt file has been written to the web root.
We also note that the uploaded file has the executable bit set by default.
# ls -lha /usr/src/EasyAccess/www/htdocs/test.txt
-rwx------ 1 nobody nobody 7 May 1 12:10 /usr/src/EasyAccess/www/htdocs/test.txt
This detail is useful for exploitation, since it will facilitate easily writing an executable file to a directory on the root PATH for arbitrary remote code execution.
Chained Impact
The vulnerabilities disclosed in this document permit an attacker with SMA SSLVPN low-privilege user credentials to perform the following five steps:
Exploit CVE-2025-32819 to delete the primary SQLite database and reset the password of the default SMA admin user.
Login as admin to the SMA web interface.
Exploit CVE-2025-32820 to make the SMA appliance’s /bin directory world-writable.
Exploit CVE-2025-32821 to write the file /bin/lsb_release. This executable is not installed by default, but we observed that an automated job on the appliance routinely attempts to execute it as root every few minutes.
Wait for sh -c lsb_release to be executed automatically. When this happens, the attacker gains root-level remote code execution on the SMA device.
Demonstration
We’ll start by grabbing our low-privilege user’s cookies in our “assumed breach” scenario. This cookie string is swap="ZHNZZThVdlJzWHY1MkpWTDM0akFjbG9XWFgyd29Hdk1yVEtPZWdzSnJlbz0="; swcctn=LEj9kOzEjYibGOSEW9YE8ElgWwiOgigN.
Now, let’s reset the administrator’s password by exploiting CVE-2025-32819 and deleting the primary SQLite database. The SMA returns a 200 status with no body.
Refreshing the web page confirms it worked, though the application is not thrilled with our decision.
After a few seconds, the watchdog has had enough and the device is rebooted. When we refresh the page a couple of minutes later, things are looking as good as new.
After logging in using the credentials admin:password, we’re greeted with an end user product agreement, indicating that the device has been initialized.
We’ll input a free trial license key to get the device back in a functional state, though a real attacker would probably use a stolen one. Next, we’ll use our CVE-2025-32820 PoC to make /bin writable. The server should return a 500 error with the message “Failed to create description file.”
Lastly, we’ll set our sights on remote code execution as root by exploiting CVE-2025-32821. We throw the reverse shell PoC below at our victim and it responds with a 200 code and “success” in the body. Note that a hash symbol is also appended to our executable file contents; this is added because the file write occasionally seems to append a junk character to our command, though it doesn’t happen every time. In order to avoid any unexpected additions, we escape the rest of the line.
One minute later, our reverse shell arrives and root-level remote code execution is confirmed.
Disclosure timeline
May 2, 2025: Rapid7 shares vulnerability details with SonicWall security contacts. The SonicWall team acknowledges the disclosure 30 minutes later and confirms that patch development work will begin.
May 4, 2025: The SonicWall security team states that a fixed build will be shared on May 5 for patch validation.
May 5, 2025: The SonicWall security team shares the 10.2.1.15 build with Rapid7. The Rapid7 team validates that the patch is effective.
May 6, 2025: The SonicWall security team states that the patch will be targeting a May 7 release date.
May 7, 2025: SonicWall releases v10.2.1.15 and publishes a security advisory. After confirming the patch is generally available, Rapid7 publishes this disclosure.
We live in a world where traditional Vulnerability Management (VM) has become infosec’s version of ‘whack-a-mole’— an attempt to tackle risks that constantly shift, multiply, and morph. As organizations push workloads to the cloud, offer customers digital experiences, or as they build AI-enabled applications across their business, the attack surface expands exponentially. For decades, security teams have relied on traditional network and endpoint-based scanners to discover and patch CVEs, but the reality is attackers don’t think in terms of “CVEs”—they think in attack paths.
The most successful hackers increase the blast radius and impact of their attacks by connecting key dots across your organization:
Weak access controls to high-privilege users.
Misconfigurations to mission-critical assets.
Known exploits to number of impacted systems.
To tame this complicated, quickly-evolving threat landscape, security teams are moving from ticking boxes for vulnerabilities patched, to understanding, contextualizing, and preempting real-world threats before they become breaches. The strategic shift has fueled the rise of Risk-Based Vulnerability Management (RBVM) and Continuous Threat Exposure Management (CTEM).
However, many organizations implement these approaches through an array of point security solutions – vulnerability scanners, endpoint detection software, penetration testing – and feed this data into one or more aggregation tools (usually SIEMs). This fragmented approach has inadvertently paved the way for tool sprawl, operational silos, and security blind spots. In this blog, I’ll explore why RBVM and CTEM have become essential security strategies, common mistakes that organizations make in implementation, and why these shortcomings have fueled the demand for unified exposure management.
Navigating the peaks and plateaus of RBVM and CTEM
RBVM helps teams prioritize remediation based on exploitability, criticality, and threat intelligence, rather than relying solely on CVE severity scores. RBVM solutions typically ingest data from vulnerability scanners, external threat feeds, endpoint detection systems, and other security tools. Security analysts then correlate key findings against SIEM tools to determine which vulnerabilities are actively being exploited in their environment.
The key benefit? This approach reduces alert noise because it filters out low-risk vulnerabilities, enabling security teams to focus remediation efforts on the most critical threats.
However, RBVM approaches come with significant drawbacks:
RBVM tools are not designed to perform scans or produce threat intel themselves.
Teams must integrate RBVM solutions into their existing security stack (SIEM, SOAR, EDR, cloud security tools) – a process that’s often complex, time-consuming, and costly.
Most critically, if there are assets that the RVBM services have no visibility into, they will not produce risk scores for them, creating an incomplete picture of your attack surface and inaccurate representation of true business threats.
The evolution to CTEM
To continuously assess and validate exposures across the entire attack surface, organizations are turning to CTEM as a proactive strategy for mitigating ongoing risk. With real-time, continuous visibility into the attack surface and attack paths, security teams can prioritize remediation efforts based on the risks that impact business-critical systems. Despite the benefits of this more advanced approach, implementing CTEM with fragmented security tools creates significant challenges:
Misleading view of the attack surface.
Your security stack may have top-tier vulnerability scanners, EDR solutions, and CSPM tools, but if these tools aren’t talking to each other, you end up with an incomplete view of the attack paths that hackers would take. Leading CTEM approaches are underpinned by platforms that go beyond CVEs by incorporating misconfigurations, cloud entitlements, shadow IT, lateral movement risks, and application security gaps to provide a comprehensive view of the attack surface.
Lacking business content and impact analysis for prioritization.
Security teams have to sort through alerts, false positives, and vulnerability scan results that often lack business context. Without a unified platform connecting vulnerability findings with risk scores and business impact, teams will struggle to accurately prioritize risk, leaving them spending valuable time remediating issues that do not actually impact business-critical systems. Organizations need to look across the entire attack surface, including internal and external-facing attack vectors, as well as telemetry signals like weak identity and access controls.
Silos hinder incident response.
Vulnerability dashboards and reports do not depict how an adversary would exploit a vulnerability. Organizations need an in-depth view of the attack path to understand, for example, how misconfigurations can result in disruptive domain compromise in the event of a breach. This insight helps security teams identify interconnected systems and organizational peers (e.g., application owners, cloud architects, developers, engineers, etc.) that they will need to coordinate with in case there is a breach.
The driving force for a unified exposure management platform
According to the 2023 Gartner® Technology Adoption Roadmap for Large Enterprises Survey, cybersecurity leaders indicated that on average their organizations had 43 tools in their cybersecurity product portfolios, and 5% of the leaders indicated their organizations had over 100 tools.” We believe that managing that many tools can be overwhelming, especially because security teams often operate their tools in silos. The ensuing sprawl creates blind spots that attackers can easily exploit. Instead of juggling multiple disconnected tools, forward-thinking organizations are embracing a unified approach to exposure management with comprehensive platforms that deliver:
Vulnerability management
CASM
EASM
Cloud security
Identity security
Threat intelligence
Because many high-profile breaches start with compromised credentials or excessive privileges, the ideal exposure management platform maps critical assets against users with weak authentication protocols.
Security teams can no longer rely on a scan-and-patch approach; they need to stay ahead of attackers by continuously identifying, validating, and mitigating risks across the entire attack surface. If your security tools aren’t fully integrated, attackers will exploit what’s left exposed. CISOs, security architects, and SOC leaders are tackling this challenge by moving beyond traditional VM and adopting a unified exposure management strategy with Rapid7’s Exposure Command Platform.
Connecting the dots with Exposure Command
Unlike traditional standalone VM, CASM, EASM, SIEM, or EDR tools that rely on proprietary agents, Exposure Command from Rapid7 brings it all together into one platform. With an inside-out and outside-in view of your risks, combined with trusted threat intelligence and a vendor agnostic approach to vulnerability aggregation, security teams gain a complete, end-to-end view of their attack surface.
Rapid7’s all-in-one Exposure Command platform goes even further by automatically mapping users, authentication protocols, and the criticality of the systems they can access. Armed with deep visibility into vulnerabilities and their impact to the business, organizations can leverage Rapid7’s Remediation Hub to address the risks that have the largest impact on their overall risk posture.
The paradigm has shifted – it’s no longer about chasing vulnerability patches, but about taking command and reducing risk across the business.
Ready to see the difference a unified approach can make? Check out the Rapid7 Exposure Command product trial to learn more about our platform and dive deeper into our unified, modern approach to managing risk and remediating security threats.
GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.
Security leaders today face a harsh reality: traditional vulnerability management isn’t enough. Threat actors are evolving, attack surfaces are expanding, and organizations need a more proactive approach to stay ahead of risk. Latest research from Gartner, How to Grow Vulnerability Management Into Exposure Management, highlights the need for security teams to move beyond simply tracking vulnerabilities and embrace a more comprehensive approach to exposure management.
At Rapid7, we are excited to offer complimentary access to this report and share our three key takeaways to help you modernize your security strategy.
Gartner states: “Creating prioritized lists of security vulnerabilities isn’t enough to cover all exposures or find actionable solutions. Security operations managers should go beyond vulnerability management and build a continuous threat exposure management program to more effectively scope and remediate exposures.”
CTEM shifts the focus from merely identifying vulnerabilities to understanding the full picture of organizational risk. It integrates asset visibility, business impact analysis, attack surface monitoring, and validation of security controls to help organizations assess and reduce their true exposure to threats.
Takeaway 2: Exposure Management Requires Business Context
One of the biggest challenges in vulnerability management today is that many security teams focus too much on discovering issues without evaluating their impact on the business. Gartner highlights the importance of integrating business context into security operations, stating that “adding a business context, such as asset value and impact of compromise, to exposure management activities can improve senior leadership engagement.”
By aligning security initiatives with business priorities, organizations can:
Focus on the vulnerabilities that pose the greatest risk to critical operations
Improve communication with senior leadership and stakeholders
Justify security investments with real business impact
Takeaway 3: Attack Surface Visibility Must Keep Up With Digital Evolution
Modern attack surfaces extend far beyond on-premises IT. The rise of cloud applications, IoT, supply chain dependencies, and remote work environments has dramatically increased the number of potential entry points for attackers. Gartner emphasizes that “current approaches to attack surface visibility are not keeping up with the rapid pace of digital evolution. Organizations must quickly reduce exposure to make their public-facing assets less visible and accessible.”
This means security teams need to enhance their discovery processes to:
Continuously monitor both their internal and external attack surface
Implement proactive security measures to reduce overall exposure
How Rapid7 Aligns with Gartner Exposure Management Vision
At Rapid7, we believe in empowering security teams with the tools and insights they need to shift from reactive vulnerability management to proactive exposure management. Our Exposure Management solution helps organizations:
Gain real-time visibility into evolving attack surfaces
Prioritize threats based on business impact and exploitability
Continuously validate security controls through adversarial exposure testing
As threats continue to evolve, organizations must rethink how they approach vulnerability management. Gartner research provides a roadmap for security leaders looking to implement a comprehensive exposure management strategy.
Garter, How to Grow Vulnerability Management Into Exposure Management, Michell Schneider, Jeremy D’Hoinne, Jonathan Nunez, Craig Lawson, 8 November 2024
GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.
On Thursday, April 24, enterprise resource planning company SAP published a CVE (and a day later, an advisory behind login) for CVE-2025-31324, a zero-day vulnerability in NetWeaver Visual Composer that carries a CVSSv3 score of 10. The vulnerability arises from a missing authorization check in Visual Composer’s Metadata Uploader component that, when successfully exploited, allows unauthenticated attackers to send specially crafted POST requests to the /developmentserver/metadatauploader endpoint, resulting in unrestricted malicious file upload.
While the vulnerable component is not installed in NetWeaver’s default configuration, SAP security firm Onapsis notes that it is widely enabled.
Per SAP’s docs, Visual Composer “operates on top of the SAP NetWeaver Portal, utilizing the portal’s connector-framework interfaces to enable access to a range of data services, including SAP and third-party enterprise systems. In addition to accessing SAP Business Suite systems, users can access SAP NetWeaver Business Warehouse and any open/JDBC stored procedures.”
Rapid7-observed exploitation
CVE-2025-31324 is being actively exploited in the wild; Rapid7 MDR has observed exploitation in multiple customer environments dating back to at least March 27, 2025, nearly all of which has targeted manufacturing companies. Adversaries have exploited the vulnerability to drop webshells in the following directory: j2ee/cluster/apps/sap.com/irj/servlet_jsp/irj/root/
Public threat intelligence on CVE-2025-31324 exploitation has highlighted the use of webshells named helper.jsp and cache.jsp. With few exceptions (like helper.jsp), most webshells Rapid7 has observed had random 8-character names, e.g.: cglswdjp.jsp ijoatvey.jsp dkqgcoxe.jsp ylgxcsem.jsp cpyjljgo.jsp tgmzqnty.jsp
Rapid7 has not attributed this activity to a specific threat actor at time of writing.
Mitigation guidance
All SAP NetWeaver 7.xx versions and service packs (SPS) are affected.
SAP’s non-public guidance indicates that customers can check system info (http://host:port/nwa/sysinfo) for the Software Component VISUAL COMPOSER FRAMEWORK (VCFRAMEWORK.SCA). If this check returns no results, SAP has said the vulnerability is “not relevant for that system.”
Customers should update to the latest version of NetWeaver AS on an emergency basis, without waiting for a regular patch cycle to occur. Note that updating to a fixed version of NetWeaver will not address pre-existing compromises. Customers who are unable to update to a fixed version of the application should disable Visual Composer by following SAP’s directions here.
Customers should also restrict access to the affected endpoint (/developmentserver/metadatauploader) and investigate their environments for signs of compromise. SAP’s non-public advisory notes that the “most common targets for an attacking agent” are the following paths under the JAVA server file system — jsp, java, or class files present directly in these paths should be considered malicious: C:\usr\sap\<SID>\<InstanceID>\j2ee\cluster\apps\sap.com\irj\servlet_jsp\irj\rootC:\usr\sap\<SID>\<InstanceID>\j2ee\cluster\apps\sap.com\irj\servlet_jsp\irj\workC:\usr\sap\<SID>\<InstanceID>\j2ee\cluster\apps\sap.com\irj\servlet_jsp\irj\work\sync
For additional information and the latest guidance, please refer to SAP’s non-public materials or contact SAP support.
Rapid7 customers
InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7’s expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage.
For InsightVM and Nexpose customers, our vulnerability coverage engineering team is investigating options to help customers assess exposure to this threat. We will update this blog no later than 3 PM ET on Monday, April 28 with additional information and delivery timelines.
On April 16, CISA extended funding to ensure no continuity issues with the critical Common Vulnerabilities and Exposures (CVE) program. This was in response to a letter sent by MITRE on April 15 to CVE board members warning of a potential issue with MITRE’s support for the CVE program. MITRE administers the global CVE program, which provides the human and technological infrastructure to reserve, publish, modify, and dispute CVEs.
Rapid7 continues to monitor both public and private discussions closely in its capacity as a CVE Numbering Authority (CNA) and as a longtime leader and participant in the CVE ecosystem.
How this could impact Rapid7 and our customers
Since funding has been extended for the next 11 months, there is no current impact. Rapid7 will continue to monitor the situation to ensure there is no future impact to our customers’ ability to use our platform to accurately assess their environment for vulnerabilities.
Rapid7’s multi-layered approach to vulnerability detection, creation, and risk scoring means that our products are not completely reliant on any single source of information. This was something we pointed to last year, when we assured customers of our continued vulnerability coverage in the face of NIST’s National Vulnerability Database delays.
The importance of MITRE and the CVE Program
The CVE program is critical infrastructure for modern vulnerability identification, tracking, management, and resolution. CVEs are used for risk identification, commercial and open-source tooling, vulnerability management workflows, security and academic research, threat intel production, incident response, and many other applications worldwide.
Rapid7 thanks and supports the MITRE organization as well as the extended ecosystem of industry collaborators who have worked diligently for the past 25 years to ensure the CVE program’s utility and integrity for the broader community.
We will continue to monitor the situation and will update this blog with any relevant developments. If you have any questions, please reach out.
Microsoft is addressing 121 vulnerabilities this April 2025 Patch Tuesday, which is more than twice as many as last month. Microsoft has evidence of in-the-wild exploitation for just one of the vulnerabilities published today, which is already reflected in CISA KEV. Once again, Microsoft has published zero-day vulnerabilities on Patch Tuesday without evaluating any of them as critical severity at time of publication, so that’s now a seven month unbroken streak. Today also sees the publication of 11 critical remote code execution (RCE) vulnerabilities. 13 browser vulnerabilities have already been published separately this month, and are not included in the total.
CLFS: zero-day EoP
The Windows Common Log File System (CLFS) Driver is firmly back on our radar today with CVE-2025-29824, a zero-day local elevation of privilege vulnerability. First, the good news: the Acknowledgements section credits the Microsoft Threat Intelligence Center, so the exploit was successfully reproduced by Microsoft; the less-good news is that someone other than Microsoft was first to discover the exploit, because otherwise Microsoft wouldn’t be listing CVE-2025-29824 as exploited in the wild. The advisory does not specify what privilege level is achieved upon successful exploitation, but it’ll be SYSTEM, because that’s the prize for all the other CLFS elevation of privilege zero-day vulnerabilities. As usual, some form of less-privileged local access is a pre-requisite, but attack complexity is low, so this is the sort of vulnerability which goes into any standard break-and-enter toolkit. Given the long history of similar vulnerabilities, it would be more surprising if exploit code wasn’t publicly available in the not-too-distant future. Although December 2024 Patch Tuesday seems as though it must have been a very long time ago, any standard calendar will tell us that only 119 days have elapsed since the last zero-day CLFS local elevation of privilege. Rapid7 discussed the history of CLFS zero-day elevation of privilege vulnerabilities at the time. All versions of Windows receive a patch, except for the venerable LTSC Windows 10 1507, which is listed on the advisory as vulnerable, but left out in the cold with no update; the FAQ says to check back later. Windows 10 LTSC 1507 is scheduled for end of servicing on 2025-10-14, so the clock is ticking regardless.
LDAP Server: critical RCE
Although it has been many months since we’ve seen a critical zero-day vulnerability from Microsoft, there is no shortage of critical remote code execution (RCE) vulnerabilities published today. Defenders responsible for an LDAP server — which means almost any organization with a non-trivial Microsoft footprint — should add patching for CVE-2025-26663 to their to-do list. With no privileges required, no need for user interaction, and code execution presumably in the context of the LDAP server itself, successful exploitation would be an attractive shortcut to any attacker. Anyone wondering if today is a re-run of December 2024 Patch Tuesday can take some small solace in the fact that the worst of the trio of LDAP critical RCEs published at the end of last year was likely easier to exploit than today’s example, since today’s CVE-2025-26663 requires that an attacker win a race condition. Despite that, Microsoft still expects that exploitation is more likely.
LDAP Client: critical RCE
If you breathe a sigh of relief when you see LDAP server critical RCE vulnerabilities like CVE-2025-26663, because you’re certain that you don’t have any Windows LDAP servers in your estate, how about LDAP clients? CVE-2025-26670 describes a critical RCE in the LDAP client, although the FAQ confusingly states that exploitation would require an attacker to “send specially crafted requests to a vulnerable LDAP server”; this seems like it might be a data entry error on the advisory FAQ, so keep an eye out for an update to that section of the advisory. Assuming the rest of the advisory is all present and correct, exploitation requires that the attacker win a race condition, which keeps the attack complexity higher than it otherwise would be. While we wait for clarification, it’s still a critical RCE which Microsoft rates as “exploitation more likely”. On that basis, patching is always recommended.
RDS: critical RCEs
The prolific Windows vulnerability pioneers at Kunlun Lab are credited with a pair of critical RCE vulnerabilities in Windows Remote Desktop Services. Although both CVE-2025-27480 and CVE-2025-27482 share a CVSSv3 base score of 8.1, Microsoft has ranked them both as critical using its own proprietary severity ranking scale. Both vulnerabilities require that an attacker win a race condition. If you’ve ever read Microsoft’s guide to deploying the Remote Desktop Gateway role, you probably have some systems to patch.
Hyper-V: critical RCE
Some Microsoft security advisory FAQs provide a satisfying level of detail, whereas others raise more questions than they answer. CVE-2025-27491 is a Hyper-V critical RCE which falls into the second category, since it states that an attacker must be authenticated — no need for elevated privileges — but also that the attacker must send the user a malicious site and convince them to open it, and it’s not at all clear why authentication would be required in that case. Also unusual: the remediation table on the advisory lists several 32-bit versions of Windows as receiving patches, although Hyper-V requires a 64-bit processor and a 64-bit host OS.
Microsoft lifecycle update
In Microsoft product lifecycle news, Dynamics GP 2015 moves past the end of extended support today. The next batch of significant lifecycle status changes are due in July 2025, when SQL Server 2012 ESU program draws to a close.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
