This release our very own cdelafuente-r7 finished implementing the Metasploit MCP Server (msfmcpd), bringing Model Context Protocol support to Metasploit Framework. MCP lets AI applications like Claude, Cursor, or your own custom agents query Metasploit data. Think of it as a middleware layer that exposes 8 standardized tools for searching modules and pulling reconnaissance data, all built on the official Ruby MCP SDK.

This first iteration is read-only, covering modules, hosts, services, vulnerabilities, and more. Tools for module execution, session interaction, and database modifications are on the roadmap for a future release. Full details are available in the documentation.

Copy Fail

Earlier this week, details of a new and high profile Linux LPE were released alongside a public PoC. The bug, nicknamed Copy Fail and identified by CVE-2026-31431, is a logic flaw in the cryptographic APIs exposed by the Linux Kernel. Metasploit has shipped a local exploit this week to leverage the flaw on AMD64 and AARCH64 targets with additional architectures planned for future releases. The exploit, which replaces the ‘su’ binary in the page cache with a small ELF file, allows users to specify command payloads for execution and will automatically determine the appropriate target architecture.

New module content (3)

Microsoft Windows HTTP to LDAP Relay

Author: jheysel-r7

Type: Auxiliary

Pull request: #21323 contributed by jheysel-r7

Path: server/relay/http_to_ldap

Description: This adds a new NTLM relay module that relays from HTTP to LDAP. On success, an authenticated LDAP session is opened which allows the operator to interact with the LDAP service in the context of the relayed identity.

Copy Fail AF_ALG + authencesn Page-Cache Write

Authors: Diego Ledda, Spencer McIntyre, Xint Code, and rootsecdev

Type: Exploit

Pull request: #21395 contributed by zeroSteiner

Path: linux/local/cve_2026_31431_copy_fail

AttackerKB reference: CVE-2026-31431

Description: Adds a module for CVE-2026-31431 (The Copy Fail LPE for Linux), a local privilege escalation affecting almost every Linux Kernel since 2017.

Linux Execute Command

Author: Spencer McIntyre

Type: Payload (Single)

Pull request: #21395 contributed by zeroSteiner

Path: linux/aarch64/exec

Description: Adds a module for CVE-2026-31431 (The Copy Fail LPE for Linux), a local privilege escalation affecting almost every Linux Kernel since 2017.

Enhancements and features (5)

• #21315 from cdelafuente-r7 - This adds a read-only MCP server for Metasploit capable of retrieving information from the loaded modules and database.
• #21352, #21353, #21355, #21359 from adfoster-r7 - Improves multiple module check code messages and statuses.

Bugs fixed (0)

None

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

• Pull Requests 6.4.130...6.4.131
• Full diff 6.4.130...6.4.131

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

The conversation reinforced what we see across many organizations: SecOps is very much focused on protecting business resilience, enabling confident decisions by senior security leaders, and building programs that scale across people, platforms, and emerging technology. Let's now take a look at some of the main highlights from this year's Summit.

The business case for SecOps has shifted and boards are listening

The ‘invest in security or get breached’ pitch has run its course. Boards have heard it too many times; plus, it frames security as a cost center that only proves its value when something goes wrong.

We’re seeing it being replaced by a resilience narrative. In most incidents, the biggest business impact is operational disruption. Hours or days of downtime create immediate revenue loss, reputational damage, and perhaps worse still for some, regulatory exposure. CISOs who can connect their programs to that reality – translating incident data into business availability and financial risk – find it significantly easier to justify spend and shape investment decisions.

That shift in dynamic changes what gets measured and prioritized as well as how security leaders communicate upward to the board. Threat intelligence and kill chains still matter inside the SOC, but the ability to translate that to a clear risk narrative is fast becoming a leadership requirement in its own right.

Platform consolidation is growing, but it's not binary

The platform-vs-best-of-breed debate was notably pragmatic. The real question is how to strike the right balance: Consolidate where it improves efficiency and visibility, retain point solutions where they materially reduce a specific risk.

On the ground, budget pressure has accelerated this. Fewer vendors, more integrated telemetry, and clearer operational ownership help make spend more defensible. The discussion framed consolidation through the lens of ‘control planes’ (endpoint, gateway, network), with shared telemetry as the connective layer.

A real-world example grounded the conversation: Build a global security program for a 5,000-person organization across 40 countries on a $3 million budget, using a selective mix of MDR, PAM, EPM, and targeted point solutions only where necessary. Throughout, the operating principle was simple in that every security investment needs to answer one question: What risk does this reduce, and importantly, what business outcome does it protect?

People remain the most difficult element of SecOps

Technology and process can be engineered, but people? They’re much harder. That was one of the most practical observations from the session, and it resonated with every security leader in the room.

The challenge goes beyond hiring technical talent to ensure organizations are building teams with the right mix of communication skills, cognitive diversity, motivation, and endurance. A common gap seen in the SOC is that many teams are strong technically but few can articulate risk effectively to executives. That matters because the value of SecOps increasingly depends on how well teams connect activity to impact.

At the same time, burnout remains a structural issue. When experienced analysts leave, institutional knowledge leaves with them. And no tool can replace that. For leaders, this reinforces the point that people strategy is core to the overall security strategy.

AI in SecOps is getting very real, and very practical

After a long hype cycle, the AI conversation is now far more grounded. The most credible use cases in SecOps are about helping teams manage volume, reduce noise, and move faster with better context.

The examples discussed in the session were telling: alert-assisted triage, natural-language log querying, incident summarisation, first-draft executive communications, and eventually more automated investigation workflows. The framing that landed best was AI as a ‘sidearm partner’; a force multiplier for experienced practitioners, rather than a substitute for judgment.

That distinction matters as human judgment is essential. But AI is becoming increasingly valuable for understaffed teams trying to scale operations and preserve the institutional knowledge that walks out the door when analysts move on.

Governing agentic AI begins with foundations you should already have

As the discussion turned to agentic AI, the focus centred on how more autonomous AI systems do introduce new governance questions, but many of the relevant controls already exist within mature security programs. Segmentation, least privilege, access management, and strong architectural boundaries remain the core defenses.

One analogy stuck: Just as graphite rods slow a nuclear chain reaction, controls like network segmentation and access boundaries can contain and constrain agentic behavior. The organizations best positioned for AI governance are often the ones that have already invested in zero trust principles and sound identity controls.

That reframes the conversation. AI governance isn’t a separate discipline,  it’s the extension of existing security foundations into how AI systems behave, access data, and operate within defined boundaries.

What this means for the road ahead

If there was a unifying message, it was that the modern SecOps mandate is bigger than prevention. The industry has, to some extent, over-rotated on stopping threats and under-invested in resilience. 

Security leaders require programs that communicate risk in business terms, make smart technology trade-offs, support their people, and adopt AI in ways that are practical and governable. The organizations that get this right will be the ones building strong foundations and using the right mix of platform, process, and intelligence to move faster and more confidently. 
Rapid7 is committed to being a partner to organizations looking to gain that confidence. Our exposure-informed MDR service empowers teams to adopt a more preemptive security posture by rapidly identifying high-impact exposures that could be imminent breach targets. Teams can also leverage expanded capabilities in data security posture management (DSPM) and compliance to help fortify assessment, prioritization, and response capabilities so they can further preempt attacks across the modern attack surface.

On April 28, 2026, cPanel issued a security update to fix a critical vulnerability affecting the cPanel & WHM and WP Squared products. In the cPanel release notes, the bug was described as "an issue with session loading and saving." CVE-2026-41940, the identifier subsequently assigned on April 29, 2026, has a CVSS score of 9.8 and allows unauthenticated remote attackers to bypass authentication and gain unauthorized administrative access to the affected systems. First-party cPanel & WHM and WP Squared vendor advisories are available.

cPanel & WHM is web hosting control panel software used to manage websites and servers. WHM provides root-level administration, while cPanel acts as the user-facing interface. Successful exploitation of CVE-2026-41940 grants an attacker control over the cPanel host system, its configurations and databases, and websites it manages. A naive Shodan query for potential targets returns approximately 1.5 million cPanel instances exposed to the internet that may be vulnerable.

A managed cPanel host, KnownHost, stated that CVE-2026-41940 is actively being exploited in the wild, with speculation of targeted zero-day exploitation happening as early as February 23, 2026, prior to the vulnerability’s public disclosure. Security firm watchTowr has published a technical analysis and proof-of-concept exploit for CVE-2026-41940. As such, widespread exploitation in the wild is expected to be imminent.

Technical overview

Systems exposing the affected web service software are vulnerable by default.

As of April 29, 2026, a technical analysis and proof-of-concept exploit have been published by security firm watchTowr. CVE-2026-41940 is an authentication bypass caused by a Carriage Return Line Feed (CRLF) injection in the login and session loading processes of cPanel & WHM.

Before authentication occurs, `cpsrvd` (the cPanel service daemon) writes a new session file to the disk. The vulnerability allows an attacker to manipulate the `whostmgrsession` cookie by omitting an expected segment of the cookie value, avoiding the encryption process typically applied to an attacker-provided value. Attackers can inject raw `\r\n` characters via a malicious basic authorization header, and the system subsequently writes the session file without sanitizing the data. As a result, the attacker can insert arbitrary properties, such as `user=root`, into their session file. After triggering a reload of the session from the file, the attacker establishes administrator-level access for their token.

Mitigation guidance

Organizations running on-premise instances of cPanel & WHM or WP Squared should prioritize upgrading to a fixed version on an emergency basis. Some hosting providers have opted to temporarily institute workaround TCP port blocks for cPanel & WHM web services on ports 2083 and 2087. However, defenders are strongly advised to patch, rather than implement workarounds.

Affected Software:

The vendor states that all versions after 11.40 are affected, prior to the following available fixed versions.

• cPanel & WHM 11.86.0 versions prior to fixed version 11.86.0.41

• cPanel & WHM 11.110.0 versions prior to fixed version 11.110.0.97

• cPanel & WHM 11.118.0 versions prior to fixed version 11.118.0.63

• cPanel & WHM 11.126.0 versions prior to fixed version 11.126.0.54

• cPanel & WHM 11.130.0 versions prior to fixed version 11.130.0.19

• cPanel & WHM 11.132.0 versions prior to fixed version 11.132.0.29

• cPanel & WHM 11.134.0 versions prior to fixed version 11.134.0.20

• cPanel & WHM 11.136.0 versions prior to fixed version 11.136.0.5

• WP Squared versions prior to fixed version 136.1.7

Please read the vendor advisory for the latest guidance.

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-41940 with authenticated vulnerability checks available in the April 30, 2026 content release.

Updates

• April 29, 2026: Initial publication.
• April 30, 2026: Update mitigation guidance with additional fixed version numbers and change wording to reflect availability of vulnerability checks.

We start with the report, but quickly move into what’s already playing out in active campaigns. What stands out is not a change in attacker technique, but the pace. Weak credentials, missing MFA, exposed services, and unpatched systems still drive most intrusions. What has changed is how quickly those conditions are identified and exploited, and that shift is forcing security teams to rethink how they prioritize and respond.

The window to act is disappearing

