Business Email Compromise (BEC) operates on a familiar playbook. Threat actors breach a mailbox, silently monitor operations, map approval chains, and ultimately exploit that access to divert funds or exfiltrate sensitive assets.

This dynamic is central to our analysis as we kick off a series around Rapid7's collaborative research with Zimbra; upcoming installments will explore technical details and broader findings based within the Zimbra Collaboration Suite. Our investigation disrupted the traditional BEC model in unexpected ways. We uncovered over 50 vulnerabilities, and found that several allow attackers not just to observe environments, but to actively rewrite them by impersonating senders without credentials, controlling inbox visibility, and altering shared documents and calendars.

Business Email Compromise in action: Digital abuse of trust

None of this is theoretical for Zimbra. But don’t take my word for it, just ask Russia. CISA keeps putting Zimbra bugs into the Known Exploited Vulnerabilities catalog, and the last three years make the point on their own:

• CVE-2024-45519, command injection in the postjournal service, unauthenticated command execution. Proofpoint saw attackers stuffing base64 payloads into CC fields on September 28, 2024. CISA added it to KEV on October 3.

• CVE-2025-27915, stored XSS in the Classic Web Client, triggered by a crafted .ICS attachment. It is used as a zero-day against Brazilian military targets to steal mail and quietly set forwarding filters. It went into KEV in October, 2025.

• CVE-2026-73570, unauthenticated command injection through SNMP notification handling. CISA added it on August 21 of this year and gave federal agencies three days. Shadowserver has been counting somewhere north of 260 compromised instances while hunting for exploitation artifacts.

Go back further and the pattern holds. Rapid7 tracked widespread exploitation of CVE-2022-27925 and CVE-2022-37042 in 2022, a path traversal chained with an authentication bypass that let attackers drop a JSP shell on a Zimbra server without credentials. Google's Threat Analysis Group later documented four separate threat groups working the same zero-day known as CVE-2023-37580. Each of these groups went after email, credentials, and authentication tokens. Attackers figured out a long time ago that the system sitting in the middle of everyone's communication is worth the effort. So when you find a set of bugs that let you write to that system instead of only reading from it, data theft stops being the interesting part.

Send an email as your CFO without ever touching their password, and you have the front half of a very convincing BEC. Keep control of the mailbox afterward and you have the back half, too. Here, the attacker has a strategic choice. They can delete the sent message to hide their tracks, effectively wiping the trail of the fraud OR they can choose to leave the message in the Sent Items folder. By doing so, they ensure the CFO sees 'evidence' of the email they supposedly sent, creating a gaslighting scenario where the victim is left questioning their own actions. Whether the attacker cleans up or leaves the trail, they are shaping the organization’s perception of reality. In the ensuing investigation, where Finance sees a sent request and the CFO sees no such activity, the organization is trapped in a conflict of evidence. At that point, BEC looks less like traditional fraud and more like a psychological operation.

Documents make it worse, as Zimbra is not just a mail server. The collaboration side holds the files employees actually use to make decisions. An attacker who can plant a fake HR memo or financial summary in an executive's enterprise drive, and make it look like it came from a peer they trust, is starting from a much better position than someone attaching a PDF to a cold email.

Say a document shows up from HR about a confidential restructuring, and a few days later an email from a trusted executive references it. Neither piece has to carry the whole deception, as each one props up the other.

Calendar warfare and manufactured enterprise reality

Then there is the thing I have started calling ‘calendar warfare.’ Meetings can be modified or deleted without generating the notification trail users expect to see. RSVP status can also be flipped. Maybe a key executive is changed from Accepted to Declined and leadership might reschedule, or move ahead without them, or read the whole thing as a deliberate opt-out.

It works in the other direction too. An "Emergency Board Meeting" lands on an executive's calendar with a believable organizer, a popup reminder, and a malicious Zoom link. When the reminder fires, the victim is not sizing up a suspicious email that arrived thirty seconds ago. They are joining a meeting that has been sitting in their calendar for two days. And the calendar is not some exotic attack surface nobody has thought of. If we look back at CVE-2025-27915, the delivery vehicle was a calendar invite.

Stack all of it together now – a financial document appears, a trusted executive emails about it, then a mandatory meeting shows up to discuss it. And the attacker still has the ability to clean up some of what gets left behind. Every artifact the victim checks lives inside a system they have no reason to question, and all of them tell the same fabricated story.

I keep coming back to the phrase 'manufactured enterprise reality'. I have touched on the idea in The Monday Brief, that attackers get to borrow whatever trust an organization has already extended to its own tooling. Zimbra makes it concrete. The platform supplies the credibility, so the attacker does not have to build any.

Collaboration suites quietly became systems of record. Email is the record of who said what. Calendars are the record of who agreed to be where. Classic BEC abuses the trust between two people. The scenario we’ve discussed here abuses the machinery those people use to decide who to trust in the first place. Once employees are making real business decisions off fabricated context, stealing data is the least of your problems.

Security teams already have long queues of potential application vulnerabilities. The useful question is what happens next: can they see how a weakness behaves in a running application, reproduce the attack, and give developers enough evidence to fix it?