One of the clearest themes in the conversation is timing. The issue is no longer how many vulnerabilities exist, but how quickly they are being used. The gap between disclosure and exploitation has narrowed to a matter of days in many cases, which removes the buffer teams used to rely on.

At the same time, most intrusions still begin with familiar conditions. Identity and access remain consistent weaknesses, with missing MFA and exposed remote access continuing to provide reliable entry points. What has changed is how those weaknesses are used. Access is now packaged and sold through a broader ecosystem, which increases both the speed and scale of attacks.

Access, persistence, and trusted systems

We also look at how attacker behaviour is evolving beyond initial access. In some environments, the goal is no longer immediate disruption but long-term presence. That changes how teams should think about detection, because finding activity is only the starting point. Understanding how long access has existed and what has already happened becomes just as important.

At the same time, attacks are concentrating inside systems organizations rely on every day. Identity platforms, cloud environments, and collaboration tools are all becoming key targets. The challenge is that activity in these systems often looks legitimate, which makes it harder to distinguish between normal behaviour and something that requires investigation.

AI is accelerating what already works

AI is part of this shift, but not because it introduces entirely new attack paths. What it does is make existing techniques faster and easier to scale, particularly in areas like social engineering and reconnaissance. Attackers can generate and adapt campaigns quickly, while defenders are dealing with increasing volumes of data.

That creates a simple but important shift. Security teams are not falling behind because they lack tools, but because the timing of attacks has changed and their processes have not kept up. The focus now is on understanding exposure earlier, prioritizing what matters, and preparing actions in advance.

Watch the full episode below to hear Christiaan’s perspective on how these trends are evolving and what they mean for security leaders heading into 2026.

⠀

At this year’s Rapid7 Global Cybersecurity Summit, Persistence Under Pressure explores that shift directly. Former Special Forces operator Jason Fox draws on real-world experience where timing, clarity, and execution all have immediate consequences, and shows how that mindset applies to modern security operations.

In our keynote talk Persistence Under Pressure, former Special Forces operator Jason Fox brings experience from environments where timing, clarity, and execution all have immediate consequences. His session looks at how that mindset translates into modern security operations, where teams are expected to act quickly, often without complete information.

The parallels are clear: Incidents do not unfold in controlled conditions. Signals compete for attention, priorities shift, and decisions need to be made in real time. What matters in those moments is not just having the right tools, but knowing how to stay focused and act with confidence.

This session explores practical ideas that apply directly to security teams, from how preparation shapes response to how understanding the adversary influences decision-making, and why composure and clarity can make the difference when pressure builds.

It also reinforces a broader theme running throughout the summit. Preemptive security operations are not only about detecting threats earlier but about enabling better decisions across the entire lifecycle, from preparation through to response and recovery.

If you are looking to understand how security operations are evolving, this session offers a different but valuable perspective. One that connects strategy and technology back to the people responsible for making it work.

Join us May 12–13 and hear how these principles apply in practice. Register now.

I write this as a Field CISO at Rapid7, but also as someone who has had to live with the operational reality of MDR on the customer side. I have seen what happens when a service is a black box, when technology and service drift apart, and when cost, retention, and accountability are misaligned. That experience shapes the view in this piece: MDR selection is not just about buying monitoring in isolation, but about choosing a partner that can help your team reduce risk and improve the way security operates over time.

When organisations evaluate MDR, they often start in the wrong place. The discussion begins with integration counts, dashboards, pricing tables, and increasingly bold claims about AI or dramatic reductions in alert volume. Those things all matter to a degree, but they are not the centre of the decision. The real question is whether you are choosing a provider that will work as a genuine partner, help you reduce risk over time, and strengthen the way your team operates when the environment becomes noisy, complex, or difficult to manage.

That matters because MDR is not a service that sits neatly off to one side of the security function. It becomes part of the operating model. It influences how visibility is created, how incidents are handled, how priorities are surfaced, and how much confidence a leadership team has in the people and processes around it. For that reason, I do not think MDR selection is primarily a tooling exercise. It is a partnership decision.

What poor MDR looks like in practice

My own view on this has been shaped by more than one experience. In one case, our MSSP was part of a defence company that was later carved out into a separate business. The service was built around a legacy SIEM. They had plenty of interest elsewhere in automation and future-state capability, but the fundamentals were being missed. We could talk about what we wanted to automate, but not with enough confidence about the quality of the underlying visibility, the operational process around it, or how the service was supposed to mature over time.

In another case, the issue was an MSSP overlay wrapped around a well-known, high-cost log indexer. On paper, that should have been a strong foundation. In practice, the management layer around it was poor. There was a lack of expertise, no credible roadmap, and very little meaningful tuning. As the MSSP was also reselling the ingest, there was no obvious incentive to optimize data use in the customer’s favour. Ingest was capped because of cost, retention was limited to 90 days, and we were left with the uncomfortable combination of high spend, constrained visibility, and a service that did not appear to be improving in any meaningful way.

Those experiences shaped how I think about MDR because they exposed the same underlying problem. The technology was not absent, but the service model around it was weak. When the gap between the platform and the service becomes too wide, the customer ends up paying for capability in theory while carrying the operational risk in practice.

Why the gap between platform and service matters

This is where many MDR relationships start to fail. Even when the tooling is capable, the provider still has to connect platform, people, process, and commercial model into one coherent service. If that does not happen, the customer ends up living with support issues, awkward hand-offs, misaligned contracts, unclear accountability, and a constant sense that there are too many moving parts and not enough ownership.

That is why I would start any MDR evaluation by looking at how the relationship is meant to work in practice. 

• Does the provider genuinely own the experience end to end, or are they effectively brokering one element through another?

• Can they show how the programme will improve over the first year, not just how onboarding works in the first month?

• Do they understand the rest of your security ecosystem and how to operate within it, or do they assume every answer involves expanding their footprint?

Strong providers think holistically. They understand that the customer already has an environment to manage, existing tools to work with, and internal teams who need clarity rather than additional friction. They think in terms of operating model, monitoring, response, and continuous improvement over time, rather than treating the service as a thin wrapper around a platform. That is usually where the difference between coverage and real partnership becomes obvious.

Proactive defense starts with the fundamentals

True partnership is defined by its ability to deliver proactive defense and continuous improvement. By this, I do not just mean threat hunting or faster triage. I mean exposure reduction in the broader sense. It is understanding attack paths, using intelligence well, tuning detections properly, improving visibility where it matters, and building a service rhythm that reduces the conditions attackers rely on.

That sounds obvious, but it is surprisingly easy for organisations to be distracted from those fundamentals. Low entry prices often mask a fundamentally constrained operating model, shifting risk and cost back to the customer. 

Sweeping promises about single digit alert volumes should be treated carefully, especially before a provider has properly understood the environment. The same is true of broad agentic AI claims. Automation can absolutely help, but it does not replace accountability, operational judgement, or the need for a provider to show how the service will improve over time.

For me, that last point is one of the clearest tests of whether the relationship is working. An MDR service should not be something you set and forget. A mature partnership should look better in month twelve than it did in month one. Visibility should improve. Tuning should improve. The roadmap should improve. Confidence in escalation and response should improve. If none of that is happening, it becomes very difficult to describe the relationship as a real partnership. At that point, you may simply have outsourced a queue.

When displacement becomes the right answer

That is also how I think about displacement. An incumbent should not be displaced simply because another provider has a sharper demo or a more fashionable story. Displacement makes sense when the existing model has stopped improving, when the service feels static or opaque, when the team lacks the expertise to tune and evolve it properly, or when the commercial structure and delivery model are working against the customer rather than with them.

If the relationship is held together by workarounds, if there is no meaningful roadmap, or if the customer is left carrying too much of the integration and governance burden themselves, the problem is usually structural rather than temporary. In that situation, the question is no longer whether the service can be tweaked around the edges. The question is whether the model is fit for purpose at all.

Consolidation is only useful if it improves the model

That does not automatically mean consolidation is the answer. Consolidation can be valuable, but only when it improves the operating model rather than simply reducing the number of logos in the environment. In some cases, the right answer will be to build a broader relationship with a provider that has earned trust and shown it can deliver more. In others, the right answer will be better integration and a clearer division of responsibilities.

What matters is whether the provider helps create a more coherent, scalable, and accountable way of operating. If consolidation leads to better hand-offs, stronger accountability, and a simpler way of reducing risk, it can be very valuable. If it does not, then consolidation is not the point. A better operating model is.

This broader view is also consistent with established security guidance. NIST CSF 2.0 frames cybersecurity as a risk management discipline across governance, protection, detection, response, and recovery [1]. NIST’s latest incident response guidance reinforces that response should be integrated into wider risk management and improved over time [2]. The NCSC makes a similar point in its guidance on building a SOC and on security monitoring, where tools, skills, and operating model all need to work together [3]. CISA’s exposure reduction guidance points in the same direction by focusing on reducing the conditions attackers rely on before incidents escalate [4].

Questions worth asking any MDR provider

There are a few practical questions I would encourage any CISO, Security Director, or Security Operations Manager to ask, whether they are reviewing an incumbent or evaluating a new provider:

• How will the service improve over the first year and beyond?

• Where do the hand-offs happen between your platform, your analysts, and my team?

• How do you work with the security and IT tools we already rely on?

• How predictable is the commercial model as coverage expands?

• What are you doing to reduce risk before the next incident, not just respond after it?

• If your commercial model benefits from more ingest, what incentive do you have to tune it down?

Those questions reveal far more than a polished demo ever will.

Ultimately, the organisations that get the most value from MDR tend to be the ones that treat it as part of a wider security partnership rather than a neatly outsourced function. They expect transparency, progress, and a provider that understands both the environment they have today and the operating model they are trying to build over time. That is the standard worth holding. If the provider is not improving the programme over time, you do not have a real partnership. And if consolidation does not lead to a better operating model, it is probably not worth doing in the first place.

Learn more about Rapid7's approach to preemptive MDR.

⠀

Alan Simpson is Field CISO for the UK and Ireland at Rapid7, advising CISOs and senior leaders on cyber risk, resilience, and security strategy that supports business outcomes. Before joining Rapid7, he served as Global Security Operations Manager and Acting CISO at Keyloop, where he led security operations and wider information security initiatives. He has also held senior security leadership roles at Allianz and LV=, with experience across security operations, incident response, architecture, awareness, supplier assurance, and security testing.

⠀

[1] https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf

[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf

[3] https://www.ncsc.gov.uk/collection/building-a-security-operations-centre

[4] https://www.cisa.gov/resources-tools/resources/exposure-reduction

Metasploit has supported check methods for many years now. It’s not always desirable to jump straight into exploiting a vulnerability but instead to determine if the target is vulnerable. Metasploit tries to be very conservative with classifying a target as “vulnerable” unless the vulnerability is leveraged as part of the check method, reserving the “appears” status for version checks. The different check codes a module is capable of returning and the logic to select among them varies from exploit to exploit and is not always the easiest to understand. Aligning with the consistent feedback that Metasploit has received that module actions should be more transparent, adfoster-r7 has been adding reasoning information en masse to the check codes returned by a variety of exploits. This information will help users understand why a particular vulnerability status was determined, making troubleshooting efforts easier and increasing confidence in the results.

Legacy SMB Improvements

This week, community member g0tm1lk made multiple improvements for legacy and non-Windows SMB targets. Version information is now more reliably extracted from targets running SMB 1, and a variety of minor bugs were fixed across multiple modules that would have affected users targeting systems the module was not intended to target as is often the case when the module is used to scan an entire network.

New module content (4)

Camaleon CMS Directory Traversal CVE-2024-46987

Authors: Goultarde, Peter Stockli, and bootstrapbool

Type: Auxiliary

Pull request: #21122 contributed by bootstrapbool

Path: gather/camaleon_download_private_file

AttackerKB reference: CVE-2024-46987

Description: This adds an auxiliary module to exploit an arbitrary file vulnerability, CVE-2024-46987, on Camaleon CMS >= 2.8.0 as well as 2.9.0.

Langflow RCE

Authors: Takahiro Yokoyama and weblover12

Type: Exploit

Pull request: #21260 contributed by Takahiro-Yoko

Path: multi/http/langflow_rce_cve_2026_27966

AttackerKB reference: CVE-2026-27966

Description: Adds exploit module for CVE-2026-27966, a prompt injection RCE vulnerability in Langflow < 1.8.0. By creating and sending a specially-crafted flow containing python code, the LangChain will execute that code because LangChain's Read-Eval-Print Loop (REPL) is exposed by default and runs any Python code it is given.

WebDAV PHP Upload

Authors: g0tmi1k and theLightCosine theLightCosine@metasploit.com

Type: Exploit

Pull request: #21256 contributed by g0tmi1k

Path: multi/http/webdav_upload_php

AttackerKB reference: CVE-2012-10062

Description: Updates code and adds features: Linux support, check() method, and cleanup after exploit.

Linux Chmod

Author: bcoles bcoles@gmail.com

Type: Payload (Single)

Pull request: #21238 contributed by bcoles

Path: linux/loongarch64/chmod

Description: Adds a new linux/loongarch64/chmod payload to change the permissions of a specified file.

Enhancements and features (11)

• #21019 from g0tmi1k - This adds support for phpMyAdmin v3.1.x to the phpMyAdmin Config File Code Injection module (CVE-2009-1285). This also adds a check method.
• #21230 from bcoles - Reduces the memory footprint of the module metadata cache in Metasploit.
• #21231 from bcoles - Improves the performance of the module metadata cache as well as bug fixes.
• #21232 from bcoles - Add a method to discover writable directories on Unix targets using the find command.
• #21256 from g0tmi1k - Updates code and adds features: Linux support, check() method, and cleanup after exploit.
• #21347

Bugs fixed (4)

• #21327 from tair-m - Fixes a crash when loading HTTP modules.
• #21341 from g0tmi1k - This fixes multiple issues related to various SMB modules when targeting Samba.
• #21344 from adfoster-r7 - Fixes a bug when running the check method for scanner/http/elasticsearch_traversal against non-vulnerable targets.
• #21346 from adfoster-r7 - Fixes a false positive that was present in auxiliary/scanner/couchdb/couchdb_enum.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

• Pull Requests 6.4.128...6.4.129
• Full diff 6.4.128...6.4.129

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

That gap shows up in different ways. Threats move across identity and cloud in ways that are difficult to track, exposure data exists but often sits disconnected from response, and AI is being introduced into workflows without a clear role in decision-making.

This year’s Rapid7 Global Cybersecurity Summit brings those threads together as part of the same operational solution.

1. You need a clearer view of how attacks actually unfold

A lot of detection strategies still assume attacks follow a clean path. In practice, they do not. They start in one place, move quickly, and often rely on small gaps rather than obvious failures.

Sessions like The Reality of Running a SOC in 2026 break this down in detail, looking at how attacks begin with things like identity misuse or cloud misconfiguration, then evolve as defenders try to keep up. That matters because it changes how detection should be designed. Coverage alone is not enough if teams do not have the context created by strong exposure management to interpret what they are seeing.

That same idea carries into Inside the Modern SOC, where a real investigation is followed from first alert to outcome. It is a useful reminder that detection is only part of the problem.Deciding how to respond, and doing it quickly, is the critical next step.

2. Exposure only matters if it connects to action

Most teams already have some form of exposure management in place. The challenge is making it useful. A long list of vulnerabilities does not help much if it is not tied to how risk actually shows up in the environment.

Sessions like Beyond the Vulnerability List and From Cloud Exposure to Runtime Attack focus on that connection. They look at how exposures turn into active threats, often before any alert is triggered, and how teams can use that information to prioritize earlier.

Here’s the part people miss. Exposure is not just about knowing what is wrong. It is about understanding what matters now, based on how the environment is being used and how attackers are likely to move through it.

3. AI is only useful if it improves decisions

AI is already part of most security conversations, but the reality is nuanced. In some cases it helps reduce noise and speed up investigations. In others, it creates new questions around trust and transparency.

The AI Dilemma: Automating Defense Without Surrendering Judgment tackles this directly. It looks at where AI is helping in real SOC workflows, where it can get in the way, and why explainability matters if teams are going to rely on it. The discussion is grounded in how analysts actually work, not just what the technology promises.

There is also a broader point here. Attackers are using AI as well, which means the balance between speed and accuracy is becoming more important on both sides.

Join the conversation

Across these sessions, the common doesn’t stem from any single technology. It is how teams connect signals, context, and decisions in a way that holds up under pressure, which shows up in how threats are understood, how exposure is prioritized, and how AI is applied. It is also why the summit is structured the way it is, moving from shared context on day one into more focused, role-based sessions on day two.

More sessions and speakers will be added in the coming weeks, but the direction is already clear. Security operations are shifting toward earlier decisions, better prioritization, and fewer assumptions.

If your work touches AI, threat detection, or exposure management, this is where those conversations start to come together.

Join us May 12–13 and see how teams are approaching it in practice.

Register now.

The headlines around Glasswing have focused on how quickly AI can surface vulnerabilities, which has naturally caught the attention of security leaders. In my conversations with teams and customers, the more useful discussion has been about what that speed means in practice for business protection, especially across open source risk, dependency choices, and software supply chain resilience. The deeper issue for security leaders sits elsewhere. 

Software risk is becoming harder to manage across the full lifecycle, especially in open source dependencies, build pipelines, developer environments, and the operational processes that sit between disclosure and remediation. When vulnerabilities can be found faster and at greater depth, security teams need more than another source of findings. They need a stronger way to understand what they run, what they trust, what they can patch quickly, and where a single weak dependency can create disproportionate risk.

Faster discovery makes software supply chain resilience a more immediate leadership issue. CISOs need a clearer view of how dependencies are chosen, monitored, validated, and governed across production, build, and developer environments, especially as open source remains essential to modern software development.

Organizations already struggle to absorb vulnerability disclosures at the pace they are coming in, because when discovery gets faster, the operational gap widens between knowing there is a problem and being able to do something useful about it. That gap is especially serious in the software supply chain, where a single dependency can introduce risk into build systems, production workloads, developer endpoints, and the tools used to secure them.

This is why I would frame AI-driven vulnerability discovery risk as a lifecycle challenge. The pressure does not sit in one place, but across inventory, dependency decisions, threat intelligence, patching discipline, and validation – with people, process, and visibility shaping how well an organization can respond. Technology matters, but it cannot compensate for a weak operating model underneath it.

Open source still matters. Dependency choices matter more.

Open source remains essential to modern software development because it helps teams move faster and get products to market without rebuilding common functionality from scratch. The better response is to be more deliberate about where and how third-party code enters the environment. 

Open source has always involved a trade-off between speed, efficiency, flexibility, and inherited risk, and that trade-off becomes harder to manage as AI makes code review deeper and faster. More flaws and supply chain compromises will likely be found in packages that teams have trusted for years, including transitive dependencies most developers did not knowingly choose. One only needs to look back a few weeks to find that the widely used Axios package suffered a supply chain compromise that bundled a Remote Access Trojan (RAT) charged with stealing secrets. That raises the value of understanding which dependencies are essential, which ones can be removed, which ones pull in large chains of transitives, and which ones are maintained by too few people to inspire confidence.

That work starts with a more disciplined question than “Is there a package that does this?” It starts with “Do we need this dependency, and do we understand the risk that comes with it?” The safest dependency is often the one that never enters the environment in the first place.

Why inventory has to go deeper than package lists

Supply chain resilience begins with knowing what you are actually running, which sounds straightforward until a critical disclosure lands in a package no one realized was in the environment three layers deep. Dependency graphs are deeper than most teams think, and transitive risk is where a lot of operational pain begins. A package chosen directly by a developer may bring in dozens of additional packages, each with its own maintainers, release cadence, security posture, and potential failure points.

A mature approach to inventory needs to move beyond a static package list, because CISOs need confidence in three views at once: What is declared in source, what is resolved and built, and what is actually running in production? Those views often drift apart over time, which means a package can be patched in source and still remain unpatched in a deployed container or runtime environment. An SBOM on its own will not close that gap; continuous, usable inventory will.

That inventory also needs clear ownership attached to it, because the moment a critical dependency is identified, someone has to decide what happens next, coordinate the change, and absorb the operational consequences. Security teams cannot do that well if responsibility is unclear, which is why ownership needs to be treated as part of resilience rather than an administrative detail.

Build pipelines and developer environments deserve the same scrutiny as production

Supply chain conversations still tend to start with production systems, even though recent incidents have shown how quickly compromise can move through the build layer, developer tooling, or the security tooling inside the pipeline itself. Those environments hold code, secrets, and trust relationships that attackers know how to exploit, while developer workstations often carry a rich mix of credentials and elevated privileges because speed matters to the business. Build systems are predictable and privileged, which makes them both valuable and vulnerable, but also easier to monitor.

Seeing those layers as part of the same attack surface means asking harder questions about how code enters the build, how package updates are governed, how actions and dependencies are pinned, what secrets exist in CI/CD, and what controls are in place on developer endpoints to detect anomalous behavior or stop high-risk package activity before it goes unnoticed.

You can gauge the maturity of the operating model with the answers to a few basic questions:

• How tightly are dependencies controlled in CI?

• How are package lifecycle scripts governed?

• What secrets exist in CI/CD, and what protections surround them?

• What visibility exists into anomalous behavior on developer endpoints?

• How would the team detect or prevent high-risk package activity before it spreads?

If those answers are unclear, important parts of the model are still missing.

Why prioritization matters more as scanning accelerates

When software risk rises, the instinct is often to add another scanner because more visibility feels like progress. What matters more over time, though, is how well teams can prioritize the findings that follow, assign them to the right owner, choose the right mitigation, and prove that exposure actually went down. Broader scanning and faster discovery mostly add to the pile unless the operating model behind them is strong enough to turn findings into action. Feed more issues into a process that is already stretched and the backlog grows, priorities become harder to sort, and remediation slows in the places where speed matters most. The organizations that come through this period well will be the ones that treat supply chain resilience as a systems problem, with stronger intake, clearer governance, better intelligence, and faster paths from alert to action.

What stronger software supply chain resilience looks like in practice

A stronger response starts with a deeper inventory of dependencies across source, build, and runtime, so teams can see both direct and transitive packages and connect them back to real environments and real owners. Once that picture is in place, intelligence monitoring becomes far more useful when it runs continuously against credible signals on vulnerabilities, package risk, maintainer health, end-of-life software, and unusual changes in dependency behavior.

The same level of care needs to carry through into dependency governance, where better decisions depend on asking whether a new package is necessary, how much transitive risk it introduces, whether its maintenance model is healthy, and what policy governs its path into production. Build and developer controls belong in that same conversation, because version pinning, private registries, secret handling, script restrictions, immutable builds, ephemeral runners, and stronger endpoint monitoring all reduce the attack surface around the software supply chain.

Monitoring threat intelligence for notifications about new vulnerabilities and compromised packages and having a well defined and practiced process for scoping and remediating emerging threats becomes critical. Your supply chain vulnerability and compromise response should be practiced – just like your incident response plan – through table top exercises and simulated threat events. You don’t want to wait until the house is on fire to know how to execute an effective response.

Similarly, Engineering, DevOps, and Security teams should collaborate on establishing a trust and reputation scoring mechanism for supply chain dependencies. Being able to evaluate the speed of response, transparency of communication and updates, and ultimate resolution of the vulnerability or compromise speak volumes for how much you can trust the maintainers of the software you depend on. The OpenSSF Scorecard project offers a great place to start evaluating the open source packages you’re already using.

Organizations should also have a fallback plan for when obtaining a security patch is not available. Some options to consider include exploring other open source packages that perform similar functions, exploring other mitigations such as application firewalling, or even forking and contributing a security patch back to the community.

Validation closes the loop by showing whether the artifact came from where it was supposed to, whether the package has drifted in unexpected ways, and whether the mitigations applied are reducing live risk rather than simply documenting the process.

How CISOs should think about the next 12 months

The strain on security teams is only growing, and the potential for AI to relieve some of that pressure is understandably compelling, especially when boards, CEOs, and CFOs are asking how the organization plans to adopt it. That makes this a leadership question as much as a technology one. CISOs need a clear point of view on where AI can genuinely improve resilience, where it still introduces too much uncertainty, and how to explain those choices in business terms.

If software engineering teams are already adopting AI-assisted development, security teams should be part of that conversation early, especially around dependency management. I have seen teams begin connecting AI coding agents to vulnerability management workflows so those agents can interpret vulnerabilities found in the code base, assess reachability with more context, help plan remediation, and validate updates much faster than traditional handoffs usually allow. Used well, that can reduce drag across the workflow and help teams move faster on classes of issues that are currently slowing them down.

Getting there safely still depends on the foundation underneath it. A more resilient path starts with a clearer picture of the environment and a more complete inventory of dependencies across source, build, and runtime. From there, ownership needs to be explicit, threat and vulnerability intelligence needs to be embedded into how the organization prioritizes, and dependency sprawl needs to be reduced with more discipline around what actually enters production. The same mindset should carry through to the build layer and developer endpoints, where tighter controls and better visibility help reduce unnecessary exposure, while faster and more repeatable paths from disclosure to action make it easier for teams to respond before risk compounds.

That foundation will matter regardless of which AI model or platform becomes dominant six or twelve months from now. It will also matter if the next wave of AI makes backlog reduction, lower-tier remediation, or patch validation more practical. Organizations that know what they run and how they operate will be in a much better position to adopt those capabilities with intent.

The shift security leaders should make now

Security in an AI-accelerated world needs to be managed as a systems challenge, with supply chain resilience shaped by how well organizations connect software composition, exposure visibility, dependency governance, threat intelligence, build integrity, endpoint controls, remediation workflows, and validation. When those layers are treated separately, gaps open quickly; when they are tied together through a stronger operating model, teams are in a much better position to absorb faster discovery without losing control of the response.

For CISOs, that means continuing to use open source with a more deliberate view of dependency risk, reducing unnecessary packages where possible, knowing what is running and who owns it, and monitoring threat and vulnerability intelligence with enough discipline to act before the queue overwhelms the team. It also means paying closer attention to the attack surface across production, build, and developer environments, while treating AI as something that will amplify both the strengths and the weaknesses already present in the program. Faster discovery is here, and the organizations that handle it best will be the ones that can respond with the same level of discipline.

For executive leadership, the emergence of Kyber ransomware represents a significant and immediate threat due to its specialized, dual-platform deployment capability targeting mission-critical virtualization infrastructure (VMware ESXi) and core Windows file systems. This cross-platform approach, coupled with effective anti-recovery measures, drastically elevates the risk of a total operational disruption. Organizations should treat Kyber not merely as another ransomware strain, but as a specialized tool capable of causing a complete operational blackout. Recent real-world incidents have demonstrated that this approach can result in large-scale operational impact across enterprise environments.

During a March 2026 incident response engagement, Rapid7 recovered two Kyber ransomware payloads deployed in the same environment, one targeting VMware ESXi infrastructure and the other Windows file servers. This provided a rare opportunity to analyze both variants side by side. In March 2026, Rapid7 recorded over 900 ransomware incidents being publicly reported.

The ESXi variant is specifically built for VMware environments, with capabilities for datastore encryption, optional virtual machine termination, and defacement of management interfaces. The Windows variant, written in Rust, includes a self-described “experimental” feature for targeting Hyper-V.

Despite these differences, both samples share a campaign identifier and Tor-based ransom infrastructure, confirming coordinated cross-platform deployment. Notably, the ransomware’s cryptographic claims are not consistent across variants. The ESXi sample advertises “post-quantum” encryption using Kyber1024, but in practice relies on ChaCha8 with RSA-4096 key wrapping, while the Windows variant does implement the advertised hybrid scheme. As usual, ransom notes prove to be more aspirational than accurate.

Kyber is a relatively new ransomware group that has recently gained visibility. Despite this, public technical analysis of the malware remains limited. The lack of spotlight on the group presented an opportunity to share our findings with the community.

Technical analysis

Kyber is a cross-platform ransomware family targeting Linux/ESXi and Windows environments. Both variants share Tor infrastructure and a campaign ID, but differ in programming language they are written, crypto, and features. While both reference the same encryption scheme in their ransom notes, only the Windows variant appears to implement it as described.

⠀

In addition, both variants share a common campaign ID and Tor-based infrastructure, including a negotiation portal and leak site, indicating coordinated operations across platforms.

Campaign ID: 5176[REDACTED]

Tor chat: Mlnmlnnrdhcaddwll4zqvfd2vyqsgtgj473gjoehwna2v4sizdukheyd[.]onion

Tor blog: Kyblogtz6k3jtxnjjvluee5ec4g3zcnvyvbgsnq5thumphmqidkt7xid[.]onion

Chat path: /chat/5176[REDACTED]

Linux/ESXi variant

The Linux/ESXi variant SHA-256: 6ccacb7567b6c0bd2ca8e68ff59d5ef21e8f47fc1af70d4d88a421f1fc5280fc is a 64-bit ELF executable, not stripped, written in C++ and statically linked against OpenSSL 1.0.1e-fips.

The sample was developed to target ESXi environments. As shown in Figure 2, the help text for the required path argument explicitly references the datastore path /vmfs/volumes, the root directory in VMware ESXi hosts where VMFS (Virtual Machine File System) datastores are mounted. The malware also relies on ESXi-native tooling esxcli and targets VMware-specific paths and artifacts.

⠀

The execution flow is straightforward:

1. Parse CLI arguments (path required, size validated 0–100)

2. Initialize logging (optional)

3. Optionally enumerate and terminate VMs (vmkill)

4. Load embedded RSA-4096 public key

5. Initialize thread pool (capped at 12 threads)

6. Traverse directories and submit encryption jobs

Background execution

To ensure encryption continues after an SSH session ends, the malware implements a detach flag. When enabled, it forks and exits the parent process, allowing the child to run in the background. The child then calls setsid() to detach from the controlling terminal, avoiding the SIGHUP signal typically sent when a session closes.

This allows the attacker to disconnect safely while encryption of /vmfs/volumes datastores continues uninterrupted in the background.

Targeting VMware

If the vmkill flag is set, the binary enumerates all running VMs before starting encryption. It forks a child process that executes the ESXi-native management command esxcli vm process list, redirecting its output to a temporary file via dup2(). The output is then parsed line by line to extract Display Name and World ID pairs.

If a whitelist is provided via the whitelist argument, matching VMs are skipped. All other VMs are terminated sequentially using esxcli vm process kill type=soft world-id <id>, with the parent process waiting for each shutdown to complete before proceeding.

Two implementation choices stand out here. First, the ransomware uses fork/execlp rather than system(). By calling fork() and then execlp() directly, ransomware developers bypass the shell entirely. This means the arguments are passed as a null-terminated array of strings (argv) directly to the execve system call. If a VM name contained a space or a special character, a system() call might crash or behave unexpectedly, but execlp ensures the command is executed exactly as intended. This suggests the developer is familiar with low-level system programming.

Second, the use of type=soft requests a graceful shutdown rather than a forced termination. This likely reduces the risk of corrupting VM disk state prior to encryption. After issuing shutdown commands, the binary sleeps briefly for about ~2 seconds before continuing, allowing ESXi to complete the operation. 

Directory traversal

The malware performs a recursive directory walk to identify targets. Interestingly enough, it drops a readme.txt ransom note into every folder before the encryption routine begins. The traversal logic does not follow symbolic links, as traversing them can lead to unexpected areas of the filesystem. The sample does not implement an extension allowlist. Files are encrypted unless explicitly excluded.

The binary explicitly ignores files with the following extensions or names:

.xhsyw (already encrypted)
.locksignal, .processing, .cryptdata_backup
.tmp, readme.txt
.sf (VMware System Files)

Figure 2: Confirmed exclusion list from protecting in-progress files, already-encrypted files, and VMware system files from double-processing.

⠀

Encryption: marketing vs reality

The ransom note claims that for encryption it uses AES-256-CTR, X25519 and Kyber1024 algorithms. 

⠀

Our technical analysis, however, says otherwise. Decompilation of the core encryption logic shows the cipher is actually ChaCha8. Two indicators support this conclusion. First, in the ECRYPT_encrypt_bytes subroutine (Figure 5) the loop executes 8 rounds (i = 8; i > 0; i -= 2), and the code applies 32-bit right rotations with constants 16, 20, 24, and 25. These correspond to the standard ChaCha left-rotation constants (16, 12, 8, and 7) defined in RFC 8439.

⠀

⠀

Second, the ECRYPT_keysetup function (Figure 6) uses the "expand 32-byte k" sigma constant. For 256-bit keys, the malware initializes its state by placing this constant in words 0–3 and the key in words 4–11 — mirroring the standard ChaCha layout.

⠀

⠀

OpenSSL is statically linked but only handles RSA-4096 key wrapping. We did not find any “post-quantum”. The operator likely just copy-pasted the ransom note from a Windows variant that actually supports Kyber1024.

Partial encryption strategy

Partial encryption logic is size-based encryptFilePartly() function.

• Files under 1MB: entire file encrypted

• Files between 1MB and 4MB: first 1MB encrypted

• Files above 4 MB: only a calculated portion of each file is encrypted, with the proportion controlled by size; the program validates this value as 0–100 in main(), and the default observed setting is 10.

• This approach significantly reduces encryption time while still rendering large files (e.g., VMDKs) unusable.

Encryption workflow

Each file is encrypted with a unique ChaCha8 key. Before encrypting the file, the binary creates a .locksignal file and renames the original to .processing to prevent concurrency. It then checks the last 535 bytes for a metadata trailer containing the markers KYBER, CDTA, and ATDC. If these are present, the file is skipped as already encrypted.

For new targets, the malware generates a 40-byte key/IV set and wraps it using an embedded RSA-4096 public key. This metadata is appended to the file and verified before encryption begins. A redundant copy is also saved as <file>.cryptdata_backup. Encryption is performed in-place in 1 MB chunks. On success, the file is renamed from .processing to .xhsyw. Any files left with the .processing suffix indicate an interrupted or failed encryption attempt.

Defacing every entry point

Even before encryption, ransomware binary replaces three specific files:

• SSH Access replaces /etc/motd (Message of the Day), displaying the ransom note immediately to anyone logging in via SSH.

• Web Management replaces the VMware web UI index pages at both /usr/lib/vmware/hostd/docroot/index.html and the Host Client interface at /usr/lib/vmware/hostd/docroot/ui/index.html.

Whether an administrator logs in via SSH or hits the web management portal, they are immediately met with the ransom note. On non-ESXi systems where these paths don't exist, the rename fails gracefully and execution continues.

⠀

Windows variant

The Windows sample SHA-256: 45bff0df2c408b3f589aed984cc331b617021ecbea57171dac719b5f545f5e8d is a 64-bit PE executable written in Rust and compiled with MSVC (VS2022). Much like the ESXi variant, the Windows binary as well is not packed, obfuscated, or even stripped. It retains full Rust panic strings and cargo dependency paths, including the build path C:\Users\user\.cargo\registry\src\index.crates.io-6f17d22bba15001f.

Additionally, the binary’s version flag reveals the project name as win_encryptor 1.0.

⠀

The Windows binary exposes a minimal CLI (Figure 8), requiring the path argument to specify the target directory. It also includes system flag which is self-described as "experimental" and intended to enforce a hard-stop on Hyper-V virtual machines.

Ransomware initializes full runtime initialization, even if invoked with just help flag. It aggregates entropy from four sources: system time, Windows CSPRNG, processor-based entropy via RDRAND, and running process data and producing ~30 KB of randomness to seed an internal AES-CTR DRBG. Unlike typical ransomware, which often relies only on BCryptGenRandom, this strain implements a custom entropy pipeline which suggests the developer cared about key material quality.

After initialization, the binary checks whether it is running with elevated privileges by attempting to acquire SeDebugPrivilege and logs are printed to the console (see Figure 8).

This privilege check determines if the destructive commands will be executed. Without elevation, the binary only does file encryption. With elevation, it unlocks its full toolkit: killing services, modifying the registry, and wiping shadow copies to prevent recovery.

Service termination and anti-recovery

When running with elevated privileges the binary first terminates services matching five patterns: msexchange, vss, backup, veeam, and sql using OpenSCManagerA, EnumServicesStatusA, and ControlService API calls. The malware forces the system locale to en-US before service enumeration. This normalization makes certain that pattern matching for service names remains reliable regardless of the victim's native system language.

It then executes 11 commands via CreateProcessW that you can see in the table below

Table 2: 11 commands executed by ransomware if it ran with elevated privilege

Hyper-V shutdown

If system flag is set, the binary enumerates Hyper-V virtual machines via PowerShell before encryption:

Get-VM | select VMId, Name | ConvertTo-Json
Stop-VM -Force -TurnOff

Figure 8: PowerShell commands used for Hyper-V termination.

Each VM is terminated with a "hard stop" (-TurnOff) which forces an abrupt shutdown, releasing file locks so the malware can encrypt. As noted in the CLI help text, the developer currently considers this Hyper-V functionality "experimental."

File encryption workflow

For each file, the binary checks for a prior encryption marker to avoid redundant processing. If the file is locked, the malware uses the Windows Restart Manager to identify and terminate the responsible process. If access is still denied, it modifies the file’s permissions (ACL) to Everyone:FullControl and clears the read-only attribute. It retries this entire sequence up to three times per file to ensure it can successfully open and encrypt the data.

Once encryption succeeds, the file is renamed with the .#~~~ extension, and a READ_ME_NOW.txt ransom note is dropped in the directory. Each successful operation is logged to the console as Successfully encrypted <file>. File size: <size>. To maintain system stability and to keep the OS bootable, the malware excludes critical system directories and files from encryption listed below:

$recycle.bin,perflog,system volume information,thumb,programdata,appdata,microsoft,netframework,c$, all users

Figure 9: Skipped directories

READ_ME_NOW.txt,lockerlog_*,processed_file.icon,ntuser.dat,ntuser.dat.log,ntuser.ini,desktop.ini,autorun.inf,ntldr,bootsect.bak,thumbs.db,boot.ini,iconcache.db,bootfont.bin

Figure 10: Skipped files

Cryptography

Unlike the Linux variant, this sample actually uses what it claims: Kyber1024 and AES-256-CTR.

The sample uses a hybrid encryption design. The embedded public key is validated against the expected Kyber1024 public key size of 1568 (0x620) bytes.

⠀

Following validation, the sample initializes an AES-256 CTR context using a 32-byte key, which it expands into a 60-word key schedule.

This confirms that Kyber is not used for direct file encryption. Instead, Kyber1024 protects the symmetric key material, while AES-CTR handles bulk data encryption. 

Registry artifacts and icon registration

When executed with elevated privileges, the malware assigns a custom icon to encrypted files by registering the .#~~~ extension. It creates C:\fucked_icon\ directory, writes processed_file.icon to that location, and configures it in the registry as the default icon.

⠀

The malware executes ie4uinit.exe to refresh the shell icon cache. This forces Windows to display the new icons immediately across the filesystem without a system restart.

Mutex

The choice of the mutex is interesting. The mutex name boomplay[.]com/songs/182988982 is stored as a wide string in .rdata and appears to be a link to a song on Boomplay, which is a legitimate African music streaming platform. We were unable to identify the specific track due to geo-restrictions we could not bypass.

Mitigation guidance

Based on the observed Tactics, Techniques, and Procedures (TTPs), organizations should focus on the following defensive actions:

Harden virtualization infrastructure (T1021.004)

Kyber’s reliance on SSH for ESXi host access and native tooling like esxcli highlights critical control points.

• Implement least-privilege access for ESXi shell and SSH, ideally disabling them entirely unless required for maintenance.

• Enforce multi-factor authentication (MFA) on all management interfaces and accounts.

• Monitor esxcli execution for VM termination (vm process kill) or configuration changes, which are late-stage indicators of compromise.

Prevent anti-recovery (T1485, T1070.001, T1562.001)

Kyber uses 11 distinct commands to impair defenses, including VSS deletion and log clearing.

• Restrict execution: Prevent unprivileged users from executing command-line utilities like vssadmin.exe, wmic.exe, and wevtutil.exe.

• Protect backups: Ensure backups (especially Veeam/SQL targets) are immutable and stored off-host or in segregated network segments that the Windows variant cannot reach, even with elevated privileges. The ransomware explicitly targets these services and file systems.

Detection focus (lateral movement & defacement):

• Monitor for defacement artifacts: Actively monitor for changes to VMware's management files (/etc/motd, /usr/lib/vmware/hostd/docroot/index.html, etc.) in ESXi environments.

• Custom entropy check: The Windows variant’s custom entropy pipeline suggests an effort to ensure key quality. Analysts should incorporate the provided IOCs (mutex: boomplay[.]com/songs/182988982) and file extensions into their detection rules.

MITRE ATT&CK techniques

Indicators of compromise (IOCs)

Conclusion

Kyber ransomware isn’t a masterpiece of complex code, but it is highly effective at causing destruction. It reflects a shift toward specialization over sophistication. The operators didn’t need custom exploits or zero-days, because they didn’t have to use them. Instead, they simply used the standard ransomware playbook of abusing native tools like esxcli and vssadmin, and it was enough.

The encryption claims in the ransom note aren’t the main story. If anything, they highlight a gap between the campaign's marketing and its execution. The sophistication of the defense must now be measured against the attacker's specialization, not their code complexity. Ignoring Kyber's multi-platform nature is an acceptance of a total operational blackout.

They want to ask better questions, move faster, and bring security context into the workflows they are already building. That’s especially true as more organizations experiment with private AI assistants, internal copilots, and LLM-powered automation. Part of this experimentation is, of course, attempting to lower the pressure on teams that have to figure out how to prioritize the sheer number of actionable vulnerabilities efforts like Project Glasswing are quickly becoming hyper-skilled at spotting.     

That’s why Rapid7 is introducing a free, open-source MCP Server and Agent Skill for Bulk Export. Bulk export is a highly efficient way to access all your Rapid7 data; no more paging APIs, no more verbose output. Bulk Export creates a local offline replica of your data the LLM can efficiently and quickly interrogate, reducing token cost and time to answer questions.

This new MCP and Agent Skill gives customers a standardized way to connect Rapid7 vulnerability and exposure data to AI assistants and custom AI workflows. Built as an open-source bridge, it helps customers bring their Rapid7 data into the tools and experiences that work best for their teams.

Why this matters now

Security teams are no longer just buying tools. They’re connecting systems, shaping workflows, and testing how AI can help analysts, IT teams, and leaders get to answers faster. For many teams, the path from raw security data to usable AI context is still manual. It often means exporting data, building wrappers, shaping queries, and managing custom integrations.

Rather than leave every team to solve that challenge from scratch, we wanted to provide a stronger foundation that is flexible, practical, and easy to extend over time. With projects like Metasploit and Velociraptor, Rapid7 is committed to Open Source, and by sharing with the broader community we hope to accelerate velocity and ensure we’re able to incorporate more use cases and fixes. These processes also give customers full visibility of the code running and tools used, ensuring data privacy and allowing the user to do with their data what they please.  

What MCP does

Model Context Protocol, or MCP, is an emerging standard for helping AI systems interact with external data and tools in a structured way.

In practical terms, it gives AI assistants a cleaner way to ask questions, retrieve data, and work with systems beyond the model itself. For customers, that means less custom glue code and a more consistent way to use security telemetry in AI-driven workflows.

That matters because many security reporting and analysis workflows still assume a high technical bar. Answering a simple question can require custom queries, SQL knowledge, or dashboard work. But the people who need those answers aren’t always security specialists. They may be IT partners, compliance stakeholders, or executives who want clarity but might not need to understand the underlying query logic.

The MCP server helps lower that barrier: Instead of starting with raw exports and working backward, teams can start with the question they need answered.

The bigger picture: MCP and CTEM

This approach also aligns with the broader shift toward continuous threat exposure management, or CTEM. 

CTEM is about helping teams move beyond point-in-time findings toward a more continuous, contextual understanding of risk. That requires security data that can be accessed, connected, and used across the workflows teams rely on. 

Bulk Export helps make that possible by giving customers more flexibility in how they use Rapid7 data. The open-source MCP server makes it easier to bring that data into AI-assisted and custom workflows.

⠀

That can support more continuous exposure management workflows by making it easier for teams to triage vulnerability and exposure data. For example, an analyst facing a large queue of new vulnerabilities could use LLM assistance to quickly narrow in on the findings most likely to need attention first. Instead of manually working through exports and queries, they could ask natural-language questions to surface the exposures tied to critical assets, unresolved remediation work, or other signals available in the data.

From data portability to AI-ready interoperability

Bulk Export was already an important step toward giving customers more control over their data. It made it easier to extract and use security telemetry in external tools and analytics environments.

The open-source MCP server builds on that foundation: Instead of using exported data only for dashboards or custom reporting, customers can now use that same data in AI-native experiences. That includes internal assistants, private copilots, workflow automation, and natural-language exploration of vulnerability and exposure data. This makes existing security data easier to use in the environments customers are already investing in.

How it works

At a high level, the architecture is straightforward. Using the Agent Skill, your LLM runs the MCP server locally and automatically prepares the environment by performing the bulk export and loading the data into a local file store. The Agent Skill provides the schemas and knowledge, with the MCP providing the tools to access this data. The LLM then will answer any question by querying, summarizing, and synthesising data locally – an extremely fast and simple process that's for the LLM. 

Depending on the data a customer exports, answers can include vulnerability records, asset data, remediated vulnerabilities, and policy-related results.

The point here isn't just that a model can access the data, it’s that an open-source layer helps customers inspect, adapt, and extend over time, empowering teams to control how that connection works in their own environment. 

What customers can do with it

This opens the door to practical use cases, including:

• Using LLM assistance to triage vulnerability data faster 

• Asking natural-language questions to spot exposure and remediation trends

• Investigating which assets are tied to the most urgent vulnerabilities

• Understanding what changed over time without manual analysis

• Exploring policy failures without building manual queries

• Feeding Rapid7 telemetry into private AI assistants and internal workflows

• Making reporting more accessible for non-technical stakeholders

⠀

For teams already trying to operationalize AI, this creates a lower-friction path. Instead of building every integration from the ground up, they can start with a reusable bridge and focus on the workflows they want to enable.

A better path from data to action

Security data only creates value when teams can use it. For many organizations, turning raw telemetry into timely answers is still harder than it should be. Analysts need speed. Leaders need clarity. Builders need flexibility. And more customers want security data that works inside the tools and workflows they already rely on.

The open-source MCP server for Bulk Export is designed to help make that possible.

Bulk Export helps customers take control of their data. This is the next step: helping them put that data to work in AI-ready security workflows.

Ready to explore it for yourself? Visit the Rapid7 Bulk Export MCP Server project on GitHub to learn more and get started.

 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.

We’re happy to announce that Metasploit Framework had a big week, landing seven new modules alongside various bug fixes and enhancements. This week’s highlights include RCE modules targeting AVideo, openDCIM, Selenium Grid/Selenoid, and ChurchCRM. On the post-exploitation side, Windows saw three new persistence techniques added as modules, targeting Telemetry scheduled tasks, PowerShell profiles, and Microsoft BITS.

What a time to be alive as a Metasploit user! We wish you all a wonderful weekend and happy hacking.

New module content (7)

AVideo Unauthenticated SQL Injection Credential Dump

Authors: Valentin Lobstein chocapikk@leakix.net and arkmarta

Type: Auxiliary

Pull request: #21075 contributed by Chocapikk

Path: gather/avideo_catname_sqli

AttackerKB reference: CVE-2026-28501

Description: Adds an auxiliary module for CVE-2026-28501, an unauthenticated SQL injection in AVideo <= 22.0, along with a new BenchmarkBasedBlind SQLi mixin class and blind extraction improvements.

openDCIM install.php SQL Injection to RCE

Author: Valentin Lobstein chocapikk@leakix.net

Type: Exploit

Pull request: #21034 contributed by Chocapikk

Path: linux/http/opendcim_install_sqli_rce

AttackerKB reference: CVE-2026-28517

Description: This PR adds a new exploit module for openDCIM that chains three vulnerabilities (https://github.com/advisories/GHSA-mg2w-x76x-59h8, https://github.com/advisories/GHSA-prmh-rp39-qc4m, https://github.com/advisories/GHSA-428h-8xhf-g3cw) to achieve remote code execution.

Selenium Grid/Selenoid Unauthenticated RCE

Authors: Jon Stratton, Takahiro Yokoyama, Valentin Lobstein chocapikk@leakix.net, and Wiz Research

Type: Exploit

Pull request: #21003 contributed by Chocapikk

Path: linux/http/selenium_greed_rce

Description: This replaces the two separate Selenium Grid RCE modules (Chrome and Firefox) with a single unified module that auto-detects available browsers and selects the best attack vector. The module targets unauthenticated Selenium Grid and Selenoid instances, supporting two techniques: a Firefox profile handler injection that works on all Grid versions including the latest (never patched since 2021), and a Chrome binary override for Grid versions prior to 4.11.0 and all Selenoid versions. No authentication is required.

ChurchCRM Database Restore RCE 6.2.0

Author: LucasCsmt

Type: Exploit

Pull request: #21095 contributed by LucasCsmt

Path: multi/http/churchcrm_db_restore_rce

AttackerKB reference: CVE-2025-68109

Description: Adds a new exploit module for CVE-2025-68109, targeting a file upload vulnerability inside ChurchCRM leading to an RCE. This module will work on version 6.2.0 of ChurchCRM and earlier.

Windows Persistence Bits Job

Author: h00die

Type: Exploit

Pull request: #20839 contributed by h00die

Path: windows/persistence/bits

Description: This adds a new persistence module that uses Microsoft Bits to maintain access to the system.

Powershell Profile Persistence

Author: madefourit

Type: Exploit

Pull request: #20933 contributed by madefourit

Path: windows/persistence/powershell_profile

Description: This adds a new persistence module that uses powershell profiles to maintain access.

Windows Telemetry Persistence

Author: h00die

Type: Exploit

Pull request: #20843 contributed by h00die

Path: windows/persistence/telemetry

Description: Adds a new persistence module, exploit/windows/persistence/telemetry, that abuses the Windows Telemetry scheduled task (Microsoft Compatibility Appraiser / CompatTelRunner) to establish persistence. The module writes a payload to disk and configures the telemetry task to execute it, resulting in a SYSTEM-level Meterpreter session either on the next scheduled run or immediately on demand. Requires an admin-level Meterpreter session on the target.

Enhancements and features (11)

• #21078 from Chocapikk - Adds multiple improvements to the multi/http/churchcrm_install_unauth_rce module.
• #21085 from dledda-r7 - This refactors the Block API code used by Windows payloads to leverage a new version of the hashing algorithm. This also fixes a bug whereby the MaximumLength field was used when calculating UNICODE_STRING names when it should have been the Length field.
• #21236 from bcoles - Add riscv64le and riscv32le architecture support to the fileless fetch payload adapter. This enables in-memory ELF execution via memfd_create on RISC-V Linux targets without writing to disk.
• #21252 from zeroSteiner - Adds a new with_adcs_certificate_request method that now used by both the MsIcpr and WebEnrollment mixins that abstracts away the enrollment process and takes a block that performs the actual request. The result is consolidation of messages, post-processing of the successfully issued certificate.
• #21255 from mxnvel - This updates two Python payloads (cmd/unix/reverse_python and cmd/unix/reverse_python_ssl) to make the PythonPath option optional. When omitted, it defaults to a shim that will determine the appropriate version of Python at runtime using a small bash expression.
• #21275 from adfoster-r7 - Adds multiple improvements to the cve_2025_14847_mongobleed module, such as adding new a dedicated check method, improved compression support detection as only zlib can be exploited, and resolving other false positives.
• #21286 from Hemang360 - Adds a cleanup keyword argument to Msf::Post::File#mkdir so callers can skip automatic directory cleanup registration. It is very useful for when we create directories in persistence modules and want the directory to remain.
• #21289 from sjanusz-r7 - Updates the db.hosts RPC call to now additionally include the comments associated with the host.
• #21291 from sjanusz-r7 - Updates the module.info RPC call to now additionally include the notes associated with the module.
• #21304 from adfoster-r7 - Improves multiple auxiliary module check code messages and statuses.

Bugs fixed (4)

• #21027 from SilentSobs - Fixes ELF shared object (elf-so) payload generation failing on 32-bit ARM Linux and RISC-V 32-bit LE targets. The _start entry point in the ARM LE template was landing at a non-word-aligned offset, which violates the architecture's 4-byte alignment requirement and caused the shared object to fail to load. The templates now use proper NASM align directives to ensure correct entry point alignment, and a similar fix is applied to the RISC-V 32-bit LE template.
• #21268 from adfoster-r7 - Fixes a crash with a small number of auxiliary modules when the check method was run and the vulnerability wasn't present.
• #21287 from zeroSteiner - Fixes the EXE templates that were rebuilt in https://github.com/rapid7/metasploit-framework/pull/20502 to work on legacy Windows targets like Server 2000 in case you find yourself in a combination hacking and time-travelling movie.
• #21309 from sfewer-r7 - Fixes a false positive in the fortinet_fortiweb_create_admin module when detecting the presence of an authentication bypass via path traversal vulnerability in the Fortinet FortiWeb management interface.

Documentation added (1)

• #20843 from h00die - Adds a new persistence module, exploit/windows/persistence/telemetry, that abuses the Windows Telemetry scheduled task (Microsoft Compatibility Appraiser / CompatTelRunner) to establish persistence. The module writes a payload to disk and configures the telemetry task to execute it, resulting in a SYSTEM-level Meterpreter session either on the next scheduled run or immediately on demand. Requires an admin-level Meterpreter session on the target.

You can always find more documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

• Pull Requests 6.4.126...6.4.128
• Full diff 6.4.126...6.4.128

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro

On March 30, 2026, a security advisory was published for a critical vulnerability affecting Nginx UI. Nginx UI is an open-source web interface to centralize the management of Nginx configurations and SSL certificates. The critical vulnerability, CVE-2026-33032, was reported in early March by Pluto Security researcher Yotam Perkal and subsequently patched on March 15, 2026. That same day, Pluto Security published a technical blog post with some vulnerability details.

CVE-2026-33032 is a missing authentication bug with a CVSS score of 9.8; as a result of missing authentication controls, an unauthenticated attacker who exploits CVE-2026-27944 to leak information can access a Model Context Protocol (MCP) server that can perform privileged operations on managed Nginx web servers. Systems are vulnerable in the default IP allowlist configuration, which allows any remote IP to access MCP functionality. Exploitation results in full attacker control of the managed Nginx service. 

According to a Recorded Future report published on April 13, 2026, exploitation of CVE-2026-33032 in the wild has begun. A PurpleOps report published on April 16, 2026 associated exploitation of CVE-2026-33032 in the wild with the information leak vulnerability CVE-2026-27944, indicating that these two vulnerabilities are being exploited as a chain.

Mitigation guidance

Organizations running Nginx UI should prioritize updating on an urgent basis to remediate CVE-2026-33032. Additionally, to reduce exposure to future vulnerabilities affecting Nginx UI, defenders should ensure that network access to the Nginx UI management interface is strictly limited to those who must have it.

Affected versions:

According to the finder’s blog post, version 2.3.3 and prior are affected, and the fix is present in version 2.3.4 and later. However the official CVE record states that versions 2.3.5 and below are affected. The information leak vulnerability being exploited in the wild with CVE-2026-33032, CVE-2026-27944, was patched in version 2.3.3. This discrepancy in affected version numbers introduces confusion as to the correct version required to remediate CVE-2026-33032. To avoid this version number discrepancy, users are advised to update to the very latest version (2.3.6).

Please read the vendor advisory for the latest guidance.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-33032 with unauthenticated checks available in the April 17 content release.

Updates

• April 16, 2026: Initial publication.

• April 17, 2026: Added additional details on exploitation workflow, vulnerable software versions, and product coverage.

It is no secret that phishing campaigns utilizing various ClickFix techniques have been a commonly used method of social engineering. One of the main reasons for this is simply because they work. You know this and Rapid7 does as well. As a company offering managed detection and response (MDR), our customers expect us to be knowledgeable about and able to detect attacks as common as ClickFix campaigns. 

Recently, Rapid7 observed a small grouping of ClickFix events across customers in the EU and US. At the time of discovery, this campaign had very little traction on sites like VirusTotal or within the online security landscape. This campaign was particularly interesting as it appeared to be masquerading as an installer for Claude, an AI tool that has received a considerable amount of attention. 

Using Rapid7 InsightIDR detection rules, our SOC analysts were able to detect and respond to the threat, preventing further compromise. This campaign demonstrates the strength Rapid7 customers get from our MDR service, while peeling back the curtain to provide a real-world example on how we operate behind the scenes. In this blog, we will detail a brief technical analysis of the observed threat actor activities and discuss how this serves as an example of the service we aim to provide our MDR customers. The analysis highlights both the multi-step delivery of the payload as well as the work Rapid7 performs when investigating threats.  

Observed attacker behavior

On April 9, Rapid7 was alerted to mshta executed on a customer asset using the Windows run utility. The alert was generated by the detection rule Attacker Technique - Remote Payload Execution via Run Utility (shell32.dll). This rule will generate an alert when a suspicious process, such as mshta, is added to the RunMRU registry key. This key is important for the detection of ClickFix campaigns, as it tracks the last 26 commands executed by the Windows run utility. One thing that stuck out about this particular mshta command is that the URL, download-version[.]1-5-8[.]com/claude.msixbundle, appeared to be impersonating an MSIX bundle for the popular AI tool, Claude. 

MSIX files are Windows app packages that one would typically see from the Microsoft store, definitely not something you would see being passed as an argument to mshta. While the host was quickly taken down before Rapid7 was able to obtain the claude.msixbundle payload, a copy was obtainable on VirusTotal. Looking at the payload, it does initially appear to be an MSIX bundle. The file header signature, PK, indicates that the file is a ZIP archive and contains a string reference to the MSIX bundle, MicrosoftBing_1.1.37.0_ARM64.msix:

⠀

⠀

Exploring the payload deeper, however, reveals an HTML Application (HTA) embedded within the ZIP archive:

⠀

The Visual Basic script within the HTA file contains a series of obfuscated strings that are deobfuscated with the following VBS function:

⠀

Additionally, one of the functions serves to generate an encoded PowerShell script that will serve as the next step in the chain:

⠀

After the deobfuscation routine is complete, these strings contain references to the required objects and function calls to craft and execute – via ShellExec – the following command:

c:\Windows\System32\cmd.exe” /v:on /c “set x=pow&&set y=ershell&&call %windir%\SysWOW64\WindowsPowershell\v1.0\!x!!y! -E [ENCODED COMMAND]

⠀

⠀

The encoded PowerShell acts as a staging payload. The script will first generate an MD5 hash value based on the COMPUTERNAME and USERNAME environment variables. It will then take the first 16 characters of the hash value and use it to craft a URL to pull another, much larger, PowerShell script. The script also contains a string deobfuscation routine that is responsible for crafting the following strings to be passed to various .NET functions:

• Assembly

• System.Mangement.Automation.AmsiUtils

• amsiContext

• NonPublic,Static

• 0x41414141

⠀

The script will then call the deobfuscation routine to craft a call to WriteInt32 in the .NET Marshal library to overwrite the amsiContext field in System.Management.Automation.AmsiUtils with the value 0x41414141. Once amsiContext is overwritten, the script will download and execute the next stage:

⠀

The URL is hosting yet another PowerShell script containing highly obfuscated strings and a large byte array. Upon execution of the script, the strings decode to contain the necessary .NET types and method calls to create and execute a PowerShell ScriptBlock. This ScriptBlock is derived from the byte array, which is first base64 decoded and then run through a deobfuscation routine:

⠀

This ScriptBlock again contains another series of obfuscated strings and a large byte array containing yet another PowerShell ScriptBlock. Following the execution of the script, the code once again creates and executes a PowerShell ScriptBlock:

⠀

This ScriptBlock culminates in a process injection routine using the .NET interoperability library. The code contains a byte array with encrypted shellcode that gets passed through a XOR routine. The script then obtains handles to the following Windows API calls:

• NtAllocateVirtualMemory

• Copy

• NtProtectVirtualMemory

• NtCreateThreadEx

• NtWaitForSingleObject

• NtFreeVirtualMemory

• NtClose

After obtaining the handles, the script crafts delegate functions for the Windows API calls and invokes the delegates to perform the process injection routine:

Importance to Rapid7’s MDR customers

Rapid7 MDR customers receive the security knowledge of our threat intelligence, detection engineering, incident response, and security operations center analysts. Input from all of these sources directly feeds into how we create detections and respond to alerts. Following is an explanation of how we use events like these to further provide and enhance our services for customers. 

As previously mentioned, ClickFix activity is not new. Detection engineers in the MDR service know this and build rules to address these techniques, such as the rule that caught the activity discussed in this blog.. Detection rules are created in response to activity observed in incident response, customer requests, activity observed from the SOC, threat intelligence, and observations of the security landscape. Rapid7’s detection engineers work with the SOC to monitor these rules for efficacy. Rules that are primarily used to detect initial compromise, such as the one that alerted on this campaign, are additionally monitored to identify any new campaigns. 

Once the campaign is identified, our detection engineers research it to create additional rules. They can also perform retroactive threat hunts across the Rapid7 customer base using IOCs or any new behavioral detections created from researching the campaign. Results from researching campaigns like this one then go on to feed threat intelligence and help inform our detection strategy. This campaign provides a great example of how Rapid7 works on the backend to detect and prevent threats in customer environments. 

Mitigation guidance

Monitor the following registry key to watch for potential ClickFix attacks such as the one observed in this case:

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

While Rapid7 MDR customers were covered by the managed SOC, Rapid7 recommends the following actions for containment:

If the activity is not expected, apply containment and review the user's browsing history for the source of the command. The initial lure is often presented to the user when they attempt to browse the internet for free downloads (media, software, etc.). In some cases the malicious command may have been copied to the user's clipboard when visiting the initial webpage, and can be viewed by inspecting the source code of the site. If the infection is successful, an information stealer is often executed as the final payload, meaning that any credentials stored on the infected system should be reset as part of restoration.

MITRE ATT&CK techniques

Indicators of compromise (IOCs)

Cloude.Msixbundle:

• 2b99ade9224add2ce86eb836dcf70040315f6dc95e772ea98f24a30cdf4fdb97

Domains observed by Rapid7:

• Oakenfjrod[.]ru

• download-version[.]1-5-8[.]com

• download[.]get-version[.]com

That is often where remediation gets harder. Security teams may know which actions matter most, but progress can slow when infrastructure, cloud, endpoint, and IT teams do not have the context needed to execute. Teams need clear asset detail to scope the work, trusted status signals to validate remediation, and usable reporting to track progress and stay aligned.

This is exactly the challenge Exposure Command is built to help solve. Exposure Command helps customers understand and prioritize the exposures that matter most, while Remediation Hub (a prioritized remediation view within Exposure Command) helps teams turn that prioritization into action. With new enhancements to Remediation Hub, customers can now do that with more context and confidence, along with better visibility into progress over time through exportable reports. 

Why remediation work slows down

Prioritization is an important step, but remediation rarely happens in one place or with one team. Security, infrastructure, cloud, endpoint, and IT operations all need enough context to understand what is being asked of them.

When that context is hard to access, progress slows. Security teams may know what should be fixed, but asset owners still need the information required to assess impact, plan the work, and take action. Teams also need to understand whether assets are actually protected, whether patching has fully taken effect, and how remediation progress should be tracked over time. Without that clarity, remediation becomes harder to coordinate and harder to validate.

Making remediation more actionable

The Top Remediations Report helps close that gap by adding a comprehensive asset-level breakdown for each remediation. In addition to summary remediation information, customers can see source-specific metadata such as operating system, IP address, cloud provider, tags, endpoint protection, and patch management.

It can be used as a high-level summary of remediation priorities; many security teams use it to define remediation goals and share clear, actionable guidance with teams that may not work directly in security tools.

That gives teams a clearer view of the work behind each remediation and makes it easier to move from prioritization to execution.

Customers can also tailor reports to match the way they work, with customizable filters for specific environments, tags, or ownership groups. Reports can be exported in CSV, HTML, and PDF formats, shared with the teams responsible for action, and automatically generated and emailed on a schedule.

Building clearer visibility into patching and endpoint coverage

Action is only part of the equation, since teams also need clear, trustworthy context around asset posture.

Remediation Hub now shows the source of patch management and endpoint protection coverage directly in remediation details, giving customers clearer visibility into where that data comes from and which tools are protecting a given asset. This is especially helpful in environments with multiple solutions in use, and reduces confusion when missing integrations would otherwise make assets appear unprotected.

The update also surfaces whether an asset still requires a reboot after patching, helping explain why vulnerabilities may persist even when remediation work has already started. Together, these additions make it easier for teams to assess true exposure, validate remediation progress, and identify where follow-up is still needed.

Extending remediation data into operational workflows

Remediation does not stop once a team has identified what to fix or validated that a change has been made. Security leaders also need ways to track progress, measure performance, and share remediation outcomes across the organization. That is where exported remediation data becomes important.

By extending access to remediation data outside the platform, customers can more easily support the workflows across reporting, operations, and leadership teams. This makes it easier to analyze remediation activity over time, align to internal reporting needs, and give stakeholders a clearer view of progress.

For security leaders, that means better visibility into whether remediation efforts are moving the organization in the right direction. For operational teams, it means less manual work to assemble and share updates, and more flexibility in how remediation data is used.

What this looks like in practice

For vulnerability management teams, this means faster handoff. Instead of sharing a remediation recommendation and then answering follow-up questions, they can send a report that already includes the asset context needed to begin planning.

For infrastructure and cloud teams, it becomes easier to focus on the parts of the environment they own. Filters help narrow remediation data to the assets, environments, and ownership groups that matter most, reducing noise and making action more straightforward.

For endpoint and patching teams, greater visibility into coverage source and reboot status helps explain why exposure may still remain, even when remediation work is already underway. That makes validation easier and helps teams troubleshoot more effectively.

For security and IT leaders, scheduled reporting and exported remediation data improve shared visibility. Rather than relying on one-off exports or manual updates, teams can more consistently track prioritized remediation work and measure progress over time.

Better context, faster progress

These enhancements help customers do more than identify top remediation priorities. They help teams act on them, validate them, and track them with more confidence.

By bringing together deeper asset context, clearer patch and endpoint visibility, and more usable remediation reporting, Remediation Hub helps reduce the friction that often slows remediation down. The result is smoother collaboration across functional teams, less manual effort, and quicker progress on the remediation work that matters most.

Read more about how Exposure Command helps teams share remediation context, improve coordination, and move faster on risk reduction.

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.

Microsoft lifecycle update

In Microsoft lifecycle news, extended support ends April 14, 2026 for a wide range of Microsoft product legacy enterprise tools, including Dynamics C5 2016, Dynamics NAV 2016, App-V 5.0 and App-V 5.1, UE-V 2.1, and BitLocker Administration and Monitoring 2.5 SP1. Microsoft .NET 9 STS (Standard Term Support, as distinct from Long Term Support) was originally scheduled to move past the end of support in May 2026, but late last year, Microsoft granted a six-month extension, so that .NET 9 STS now reaches end of support on November 10, 2026.

Summary charts

Summary tables

Azure vulnerabilities

Developer Tools vulnerabilities

ESU vulnerabilities

Microsoft Dynamics vulnerabilities

Microsoft Office vulnerabilities

Open Source Software vulnerabilities

SQL Server vulnerabilities

System Center vulnerabilities

Windows vulnerabilities

Zero-Day Vulnerabilities: Known Exploited

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

Critical RCEs and EoPs

Taking place May 12-13, the summit explores how detection and response are evolving across cloud, identity, and endpoint environments. The focus is practical: how attacks actually unfold, how teams respond under pressure, and how detection strategies need to adapt.

Detection is no longer just about coverage

One of the clearest themes across the agenda is that traditional detection models are struggling to keep pace with attackers. Environments are more dynamic, and attackers are more targeted. Catching everything is no longer realistic, and in many cases it is not useful.

Sessions like The New Rules of Detection Engineering will examine this shift in detail. The focus moves away from volume and toward precision. It will ask questions like: What makes a detection meaningful? How should teams prioritize signals? And how can detection strategies support real outcomes rather than just generate alerts? This is especially important in cloud environments, where context changes quickly and signals are often incomplete.

Understanding how attacks actually unfold

To improve detection, teams need to understand how attacks behave in practice. Several sessions across the summit focus on this directly.

The Reality of Running a SOC in 2026 will explore how modern attacks begin — from identity misuse to cloud misconfigurations— and how they evolve over time. Rather than following a predictable path, attacks move across systems, taking advantage of gaps in visibility and delayed decisions.

This theme continues in sessions like Inside the Modern SOC, where attendees follow a real investigation from first alert to outcome. These walkthroughs show how signals are correlated across environments and how decisions are made when time and clarity are limited.

From exposure to runtime risk

Cloud security also requires a closer connection between exposure and detection. In many cases, incidents begin long before an alert is triggered.

Sessions such as From Cloud Exposure to Runtime Attack explore how misconfigurations, permissions, and overlooked risks lead to active threats. The focus is on how teams connect exposure insights with runtime behavior to improve prioritization and respond earlier in the attack lifecycle.

This is a practical shift. Detection is no longer a separate function but part of a broader process that starts with understanding exposure and continues through to response.

What this means for security teams

Across these sessions, a consistent message emerges: Detection strategies need to be grounded in how environments actually behave, not how they are expected to behave.

This means focusing on signal quality rather than volume, connecting data across cloud, identity, and endpoint, and building workflows that support faster decisions. It also means accepting that not all alerts have equal weight, and that prioritization is a core part of modern detection.

A preview of what’s to come

Cloud detection is just one part of a broader shift happening across the summit. Sessions on MDR, AI, and exposure management all connect back to the same idea. Security operations must move earlier, reduce noise, and act with greater confidence.

If you are rethinking how your team detects and responds to threats in cloud and hybrid environments, this is where those conversations come together.

Join us May 12–13 and see how security teams are evolving their detection strategies for 2026.

Register now.

In practice, that means dozens of investigations per shift, each requiring fast judgment with incomplete context. A 2024 SANS survey shows that SOC teams report alert volume, limited context, and lack of automation continue to slow investigation and response [2].

Speed suffers. So does consistency.

Turn raw logs into a clear narrative

AI-Powered Log Summary in Rapid7 Incident Command transforms raw log data into a clear, concise narrative directly within the investigation workflow. Analysts see what happened, why it matters, and what to do next in seconds, not minutes.

Instead of decoding logs line by line, analysts get:

• Instant identification of who initiated the activity.

• Fast understanding of exactly which actions occurred.

• Clarity into when and where events unfolded.

• Connectivity into why that behavior matters.

Analysts stay grounded in the original data, but they no longer have to fight through it to find answers. The summary provides immediate orientation and focus, keeping their focus on what to do next.

Built for real SOC workflows

⠀

AI-Powered Log Summary is embedded directly into the log search workflow. No pivoting, and no context switching. With a single action, analysts generate a contextual summary tailored to their results in seconds. That means faster investigations without breaking flow.

Summaries can be shared with teammates or leadership to communicate findings quickly, without rewriting technical details into plain language. Everyone stays aligned on what happened and what comes next.

AI integration in action

Rapid7 leverages the best available technology to protect our customers' attack surfaces. Our mission drives us to keep abreast of the latest AI advancements to deliver optimal value to customers while effectively managing the inherent risks of the technology. Integrating AI into our core processes enhances our operational security and underscores our commitment to ethical innovation. 

At Rapid7, we are dedicated to leading responsibly in the AI space, ensuring that our technological advancements positively contribute to our customers, company, and society. Read more about how our TRiSM (Trust, Risk, and Security Management) is a foundational strategy that guides us in navigating the intricate landscape of AI with confidence and security.

Less noise, more impact

By reducing time spent parsing logs, teams can focus on what matters: containment, remediation, and proactive threat hunting.

⠀

This brings analysts:

• Faster triage and investigations.

• More consistent analysis across shifts.

• Lower cognitive load during high-volume periods.

• Clear communication to stakeholders.

Rapid7 is at the vanguard of integrating AI into its products to accelerate outcomes for our customers, with a particular focus on amplifying analyst impact and bringing speed and clarity to SOC operations throughout the threat detection and response lifecycle. 

That is how modern SOC teams move faster. Visit the Incident Command page for more information.

⠀

[1] Verizon 2025 DBIR

[2] SANS 2024 SOC Survey

This week, we have added new modules to Metasploit Framework targeting Cisco Catalyst SD-WAN controllers and osTicket as well as updates and improvements to Windows service-for-user persistence, and LDAP/ADCS-related modules to automatically report related services resulting in an improved data stream, which can be queried by using the services command.

We also landed an improvement to msfvenom’s bootup time, thanks to bcoles, resulting in an approximate two-times speedup.

New module content (4)

AD/CS Authenticated Web Enrollment Services Module

Authors: Spencer McIntyre, bwatters-r7, and jhicks-r7

Type: Auxiliary

Pull request: #20752 contributed by bwatters-r7

Path: admin/http/web_enrollment_cert

Description: This adds a new auxiliary/admin/http/web_enrollment_cert modules that allows certificates to be issued from an Active Directory Certificate Services Web Enrollment portal. Its usage is the same as the auxiliary/admin/http/icpr_cert module but enables operators to issue certificates when the web enrollment portal is accessible but the MS-ICPR service is not.

Cisco Catalyst SD-WAN Controller Authentication Bypass

Author: sfewer-r7

Type: Auxiliary

Pull request: #21158 contributed by sfewer-r7

Path: admin/networking/cisco_sdwan_auth_bypass

AttackerKB reference: CVE-2026-20127

Description: This adds an auxiliary module to exploit an authentication bypass vulnerability, CVE-2026-20127, affecting Cisco Catalyst SD-WAN Controller. Recently exploited in the wild as a zero-day.

osTicket Arbitrary File Read via PHP Filter Chains in mPDF

Authors: Arkaprabha Chakraborty <@t1nt1nsn0wy> and HORIZON3.ai Team

Type: Auxiliary

Pull request: #20948 contributed by ArkaprabhaChakraborty

Path: gather/osticket_arbitrary_file_read

AttackerKB reference: CVE-2026-22200

Description: This adds an auxiliary module to exploit, CVE-2026-22200, an authenticated file read vulnerability in osTicket.

Windows Service for User (S4U) Scheduled Task Persistence - Event Trigger

Authors: Brandon McCann "zeknox" bmccann@accuvant.com, Thomas McCarthy "smilingraccoon" smilingraccoon@gmail.com, and h00die

Type: Exploit

Pull request: #20814 contributed by h00die

Path: windows/persistence/service_for_user/event

Description: Updates the Windows service-for-user persistence technique.

Enhancements and features (7)

• #20814 from h00die - Updates the Windows service-for-user persistence technique.

• #20973 from bitstr3m-48 - This release enables command execution for non-interactive HWBridge sessions via the sessions -c flag. Additionally, the hwbridge/connect module now preserves parsed JSON error bodies from failed HTTP responses, which improves error messaging.
• #20977 from g0tmi1k - This updates the exploit/unix/webapp/php_eval module to have a FORMDATA datastore option, which adds HTTP POST-request support and makes the HEADERS datastore option consistent with other modules.
• #20979 from g0tmi1k - This updates the exploit/unix/webapp/php_include module with additional datastore options and make its usage more consistent with the similar exploit/unix/webapp/php_eval module.
• #21031 from zeroSteiner - Enhances the Metasploit’s LDAP/ADCS-related modules to automatically report related services (LDAP, DCERPC/ICertPassage/ADCS CA) and to improve vulnerability reporting by associating findings with the affected LDAP object’s DN (and, for ADCS template findings, the template name) so results are uniquely keyed and easier to interpret.
• #21143 from SaiSakthidar - This bumps the Metasploit payloads to include changes that enable the PHP Meterpreter to open TCP server sockets. This enables operators to listen for inbound connections on compromised hosts and closes a feature gap between PHP and the other Meterpreters.
• #21229 from bcoles - This updates the msfvenom utility to use the metadata cache. The result is roughly 2x faster execution times when listing modules

Bugs fixed (1)

• #21153 from Nayeraneru - This fixes an issue with some mutable constant datastore options. Using shared options like CHOST or CPORT are not changing visibility across modules anymore.

Documentation added (1)

• #21221 from cgranleese-r7 - This PR improves module_doc_template.md with examples to better guide contributors.

You can always find more documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

• Pull Requests 6.4.125...6.4.126
• Full diff 6.4.125...6.4.126

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest. To install fresh without using git, you can use the open-source-only Nightly Installers or the commercial edition Metasploit Pro