Dynamic application security testing (DAST) helps answer those questions by testing applications as an attacker encounters them. The IDC MarketScape: Worldwide Dynamic Application Security Testing 2026 Vendor Assessment (Doc #US54119126, September 2026). The IDC MarketScape evaluated 16 vendors and named Rapid7 a Leader.

We believe the result reflects the strength of Rapid7’s DAST capabilities, but the IDC MarketScape also offers a useful view of where the category is heading. DAST has developed beyond traditional web scanning into a source of runtime evidence that can help organizations validate risk across the application layer.

From possible weakness to validated application risk

Code analysis and dependency scanning help teams identify weaknesses before an application is deployed. DAST provides a different view by interacting with the assembled application while it is running. It can show what happens when a particular request reaches the application, how the application responds, and whether a suspected weakness can be reproduced.

This is especially valuable for APIs and AI-backed applications, where risk may emerge through interactions among models, prompts, data, tools, and permissions. Some of these behaviors cannot be fully understood from source code or a dependency manifest. They become visible when the application is exercised under runtime conditions.

DAST therefore has a direct role in continuous threat exposure management (CTEM). Discovery gives teams a view of their assets and possible weaknesses, but that view alone does not tell them where to focus. Validation helps narrow the field by showing which exposures can be reached or exploited and providing evidence that teams can use to take action.

For Rapid7, DAST is exposure management applied to the application layer. Web applications, APIs, and AI-backed endpoints are all part of the attack surface, so they need to be discovered, tested, prioritized, and managed alongside infrastructure, cloud, and other exposures.

Why we believe Rapid7 was named a Leader by IDC

Rapid7’s DAST solution is delivered as part of the Exposure Command portfolio. Its scan engine maps an application, executes attacks against the discovered paths, and validates confirmed findings. Security teams can map a broad area of an application while limiting active attacks to an appropriate set of paths, giving them control over how testing is performed.

Findings are checked against Rapid7 telemetry to help determine which issues warrant closer attention. When a finding needs action, browser-based replay reproduces the original request, the attack request, and the triggering response. Developers receive evidence they can work with, rather than a finding they must first spend time proving.

Authenticated scanning can be difficult to maintain across a changing application portfolio, and a broken login sequence can leave important areas untested. Rapid7’s solution can identify the affected step and support a targeted update without requiring the entire sequence to be recorded again.

The connection with Surface Command adds another useful layer. Newly discovered external assets can be surfaced for application testing, helping teams close the gap between finding an application and understanding the risk it presents

DAST plays a core role within Exposure Command: providing the application-layer validation teams need to prioritize risk and move from findings to remediation.

Learn more about Rapid7 Exposure Command.

Overview

On September 22, 2026, F5 published a security advisory for CVE-2026-94127, a critical heap-based buffer overflow vulnerability affecting F5 BIG-IP Access Policy Manager (APM). The vulnerability has a CVSS v3.1 score of 9.8. An unauthenticated attacker with network access to an affected virtual server may be able to achieve remote code execution (RCE) by sending specifically crafted traffic.

BIG-IP APM provides identity-aware access control for applications and other corporate resources and can integrate with authentication technologies including OAuth, OpenID Connect, and SAML. CVE-2026-94127 is not exposed in a default configuration: exploitation requires a BIG-IP virtual server with both an APM access policy and an OAuth profile configured. Because affected BIG-IP systems may process traffic at an organization's network edge, organizations using this configuration should prioritize remediation.

The vulnerability affects the data plane and does not expose the BIG-IP control plane. BIG-IP systems operating in Appliance mode are also affected.

F5 lists the following affected release trains and corresponding fixed hotfixes:

• BIG-IP 21.1.0: versions prior to Hotfix-BIGIP-21.1.0.2.0.30.22-ENG

• BIG-IP 17.5.0: versions prior to Hotfix-BIGIP-17.5.1.9.0.160.12-ENG

• BIG-IP 17.1.0: versions prior to Hotfix-BIGIP-17.1.3.5.0.41.14-ENG

As of September 22, 2026, CVE-2026-94127 has been added to the CISA KEV while a publicly available proof of concept was not confirmed.

Mitigation guidance

Organizations running affected F5 BIG-IP deployments should apply the appropriate F5 hotfix as soon as operationally feasible, particularly where a vulnerable APM and OAuth configuration is reachable from untrusted networks.

F5 lists the following remediation versions:

• BIG-IP 21.1.0: update to Hotfix-BIGIP-21.1.0.2.0.30.22-ENG or later.

• BIG-IP 17.5.0: update to Hotfix-BIGIP-17.5.1.9.0.160.12-ENG or later.

• BIG-IP 17.1.0: update to Hotfix-BIGIP-17.1.3.5.0.41.14-ENG or later.

Administrators should first determine whether a BIG-IP APM access policy and an OAuth profile are configured together on a virtual server, since this configuration is required for exposure.

For organizations that cannot immediately apply the applicable update, F5 provides an iRule workaround through F5 Support. Customers should open a support case with F5 to obtain the vendor-provided workaround and follow F5's implementation guidance.

Rapid7 customers

Exposure Command, Vulnerability Management, and Nexpose

Exposure Command, Vulnerability Management, Nexpose customers can assess exposure to CVE-2026-94127 using vulnerability checks expected to be available in today’s (September 23) content release.

Updates

• September 22, 2026: Initial publication.

Overview

On September 14, 2026, Cisco published a security advisory for CVE-2026-76461, a critical SQL injection vulnerability affecting Cisco AsyncOS Software for Cisco Secure Email Gateway. The vulnerability has a reported CVSS v3.1 base score of 9.8 and could allow an unauthenticated, remote attacker to execute arbitrary commands with root privileges on an affected appliance.

Cisco Secure Email Gateway, formerly known as IronPort Email Security Appliance, is an enterprise email security product that inspects inbound and outbound email for threats including phishing, malware, spam, and business email compromise. Because affected gateways process externally delivered email as part of their normal operation, exploitation does not require access to an administrative interface or authentication. An attacker can reportedly trigger the vulnerability by sending a specially crafted email through a vulnerable gateway.

CVE-2026-76461 was added to CISA's Known Exploited Vulnerabilities (KEV) catalog on the same day as the vendor disclosed the vulnerability, indicating that CVE-2026-76461 was exploited as a zero-day prior to disclosure. Cisco noted that their PSIRT became aware of active exploitation in September 2026. At the time of publication, there is no public proof-of-concept exploit code available, and no attribution for the current threat actor activity.

Mitigation guidance

Organizations running Cisco Secure Email Gateway should prioritize upgrading to a vendor-supplied fixed version on an emergency basis, outside of normal patching cycles.

Given the reported active exploitation and the ability to achieve unauthenticated root-level command execution through malicious email processing, organizations should prioritize patching rather than relying solely on network controls or monitoring. Cisco also strongly recommends that customers migrate to the latest product version, 16.5.0-780.

For the latest remediation guidance, see the vendor advisory.

Indicators of compromise

The following indicators of compromise for CVE-2026-76461 were reported within the Cisco security advisory.

To confirm any attempted exploitation of this vulnerability, review the mail_logs and look for suspicious SQL statements. If the device is part of a cluster, review the logs of each cluster device. The following is a non-exhaustive example of how a malicious SQL statement could be detected in the logs:

cisco-esa> grep -i "COPY.*TO PROGRAM" [IronPort Text Mail Logs Log name - Default: mail_logs]

The presence of any entry in the output may indicate malicious activity.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-76461 with a vulnerability check expected to be available in the September 16 content release.

Updates

• September 15, 2026: Initial publication.

The managed detection and response (MDR) market has reached a turning point. We’ve gone beyond the baseline of 24/7 monitoring focusing on the speed of detection and moved to a world with a convergence of exposure management and response to deliver measurable, outcome-based defenses of a larger, AI-driven attack surface.

For anyone evaluating MDR right now, the Managed Detection and Response Services Landscape, Q3 2026 report by Forrester is a useful map that lays out where the market is heading. This is a market that has moved beyond "do you cover my telemetry?" to “Can a provider connect and prove that its activity is tied to real reduction in risk?”. 

Rapid7 was named among the notable providers in this Forrester MDR Landscape. Being included matters to us, but the more interesting story is in what Forrester says about the market itself.

Detection and exposure are becoming one service

One of the report's clearest signals is directional: Forrester writes that "MDR services will converge with exposure and posture improvement.”

That convergence is the whole basis of Rapid7 MDR and our Command Platform strategy. Most MDR services react after an attacker has already broken in. Rapid7 designed its service to anticipate where attackers are likely to succeed and disrupt them earlier. We combine exposure context, detection, and response into a single operational loop, where vulnerability findings and asset risk scoring flow directly into alerts and investigations. This means analysts can cut noise and focus response on the exposures most likely to cause business impact. It's what we mean by exposure-informed, Preemptive MDR: The same context that tells you where you're weak is the context that sharpens how you detect and respond.

For buyers, the practical implication is that old procurement habits are changing. Buyers used to invest in detection from one vendor, exposure management from another, and then hope the two solutions would seamlessly talk to each other. That approach is now turning into a liability.

The market will reward providers that connect these additions to measurable risk reduction rather than bolting on loosely joined SKUs. That's a bar customers should hold every provider to, including Rapid7.

"Make providers prove the investigation, rather than narrate the dashboard"

The second theme is about accountability. In its guidance on working with providers, Forrester is blunt: Buyers should "make providers prove the investigation, rather than narrate the dashboard." A slick activity feed is not evidence that anyone reached the right conclusion. Buyers should ask to see the reasoning behind a disposition, the actions taken, and the controls that keep automation from making unsafe decisions.

This is a healthy pressure on the whole market, and it's a test we welcome. Rapid7 MDR is delivered on Rapid7's own SIEM, which gives customers a direct window into our SOC, including validated threats, the response actions taken, where AI accelerated the work, and where a human analyst stepped in and why. Every action is logged, explainable, and auditable. As agentic AI takes on more of the investigation workload, that transparency becomes the difference between a service you trust and a black box you hope is working. Our approach is deliberately human-led and AI-enhanced: AI scales triage and investigation across large volumes of telemetry, while analysts stay responsible for validation and response decisions.

Accountability also shows up in commercial terms. Rapid7 MDR includes unlimited incident response, so the team stays engaged until an incident is fully remediated rather than stopping when a clock runs out, and gives a concrete answer to the "who owns the outcome?" question.

What to do with the report

If you're evaluating MDR, and have access to Forrester, the report is a strong prompt to rewrite your evaluation criteria. A few questions worth taking into any provider conversation:

• Ask how exposure context actually enters investigations. Is it a legitimate input to detection and prioritization, or a separate dashboard? 

• Ask to see a real, redacted case file rather than a metrics summary. Then probe how the provider handles uncertainty and model failure. 

• Clarify the place where accountability sits when a response action carries risk, and get a clear answer on how far the provider remains engaged during an incident. 

These are the same standards we hold ourselves to, and they map to how we've built our MDR service. If you want to go deeper, our MDR Buyer's Guide walks through what to look for in a partner, and you can compare Rapid7 MDR against other providers or talk to our SOC team directly.

The MDR market is one in which detection, exposure, and response stop being separate purchases and start being one accountable outcome. That's the service we set out to build, and now is a good moment for every security leader to ask whether their current provider is heading the same way.

Source: Forrester, The Managed Detection And Response Services Landscape, Q3 2026, Jeff Pollard with Joseph Blankenship, Emily Doherty, and Michael Belden, September 1, 2026. Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. This report is part of a broader collection of Forrester resources, including interactive models, frameworks, tools, data, and access to analyst guidance. For more information, read about Forrester’s objectivity here .

Overview

On September 10, 2026, GitLab published a critical patch release for GitLab Community Edition (CE) and Enterprise Edition (EE). The release addresses CVE-2026-85706, a critical path traversal vulnerability (CWE-22) in the repository commits API with a CVSSv3.1 score of 10.0. According to GitLab, improper path confinement and missing authentication enforcement could allow an unauthenticated user to read arbitrary files from an affected GitLab server under certain conditions.

On September 11, 2026, CVE-2026-85706 was added to the U.S. Cybersecurity and Infrastructure Security Agency's (CISA) Known Exploited Vulnerabilities (KEV) catalog, based on evidence of active exploitation. CISA set a remediation due date of September 14, 2026, for affected Federal Civilian Executive Branch agencies and marked the vulnerability as subject to forensic triage requirements under Binding Operational Directive 26-04.

Organizations running affected self-managed GitLab instances should remediate CVE-2026-85706 on an emergency basis, outside of normal patch cycles.

Mitigation guidance

A vendor-supplied update is available to remediate CVE-2026-85706. Organizations running affected self-managed GitLab CE or EE instances should upgrade to a fixed version immediately.

GitLab.com is already running a patched version, and GitLab Dedicated customers do not need to take action. Per GitLab, all self-managed deployment types are affected, including Omnibus, source code, and Helm chart deployments.

The updates include database migrations. Single-node installations will experience downtime while the migrations run; multi-node deployments can use GitLab's zero-downtime upgrade procedure. Of the fixed releases, only 19.3.2 includes post-deployment migrations.

The patch release also addresses 17 other vulnerabilities. These include CVE-2026-87719, a critical insecure deserialization vulnerability (CWE-502) in GitLab EE with a CVSSv3.1 score of 9.9. GitLab states that, under certain conditions, an authenticated user with Duo Chat access could obtain Advanced Search instance configurations and sensitive credentials using a specially crafted GraphQL subscription argument. At the time of publication, only CVE-2026-85706 is known to be exploited in the wild.

Given the confirmed exploitation, Rapid7 strongly recommends looking for signs of compromise even after the update has been applied. Organizations subject to CISA's BOD 26-04 should also follow the forensic triage requirements associated with the KEV entry.

For the latest mitigation guidance, please refer to the vendor's security advisory.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-85706 with a vulnerability check available in the September 15 content release.

Updates

• September 14, 2026: Initial publication.

This One Goes to Sixteen!

Another banger from Metasploit with sixteen new modules, including ten exploit modules, with five on the CISA KEV list. Cisco, Papercut, Sonicwall, Jetbrains, and Langflow all have exploit modules, and not to be outdone, we even have a Metasploit scanner to watch the watchers!

New module content (16)

Elasticsearch ingest-attachment Apache Tika XFA XXE Local File Read

Authors: Bourbon Offensive Security Services and Jean-Marie Bourbon

Type: Auxiliary

Pull request: #21739 contributed by kmkz

Path: scanner/http/elasticsearch_tika_xfa_xxe

CVE reference: CVE-2025-66516

Description: Adds an auxiliary scanner module for CVE-2025-54988/CVE-2025-66516. The module validates an XML External Entity (XXE) vulnerability in Apache Tika's XFA parser exposed through the Elasticsearch attachment ingest processor.

SPIP Unauthenticated Blind SQLi via Date Field Escaping Bypass

Authors: Benoit Hua, Franck Chevalier, Julien Voisin, and ka3n1x

Type: Auxiliary

Pull request: #21791 contributed by jvoisin

Path: scanner/http/spip_annee_sqli

Description: Adds modules/auxiliary/scanner/http/spip_annee_sqli.rb which exploits a blind SQL injection in SPIP's date column escaping logic.

Metasploit Payload Handler Detection (TCP/UDP/HTTP/HTTPS)

Author: h00die

Type: Auxiliary

Pull request: #21551 contributed by h00die

Path: scanner/msf/handler_detect

Description: Adds a scanner module to enumerate ports on a host and determine if they're a Metasploit Reverse Handler or not, and if they are, what kind of shell they were going to land.

ESC8 Relay: SMB to HTTP(S) via Kerberos

Author: Pushpender Rathore

Type: Auxiliary

Pull request: #21709 contributed by Pushpenderrathore

Path: server/relay/esc8_kerberos

CVE reference: CVE-2026-20929

Description: This introduces native Kerberos authentication relay capabilities to the framework's relay stack. It includes a new auxiliary module (esc8_kerberos) that exploits CVE-2026-20929 by targeting AD CS Web Enrollment (ESC8). The module captures an SMB2 AP-REQ from a coerced client and seamlessly replays the authentication to the target certificate server over HTTP. This chain ultimately allows an attacker to issue a certificate for the coerced victim and obtain a valid Kerberos TGT without requiring their credentials.

Linux x64 Sandbox Environment Gate

Author: Massimo Bertocchi

Type: Evasion

Pull request: #21642 contributed by litemars

Path: linux/x64/sandbox_gate

Description: Adds a Linux x64 sandbox‑evasion module that performs lightweight runtime environment checks and aborts execution when a likely sandbox or VM is detected.

Cisco Secure Firewall Management Center Authentication Bypass RCE

Authors: Arian Eidizadeh, Brandon Sakai, and Cale Black

Type: Exploit

Pull request: #21796 contributed by CyberAuth

Path: linux/http/cisco_fmc_auth_bypass_rce

CVE reference: CVE-2026-20079

Description: Adds a native Metasploit exploit module for CVE-2026-20079, an unauthenticated authentication bypass in Cisco Secure Firewall Management Center (FMC).

SonicWall SMA1000 WorkPlace SSRF to Root Remote Code Execution

Authors: Adam Babis, William Perry, and sfewer-r7

Type: Exploit

Pull request: #21883 contributed by sfewer-r7

Path: linux/http/sonicwall_sma1000_couchdb_rce

CVE reference: CVE-2026-83549

Description: This adds an exploit module for the recent SonicWall SMA1000 zero-day exploit chain that was disclosed in the first week of September as being exploited in-the-wild. CVE-2026-83548 is an SSRF used to bypass auth. SMA1000-9427 is an RCE with low privileges via CouchDB read/write primitives. CVE-2026-83549 is a command injection in cmsSnmpTrap.sh for RCE with root privs. The patched version 12.5.0-02952 has been verified to successfully remediate this exploit chain.

JetBrains TeamCity Agent Polling Unauthenticated Remote Code Execution

Authors: Antoni Tremblay and sfewer-r7

Type: Exploit

Pull request: #21775 contributed by sfewer-r7

Path: multi/http/jetbrains_teamcity_rce_cve_2026_63077

CVE reference: CVE-2026-63077

Description: This introduces a new unauthenticated Remote Code Execution (RCE) exploit module for JetBrains TeamCity, targeting the vulnerability tracked as CVE-2026-63077. The module exploits an unsafe XStream deserialization flaw within the agent polling protocol to deliver and execute a one-shot JSP payload on the server. The module supports both Windows and Linux targets and features built-in cleanup logic to automatically unregister and remove the fake build agent created during the exploitation process.

Langflow AI authenticated RCE

Author: Richard Howe

Type: Exploit

Pull request: #21837 contributed by rmhowe425

Path: multi/http/langflow_auth_rce_cve_2026_19295

CVE reference: CVE-2026-19295

Description: Adds a new module targeting CVE-2026-19295, an authenticated remote code execution vulnerability impacting Langflow versions 1.10.0 and below.

MCPJam Inspector Connect API Command Execution

Authors: Louay-075 and earthenvessel

Type: Exploit

Pull request: #21655 contributed by earthenvessel

Path: multi/http/mcpjam_inspector_rce

CVE reference: CVE-2026-23744

Description: This adds a new exploit module for CVE-2026-23744, an unauthenticated command execution vulnerability in MCPJam Inspector. The module targets the /api/mcp/connect endpoint. Vulnerable versions accept a JSON serverConfig object containing a command and args array, then use those values to start an MCP server. When MCPJam Inspector is exposed on a routable interface, an unauthenticated remote attacker can abuse this behavior to execute operating system commands as the user running MCPJam Inspector.

PaperCut NG/MF Unauthenticated RCE (CVE-2026-81578 + CVE-2026-82078)

Author: sfewer-r7

Type: Exploit

Pull request: #21842 contributed by sfewer-r7

Path: multi/http/papercut_ng_external_user_lookup_rce

CVE reference: CVE-2026-82078

Description: Adds an exploit module for the recent PaperCut MF and PaperCut NG exploit chain (CVE-2026-81578 + CVE-2026-82078) that was reported last week as a zero-day being actively exploited in the wild.

SimpleHelp OIDC Authentication Bypass Remote Code Execution

Authors: Blackpoint Cyber, Horizon3.ai, Zach Hanley, and jheysel-r7

Type: Exploit

Pull request: #21825 contributed by jheysel-r7

Path: multi/http/simplehelp_oidc_auth_bypass_rce

CVE reference: CVE-2026-48558

Description: Adds an exploit module for CVE-2026-48558, an OIDC authentication bypass affecting SimpleHelp 5.5.0 through 5.5.15.

SPIP Autosave Session Unauthenticated RCE

Author: Julien Voisin

Type: Exploit

Pull request: #21859 contributed by jvoisin

Path: multi/http/spip_autosave_rce

Description: Adds a module targeting an unauthenticated remote code execution vulnerability in SPIP <= 4.4.21 via the forum autosave session handler. The action=session endpoint lets any visitor store arbitrary PHP code in a session variable, which is then executed by the template engine when the article page is rendered. No CVE has yet been issued.

Next.js Unauthenticated RCE on Windows Servers

Authors: Avishek Sarkar, Bogyeom Lee, and Maksim Rogov

Type: Exploit

Pull request: #21834 contributed by vognik

Path: windows/http/nextjs_unauth_rce_cve_2026_75604

CVE reference: CVE-2026-75604

Description: Adds a module targeting CVE-2026-75604, a Remote Code Execution (RCE) vulnerability in Next.js applications hosted on Windows servers. Specifically crafted requests can execute arbitrary code on the target server running Next.js versions from 13.4.0 up to 15.5.24, and 16.0.0 up to 16.3.3.

Boot Verification Program Persistence

Author: Emanuele Cervelli

Type: Exploit

Pull request: #21550 contributed by M4nu02

Path: windows/persistence/boot_verification_program

Description: Adds a Windows persistence module leveraging the registry key BootVerificationProgram.

Windows Time Provider Persistence

Author: Emanuele Cervelli

Type: Exploit

Pull request: #21522 contributed by M4nu02

Path: windows/persistence/time_provider

Description: Adds a new persistence module that registers a custom Time Provider DLL under the W32Time service registry key.

Bugs fixed (4)

• #21719 from Pushpenderrathore - Fixes a race condition in the module Metadata cache.
• #21838 from jheysel-r7 - Fixes payload choosing behaviour when swapping targets to auto-select the most fitting payload which can now also include Java payloads.
• #21853 from Pushpenderrathore - Three fixes to the core Rex::Proto::DNS forward/cache path that surface once the DNS server is used as a selective poisoner in front of a real upstream resolver
• #21861 from prithvee07 - Fixes a recent regression in the vsftpd_234_backdoor module where by updating the module to support ARCH_CMD payloads we inadvertently dropped support for cmd/unix/interact payloads. Both payloads are now supported.

Documentation

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

Get it

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

• Pull Requests 6.5.3…6.5.4
• Full diff 6.5.3…6.5.4

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

Introduction

The surge in emerging threat actors directly correlates with the rapid escalation of victim counts and stolen financial resources. Simultaneously, this growth has spurred the proliferation of specialized supply storefronts across social media platforms, dark web channels, and various smaller niche marketplaces. Security teams today face evolving challenges, requiring them to continuously refine monitoring channels, adjust operational strategies, and foster cross-functional internal collaboration to capture actionable intelligence.

With fraud damages anticipated to approach hundreds of billions of USD, security teams must navigate numerous non-compliant channels while ingesting and processing diverse data formats—such as documents, imagery, video, and unformatted text—linked to organizational assets. The recent introduction of a new Fraud framework by the MITRE organization underscores the critical need to combat fraud and highlights the significant danger these threat actors pose to all organizations. The MITRE organization has been taking a positive step towards standardizing the fight against fraud, while helping organizations target the relevant directions to look at. 

These marketplaces supply a range of services in need for the novice fraudster, encompassing server infrastructure, targeted lists, and even support for money laundering facilitated through compromised accounts across various platforms. As larger, well-known marketplaces have been dismantled, smaller, specialized shops are experiencing heightened activity from buyers seeking to engage in fraudulent endeavors.

This blog post undertakes an exploration of these marketplaces and their operational modalities, illuminating the contemporary fraud economy and underscoring the enduring critical nature of robust detection and prevention initiatives.

Fraud-as-a-Service (FaaS)

Fraud is broadly defined as an intentional, dishonest act or misrepresentation of material facts, calculated to deceive others in order to secure an unfair or unlawful gain. Consequently, the Fraud-as-a-Service (FaaS) model encompasses various vendors and digital storefronts that facilitate such activities by providing new tools, instructional guides, and ancillary services for fraudsters.

Online shops and marketplaces, such as Xleet, Blackpass, Infodig and Styx, provide a venue for contemporary fraudsters to acquire the necessary resources for whichever scheme they intend to execute. Users are able to purchase active accounts for online platforms, including major financial institutions, online dating services, and even AI platforms. In addition different offerings may include stolen PII, synthetic identity generator, and ready to use online infrastructure.

To satisfy shifting market demands, threat actors—alongside malware developers and marketplace administrators—continuously refine their products to optimize future monetization. Novice fraudsters often begin their journey by seeking instructional manuals on various forums or platforms like Styx. Once a strategy is established, they leverage diverse online shops and marketplaces to acquire the necessary infrastructure and credentials. These same venues frequently provide stolen personal or business data, which criminals then exploit during the monetization phase. A common tactic involves business email compromise (BEC) schemes designed to manipulate customers into transferring funds directly to accounts controlled by the fraudster.

⠀

As companies attempt to protect themselves from being taken advantage of by these fraudsters, they could gather troves of important intelligence about how the malicious actors think, and more importantly gain operational information about breaking fraud networks and protecting their ecosystems. Companies may utilize the available or purchased information into operational decisions, reducing the number of incidents, or at least hinder the fraudster’s attempts. 

MITRE Fraud Fighting Framework (F3)

Introduced in early 2026, the MITRE Fraud Fighting Framework (MITRE F3) is designed to help organizations recognize adversarial TTPs, and could help security teams prioritize relevant sources for monitoring through prioritization of attack vectors or vulnerabilities. Due to the large amount of available sources, such a framework could indeed help organizations create the best strategy.

While the framework's structure mirrors traditional MITRE matrices, MITRE F3 expands into domains bridging cybersecurity and financial crime, specifically addressing the monetization stage. Although it introduces a novel perspective on fraud analysis, it does not sufficiently address the necessity of enhanced collaboration between an organization's internal departments.

To obtain meaningful environmental insights, security, fraud, and financial crime teams must maintain constant surveillance of marketplaces and similar forums. Monitoring marketplaces for asset mentions is critical for early detection of threats and new trends targeting new victims.

Key marketplaces and trends

Like other cybercrime-focused shops and forums, our monitored marketplaces also handle external threats targeting their clientele; some even use mirror sites. Similarly to other underground marketplaces, the key players must navigate themselves in an ever changing shattered environment where new marketplaces operate along alternative shopping methods through Telegram and P2P options.

When examining the MITRE framework, we can immediately see many techniques in common–mostly account takeover (ATO) techniques. Nevertheless, as seen in the different stocks and sellers, the offerings changed with time according to market demands.

There are some notable differences between Styx and the rest of the reported marketplaces, however. Styx operates by offering sellers more space for promoting their own personal shops, available mostly through Telegram.

⠀

Styx also aims to cultivate a specialized community through their "freemium" model, where premium, high-value content is reserved for users willing to pay significant fees.

⠀

While some of the free manuals have been posted through different cybercrime forums before, they show not only a real attempt by the Styx admins to generate additional income, but also sell ad space for different sellers working outside of the marketplace. These monetization techniques indicate the admins are probably well aware they have many competitors, as they attempt to provide a different shopping experience for their users.

Resource development: Infrastructure

Infrastructure for cybercrime operations has been sold for a long time, offering adversaries illegal access to active domains, cpanels, and more.

One of the leading marketplaces for such items is Xleet, first observed in 2022, which has quickly become a source for large collections of stolen credentials spanning multiple platforms. Distinguishing itself from other monitored marketplaces, Xleet is transparent about its offerings, frequently including evidence like screenshots or even email proof sent to the compromised account's email address.

⠀

⠀

Access to SMTP servers could help fraudsters reach larger audiences and evade different email protection and filtering services, thus improving success rate for different schemes. Xleet also offers alleged access to protected networks through Cpanel, web shells, SSH, and RDP connections, as well as VoIP access through their accounts:

⠀

BlackPass is another marketplace offering RDP credentials, as well as proxy services used by malicious actors for veiling their location or, as mentioned above, bypassing different restrictions on their IP addresses.

Blackpass, initially named 'Paysell,' emerged as one of the first known online marketplaces dedicated to selling compromised accounts. Estimates suggest this platform has facilitated the sale of hundreds of millions of accounts. Legal documents indicate the marketplace is controlled by Russian cybercriminals, a detail consistent with its product focus: items exclusively targeting Western countries, particularly the US.

⠀

All of these vulnerable environments could be part of a bigger scheme run by fraudsters, leading to other techniques being executed like a new vendor set up.

Another marketplace, Infodig, would offer different phone infrastructure in the past as mentioned in one of their opening posts on a cybercrime forum. Foreign or stolen numbers could be used for receiving or intercepting OTP messages, forging IT calls to employees, or self registering new accounts for other services.

Infodig has recently revamped some services offered, including the phone infrastructure, having been removed completely around the end of 2025 during an update the marketplace went through.

⠀

Styx also offers many options for fraudsters looking for ready to use infrastructure including eSIMs, VoIP services, and compromised VPN accounts. Localized SIM cards could be used by fraudsters for many reasons such as account creation but more importantly as a way to strengthen claims when confronting modern anti-fraud solutions, thus improving scam success rates.

⠀

The same marketplaces offer additional stolen, forged, and even active company documents for sale including incorporation forms, US tax forms, and other various products connected to shelf companies and stolen PII. These documents allow threat actors to generate troves of mule accounts, shelf corporations, and even combine them into money laundering networks.

Acquiring access

Stolen, self-registered (self-reg), or user-sold accounts are high-demand assets in underground markets. By acquiring pre-existing accounts that have already circumvented anti-fraud protections, threat actors can rapidly deploy them for various criminal operations.

These platforms provide access to a wide range of services, from financial institutions and streaming providers to dating sites and AI-driven website builders. Novice fraudsters often utilize these resources to secure quick profits or to stockpile accounts for future resale.

For example, Blackpass features an extensive account inventory that includes regional banks, neo-banks, and major corporations. Pricing within these markets is fluid; however, self-reg accounts typically represent the most expensive tier due to the significant labor required for their initial setup.

⠀

Xleet provides an extensive accounts division that covers a broad spectrum of common targets, including gaming, streaming, and dating service profiles. These specific credentials serve as high-value assets for executing various "pig butchering" fraud operations. Furthermore, a notable emerging trend within this marketplace is the significant surge in available credentials for AI platforms, especially those focused on accelerated website creation.

The newer type of marketplace, active since 2023, features an unorthodox design and much higher prices for their products. Styx holds the usual stock including stolen or self-reg accounts for a large variety of services, including financial institutions, social media accounts, streaming services, and casinos or other gambling sites.

⠀

The inventory at Infodig is categorized into several distinct sections, featuring stealer logs alongside stolen Financial Information and Personal Identifiable Information (PII), such as Social Security numbers. Their accounts division has recently been going through some technical or supply issues and there are no current accounts available. However the marketplace has revamped their target list section into a new ULP (URL:LOGIN:PASS), offering a new targeted option for large scale ATO operations.

Monetization

Styx has gained notoriety for its support of various "cashout" operations, which are prominently featured in numerous service advertisements throughout the platform.

By functioning as a hybrid of a marketplace and a forum, Styx provides a unique platform where merchants can offer specialized cashout services that exploit financial institutions across different payment rails. These merchants utilize various business accounts to assist fraudsters in laundering illicit funds through established methods, including payroll schemes, ACH transfers, and refund scams targeting multiple banks and geographic regions.

⠀

Beyond explicit solicitations for these services, marketplaces provide a variety of other products that are frequently exploited for money laundering. The exploitation of online gambling platforms remains a prevalent tactic for fraudsters, particularly as new regulations across the US lead to more states and companies entering the market. By acquiring stolen or synthetic PII, malicious actors can establish new gambling accounts to facilitate the laundering of illicit funds through techniques like chip dumping and minimal gameplay.

Conclusion

The fraud economy is changing at a fast pace with new techniques and players entering the field every day. By examining the different marketplaces portrayed in this blog post, we can see that they all react and appeal to different market needs. 

The change seen through available items across shops are a clear indication of this, as marketplaces pivot towards a larger crowd–one lacking the deep technical knowledge of the earlier fraudsters and carders. The different marketplaces allow every new fraudster to purchase their entire infrastructure for the fraud kill chain, from target lists, servers, and even support for laundering illegal income. Other online services include rapid AI creation of phishing threats, or other forms of abuse of legitimate service through stolen credentials. Marketplaces are not solely made for direct use and other threat actors view them as a major supplier for their shops as well, due to their fixed prices for items with prices which could easily be inflated through their personal shops as seen below:

⠀

⠀

As fraud communities and groups become increasingly fragmented, the industry continues to splinter into smaller shops. These new, smaller marketplaces often require an invitation or administrator approval to join, a tactic designed to impede investigations and extend the lifespan of their fraudulent products. This shift to smaller shops also benefits merchants, allowing them to keep 100% of their profits instead of sharing them with marketplace administrators. Targeted companies should continue to monitor the marketplaces as they continue to function as an important link in the fraud supply chain. Threat actors are very aware and understand a major part of every business is the profit, therefore financial crime services and associated accounts are continuing to evolve.  

Nevertheless, underground marketplaces will continue to operate as an important part of the cybercrime economic system. Smaller merchants may use these larger stores as suppliers for their smaller shops, as second income or even double or triple their income by selling the same stock in multiple locations. However companies should not only be aware of these underground ‘malls’, and regularly monitor them for any suspicious findings, but take a more proactive approach. The evolving nature of fraud demands a stronger reaction from organizations as well as cooperation from security, financial crime, and compliance teams for proactive measures against these threats.

Targeted companies, especially financial institutions or gambling providers, should actively investigate stolen accounts and gather vital intelligence for protecting themselves in the future, making it more difficult for threat actors to abuse their payment rails, brands, and customers. 

What organizations should do

To safeguard both their infrastructure and clients, security teams must move beyond monitoring disparate data streams and actively align with internal fraud and financial crime units to cultivate actionable intelligence. Because illicit merchants rely on marketing their offerings, security analysts should actively communicate with threat actors, purchase account samples, as well as analyze images or videos to map threat actor networks, verify operational legitimacy, and finally deploy targeted security countermeasures. Threat actors are threatening organizations with more than just data exfiltration, with compliance or financial crime requirements, companies become more vulnerable to newer forms of threats, not commonly associated with security teams, but initiating through cybercrime sources.

By proactively identifying leaked assets, correlating them to their own environments, and responding quickly through credential resets, and fraud monitoring, organizations can significantly reduce both financial losses and downstream risks such as ATO, and money laundering.

If your scan engine already holds credentials for a host, it can ask that host which ports are open instead of probing for them.

Every scan begins with the same question: which ports on this host are open? Everything after it, from identifying services to checking for vulnerabilities to evaluating policy, depends on the answer being right. The traditional answer comes from the outside: the scan engine sends traffic to a range of ports and infers each port's state from how the host responds. That approach is the industry standard, and it works well when a clear network path exists between the engine and the host. Hardened hosts can stay silent rather than replying, which forces the engine to wait out timeouts. Rate limiting and intrusion prevention can throttle a burst of probes, and genuinely open ports go missing when they do. Large port ranges take time to cover thoroughly, and that time comes out of your scan window.

There is a more direct route on any host where the scan engine already holds valid credentials: ask the host itself. This is credentialed discovery, so a credential that matches the host is the precondition for everything that follows. The engine connects to the port that credential uses, authenticates with a credential you already manage, and the host's operating system returns an authoritative list of the ports it is listening on. That list covers both TCP and UDP ports. There is no probing, no inference, and nothing to wait out.

Three things to know before enabling pre-port discovery

1. Pre-port discovery can report ports that a firewall or other network control stops your scan engine from reaching, and on those hosts you get fewer results and a longer scan.

2. SSH and the Scan Assistant are tried on their standard ports, TCP 22 and TCP 21047, unless you set a different port on the credential's restriction.

3. Credential coverage decides which hosts benefit, and a host with no matching credential falls back to a network port scan.

Each of these is covered in full in the configuration and troubleshooting documentation. If your engine only reaches these hosts through a restrictive firewall, see who should leave this off below.

Why probing from the outside can hit a wall

A network port scan works by inference. The engine sends traffic to each port in a configured range and reads the host's response, or its silence, as evidence about that port's state. Inference is the whole method, and its accuracy depends on the path between the engine and the host behaving predictably.

Several common conditions break that assumption. A hardened host that drops unsolicited traffic instead of refusing it gives the engine nothing to work with, so the engine waits for a timeout and then records an ambiguous result. Rate limiting and intrusion prevention are built to react to exactly the traffic pattern a port scan produces, and a throttled probe looks the same to the engine as a closed port. Wide port ranges make both problems worse, because every additional port is another probe, another possible timeout, and more scan time.

The outcome is a picture that can be partial on one scan and different on the next, on the hosts where an accurate picture matters most.

If you already have credentials, ask the host

Credentialed pre-port discovery replaces that inference with a question, and it is available from version 8.58. The engine connects to the port a credential uses, authenticates, and reads the list of listening ports from the host. For any host where that succeeds, the engine skips the network port scan and moves straight to examining the ports the host reported. That is what pre-port discovery means: discovering ports before, and in place of, the network port scan.

There is nothing new to deploy, because pre-port discovery reuses the credentials you already configure for authenticated scanning. You do not have to choose a method: when more than one credential fits a host, the engine prefers the Scan Assistant, then SSH, then a direct Windows connection, and it uses the first one that authenticates.

A host with no matching credential, or one where authentication does not succeed, falls back to a network port scan automatically, and that fallback is not reported as an error.

The option is a per-template checkbox under Asset Discovery, and it is off by default. Everything after port discovery is unchanged: fingerprinting, vulnerability checks, and policy evaluation run as they do today. The configuration guide has the console and REST API steps.

Pre-port discovery's trade-off, stated plainly

A host reports what it is listening on, and it has no way of knowing what sits between it and your scan engine. A network port scan never ran into that, because it only ever reported a port it could actually reach. Pre-port discovery trades that outside-in view for the host's authoritative inside-out view, and the trade has a cost worth understanding first.

The engine still tries to connect to each reported port to identify the service running there. A port the engine cannot reach does not answer, so that connection has to wait out a short timeout before the engine gives up on it. That is why no service is identified on that port and why the scan takes a little longer. Pre-port discovery already confirmed the port is open, so the engine does not treat these failed connections as the host going offline. It records each unreachable port, notes in the scan log that a host firewall or similar network restriction is the likely cause, skips that port, and keeps assessing the host on the ports it can reach. What you lose is coverage of whatever is behind the unreachable ports, plus a little scan time, not the scan of the host.

The engine only falls back to treating repeated connection failures as a host that has stopped responding for hosts pre-port discovery could not reach at all, such as a host with no matching credential. Those hosts are scanned the normal way.

The finding describes the engine's experience of the host, not the health of the host. The port is genuinely open, and the host answered every question pre-port discovery asked it. The troubleshooting documentation covers what can block the path and how to test reachability from the engine.

Who should (and should not) turn on pre-port discovery?

Pre-port discovery is a good fit where the scan engine has broad network reachability to the hosts it scans, and where you already use SSH, Scan Assistant, or Windows credentials for authenticated scanning. It pays off most on hardened or rate-limited hosts and on large port ranges, which are the cases where a network port scan has been slow or inconsistent. A responsive host on a fast network may show little difference.

Approach it with more care where the engine is deliberately segmented from the hosts it scans and allowed through on only specific ports, or where the firewall rules between the engine and those hosts are restrictive or not fully known. In those environments, confirm reachability first, or keep using the network port scan.

Because this is a per-template setting, both approaches can coexist: a pre-port discovery template for the estate your engine can reach broadly, and a standard template for the hosts that segmentation deliberately keeps at a distance.

When to leave it off:

• Your scan engine is segmented from the hosts and allowed through on only specific ports. Pre-port discovery still reports every port the host is listening on, so the engine spends time on ports it cannot reach and returns no results for them.
• A host’s results must stay within a fixed set of ports. Pre-port discovery reports every port the host is listening on and does not apply your scan template’s port range, additional ports, or excluded ports. To keep results inside a defined set, scan with a template that has pre-port discovery turned off.

Try it on one template

One template at a time is the easiest way to judge the difference. Enable pre-port discovery on a single template, scan a representative group of hosts with it, and compare the results against what those same hosts returned before. If the port lists and the scan times look the way you expect, widen it from there. The configuration and troubleshooting guide has the details.

Further reading

Credentialed pre-port discovery: How to enable it in the console and over the REST API, how it picks a credential and a port, what your scan template’s port settings apply to (the fallback network port scans for hosts without a matching credential, not the port's pre-port discovery returns), and what to check when a host does not behave the way you expect.

Microsoft is publishing 974 own-product vulnerabilities on September 2026 Patch Tuesday, including 723 vulnerabilities in Windows. Along with Microsoft fixes for 25 non-Microsoft CVEs, that brings the total number of vulnerabilities on the table today to 999. Whether this is the biggest Patch Tuesday ever depends on how we count, but this is by far the most CVEs that Microsoft has ever published in a single day. As Rapid7 noted last month, 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 two of the vulnerabilities published today.

Windows ALPC: zero-day EoP

The eternal game of elevation of privilege whack-a-mole between Microsoft and attackers continues. This month, the battle is centered on the Windows Advanced Local Procedure Call (ALPC) mechanism, a kernel capability that facilitates inter-process communication. Microsoft is aware of exploitation in the wild already. Successful abuse of the flaw underlying CVE-2026-85880 grants an attacker SYSTEM via a buffer overflow that enables an out-of-bounds write, and as we all know by now, this is exactly what would happen during the first five minutes of a technically accurate horror movie about ransomware. We can infer one silver lining here: since neither Server 2025 nor Windows 11 receives patches for CVE-2026-85880, it is likely that Microsoft’s ongoing efforts to level up memory safety by rewriting critical kernel components in Rust are paying off.

Windows Update Stack: zero-day EoP

Attackers disappointed by Microsoft’s move towards memory safety improvements for various critical kernel components need not leave empty-handed today. Microsoft is aware of existing exploitation in the wild for CVE-2026-81963, an elevation of privilege vulnerability in the Windows Update Stack that leads to SYSTEM privileges via improper link resolution. All supported versions of Windows receive a patch, which presumably tightens up controls to prevent the Windows Update Stack from following a malicious link and overwriting a system component with an attacker-controlled imposter. The relatively pedestrian CVSS v3 base score of 7.8 is no reason for less concern, since no serious attacker will bother developing an intricate one-shot RCE when a two-stage attack chain consisting of low-privileged local access coupled with elevation of privilege will achieve the same ultimate goal much more easily.

Living on the Edge: browser advisory uncertainty

For the second month in a row, Microsoft does not appear to have published any desktop browser security advisories between the start of the month and Patch Tuesday. Microsoft Edge is built on top of Google’s open-source Chromium project, and on September 3, 2026, Google Chrome patched CVE-2026-85046, an exploited-in-the-wild zero-day vulnerability in the V8 JavaScript engine relied upon by both Edge and Chrome. So, is Microsoft Edge falling dangerously behind Google Chrome? Well, maybe. In this specific case, the Edge stable channel did receive a patch a day earlier than Chrome on September 2, 2026, and we know this because the Edge release notes mention it. However, almost a week later, Microsoft still hasn’t published a security advisory for CVE-2026-85046, and until that URL returns something better than a 404, that will remain true. In short: if you’re patched, you are protected, but if you rely on advisories to know which vulns exist, you could miss this zero-day vulnerability altogether. Only Microsoft knows why this advisory is missing, but there is no reason to suppose that Microsoft is somehow immune to the pressures that come along with the vast increase in vulnerability volume. A patch without an advisory is perhaps marginally better than an advisory without a patch, but keeping track of exposures without reliable advisory materials is not straightforward. Chrome patched 11 other vulnerabilities at the same time as CVE-2026-85046, but it’s not yet clear if those are patched in Edge. Until Microsoft sets the record straight, the only safe assumption is that these vulnerabilities (e.g. CVE-2026-85045) remain unpatched in Edge.

Microsoft lifecycle update

The next Microsoft product 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.

Summary charts

Summary tables

Apps vulnerabilities

Azure vulnerabilities

Browser vulnerabilities

Developer Tools vulnerabilities

ESU vulnerabilities