On September 22, 2026, F5 published a security advisory for CVE-2026-94127, a critical heap-based buffer overflow vulnerability affecting F5 BIG-IP Access Policy Manager (APM). The vulnerability has a CVSS v3.1 score of 9.8. An unauthenticated attacker with network access to an affected virtual server may be able to achieve remote code execution (RCE) by sending specifically crafted traffic.
BIG-IP APM provides identity-aware access control for applications and other corporate resources and can integrate with authentication technologies including OAuth, OpenID Connect, and SAML. CVE-2026-94127 is not exposed in a default configuration: exploitation requires a BIG-IP virtual server with both an APM access policy and an OAuth profile configured. Because affected BIG-IP systems may process traffic at an organization's network edge, organizations using this configuration should prioritize remediation.
The vulnerability affects the data plane and does not expose the BIG-IP control plane. BIG-IP systems operating in Appliance mode are also affected.
F5 lists the following affected release trains and corresponding fixed hotfixes:
BIG-IP 21.1.0: versions prior to Hotfix-BIGIP-21.1.0.2.0.30.22-ENG
BIG-IP 17.5.0: versions prior to Hotfix-BIGIP-17.5.1.9.0.160.12-ENG
BIG-IP 17.1.0: versions prior to Hotfix-BIGIP-17.1.3.5.0.41.14-ENG
As of September 22, 2026, CVE-2026-94127 has been added to the CISA KEV while a publicly available proof of concept was not confirmed.
Mitigation guidance
Organizations running affected F5 BIG-IP deployments should apply the appropriate F5 hotfix as soon as operationally feasible, particularly where a vulnerable APM and OAuth configuration is reachable from untrusted networks.
F5 lists the following remediation versions:
BIG-IP 21.1.0: update to Hotfix-BIGIP-21.1.0.2.0.30.22-ENG or later.
BIG-IP 17.5.0: update to Hotfix-BIGIP-17.5.1.9.0.160.12-ENG or later.
BIG-IP 17.1.0: update to Hotfix-BIGIP-17.1.3.5.0.41.14-ENG or later.
Administrators should first determine whether a BIG-IP APM access policy and an OAuth profile are configured together on a virtual server, since this configuration is required for exposure.
For organizations that cannot immediately apply the applicable update, F5 provides an iRule workaround through F5 Support. Customers should open a support case with F5 to obtain the vendor-provided workaround and follow F5's implementation guidance.
Rapid7 customers
Exposure Command, Vulnerability Management, and Nexpose
Exposure Command, Vulnerability Management, Nexpose customers can assess exposure to CVE-2026-94127 using vulnerability checks expected to be available in todayβs (September 23) content release.
On September 14, 2026, Cisco published a security advisory for CVE-2026-76461, a critical SQL injection vulnerability affecting Cisco AsyncOS Software for Cisco Secure Email Gateway. The vulnerability has a reported CVSS v3.1 base score of 9.8 and could allow an unauthenticated, remote attacker to execute arbitrary commands with root privileges on an affected appliance.
Cisco Secure Email Gateway, formerly known as IronPort Email Security Appliance, is an enterprise email security product that inspects inbound and outbound email for threats including phishing, malware, spam, and business email compromise. Because affected gateways process externally delivered email as part of their normal operation, exploitation does not require access to an administrative interface or authentication. An attacker can reportedly trigger the vulnerability by sending a specially crafted email through a vulnerable gateway.
CVE-2026-76461 was added to CISA's Known Exploited Vulnerabilities (KEV) catalog on the same day as the vendor disclosed the vulnerability, indicating that CVE-2026-76461 was exploited as a zero-day prior to disclosure. Cisco noted that their PSIRT became aware of active exploitation in September 2026. At the time of publication, there is no public proof-of-concept exploit code available, and no attribution for the current threat actor activity.
Mitigation guidance
Organizations running Cisco Secure Email Gateway should prioritize upgrading to a vendor-supplied fixed version on an emergency basis, outside of normal patching cycles.
Affected Version
Fixed Version
15.5 and earlier
15.5.5-014
16.0
16.0.4-302
16.5
16.5.0-780
Given the reported active exploitation and the ability to achieve unauthenticated root-level command execution through malicious email processing, organizations should prioritize patching rather than relying solely on network controls or monitoring. Cisco also strongly recommends that customers migrate to the latest product version, 16.5.0-780.
For the latest remediation guidance, see the vendor advisory.
Indicators of compromise
The following indicators of compromise for CVE-2026-76461 were reported within the Cisco security advisory.
To confirm any attempted exploitation of this vulnerability, review the mail_logs and look for suspicious SQL statements. If the device is part of a cluster, review the logs of each cluster device. The following is a non-exhaustive example of how a malicious SQL statement could be detected in the logs:
cisco-esa> grep -i "COPY.*TO PROGRAM" [IronPort Text Mail Logs Log name - Default: mail_logs]
The presence of any entry in the output may indicate malicious activity.
Rapid7 customers
Exposure Command, InsightVM, and Nexpose
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-76461 with a vulnerability check expected to be available in the September 16 content release.
If your scan engine already holds credentials for a host, it can ask that host which ports are open instead of probing for them.
Every scan begins with the same question: which ports on this host are open? Everything after it, from identifying services to checking for vulnerabilities to evaluating policy, depends on the answer being right. The traditional answer comes from the outside: the scan engine sends traffic to a range of ports and infers each port's state from how the host responds. That approach is the industry standard, and it works well when a clear network path exists between the engine and the host. Hardened hosts can stay silent rather than replying, which forces the engine to wait out timeouts. Rate limiting and intrusion prevention can throttle a burst of probes, and genuinely open ports go missing when they do. Large port ranges take time to cover thoroughly, and that time comes out of your scan window.
There is a more direct route on any host where the scan engine already holds valid credentials: ask the host itself. This is credentialed discovery, so a credential that matches the host is the precondition for everything that follows. The engine connects to the port that credential uses, authenticates with a credential you already manage, and the host's operating system returns an authoritative list of the ports it is listening on. That list covers both TCP and UDP ports. There is no probing, no inference, and nothing to wait out.
Three things to know before enabling pre-port discovery
Pre-port discovery can report ports that a firewall or other network control stops your scan engine from reaching, and on those hosts you get fewer results and a longer scan.
SSH and the Scan Assistant are tried on their standard ports, TCP 22 and TCP 21047, unless you set a different port on the credential's restriction.
Credential coverage decides which hosts benefit, and a host with no matching credential falls back to a network port scan.
A network port scan works by inference. The engine sends traffic to each port in a configured range and reads the host's response, or its silence, as evidence about that port's state. Inference is the whole method, and its accuracy depends on the path between the engine and the host behaving predictably.
Several common conditions break that assumption. A hardened host that drops unsolicited traffic instead of refusing it gives the engine nothing to work with, so the engine waits for a timeout and then records an ambiguous result. Rate limiting and intrusion prevention are built to react to exactly the traffic pattern a port scan produces, and a throttled probe looks the same to the engine as a closed port. Wide port ranges make both problems worse, because every additional port is another probe, another possible timeout, and more scan time.
The outcome is a picture that can be partial on one scan and different on the next, on the hosts where an accurate picture matters most.
If you already have credentials, ask the host
Credentialed pre-port discovery replaces that inference with a question, and it is available from version 8.58. The engine connects to the port a credential uses, authenticates, and reads the list of listening ports from the host. For any host where that succeeds, the engine skips the network port scan and moves straight to examining the ports the host reported. That is what pre-port discovery means: discovering ports before, and in place of, the network port scan.
There is nothing new to deploy, because pre-port discovery reuses the credentials you already configure for authenticated scanning. You do not have to choose a method: when more than one credential fits a host, the engine prefers the Scan Assistant, then SSH, then a direct Windows connection, and it uses the first one that authenticates.
A host with no matching credential, or one where authentication does not succeed, falls back to a network port scan automatically, and that fallback is not reported as an error.
The option is a per-template checkbox under Asset Discovery, and it is off by default. Everything after port discovery is unchanged: fingerprinting, vulnerability checks, and policy evaluation run as they do today. The configuration guide has the console and REST API steps.
Pre-port discovery's trade-off, stated plainly
A host reports what it is listening on, and it has no way of knowing what sits between it and your scan engine. A network port scan never ran into that, because it only ever reported a port it could actually reach. Pre-port discovery trades that outside-in view for the host's authoritative inside-out view, and the trade has a cost worth understanding first.
After discovery, the engine still connects to each reported port to identify the service on it. A port the engine cannot reach has to time out before the engine moves on. Three things follow on that host: no service is identified on the unreachable port, the scan takes longer, and the engine can read repeated connection failures as a sign that the host has stopped responding. In that case it stops examining the host early and reports a finding saying the host scan was terminated because of excessive connection errors.
The finding describes the engine's experience of the host, not the health of the host. The port is genuinely open, and the host answered every question pre-port discovery asked it. The troubleshooting documentation covers what can block the path and how to test reachability from the engine.
Who should turn on pre-port discovery?
Pre-port discovery is a good fit where the scan engine has broad network reachability to the hosts it scans, and where you already use SSH, Scan Assistant, or Windows credentials for authenticated scanning. It pays off most on hardened or rate-limited hosts and on large port ranges, which are the cases where a network port scan has been slow or inconsistent. A responsive host on a fast network may show little difference.
Approach it with more care where the engine is deliberately segmented from the hosts it scans and allowed through on only specific ports, or where the firewall rules between the engine and those hosts are restrictive or not fully known. In those environments, confirm reachability first, or keep using the network port scan.
Because this is a per-template setting, both approaches can coexist: a pre-port discovery template for the estate your engine can reach broadly, and a standard template for the hosts that segmentation deliberately keeps at a distance.
Try it on one template
One template at a time is the easiest way to judge the difference. Enable pre-port discovery on a single template, scan a representative group of hosts with it, and compare the results against what those same hosts returned before. If the port lists and the scan times look the way you expect, widen it from there. The configuration and troubleshooting guide has the details.
Further reading
Credentialed pre-port discovery: How to enable it in the console and over the REST API, how it picks a credential and a port, what your template's port settings still control, and what to check when a host does not behave the way you expect.
Microsoft is publishing 974 own-product vulnerabilities on September 2026 Patch Tuesday, including 723 vulnerabilities in Windows. Along with Microsoft fixes for 25 non-Microsoft CVEs, that brings the total number of vulnerabilities on the table today to 999. Whether this is the biggest Patch Tuesday ever depends on how we count, but this is by far the most CVEs that Microsoft has ever published in a single day. As Rapid7 noted last month, there is no reason to suppose that Patch Tuesday will ever return to the lower volumes we saw prior to 2026. Microsoft is aware of exploitation in the wild for two of the vulnerabilities published today.
Windows ALPC: zero-day EoP
The eternal game of elevation of privilege whack-a-mole between Microsoft and attackers continues. This month, the battle is centered on the Windows Advanced Local Procedure Call (ALPC) mechanism, a kernel capability that facilitates inter-process communication. Microsoft is aware of exploitation in the wild already. Successful abuse of the flaw underlying CVE-2026-85880 grants an attacker SYSTEM via a buffer overflow that enables an out-of-bounds write, and as we all know by now, this is exactly what would happen during the first five minutes of a technically accurate horror movie about ransomware. We can infer one silver lining here: since neither Server 2025 nor Windows 11 receives patches for CVE-2026-85880, it is likely that Microsoftβs ongoing efforts to level up memory safety by rewriting critical kernel components in Rust are paying off.
Windows Update Stack: zero-day EoP
Attackers disappointed by Microsoftβs move towards memory safety improvements for various critical kernel components need not leave empty-handed today. Microsoft is aware of existing exploitation in the wild for CVE-2026-81963, an elevation of privilege vulnerability in the Windows Update Stack that leads to SYSTEM privileges via improper link resolution. All supported versions of Windows receive a patch, which presumably tightens up controls to prevent the Windows Update Stack from following a malicious link and overwriting a system component with an attacker-controlled imposter. The relatively pedestrian CVSS v3 base score of 7.8 is no reason for less concern, since no serious attacker will bother developing an intricate one-shot RCE when a two-stage attack chain consisting of low-privileged local access coupled with elevation of privilege will achieve the same ultimate goal much more easily.
Living on the Edge: browser advisory uncertainty
For the second month in a row, Microsoft does not appear to have published any desktop browser security advisories between the start of the month and Patch Tuesday. Microsoft Edge is built on top of Googleβs open-source Chromium project, and on September 3, 2026, Google Chrome patched CVE-2026-85046, an exploited-in-the-wild zero-day vulnerability in the V8 JavaScript engine relied upon by both Edge and Chrome. So, is Microsoft Edge falling dangerously behind Google Chrome? Well, maybe. In this specific case, the Edge stable channel did receive a patch a day earlier than Chrome on September 2, 2026, and we know this because the Edge release notes mention it. However, almost a week later, Microsoft still hasnβt published a security advisory for CVE-2026-85046, and until that URL returns something better than a 404, that will remain true. In short: if youβre patched, you are protected, but if you rely on advisories to know which vulns exist, you could miss this zero-day vulnerability altogether. Only Microsoft knows why this advisory is missing, but there is no reason to suppose that Microsoft is somehow immune to the pressures that come along with the vast increase in vulnerability volume. A patch without an advisory is perhaps marginally better than an advisory without a patch, but keeping track of exposures without reliable advisory materials is not straightforward. Chrome patched 11 other vulnerabilities at the same time as CVE-2026-85046, but itβs not yet clear if those are patched in Edge. Until Microsoft sets the record straight, the only safe assumption is that these vulnerabilities (e.g. CVE-2026-85045) remain unpatched in Edge.
Microsoft lifecycle update
The next Microsoft product lifecycle changes with broad impact occur on October 14, 2026, when Windows 11 24H2 Home & Pro reach end of servicing, and Windows Server 2022 moves to extended support, with free critical security updates continuing, but no further feature development. At the same time, the final curtain falls for Windows Server 2012 and 2012 R2 with the expiry of the third and final year of cash-for-updates Extended Security Update (ESU) program for these aging workhorses. Office 2021 also moves beyond support, including the Long-Term Servicing Channel, with no ESU available in that case. Also in October, Exchange Server 2016 and 2019 will join the βno ESUβ club, after two previous six-month reprieves. Presumably, Microsoft really means it this time.
An information disclosure issue in the zipfileInflate function in the zipfile extension in SQLite v3.51.1 and earlier allows attackers to obtain heap memory via supplying a crafted ZIP file.
An information disclosure issue in the zipfileInflate function in the zipfile extension in SQLite v3.51.1 and earlier allows attackers to obtain heap memory via supplying a crafted ZIP file.
An information disclosure issue in the zipfileInflate function in the zipfile extension in SQLite v3.51.1 and earlier allows attackers to obtain heap memory via supplying a crafted ZIP file.
While conducting research into a recent N-able N-central authentication bypass vulnerability (CVE-2026-18577), Rapid7 Labs discovered two new vulnerabilities affecting the latest version of N-central. When chained together, these two vulnerabilities allow a remote unauthenticated attacker to bypass authentication and create a new attacker-controlled System administrator account on an affected server.
Both CVE-2026-86206 and CVE-2026-86207 have been patched by the vendor via N-central 2026.3 Hotfix 3.
Product description
N-able N-central is an enterprise-grade Remote Monitoring and Management (RMM) platform designed for Managed Service Providers (MSPs) and IT departments to monitor, manage, and secure complex, large-scale networks from a centralized dashboard.
Credit
These vulnerabilities were discovered by Stephen Fewer, Senior Principal Security Researcher at Rapid7, and are being disclosed in accordance with Rapid7's vulnerability disclosure policy.
Technical analysis
CVE-2026-86206
N-central exposes its management interface (TCP 8443 by default) through Envoy, an edge proxy. Envoy passes accepted requests to Jetty, the Java web server that hosts N-central's application. The application gives requests from the loopback address (i.e. 127.0.0.1) more access than requests from a remote system. This design depends on Envoy, Jetty, and the N-central access filter all agreeing on which application path the client requested and whether the client is really local. The following request can make them disagree about both of these things:
POST /dms;/services/ServerUI HTTP/1.1
Forwarded: for="127.0.0.\1"
Content-Type: text/xml; charset=utf-8
SOAPAction: ""
The semicolon in the URI and backslash in the Forwarded value introduce a discrepancy when processing the request that leads to an access control bypass. Looking at Figure 1 below, we can see an overview of how these two values are processed during an incoming malicious request.
Figure 1: Processing a malicious request.
The semicolon gets the request past Envoy
The Envoy proxy rules come from the n-central-proxy-4.5.6-5 package. In /etc/opt/envoy/lds_intermediate.yaml, shown below (and edited for brevity), the management listener returns HTTP 403 for paths beginning with /dms/services or /internal/dms. A final catch-all rule sends other paths to the DMS application.
Envoy compares those prefixes with the path it received. The path /dms;/services/ServerUI does not begin with /dms/services, because the next character after /dms is a semicolon. It therefore reaches the catch-all route, passing the request from Envoy to Jetty.
Jetty interprets the path differently. The shipped jetty-http-9.4.56.v20240826.jar contains org.eclipse.jetty.http.HttpURI, and org.eclipse.jetty.util.URIUtil. Together, these classes treat text beginning with a semicolon as a path parameter and remove it when producing the decoded path used for servlet dispatch. As a result, Jetty turns /dms;/services/ServerUI into /dms/services/ServerUI. That decoded path then matches the Axis SOAP servlet mapping in /opt/nable/webapps/ROOT/WEB-INF/web.xml.Β
Similarly, the same technique can be used to target the SOAP service via /internal;/dms/services2/ServerUI2. Jetty decodes it to /internal/dms/services2/ServerUI2, which matches the CXF SOAP servlet mapping. A single semicolon is sufficient to create the routing disagreement.
Reaching these servlet mappings puts the request at the protected SOAP interfaces that an exploit can leverage to establish an application session and later manage privileged objects, but the semicolon trick alone does not authorize the request. Without the crafted Forwarded header, Jetty retains the client's real remote address and N-central's ServletPathFilter denies access. Conversely, the header trick alone cannot help a request to the ordinary /dms/services/ServerUI or /internal/dms/services2/ServerUI2 path: Envoy returns HTTP 403 without forwarding that request to Jetty.Β
As such, an exploit needs both discrepancies; the semicolon to pass Envoy's path check and the header to pass N-central's local-request check.
The header makes the remote client look local
The Forwarded header tells an application about the original client behind a proxy. In a malicious request, the for value is quoted and contains a quoted-pair (\1):
Forwarded: for="127.0.0.\1"
Under the HTTP quoted-string grammar, the backslash escapes the following character. Jetty's ForwardedRequestCustomizer, from jetty-server-9.4.56.v20240826.jar, applies that rule. It removes the backslash, reads the value as 127.0.0.1, and exposes that value to N-central as the request's remote address.
N-central then parses the original header a second time. Its parser is in com.nable.util.LocalHostUtils, from /opt/nable/webapps/ROOT/WEB-INF/lib/dmsservice-11.0.1-SNAPSHOT.jar. This parser removes the surrounding quotes but does not remove the backslash. It therefore checks 127.0.0.\1.
That string is not a valid IP address. LocalHostUtils.xffCheck() rejects an invalid value found in X-Forwarded-For, but its Forwarded branch rejects only values that it successfully recognizes as loopback. The below (abridged) decompilation shows the relevant branch:
When given the header value 127.0.0.\1, the isLoopbackAddress() call (at [1]) returns false (at [2]) because the value is invalid. The loop therefore continues and xffCheck() returns true (at [3]). In other words, an invalid Forwarded header value causes xffCheck to fail open. The final decision occurs in com.nable.server.ServletPathFilter, shown below.
The first check asks whether a forwarding header is trying to claim a loopback address (at [4]). N-central's parser sees the invalid value 127.0.0.\1, does not recognize it as loopback, and allows it. The second check asks whether Jetty's remote address is local (at [5]). Jetty has already converted the same header value to 127.0.0.1, so this check succeeds. The filter returns true (at [6]) before consulting the normal remote-path allowlist.
CVE-2026-86207
By leveraging CVE-2026-86206 to reach the protected URI /dms/services/ServerUI, a SessionID returned by the Session.Hello SOAP operation (See the prior work by Horizon3 on leveraging the legacy SOAP API) can be generated. However, this SessionID is only a pre-login session. It proves that the request reached the local-only SOAP API via the access control bypass, but it does not yet identify an authenticated user. A separate authentication bypass vulnerability, in how legacy two-factor authentication operates, allows a pre-login session to become an authenticated session.
The method com.nable.server.ui.UserTwoFactorLogin, from dmsservice-11.0.1-SNAPSHOT.jar (shown below), binds a requested user ID (e.g. the builtin N-able Administrator accountβs well known ID 1) to the session (at [1]) before it attempts legacy two-factor authentication (at [2]) . A normal authentication rejection removes that binding (at [4]), but if an exception occurs, this binding is left in place (at [3]).
N-central supports two distinct second-factor systems: legacy, profile-based authentication using an external AuthAnvil or RSA SecurID server, and native time-based one-time password (TOTP) βTwo-Step Verificationβ using an authenticator application. Despite overlapping 2FA/MFA terminology in N-ableβs documentation, com.nable.server.ui.UserTwoFactorLogin implements the former profile-based mechanism; it does not enforce the userβs native TOTP setting.
In a default installation, legacy two-factor processing raises an exception for several builtin identities used by N-central, as each of these identities lack a single legacy AuthAnvil or RSA 2FA profile association required by UserTwoFactorLogin. Specifically the following built-in identities can be leveraged via their known ID numbers.
User ID 1 (N-able Administrator)
User ID 50 (Product Administrator)
User ID 51 (N-able Support)
By creating a new pre-login session for any one of the above IDs, a SOAP call to User.TwoFactorLogin with a dummy password will achieve the authentication bypass, converting the pre-login session to a privileged SOAP session for that user. By using additional calls to the ServerUI2 SOAP endpoint, a new attacker-controlled System user account can be created.
Remediation
The vendor-supplied release of N-central 2026.3 Hotfix 3 (version 2026.3.1.13) remediates both CVE-2026-86206 and CVE-2026-86207. All versions of N-central prior to 2026.3.1.13 are vulnerable. Customers running affected on-premise N-central environments are urged to apply the latest update on an urgent basis, outside of normal patching cycles.
Customers using hosted N-central environments do not need to take action as the vendor has applied the needed updates.
Exposure Command, InsightVM and Nexpose customers will be able to assess their exposure to both CVE-2026-86206 and CVE-2026-86207, with authenticated vulnerability checks expected to be available in the September 8 content release.Β
Disclosure timeline
August 27, 2026: Rapid7 makes initial outreach to N-able who respond the same day.
August 28, 2026: Rapid7 provides a detailed technical analysis and exploit script to N-able, along with a proposed timeline for a coordinated disclosure.
September 5, 2026: N-able release N-central 2026.3 HF3 which fixes two of the vulnerabilities (CVE-2026-86206, CVE-2026-86207) reported by Rapid7.
September 7, 2026: Rapid7 contacts N-able requesting clarity on several issues. N-able responds the same day with requested information.
September 8, 2026: This disclosure for CVE-2026-86206 and CVE-2026-86207.
On August 27, 2026, PaperCut Software published an urgent security advisory stating that it is investigating active exploitation of a vulnerability affecting PaperCut NG and PaperCut MF. PaperCut has confirmed customer incidents and is treating the issue as a security emergency. At the initial time of disclosure, the vulnerability had not been assigned a CVE identifier, and PaperCut had not publicly disclosed a CVSS score, vulnerability class, authentication requirements, or the technical details of the exploit path. However on August 28, the vendor assigned CVE-2026-81578 and CVE-2026-82078 for the two vulnerabilities that make up the exploit chain.
CVE ID
Description
CWE
CVSSv4
CVE-2026-81578
Authentication Bypass
CWE-306 Missing authentication for critical function.
PaperCut NG and PaperCut MF are print management platforms commonly deployed within enterprise, education, and other organizational environments. Because the PaperCut Application Server provides web-accessible administrative and application functionality, organizations with servers exposed to the public internet should prioritize remediation and access restriction.
PaperCut stated in its advisory that information supplied by a university customerβs security team and digital forensics and incident response team enabled its security response team to reproduce the vulnerability in PaperCut NG and PaperCut MF. On August 28, 2026 at 02:10 AEST, PaperCut released emergency patches for PaperCut NG and PaperCut MF versions 25 and 26, followed later the same day with patches for version 24.
PaperCut has been targeted in the past; in 2023, CVE-2023-27350 was broadly exploited in the wild by multiple threat-actor groups, including ransomware operators. This prior history increases the urgency organizations should address this new zero-day with.
PaperCut currently considers all versions of PaperCut NG and PaperCut MF potentially impacted. Customers operating internet-accessible PaperCut Application Servers should take immediate action even if no suspicious activity has been observed.
On August 31, 2026, both CVE-2026-81578 and CVE-2026-82078 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. A Metasploit module is now available to validate exposure to the exploit chain.
Technical overview
The vulnerability is an authentication bypass that lets attackers invoke privileged PaperCut components. This can be leveraged to reconfigure an external database lookup. When this lookup is triggered, malicious SQL can be executed, resulting in remote code execution.
PaperCut uses the Apache Tapestry framework, whose "complex direct" request format can identify one page to display and a different page containing the component to execute. PaperCut validates access only to the displayed page. By selecting either the public Error page or Exception page for display, an attacker can bypass authentication while invoking administrative components belonging to ConfigEditor or UserList. Additionally, the first emergency patch could be bypassed by using the Home page for display, however the newest version of the vendor patch correctly remediates this bypass.
The attack uses HTTP POST requests to the following URIs (Note that the path segment with the value 1 shown below can be any value for this path segment, and the Error path segment may also be the Exception or Home path segment):
The first two URIs provide unauthenticated access to PaperCut's configuration editor. The third can invoke a user or card search that triggers the configured external database lookup.
An attacker first uses the ConfigEditor requests to modify four external user-lookup settings:
These settings normally allow administrators to connect PaperCut to an external card database. After bypassing authentication, however, the attacker can configure them with a malicious JDBC connection and a malicious SQL statement.
By leveraging PaperCut's bundled Apache Derby database driver and supplying a Derby CALL statement that activates its foreignViews feature, Derby opens an attacker-controlled H2 JDBC URL. H2 processes an inline INIT statement that creates a JavaScript-backed database trigger. PaperCut includes the Nashorn JavaScript engine, allowing that trigger to start an operating-system process. However it is expected that other mechanisms to execute an arbitrary command can also be used instead of Nashorn. Finally, the attacker submits a search through the forged UserList request. This activates the external lookup and executes the malicious SQL.
Mitigation guidance
Organizations running PaperCut NG or PaperCut MF should prioritize patching on an emergency basis, particularly where the PaperCut Application Server is accessible from the public internet.
PaperCut has released emergency patches for PaperCut NG and PaperCut MF versions 24, 25 and 26.Β
Updated on September 1, 2026: Note that the vendor has released a third version of the emergency patch. Any organization that has applied either the original first version or the second version of the emergency patch is not fully protected, and must apply the third emergency patch immediately.
The vendor notes that these builds have not undergone their normal release process and are intended as emergency fixes for customers with public-facing servers that cannot otherwise sufficiently mitigate exposure.
PaperCut recommends that administrators immediately restrict web access to trusted IP addresses only, such as internal corporate network ranges. Firewall rules, network access controls, reverse-proxy restrictions, or equivalent measures should be used to prevent untrusted internet hosts from reaching PaperCut web interfaces.
Please read the PaperCut security advisory for the latest remediation guidance, updated indicators of compromise, and additional release information.
Artifacts/Evidence Sources and IOCs
For detection and forensic analysis, PaperCut has identified several preliminary artifacts and evidence sources that may indicate compromise.
Application activity: Alerts from intrusion-detection, endpoint-security, or network-monitoring products involving the PaperCut Application Server, particularly suspicious post-exploitation activity associated with pc-app.exe.
Log integrity: Missing, unexpectedly truncated, or deleted PaperCut server.log files.
PaperCut server.log entries:
ERROR No suitable driver found for jdbc:no:x
ERROR DatabaseUtils - Database error looking up cardID: VALUES CAST
PaperCut has not yet published validated network-based indicators such as malicious IP addresses, domains, or URLs.
The vendor specifically warns that the absence of these indicators should not be interpreted as evidence that a system has not been affected.
Rapid7 customers
Exposure Command, InsightVM, and Nexpose
Exposure Command, InsightVM, and Nexpose customers can assess exposure to this new PaperCut zero-day, with an authenticated vulnerability check expected to be available in the August 28 (todayβs) content release.
Updates
August 28, 2026: Initial publication.
August 28, 2026: Updated to reflect new emergency patches and CVE ID assignment. Updated remediation to include the new v24 patches. Updated Technical Overview to indicate first patch bypass.
August 31, 2026: Updated the Overview to note that both CVEs were added to the CISA KEV list, and the availability of a Metasploit module.
September 1, 2026: Updated the Remediation section to reflect the vendor's new emergency patch (release 3).
On August 19, 2026, a security advisory was published for CVE-2026-19490, a critical authentication bypass vulnerability affecting Citrix NetScaler ADC and NetScaler Gateway. The vulnerability carries a CVSS v4.0 base score of 9.3 and can be exploited remotely by an unauthenticated attacker over the network without user interaction or elevated privileges.
NetScaler ADC and NetScaler Gateway are widely deployed enterprise networking products commonly positioned at or near the network perimeter. NetScaler ADC provides application delivery, traffic management, load balancing, SSL/TLS offloading, and application security capabilities, while NetScaler Gateway provides secure remote access and VPN functionality. Because these systems are frequently deployed in enterprise DMZs and exposed to the public internet, authentication bypass vulnerabilities affecting Citrix products are nearly always exploited by threat actors.
NetScaler ADC and NetScaler Gateway 14.1: Versions prior to 14.1-73.32
NetScaler ADC and NetScaler Gateway 13.1: Versions prior to 13.1-63.21
NetScaler ADC FIPS: Versions prior to 14.1-73.32 FIPS
NetScaler ADC FIPS and NDcPP: Versions prior to 13.1-37.277
As of August 19, 2026, Rapid7 has not observed evidence that CVE-2026-19490 is being exploited in the wild. However, organizations should prioritize patching affected systems on an emergency basis, since Citrix products are high-value targets that tend to quickly see exploitation in the wild.
On September 9, 2026, CVE-2026-19490 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. With active exploitation now occurring, organizations running affected versions of Citrix NetScaler ADC and NetScaler Gateway should remediate these issues on an urgent basis, outside of normal patching cycles.
Mitigation guidance
Organizations running affected NetScaler ADC or NetScaler Gateway appliances should review the official NetScaler advisory and apply the required updates to affected systems on an emergency basis.
Fixed versions for affected products are listed below:
NetScaler ADCβ―and NetScaler Gateway14.1-73.32 and later releases
NetScaler ADCβ―and NetScaler Gateway13.1-63.21 and later releases of 13.1
NetScaler ADC 14.1-FIPS14.1-73.32 FIPS and later releases of 14.1-FIPS
NetScaler ADC 13.1-FIPS and 13.1-NDcPP13.1-37.277 and later releases of 13.1-FIPS and 13.1-NDcPP
According to Citrix, customers can determine whether affected systems are vulnerable to CVE-2026-19490 by inspecting their NetScaler configuration for the following configuration entries. If one or more of the following items are present, and if the systems are running affected versions, the system is likely to be exploitable:
SAML action configuration is in place:
"add authentication samlAction.*"
Auth or VPN vserver is configured:
Β "add authentication vserver .*"
Β "add vpn vserver .*"
For the latest guidance, please refer to the official Citrix advisory.
Rapid7 customers
Exposure Command, InsightVM, and Nexpose
Customers can assess exposure to CVE-2026-19490 on Citrix NetScaler ADC and Gateway using a vulnerability check available in the August 20 content release.
Updates
August 19, 2026: Initial publication.
August 20, 2026: Updated Rapid7 customers section to reflect availability of vulnerability check.
September 11, 2026: Updated Overview to add new CISA KEV reference.
Microsoft is publishing 421 vulnerabilities on August 2026 Patch Tuesday, including 236 vulnerabilities in Windows. This is lower volume than last monthβs record-breaking behemoth, but still one of the largest Patch Tuesday totals ever. There is no reason to suppose that Patch Tuesday will ever return to the lower volumes we saw prior to 2026. Microsoft is aware of exploitation in the wild for one of the vulnerabilities published today, as well as public disclosure for two others, although the Notable CVEs section of the Security Update Guide omits one of these. As usual, browser vulns are not included in the Patch Tuesday count above, but unusually, Microsoft does not appear to have published any desktop browser security patches so far this month.
SharePoint: critical RCE chain by Rapid7
Today sees the publication of CVE-2026-63520, a high-severity remote code execution in Microsoft SharePoint. Discovered by Rapid7 Senior Principal Security Researcher Stephen Fewer, and published today in coordination with Microsoft; this vulnerability is the second in a pair of exploits which, when chained together, comprise a critical unauthenticated remote code execution vulnerability in a vulnerable SharePoint server. Patches are available for SharePoint Server Subscription Edition, 2019, and 2016. Alongside todayβs coordinated disclosure of CVE-2026-63520, Rapid7 has now published a detailed technical analysis and proof-of-concept for CVE-2026-55040, the first vulnerability in the chain.
AFD for Winsock: zero-day EoP
Rapid7 has previously discussed the Windows Ancillary Function Driver for WinSock, and today it returns to center stage with another exploited-in-the-wild elevation-of-privilege vulnerability. Successful exploitation requires winning a race condition, which increases the difficulty of producing a stable exploit. This also helps keep the CVSS v3 base score down to 7.0, along with a Microsoft proprietary severity ranking of merely important, rather than critical. However, with no user interaction required, and a prize of SYSTEM-level access, CVE-2026-68820 is just what the doctor ordered, if the doctor is based in Pyongyang and wants to steal your cryptocurrency. Microsoft credits CVE-2026-68820 to researchers at Check Point (misspelled βCheckpointβ on the advisory). CVE-2026-68820 isnβt yet listed on CISA KEV, but it will be soon.
Whatβs the opposite of coordinated disclosure?
This monthβs entry in the ongoing saga of Microsoft vs. a pseudonymous security researcher with a clear dislike of Microsoft comes in the form of CVE-2026-62832, an elevation of privilege vulnerability in the Windows User Profile Service. Exploitation leads to administrator rights on the local asset, and is achieved via a specially crafted application, which is Microsoft corporate argot for exploit code. Between the public disclosure and the FAQ, which describes an authenticated attacker who has credentials for another account and loads another userβs registry hive, the advisory is a solid match for Nightmare Eclipseβs description of LegacyHive, which Rapid7 discussed last month.
Patch Tuesday watchers will have been wondering whether Nightmare Eclipse would continue the pattern of the past few months by dropping yet another zero-day vuln late on Patch Tuesday to maximize friction and inconvenience for Microsoft. Wonder no more, because the new entry on this growing list of headaches is ShieldBreak. Nightmare Eclipse describes ShieldBreak as a full patch bypass for RoguePlanet, a previous entry in the series which Microsoft patched as CVE-2026-50656 during July, a month after its public disclosure. Both vulnerabilities are therefore elevation-of-privilege to SYSTEM vulnerabilities in Defender.
CVE-2026-72971 describes a tampering vulnerability in the Windows Container Isolation FS Filter Driver (unionfs.sys), where abuse of a flaw in the vulnerable driver presumably allows an unauthorized attacker to overwrite certain files. Since this might include an action taken within a container leading to an unauthorized impact outside the container, it might be surprising that the advisory claims no scope change. Presumably Microsoft is leaning on the fact that the vulnerability is within a driver which operates entirely within a single security authority, i.e. kernel space, so there is only one impacted component and no scope change according to the CVSS v3 spec. Still, the low CVSS v3 base score of 5.5 probably isnβt telling the whole story in this case.
Vulnerabilities classed as tampering are somewhat rare in the Microsoft corpus, making up just a few dozen of the thousands of unique vulnerabilities which MSRC has ever patched or otherwise addressed. CVE-2026-72971 isnβt mentioned in the Notable CVEs section of the new slimline Security Update Guide. Should it be? Perhaps, because Microsoft is aware of public disclosure in this case, but then again the categorization as tampering means that Microsoft is not currently aware of a path to a more severe impact such as elevation of privilege or code execution. The advisory acknowledges a pair of pseudonymous reporters, who also receive credit on at least 40 other advisories over the past few months, across a wide variety of Windows components and Microsoft Office, including 11 critical vulnerabilities.
Edge: update slowdown?
Typically, Microsoft patches a fair few browser vulnerabilities between the start of each month and that monthβs Patch Tuesday, but not this month. Conspicuous by its absence at the time of Patch Tuesday publication today was Microsoft Edge, which receives regular batches of patches as a downstream consumer of Google Chromium. At the moment of Patch Tuesday publication, the desktop incarnations of Edge last received security patches on July 31, 2026. Meanwhile, the Chrome Stable Channel received patches for 41 vulnerabilities on August 6, 2026. Anyone responsible for assets with Microsoft Edge installed will be relieved to know that patches for Edge eventually emerged a few hours later on Patch Tuesday itself, but five days is still a longer unpatched gap between Chrome and Edge than has been typical in the past.
Microsoft lifecycle update
August is typically a quieter month for Microsoft product lifecycle transitions, and this year continues that pattern. The next lifecycle changes with broad impact occur on October 14, 2026, when Windows 11 24H2 Home & Pro reach end of servicing, and Windows Server 2022 moves to extended support, with free critical security updates continuing, but no further feature development. At the same time, the final curtain falls for Windows Server 2012 and 2012 R2 with the expiry of the third and final year of cash-for-updates Extended Security Update (ESU) program for these aging workhorses. Office 2021 also moves beyond support, including the Long-Term Servicing Channel, with no ESU available in that case. Also in October, Exchange Server 2016 and 2019 will join the βno ESUβ club, after two previous six-month reprieves. Presumably, Microsoft really means it this time.
On August 2, 2026, N-able published a security advisory for CVE-2026-18577, an authentication bypass vulnerability affecting N-central that was discovered being exploited in-the-wild after an incomplete fix for an earlier authentication bypass issue, CVE-2026-18556 was disclosed. CVE-2026-18577 allows a remote unauthenticated attacker to bypass authentication and obtain administrative control of vulnerable N-central servers in affected deployments.
N-able N-central is a widely deployed Remote Monitoring and Management (RMM) platform used by managed service providers (MSPs) and enterprise IT teams to centrally administer servers, workstations, network devices, and other managed assets. Because the platform operates with extensive administrative privileges across customer environments, successful compromise of an N-central server can provide attackers with an efficient path to compromise downstream managed systems.
According to N-able, exploitation of CVE-2026-18577 has been observed in the wild since August 1, 2026. Following successful exploitation, attackers leveraged the platform's Take Control functionality to remotely access managed endpoints, and deployed Cloudflare Tunnel (cloudflared) to establish persistent remote access. On August 3, 2026, CVE-2026-18577 was added to CISAβs Known Exploited Vulnerability (KEV) catalog and on August 5, 2026, CVE-2026-18556 was also added to the catalog.
On August 6, 2026, N-able released a second hotfix to further address CVE-2026-18577. This second hotfix supersedes the original hotfix published on August 2, 2026, and provides additional mitigations against the same vulnerability. Customers who have not yet applied the new 2026.3 Hotfix 2 should do so on an urgent basis.
Mitigation guidance
Organizations operating vulnerable N-central deployments should prioritize remediation on an urgent basis, outside of normal patching schedules. Hosted N-central environments are upgraded automatically by the vendor, while on-premise deployments require manual remediation.
Affected versions:
All versions of N-able N-central up to and including version 2026.3.1, prior to Hotfix 2.
Fixed version:
N-able N-central 2026.3.1 Hotfix 2 (2026.3.1.10).
The vendor also recommends:
Upgrading N-central agents after applying the server hotfix.
Reviewing systems for indicators of compromise.
Contacting N-able Support immediately if evidence of compromise is discovered.
Engaging internal incident response teams if malicious activity is identified.
N-able has published several artifacts that administrators should investigate during incident response.
Endpoint Artifacts:
Presence of a cloudflared service.
A suspicious svchost.exe located within the user's Documents folder.
Network Indicators:
Administrators should review historical network logs for inbound or outbound communication involving the malicious IP addresses identified by the vendor:
173[.]249[.]252[.]200
87[.]249[.]138[.]34
37[.]19[.]210[.]32
37[.]153[.]90[.]88
92[.]118[.]112[.]181
68[.]235[.]46[.]214Β
Organizations should also review:
Authentication logs
Administrative account creation or modification
Take Control session activity
Remote management logs
Windows service installation events
To assist affected organizations running N-central, the vendor has provided a detection template for CVE-2026-18577, which organizations can use to help identify potential compromise.
Rapid7 customers
Exposure Command, InsightVM, and Nexpose
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-18577 and CVE-2026-18556 with vulnerability checks available in the August 4 content release. Note that potential check type must be enabled in the scan template before scanning.
Updates
August 4, 2026: Initial publication.
August 4, 2026: Updated Rapid7 customers section to reflect the availability of vulnerability checks.
August 7, 2026: Updated the Overview and Rapid7 Customers sections to indicate addition of CVE-2026-18556 to CISA KEV and availability of vulnerability checks.
August 14, 2026: Updated the Overview and Mitigation guidance sections to include the new vendor guidance that 2026.3 Hotfix 2 supersedes the original 2026.3 Hotfix 1.
On July 29, 2026, the Ruby on Rails project published a security advisory for CVE-2026-66066, a critical vulnerability affecting Active Storage image processing when used in conjunction with the libvips image processing library. The vulnerability has a CVSSv4 score of 9.5 and is classified as Initialization of a Resource with an Insecure Default (CWE-1188). An unauthenticated attacker may be able to leverage CVE-2026-66066 and read files accessible to the Rails application process, potentially exposing secrets that could enable remote code execution (RCE) or access to connected systems.
An application is affected when it uses libvips for Active Storage image processing and accepts image uploads from untrusted users. Rails notes that generating image variants is not a separate requirement for exposure. Vips is the default Active Storage variant processor for applications configured with Rails 7.0 or later defaults. According to Ethiack, only the Vips processor is affected; applications using Magick are not affected through the reported vector.
As of July 30, 2026, Rapid7 is not aware of exploitation in the wild. Ethiack and GMO Flatt Security, who independently reported the vulnerability, have withheld proof-of-concept code and details of the full attack chain. Public code claiming to exploit CVE-2026-66066 exists, but it is unclear how closely it corresponds to the full attack chain reported privately to Rails. According to the Rails Security Announcement, additional details will be disclosed no later than August 28, 2026. Rapid7 recommends remediating affected applications on an urgent basis, outside of normal patch cycles.
Update #1: On July 31, 2026, Rails published technical details and forensic tools earlier than its planned August 28 disclosure date after several researchers reverse-engineered the attack and published proof-of-concept code.
Technical overview
libvips uses operations to load and save image formats, including operations backed by third-party libraries. Some are marked "unfuzzed" or "untrusted" because they are unsafe for untrusted content. According to Rails, Active Storage did not disable these operations before processing user-supplied files, which may allow a crafted upload to trigger an unsafe operation and disclose files readable by the application.
The attack details published by Rails describe a chain in which an attacker creates a blob through Active Storage's direct-upload endpoint with a false image content type and obtains a genuine signed variation_key from a page that renders an Active Storage representation. A crafted file identifies itself to libvips as a MATLAB level 5 file but to libmatio as a MAT 7.3 HDF5 container. HDF5's External File List then reads bytes from an attacker-selected path, which are rendered as image pixels and returned in the resulting variant. This known chain also requires the deployed libvips build to include the matload operation.
For this documented chain, the Active Storage direct-upload route must be reachable. When Active Storage routes are mounted, the direct-upload route is present by default even if the application's own interface does not use direct uploads. Rapid7 testing found that ordinary server-side attachment does not satisfy this chain because Rails re-identifies the crafted file as MATLAB data before variant processing.
The arbitrary file-read stage does not require knowledge of secret_key_base or a forged variation key. Rapid7 also verified an RCE escalation in which recovered Rails signing material is used to forge an ImageProcessing 1.x variation; this path does not require Marshal deserialization.
The Rails patch that remediates CVE-2026-66066, disables untrusted operations during Active Storage initialization. When ruby-vips is installed, patched versions prevent the application from starting if ruby-vips or libvips is too old to support that protection.
On August 3, 2026, Rapid7 Labs published a full root cause technical analysis of CVE-2026-66066, detailing the full RCE chain and accompanying metasploit module.
Mitigation guidance
Organizations running affected Ruby on Rails applications should upgrade to a fixed Active Storage release and ensure libvips is 8.13 or later. Updating Rails or Active Storage alone is not sufficient when an older libvips version is installed.
Rails has published forensic tools to assess whether an application was vulnerable and search Active Storage data for crafted files. Because scheduled cleanup of unattached blobs may remove evidence, Rapid7 recommends beginning forensic assessment promptly.
The Rails advisory identifies patched Active Storage releases 7.2.3.2, 8.0.5.1, and 8.1.3.1. The fixed Rails releases are:
Rails branch
Affected versions
Fixed version
Rails 7.x
7.0.0 through 7.2.3.1
7.2.3.2
Rails 8.0.x
8.0.0 through 8.0.5
8.0.5.1
Rails 8.1.x
8.1.0 through 8.1.3
8.1.3.1
The Rails advisory lists all Active Storage releases earlier than 7.2.3.2 as affected, which includes releases before Rails 7.0. Ethiack reports that Rails 6.0.0 through 6.1.7.10 may be affected when Active Storage is configured to use Vips, and Rapid7 has verified that the known attack works on the Rails 6.0 and 6.1 branches under that non-default configuration. Rails has not published fixed releases for branches earlier than 7.2, so affected applications on those branches should migrate to a supported fixed branch or apply the applicable workaround below.
When ruby-vips is installed, organizations should ensure it is 2.2.1 or later. Rails advises affected organizations to replace secret_key_base and other secrets accessible to the application process, including the Rails master key and the credentials it decrypts, storage service credentials, database credentials, and third-party service tokens or keys. Replacing secret_key_base expires active sessions and affects encrypted and signed cookies, signed global IDs, and Active Storage URLs.
As a temporary workaround on libvips 8.13 or later, organizations can set VIPS_BLOCK_UNTRUSTED or, with ruby-vips 2.2.1 or later, call Vips.block_untrusted(true) from an initializer. For libvips versions earlier than 8.13, Rails states that the only workaround is to remove the libvips dependency.
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-66066 with vulnerability checks expected to be available in the July 31 content release.Β
Updates
July 30, 2026: Initial publication.
July 31, 2026: Updated with technical details and forensic resources published by Rails, and clarified the affected version range.
August 3, 2026: Added a Technical analysis section for the new Rapid7 Analysis.
On July 22, 2026, Check Point published a security advisory for multiple vulnerabilities affecting Security Management, Multi-Domain Management, and firewall products. The most urgent of these is CVE-2026-16232, an authentication bypass in the SmartConsole login process classified as improper authentication (CWE-287). CVE-2026-16232 has been assigned a critical CVSS score of 9.1. The vulnerability allows an unauthenticated remote attacker to obtain an application login token and authenticate to the management server with full administrative privileges, enabling modification of security policies and configurations.
Check Point has confirmed that CVE-2026-16232 is being actively exploited in the wild, affecting what the vendor describes as a small number of customers. Remote exploitation requires network access to the Management Server IP address in environments that do not restrict Trusted Clients. On the same day as the advisory, CVE-2026-16232 was added to the U.S. Cybersecurity and Infrastructure Security Agency's (CISA) list of known exploited vulnerabilities (KEV), with a remediation due date of July 25, 2026, giving organizations only three days to respond.
The advisory addresses three vulnerabilities in total:
CVE
CVSS
Description
Affected Products
Exploitation Status
CVE-2026-16232
Vendor: 9.3 (Critical) CISA: 9.1 (Critical)
Authentication bypass via SmartConsole application token
Security Management, Multi-Domain Management
Exploited in the wild
CVE-2026-62144
Vendor: 9.3 (Critical) CISA: 9.1 (Critical)
Management authentication bypass and privilege escalation
Security Management, Multi-Domain Management
No known exploitation
CVE-2026-62145
7.5 (High)
Local privilege escalation in GaiaOS WebUI
Firewall, Multi-Domain Management, Multi-Domain Log Server
No known exploitation
Compromise of a Security Management Server is particularly consequential because it sits at the top of the trust hierarchy. An attacker with administrative access can modify security policies across managed gateways, alter administrator permissions, manipulate VPN configurations, and potentially disable or tamper with logging and monitoring. According to Check Point's advisory, the vulnerabilities were discovered during a routine internal review, with subsequent analysis revealing that CVE-2026-16232 had been exploited prior to the availability of a patch.
Check Point network security products have been targeted by multiple in-the-wild vulnerabilities over the past two years. In June 2026, CVE-2026-50751, a critical authentication bypass in Check Point Remote Access VPN, was exploited in the wild and added to the CISA KEV. In May 2024, CVE-2024-24919, a high-severity information disclosure vulnerability in Check Point Quantum Security Gateways, was also exploited in the wild. Organizations running affected Check Point management products should apply the available hotfixes on an emergency basis.
Technical analysis
On July 28, 2026, Rapid7 Labs published a full root cause technical analysis of CVE-2026-16232. Our analysis details the vulnerability and how an unauthenticated attacker can exploit the vulnerability to login to a vulnerable appliance via SmartConsole with full admin privileges.
Mitigation guidance
Check Point released Jumbo Hotfixes on July 22, 2026, to remediate CVE-2026-16232, CVE-2026-62144, and CVE-2026-62145. Organizations running affected versions of Security Management or Multi-Domain Management should install the latest Jumbo Hotfix on an emergency basis, without waiting for a regular patch cycle to occur.
The following versions are affected by CVE-2026-16232:
R82.10: fixed in Jumbo Hotfix Take 36 and later
R82: fixed in Jumbo Hotfix Take 118 and later
R81.20: fixed in Jumbo Hotfix Take 158 and later
R81.10, R81, R80.30, R80.20, R80.10, R80, and R77.30: no fix specified
CVE-2026-62144 and CVE-2026-62145 affect the same release families (R81.10, R81.20, R82, R82.10) per the vendor advisory, with older versions also impacted.
Smart-1 Cloud customers are already protected according to Check Point. For on-premises deployments where the hotfix cannot be applied immediately, Check Point recommends the following steps to reduce exposure:
Restrict Trusted Clients (GUI clients) to trusted IP addresses or subnets
Protect Management access with a firewall and restrict access to trusted IP addresses
Verify that implied rules for control connections are enabled
These mitigations reduce the attack surface, but they do not address the underlying vulnerability. Installing the Jumbo Hotfix remains the priority.
Rapid7 strongly recommends investigating for signs of compromise even after applying the hotfix, particularly in environments where the Management Server has been accessible from the internet. Organizations should review administrator, SmartConsole, API, and application token activity, and search logs for the published indicators of compromise listed below.
For the latest mitigation guidance, please refer to the vendor advisory.
Rapid7 customers
Exposure Command, InsightVM, and Nexpose
Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-16232, CVE-2026-62144, CVE-2026-62145 with authenticated vulnerability checks available in the 24 July content release.
Indicators of compromise
Check Point has published the following IP addresses associated with observed exploitation of CVE-2026-16232:
151.241.99[.]207
151.241.99[.]233
158.62.198[.]182
192.142.10[.]99
139.28.37[.]250
194.213.18[.]137
Per the vendor, the presence of these indicators should prompt investigation, but the absence of these addresses does not confirm that an environment was unaffected.
Updates
July 23, 2026: Initial publication.
July 24, 2026: Updated to reflect availability of vulnerability checks.
July 28, 2026: Added a Technical analysis section for the new Rapid7 Analysis.
Microsoft is publishing 622 vulnerabilities on July 2026 Patch Tuesday, including a record-breaking 416 Windows vulnerabilities. Microsoft is aware of exploitation in the wild for two of the vulnerabilities published today, both of which are listed on CISA KEV, as well as public disclosure for one other. As usual, browser vulns are not included in the Patch Tuesday count above. Rapid7 noted last month that Microsoft no longer enumerates Chromium CVEs in the Security Update Guide. However, Microsoft has now taken the pursuit of minimalism much further, since todayβs Security Update Guide no longer lists out even Microsoft vulnerabilities! Instead, we now receive a summary table of vulnerability counts by product family, as well as a new slimline βNotable CVEsβ section. All of this only serves to illustrate the recent industry-wide trend of exploding vulnerability report counts, with an associated uptick in the publication of remediations as a trailing indicator.
SharePoint: critical auth bypass by Rapid7
Today sees the publication of CVE-2026-55040, a critical authentication bypass in Microsoft SharePoint. Discovered by Rapid7 Senior Principal Security Researcher Stephen Fewer, and published today in coordination with Microsoft, this vulnerability is the first in a pair of exploits which, when chained together, can lead to unauthenticated remote code execution against a vulnerable SharePoint server. Patches are available for SharePoint Server Subscription Edition, 2019, and 2016. As the full Rapid7 blog post sets out, the second vulnerability in the full RCE chain remains embargoed for now, with Microsoft expected to publish patches for that second vulnerability as part of Patch Tuesday August 2026. Microsoft noted: βWe would like to thank Rapid7 for responsibly reporting this issue through coordinated vulnerability disclosure.β
SharePoint: zero-day EoP
Itβs a rare Patch Tuesday which doesnβt include multiple SharePoint fixes, and today is no exception. Microsoft is aware of existing in-the-wild exploitation of CVE-2026-56164, where successful exploitation allows an attacker to elevate privileges over a network, with no existing privileges required, and low attack complexity since βan attacker does not require significant prior knowledge of the system, and can achieve repeatable successβ. This is as good an example as any that a relatively low CVSS v3 base score (5.3) may be an imperfect signal concealing something much spicier, and Microsoft acknowledges that possibility by assigning a severity rating of Important. Microsoft certainly intended to list CVE-2026-56164 in the new Notable CVEs section of the Security Update Guide instead of erroneously listing CVE-2026-56155 twice, and itβs likely that this will be corrected shortly.
Whatβs the opposite of coordinated disclosure?
After years of relative stability, the Patch Tuesday process has experienced significant turbulence so far in 2026. As well as the AI-fuelled exponential growth of vulnerability reporting and discovery, Microsoft is grappling with the emergence of a series of vulnerabilities disclosed in such a way as to bring maximum discomfort for Redmond. Pseudonymous researcher Nightmare Eclipse dropped another Defender elevation of privilege vulnerability in the hours following Patch Tuesday June 2026, which Microsoft subsequently published and patched as CVE-2026-50656, along with a terse acknowledgement of the vulnerabilityβs celebrity nickname of RoguePlanet. Recently, Nightmare Eclipse has given conflicting estimates of what sort of surprises Microsoft can expect today, as well as claiming that the CVE-2026-50656 patches introduce a new avenue for a disk exhaustion attack. Today,Β a new proof of concept for a further vulnerability nicknamed LegacyHive has emerged from the same source, which appears to allow a non-privileged user to mount another userβs user hive.
Microsoft BitLocker receives patches today for a publicly-known security feature bypass vulnerability. The advisory for CVE-2026-50661 explains that an unauthorized attacker with physical access to the target machine can bypass Windows BitLocker. While Microsoft doesnβt confirm either way, itβs very probable that this is a patch for the GreatXML vulnerability which Nightmare Eclipse announced the day after Patch Tuesday June 2026.
Active Directory Federation Services: zero-day EoP
Active Directory administrators should note the emergence today of CVE-2026-56155, an exploited-in-the-wild elevation of privilege vulnerability in Active Directory Federation Services which allows an authorized attacker to elevate privileges locally. Eight other vulnerabilities are also published today in Active Directory Federation Services, all ranked as Important on Microsoftβs proprietary severity ranking scale. The advisory doesnβt explicitly describe the location of the attacker, but itβs likely that an attacker would need an existing toehold on the target system to chain together with the elevation of privilege opportunity on offer here.
Age of Empires II: RCE
Historically, Patch Tuesday hasnβt seen too many security patches for video games. However, Age of Empires II: Definitive Edition is a new entrant to the Microsoft CVE roster today. Veteran AoE2 players may well be familiar with dangerous opposition early game strategies such as the Persian Town Center nuisance or the Aztec monk rush, but anyone who opens a malicious game scenario file without applying the patch for CVE-2026-50663 might suffer a serious defeat. Successful exploitation allows an attacker to place malicious files in unexpected locations, potentially enabling code execution on the target system.
Microsoft lifecycle update
As Rapid7 noted last month, there are some significant Microsoft product lifecycle changes taking place in mid-July. SQL Server 2016 moves beyond regular extended support and into the pay-to-play Extended Security Updates (ESU) phase from July 15, 2026, and its older sibling SQL Server 2014 moves into the third and final year of ESU. Also on July 14, 2026, SharePoint Server 2016 and 2019 reach extended end date, and since thereβs no ESU available, the only remaining option for fully-supported self-hosted SharePoint after today is SharePoint Subscription Edition. The July 2026 lifecycle casualties continue with Project Server 2016 and 2019, Dynamics GP 2016 and 2016 R2, InfoPath 2013, and SharePoint Designer 2013, which also all reach their Extended End Dates, ending their supported lifecycles. Visual Studio 2022 Version 17.12 Long-Term Servicing Channel (LTSC) reaches its release end date on July 14, leaving either the Visual Studio 2022 current channel or an upgrade to Visual Studio 2026 as supported options.
Security leaders rarely struggle to gather data, but they often struggle to turn that data into something clear and meaningful for the business. In a typical week, a CISO might receive a report listing hundreds or even thousands of vulnerabilities, most of them accompanied by CVSS scores that make the entire list look urgent, while also managing the wider set of operational, regulatory, and strategic demands that already come with the role.
That difficulty becomes more obvious when the same information has to be carried into the boardroom, where the questions are rarely about CVE IDs or exploit counts in isolation. What leadership wants to understand is whether the organizationβs revenue, uptime, legal exposure, or broader resilience could be affected, and how quickly those risks need to be addressed.
This is where many security programs lose momentum, because the technical view of severity does not always line up neatly with the business view of consequence. Bridging that gap has traditionally been slow, manual work, which is one reason AI is starting to matter more in vulnerability management: it can help translate technical findings into business context that is clearer, faster to act on, and easier for leadership to understand.
Why CVSS alone does not reflect real-world business risk
For years, the industry has relied on CVSS as a quick way to judge urgency, and while the framework does account for factors such as attack vector, attack complexity, and other attack requirements, the score is still calculated in isolation and often misses the conditions that shape real risk inside an organization. A CVSS 9.8 vulnerability affecting a legacy printer in a segmented branch office may look critical on paper, but it is unlikely to carry the same business impact as a 7.5 vulnerability affecting an internet-facing database that holds sensitive customer data.
One of the long-standing weaknesses of static scoring is that it tells you how severe a flaw may be in theory, but not how much disruption it could cause in your own environment, how exposed the affected asset is, or how closely it is tied to a revenue-generating or business-critical process. That is where AI becomes more useful, because it can add the missing context that helps security teams judge not just how serious a vulnerability looks, but how much it matters in practice.
Machine learning models can now process a much broader set of inputs, including attacker activity, exploit availability, internal network topology, and the business value attached to the asset or process involved. Rather than leaving teams with a static queue of scores, that creates a live view of risk shaped by reachability, exposure, and business consequence, making it easier to separate technical severity from actual organizational risk.
How AI helps connect vulnerabilities to business impact
One of the more practical ways AI can improve vulnerability management is by helping security teams connect technical findings to the parts of the business they actually affect. A vulnerability tied to an obscure IP address may not mean much on its own, but the picture changes quickly when that asset is identified as part of a regional payment system, a customer-facing portal, or a supply chain application the business depends on. That kind of asset attribution has traditionally taken time, context, and manual investigation. AI can help shorten that process by linking technical findings to business function much more quickly.
Instead of relying only on severity scores or yesterdayβs alerts, AI can weigh a broader set of signals, including exploit activity, attacker behavior, asset exposure, and internal topology, which gives security teams a more grounded way to judge where risk is most likely to become operationally significant. The benefit is not simply speed, but a clearer picture of which vulnerabilities are most likely to affect revenue, uptime, or business continuity if they are left unresolved.
At the leadership level, this same approach can help turn a large volume of technical output into something more usable. Rather than forcing CISOs to manually translate thousands of low-level alerts into board-facing language, AI can support that reporting by summarizing likely business impact, highlighting where exposure is growing, and making it easier to explain how remediation work is reducing financial and operational risk.
Two vulnerabilities, two very different business outcomes
To see how this plays out in practice, it helps to compare two vulnerabilities that might appear similarly urgent in a standard scanner, but look very different once business context is added.
Vulnerability A: The ghost in the machine
A scanner flags a CVSS 9.8 critical remote code execution flaw in an aging media server. On paper, that score suggests immediate attention. Once more context is added, the picture changes. The asset sits on a segmented guest Wi-Fi VLAN, has no path to the corporate core, and has not been linked to in-the-wild exploitation for more than two years. In practical terms, the business impact is low. The issue still needs to be addressed, but it is unlikely to justify urgent remediation ahead of higher-consequence exposures.
Vulnerability B: The quiet threat
A second finding carries a lower CVSS 7.2 high severity score, but affects a common web framework running on the organizationβs primary customer portal. When AI correlates that vulnerability with asset and business context, the risk profile changes quickly. The portal is identified as a critical business process, estimated to support $250,000 in transactions per hour, while external signals point to growing exploit interest around the same framework. In that case, the business impact is far more serious. What looks like a lower-priority technical issue becomes a potential source of revenue disruption measured in millions per day.
This is where AI-assisted prioritization becomes useful. It helps teams move beyond the assumption that the highest score always deserves the fastest response and instead focus on the vulnerabilities most likely to create operational or financial harm. In practice, that means spending less time working through a queue in score order and more time reducing the exposures that matter most to the business.Β
How AI helps CISOs explain vulnerability risk in business terms
When security leaders can move beyond reporting how many patches were deployed and begin showing how exposure is changing in financial or operational terms, the conversation becomes much more useful. A reduction in mean time to remediate may matter to a security team, but it carries more weight at the leadership level when it is tied to a lower likelihood of downtime, reduced regulatory exposure, or less risk to a revenue-generating service.
When vulnerability data is tied to business context, it becomes easier to justify automation, tooling, or headcount based on their contribution to resilience, continuity, and measurable risk reduction, rather than on activity alone. At that level, the conversation is less about severity scores and more about what is exposed, what it could affect, and where action matters most.
One of the more practical benefits of AI is that it can help security teams explain risk in a way leadership can act on. Instead of adding another layer of technical output, it can support clearer reporting on why one issue matters more than another, what is most likely to affect the business, and where action should come first.
As attack surfaces expand and exploit timelines continue to shrink, the gap between technical findings and business understanding will only become harder to manage. Organizations that can connect those two views more effectively will be in a much stronger position to prioritize the right work, explain risk more clearly, and make vulnerability management a more meaningful part of business decision-making.
Microsoft is publishing 200 vulnerabilities on June 2026 Patch Tuesday. Microsoft is not aware of exploitation in the wild for any of these vulnerabilities, and is aware of public disclosure for three. This is similar to last monthβs Patch Tuesday, however several of last monthβs vulnerabilities ended up on CISA KEV in the days following their publication. So far this month, Microsoft has provided patches to address 360 browser vulnerabilities, which is an order of magnitude more than has been typical in any given month over the past few years. As usual, browser vulns are not included in the Patch Tuesday count above. Indeed, the vast, and presumably sustained, uptick in the number of browser vulnerabilities has led to Microsoft no longer enumerating Chromium CVEs in the Security Update Guide. Other vulnerability categories, especially Linux kernel vulnerabilities, are seeing a similar increase in AI-assisted vulnerability reports.
What's the opposite of coordinated disclosure?
In recent weeks, an independent vulnerability researcher going by the pseudonym Nightmare Eclipse has attracted significant attention by publishing details of six Microsoft vulnerabilities, including elevation of privilege vulnerabilities in Defender, and a Secure Boot disk encryption bypass. The researcher provided full proof-of-concept code for some, and providedΒ significant-but-incomplete detail around the path to exploitation for others. Microsoft has confirmed that these disclosures were not coordinated, and it is clear that the relationship between this researcher and Microsoft is less than cordial. Two of the disclosures emerged in the hours after last monthβs Patch Tuesday, which provides maximum visibility, while limiting Microsoftβs ability to respond without out-of-cycle patches.
At time of writing, Microsoft has provided mitigation advice and patches for CVE-2026-33825, CVE-2026-45585, CVE-2026-45498, and CVE-2026-41091, leaving only two elevation of privilege vulnerabilities unpatched, known as MiniPlasma and GreenPlasma. However, a recent blog post by Nightmare Eclipse with the title β7β has been widely interpreted to mean that there is at least one more vulnerability to come. The post contained no content other than an image of Albert Vesker, a character from the Resident Evil video game series who formerly worked as a researcher for a technology corporation before going rogue. Any inference around the possible meaning of the image is left as an exercise for the reader.
Given the timing of last monthβs disclosures in the hours following Patch Tuesday, a further high-friction disclosure today would perhaps be unsurprising. Indeed, a new blog post and a new GitHub account from the same researcher have emerged in the hours following Microsoftβs publication of the June 2026 Patch Tuesday updates. The apparent seventh disclosure is nicknamed RoguePlanet, and appears to describe another elevation of privilege to SYSTEM in Defender.
It is not at all difficult to understand why Microsoft and many blue team practitioners are deeply alarmed by the partial or even full disclosure of proof-of-concept code for an ongoing series of vulnerabilities affecting fully-patched Windows systems. However, multiple leading voices in the broader vulnerability disclosure community have expressed concern that Microsoftβs invocation of the Digital Crimes Unit in a May 27, 2026 blog post may yet prove counterproductive, especially if it causes other researchers to back away from mutually beneficial engagements with MSRC. A few days later, MSRC issued a further statement clarifying that they have no intention of pursuing action against security researchers, but only those who break the law or engage in malicious activity causing real harm. For now, one safe conclusion is that this unusually sensational Microsoft vulnerability management story arc is far from over.
HTTP/2: denial of service
Every so often, a new round of denial of service vulnerabilities emerge which affect web servers implementing HTTP/2 and HTTP/3 standards. This class of vulnerabilities is likely to expand further as researchers, including the discoverers of CVE-2026-49160, use advances in LLM capability to probe not just specific software, but also the standards on which software rests. Microsoft warns that exploitation leads to uncontrolled resource consumption over a network, and expects that exploitation is more likely. The advisory credits both a third-party research firm and OpenAIβs Codex.
Microsoft has not yet directly addressed another HTTP/2 vulnerability which allows trivial denial-of-service against the default HTTP/2 configuration of multiple web server platforms, including Microsoft IIS. CVE-2026-49975, also known as HTTP/2 Bomb, became public knowledge a week ago. This denial of service works by exhausting memory on the target server, and unlike a distributed denial of service attack, there is no requirement that an attacker control a large amount of bandwidth. Patches are available for NGINX and Apache, with IIS presumably to follow at some point. If practically possible, disabling HTTP/2 is a valid mitigation.
PowerToys: SYSTEM EoP
The Microsoft PowerToys utility provides a wide variety of useful control and configuration options for Windows power users which arenβt otherwise easily accessible. It turns out that PowerToys also offers an undocumented extra: local elevation of privilege to SYSTEM via successful exploitation of CVE-2026-42902. It is worth noting that the fix was included in PowerToys v0.99.1 on April 29, 2026, without any apparent mention in the release notes. Attackers with patch-diffing toolkits may well take note of this discrepancy.
Microsoft lifecycle update
There are no significant Microsoft product lifecycle changes this month. SQL Server 2016 moves beyond regular extended support and into the pay-to-play Extended Security Updates (ESU) phase after July 14, 2026. On that same date, SharePoint 2016 and 2019 will also move past extended support, but since thereβs no ESU available, the only remaining option for fully-supported self-hosted SharePoint after the middle of next month will be SharePoint Subscription Edition.
Microsoft is publishing 137 vulnerabilities on May 2026 Patch Tuesday. Microsoft is not aware of exploitation in the wild or public disclosure for any of these vulnerabilities. So far this month, Microsoft has provided patches to address 133 browser vulnerabilities, which are not included in the Patch Tuesday count above.
Windows Netlogon: critical RCE
Anyone responsible for securing a domain controller should prioritize remediation of CVE-2026-41089, which is a critical stack-based buffer overflow in Windows Netlogon with a CVSS v3 base score of 9.8. Exploitation leads to execution in the context of the Netlogon service, so thatβs SYSTEM privileges on the domain controller. For most pentesters, thatβs the point at which the customer report more or less writes itself. No privileges or user interaction are required, and attack complexity is low, which suggests that creation of a reliable exploit might not be especially difficult for anyone with knowledge of the specific mechanism.
Microsoft assesses exploitation as less likely, but since those exploitability assessments are provided without an accompanying explanation, itβs not clear how much reassurance defenders should take. Anyone who remembers the much-discussed CVE-2020-1472 (aka ZeroLogon) back in 2020 will note that CVE-2026-41089 offers an attacker more immediate control of a domain controller. Patches are available for all versions of Windows Server from 2012 onwards.
Windows DNS Client: critical RCE
An attacker looking for a master key for Windows assets will pay attention to CVE-2026-41096, a critical RCE in the Windows DNS client implementation. A modern computer talks to DNS the way a child in the back of a car asks βare we there yet?β The variable and complex structure of DNS responses means that DNS client implementations are also complex and thus prone to flaws. Microsoft assesses exploitation as less likely, and we can hope that modern mitigations such as heap address randomization and optional-but-recommended encrypted channel DNS will make weaponization significantly more challenging by putting barriers across specific paths to exploitation. The DNS client on Windows runs as the NetworkService role, rather than SYSTEM, but a foothold is a foothold, and skilled attackers expect to chain exploits together.
JIRA/Confluence Entra ID auth plugin: critical EoP
If youβre still self-hosting Atlassian JIRA or Confluence and relying on the Microsoft Entra ID authentication plugin, youβll want to know about CVE-2026-41103. This critical elevation of privilege vulnerability allows an unauthorized attacker to impersonate an existing user by presenting forged credentials, thus bypassing Entra ID. Microsoft expects that exploitation is more likely. Even if you canβt always find what you want on the corporate Confluence, a motivated attacker probably will. Curiously, the patch links on the advisory lead to older versions of the plugins published in 2024.
Microsoft WARP team
Microsoftβs WARP team is credited with multiple critical vulnerabilities today, after making their first appearance in MSRC advisory acknowledgements in last monthβs Patch Tuesday. We can speculate that they likely know a great deal about the current state of AI-powered vulnerability research as it applies to Microsoft products.
Microsoft lifecycle update
There are no significant Microsoft product lifecycle changes this month. Microsoft .NET 9 STS (Standard Term Support, as distinct from Long Term Support) was originally scheduled to move past the end of support in May 2026, but late last year, Microsoft granted a six-month extension, so that .NET 9 STS now reaches end of support on November 10, 2026.
Anthropicβs Project Glasswing has sparked plenty of discussion about what AI might soon do for vulnerability discovery, but the more useful question for most security teams is how to prepare for, and more importantly seize the opportunity of, what comes next.
Β As we wrote in our earlier blog, What Project Glasswing Means for Security Leaders, AI is becoming more capable of finding software flaws. The pressure that follows lands on the teams responsible for deciding what matters, validating risk, assigning ownership, and getting remediation moving across environments that were already hard to manage. We believe that the organizations that will benefit most from the next wave of AI will be the ones that understand their environment well enough to use these emerging AI models with intent, rather than layering them onto immature processes and hoping that speed alone will solve the backlog.
What this moment means for security teams
The number of publicly tracked software vulnerabilities has broken records almost every year over the last decade, while supply chain risk has continued to rise. Most teams were already feeling the strain of more findings than they could process cleanly. The Common Vulnerabilities and Exposures (CVE) program, the standard system for identifying and tracking known vulnerabilities, recorded 48,185 disclosures in 2025, a 20% increase over 2024, with roughly 40% of those disclosed vulnerabilities rated high or critical.Β
The pace in 2026 was already working out to hundreds of new CVEs per day when those figures were cited. That tells you something important about the current environment: the challenge has not necessarily beenΒ a lack of findings, but instead converting a growing stream of findings into measurable risk reduction.
The reality is that very few organizations are going to hand a model free rein over their most sensitive environments the minute those capabilities become more widely available. Trust will be built in stages: early adoption is much more likely to focus on backlog reduction, triage support, patch testing, and repetitive lower-tier remediation work that consumes time without carrying the same level of operational risk as the most critical systems in the business. That is a more realistic starting point, and it leads to a more useful question. Before teams apply AI more broadly, they need to understand their environment well enough to use it intentionally.
Establish the foundation before layering in AI
The promise from Project Glasswing and almost every other AI-powered security initiative is quite similar: leverage AI to identify patterns, summarize risk, suggest fixes, and speed up repetitive work. Regardless of technology, successΒ still depends on how well an organization understands its environment, the context around each finding, and the process used to act on it.Β
A model can generate more output than a team ever could on its own, but that output becomes noise if the organization cannot answer basic questions about scope, ownership, criticality, and exposure. Teams need a clear, continuously updated picture of the environment before they can decide where AI should be applied, what should remain human-led, and which parts of the backlog are safe to push through more automated workflows.
The AI landscape is already shifting fast, and it will keep shifting, which is why this moment should prompt a more preemptive and resilient strategy rather than another round of tooling hype. Chasing each new capability as it arrives will inevitably force teams to keep reorganizing around the latest announcement. A stronger path is to get the foundation right first - understand the environment, the attack paths, and the assets that matter most; but most importantly, establishing the process and the people behind making these decisions. Then use AI where it meaningfully improves speed, consistency, and focus.
Why Attack Surface Management should be part of that foundation
A strong foundation starts with visibility. Security teams need a live picture of what exists in the environment, what is exposed, how assets connect to one another, and which systems carry the greatest business impact if something goes wrong. That is where Attack Surface Management becomes central. Rapid7βs approach through Surface Command is built around a continuous view of the attack surface across the digital estate, which helps teams understand where exposures sit and how they relate to internet-facing, business-critical, or otherwise high-impact systems.
That matters for AI adoption just as much as it matters for day-to-day security operations. Teams cannot apply AI strategically if they are guessing about which parts of the environment are lower priority, which assets belong to which owners, or where a newly disclosed flaw could create real business risk. A better view of the attack surface gives organizations the context they need to segment the problem properly. That makes it far easier to start with the right use cases, whether that is backlog reduction in lower-impact systems, targeted prioritization of exposed assets, or faster triage where the risk picture is already well understood.
Ownership is part of that foundation too. Remediation slows down when no one can quickly identify who owns the affected application, environment, or workflow. Security teams already lose time there today, and AI will only make that bottleneck more visible if it starts surfacing issues faster than organizations can assign them. Attack Surface Management helps turn that ambiguity into something more actionable by tying exposure to environment context and likely ownership.
How Vulnerability and Exposure Management turns visibility into action
Once the environment is understood, teams still need a way to move from findings to outcomes. That is where Vulnerability and Exposure Management becomes the operating layer that keeps the work grounded.
The biggest value here is not simply collecting more vulnerability data. It is targeted prioritization and validation. When a disclosure lands, teams need to know whether the issue affects an exposed asset, whether there is evidence of exploitation or attacker interest, whether the impacted system is business-critical, and whether existing controls already reduce some of the risk. That is the kind of context that helps organizations decide what deserves immediate attention and what can be handled through a normal remediation cycle.
This is where artificial intelligence can help move remediation forward faster. Instead of asking teams to manually connect exploit signals, asset criticality, and vulnerability intelligence on their own, AI can distill that context directly in the remediation workflow. That makes it easier to understand why an issue matters, what the likely impact is, and what to do next, which shortens the gap between discovery and a confident decision on how to respond.
We expect most organizations to use AI to assist with, or in some cases take over, lower-tier triage, backlog cleanup, summary generation, and patch support in areas where the workflow is already established and the blast radius is more manageable. Human experts still stay closest to the most critical business logic, the most sensitive environments, and the most complex remediation paths. That is a practical adoption model, and it only works when the organization already has enough structure in place to know where those boundaries are.
Curated vulnerability intelligence changes the quality of decisions
That kind of deliberate adoption only works when teams can make better decisions, faster. Security teams need more than severity scores and a long list of CVEs. They need enough context to understand what matters, what can wait, and where action will reduce real risk fastest. As Rapid7 outlined in The Power of Curated Vulnerability Intelligence, the goal is to identify the vulnerabilities that actually matter and give teams enough context to act with confidence.
That intelligence provides a form of validation that most teams need badly as disclosure volume rises. It helps answer whether a finding is tied to active attacker interest, whether proof-of-concept activity is public, whether the asset is exposed, and whether delaying a patch creates unacceptable risk. It also supports the decisions that happen in the gap between discovery and full remediation. When a patch is delayed because of change controls, testing constraints, or lack of a vendor fix, teams still need to reduce exposure. Curated intelligence helps them decide whether to use segmentation, access restrictions, configuration changes, added monitoring, or virtual patching while the longer-term fix is being worked through.
That is one of the clearest ways Rapid7 helps customers move from data to outcomes. Intelligence is fused into the workflow so teams can prioritize with more precision and validate their actions against real threat context, not just generalized scores.
How runtime and remediation fit into the broader AI story
There is another part of this story that matters as organizations think more seriously about AI-driven security operations. As AI shapes the way teams handle exposures earlier in the lifecycle, context of application at runtime matters more too.
To make that foundation complete, organizations need to look beyond static posture and bring runtime validation into the picture. When teams can identify which vulnerabilities and misconfigurations are actively exploitable in production, and map sensitive data and identity access to real-world attack paths, they get a much clearer view of actual risk. Security teams need to understand what is vulnerable, how systems behave when live, and where unusual activity may suggest a problem is moving toward exploitation. With that runtime context in place, teams can spend less time chasing theoretical vulnerabilities and more time focusing on the exposures that are actively creating risk in live environments.Β
That connection between exposure, intelligence, remediation, and runtime behavior is where AI starts to become genuinely useful rather than simply impressive. It supports a more intentional model of security decision-making, one that narrows the gap between what is found, what matters, and what happens next.
What security leaders should do now
This is a good time for security leaders to step back and ask a more disciplined set of questions.
Do we understand our environment well enough to direct AI toward the right problems?Β
Can we clearly separate higher-risk, higher-impact assets from the parts of the backlog that are mostly operational drag?Β
Is threat intelligence embedded in how we interpret findings, or are we still depending too heavily on raw severity?Β
Can we identify ownership fast enough for AI-assisted triage to result in meaningful action?Β
Are compensating controls part of the plan when remediation cannot happen immediately?
Those questions shape the quality of everything that follows.
Glasswing creates a real opportunity for security teams that are ready to use AI with more intention. AI can move work forward faster, reduce manual drag, and absorb classes of issues that currently consume time without improving outcomes. The teams that benefit most will not be the ones that rush to apply new models everywhere. They will be the ones that understand their environment, have a clear view of their attack surface, have mature enough workflows to apply AI where it makes sense, and can measure whether the actions taken actually reduced exposure.
Rapid7βs approach to building resilience is grounded in those same needs. Attack Surface Management provides the environmental foundation, Vulnerability Management drives prioritization and action, curated vulnerability intelligence strengthens validation and decision-making, AI-generated remediation insights compress the time from discovery to the next step, and runtime security adds context where live behavior matters. Together, those pieces help customers build a security program that is ready for AI rather than constantly reacting to it.
Microsoft is publishing 167 vulnerabilities on April 2026 Patch Tuesday. Microsoft is aware of exploitation in the wild for one of todayβs vulnerabilities, and public disclosure for one other. Microsoft evaluates 19 of the vulnerabilities published today as more likely to see future exploitation. So far this month, Microsoft has provided patches to address 80 browser vulnerabilities, which are not included in the Patch Tuesday count above.
Increasing volumes of vulnerabilities
Regular Patch Tuesday watchers will know that these vulnerability totals are significantly higher than usual, especially the browser numbers. Late last week, Microsoft published patches to resolve more than 60 browser vulnerabilities in a single day, which is a new record in that very specific category.
It might be tempting to imagine that this sudden spike was tied to the buzz around the announcement a week ago today of Project Glasswing, but this is not the case. Edge is based on the Chromium engine, and the Chromium maintainers acknowledge a wide range of researchers for the vulnerabilities which Microsoft republished last Friday. This reflects a significant industry-wide uptick in the volume of vulnerability reports over the past few weeks. A safe conclusion is that this increase in volume is driven by ever-expanding AI capabilities. We should expect to see further increases in vulnerability reporting volume as the impact of AI models extend further, both in terms of capability and availability.
SharePoint: zero-day spoofing
When everything is changing rapidly, it can be tempting to look to familiar things for comfort. SharePoint admins should start by addressing CVE-2026-32201, an exploited-in-the-wild spoofing vulnerability. The advisory doesnβt offer much detail, but does mention CWE-20: Improper Input Validation and low impact to confidentiality and integrity, with no impact to availability. Of course, the greatest attacker impact is typically achieved by chaining together multiple vulnerabilities that by themselves might not seem so bad.
Ever-increasing novel AI capabilities in offensive cybersecurity now appear to provide real competition for all but the most elite human researchers; if it was ever valid to suppose that a vulnerability with a CVSS v3 base score of 6.5 was unlikely to cause much pain, itβs certainly not a safe defensive assumption in 2026. Patches are available for all supported versions of SharePoint, including SharePoint 2016, which moves beyond extended support on July 14, 2026.
Defender: zero-day elevation of privilege
Microsoft Defender receives a patch today for CVE-2026-33825, a local privilege escalation vulnerability for which Microsoft is aware of public disclosure. Successful exploitation leads to SYSTEM privileges, so this is certainly worth patching sooner rather than later. Microsoft points out that no action should be required to install this update, since the Microsoft Defender Antimalware Platform automatically updates by default. A further silver lining is that systems that have disabled Microsoft Defender are not in an exploitable state. Hopefully, any such system is running a suitable third-party replacement for Defenderβs capabilities.
Windows [I donβt like] IKE: zero-day pre-auth RCE
The Windows Internet Key Exchange (IKE) Services Extensions is the site of CVE-2026-33824, a critical unauthenticated remote code execution vulnerability. Exploitation requires an attacker to send specially crafted packets to a Windows machine with IKE v2 enabled, which could enable remote code execution. Vulnerabilities leading to unauthenticated RCE against modern Windows assets are relatively rare, or weβd see more wormable vulnerabilities self-propagating across the internet. However, since IKE provides secure tunnel negotiation services, for instance for VPNs, it is necessarily exposed to untrusted networks and reachable in a pre-authorization context. Itβs hard to imagine this turning into a rampaging internet-wide worm, but thereβs plenty of scope for initial access abuse, so this IKE vulnerability is still yikes.
The advisory does contain a section with potential mitigations for anyone unable to patch immediately, which center on least-privilege restriction of relevant UDP traffic. This same portion of the advisory also furnishes a helpful link to the definition of the word βmitigationsβ in the MSDN glossary. All versions of Windows back as far as Server 2016 and Windows 10 1607 LTSC receive patches.
The advisory credits both the WARP and MORSE (Microsoft Offensive Research & Security Engineering) teams at Microsoft. MORSE appears in Acknowledgements over the past few years, but today marks the first explicit mention of WARP in a Microsoft security advisory Acknowledgements section; we can speculate that WARP is an internal designator for the Microsoft Windows Enterprise Security Team.
Security leaders rarely struggle to produce data. The challenge is turning that data into something the board can use to make decisions.
Walk into a board meeting with a slide showing 1,200 critical vulnerabilities and 44 internet-facing assets, and you will likely see polite acknowledgment rather than meaningful discussion. The question that follows tends to cut through quickly: what does this mean for the business?
Boards allocate capital based on financial exposure, not vulnerability counts. A list of findings describes workload, but directors are responsible for revenue protection, liability, and risk to the balance sheet. When security reporting remains technical, it sits outside the way investment decisions are made elsewhere in the organization. The issue is less about communication and more about framing the problem in terms the business already understands.
From severity to risk
CVSS measures theoretical severity, but it does not measure business risk. A high score indicates that a flaw could be dangerous, yet it does not tell you whether the vulnerability is reachable in your environment, whether exploit code exists, or whether it is likely to affect revenue in the near term. It answers a useful engineering question, but it does not answer the question the board is asking.
That question is about likelihood and impact. Most enterprise risk frameworks define risk in those terms, and that is how financial decisions are made. The gap becomes clear when two vulnerabilities appear similar on a dashboard but carry very different consequences. A high-CVSS issue on a segmented lab system may present little business risk, while a moderately severe vulnerability on an internet-facing production system with active exploit activity can expose regulated data and revenue streams.
What is often missing in that comparison is threat context. Understanding how attackers behave, which vulnerabilities they are exploiting, and where access paths actually exist changes how risk is interpreted. Active Risk in InsightVM brings those elements together by combining exploit telemetry, attacker behavior, and asset context to estimate the likelihood that a vulnerability will be used. When that likelihood is paired with business impact, the conversation shifts toward exposure rather than severity.
From CVSS scores to financial exposure
Prioritization alone does not translate into board-level decisions. Knowing what is most likely to be exploited is necessary, but it is not sufficient when the goal is to justify investment.
FAIR provides a way to bridge that gap. The model defines risk as a combination of how often a loss event is likely to occur and how much that event would cost. In practical terms:
Annualized Loss Exposure (ALE) = Loss Event Frequency Γ Probable Loss Magnitude
Active Risk informs the likelihood side of that equation by grounding it in observed attacker behavior and exploit activity. FAIR converts that likelihood into financial terms, allowing security teams to describe exposure in a way that aligns with how capital is allocated.
Instead of reporting that a set of vulnerabilities is βhigh risk,β the discussion becomes more concrete. A team might say that a group of issues represents several million dollars in annualized exposure across systems tied to revenue. That is a number that can be evaluated alongside other business risks, rather than interpreted as a technical signal.
A practical example
Consider two vulnerabilities identified during a scan. The first is a CVSS 9.8 issue on a segmented guest Wi-Fi router. It is severe from a technical standpoint, but it has no access to sensitive data, no path into production systems, and no evidence of active exploitation.
The second is a vulnerability with a moderate CVSS score on an internet-facing customer database. Public exploit code exists, and the system stores regulated data tied directly to revenue and compliance obligations.
On a scanner dashboard, the first may appear more urgent. When viewed through a financial lens, the second carries greater risk.
Assume an annual probability of exploitation of 20 percent for the database scenario. If the potential impact includes $750,000 in incident response, $1.2 million from several days of business interruption, $600,000 in legal and regulatory costs, and $1 million in customer churn and reputational damage, the total loss for a single event is $3.55 million.
Applying the FAIR model results in approximately $710,000 in annualized exposure. That figure reflects the risk carried by that single vulnerability on a production system.
By contrast, even if the Wi-Fi router vulnerability had a 5 percent probability of exploitation and a $50,000 impact, the resulting exposure would be around $2,500. Both findings may appear critical in a technical report, but only one represents a material financial concern.
This is where Active Risk and FAIR work together. One identifies where attackers are likely to act, and the other expresses the consequence in financial terms. The combination changes how vulnerabilities are evaluated and how priorities are set.
Visualizing exposure across your environment
Once risk is expressed in financial terms, the next step is to understand how that exposure is distributed. Boards tend to think in terms of portfolios rather than individual issues, and the same principle applies to cybersecurity.
In most environments, exposure is not evenly spread. A relatively small number of systems and vulnerabilities account for a large portion of potential loss. Internet-facing services, systems tied to revenue, and assets with known exploit activity often sit at the higher end of that distribution.
This creates a practical way to focus effort. Rather than attempting to address every vulnerability equally, teams can identify where exposure is concentrated and reduce risk in those areas first. In many cases, addressing a small number of issues can significantly reduce overall exposure, particularly when those issues sit on systems that are both reachable and business-critical.
A before-and-after view helps make this visible. If an organization reduces modeled exposure from several million dollars to a substantially lower figure through targeted remediation, the result can be explained in terms of reduced downside risk rather than increased patching activity. Over time, tracking that change shows whether investments are producing measurable outcomes.
Making risk actionable
By the time exposure is expressed in financial terms, the discussion in the boardroom has already shifted. The focus moves away from counts and severity toward risk, trade-offs, and acceptable levels of exposure.
One of the first issues that arises in that context is the assumption that risk should be driven to zero. In practice, eliminating all exposure is neither achievable nor economically sensible. Reducing risk always involves trade-offs, and those trade-offs become clearer when expressed in financial terms.
If an organization has already reduced exposure significantly, but further reduction requires a disproportionate increase in cost, the decision becomes one of balance. The question is no longer why risk still exists, but whether the remaining exposure aligns with the organizationβs tolerance.
The same logic applies when discussing budget. Requests framed in operational terms, such as additional headcount or tooling, are difficult to evaluate in isolation. When those requests are tied to measurable reductions in exposure, the relationship between cost and benefit becomes clearer.
For example, if additional resources reduce several million dollars of modeled exposure at a fraction of that cost, the investment can be assessed alongside other initiatives using the same financial lens. At that point, the discussion is no longer about capacity. It is about risk reduction.
Putting security in business terms
Reducing exposure also affects how the organization is perceived externally. Cyber insurance underwriting, for example, increasingly considers factors such as attack surface, exploit availability, and remediation speed. Demonstrating that exposure is measured and reduced over time can influence how risk is priced.
The same applies during customer due diligence. Being able to explain where risk exists, how it is prioritized, and how it has been reduced provides evidence of maturity. It shows that security is being managed deliberately rather than reactively.
Aligning to risk tolerance
Productive board discussions tend to end with agreement on acceptable levels of exposure. Without a financial view, every issue can appear urgent. With it, prioritization becomes more grounded.
Leadership can evaluate whether the level of risk being carried is consistent with business objectives, and whether further investment is warranted. That shifts vulnerability management from a process focused on volume to one focused on where exposure is concentrated and how it can be reduced most effectively.
Clear exposure, clearer decisions
Vulnerability management has often been treated as an operational activity centered on patching and scanning. When combined with threat context and financial modeling, it becomes part of enterprise risk management.
Instead of reporting how many vulnerabilities exist, security leaders can describe how much exposure the organization carries. Instead of focusing on activity, they can show how targeted actions reduce risk over time. That framing aligns cybersecurity with the same decision-making process used across the rest of the business.
When exposure is clear, decisions become clearer. Leadership can determine where to accept risk, where to transfer it, and where to invest in reduction. The conversation with the board moves away from technical detail and toward measurable impact, which is where security becomes part of strategy rather than an isolated function.
Microsoft is publishing 77 vulnerabilities this March 2026 Patch Tuesday. Microsoft is aware of public disclosure of two of todayβs vulnerabilities, but without evidence of exploitation in the wild for any (yet), so there are no Microsoft additions to CISA KEV today. Earlier in the month, Microsoft provided patches to address nine browser vulnerabilities, which are not included in the Patch Tuesday count above.
SQL Server: zero-day remote EoP
SQL Server often goes several months in a row without any mention on Patch Tuesday. Today, however, all versions from the latest and greatest SQL Server 2025 back as far as SQL Server 2016 SP3 receive patches for CVE-2026-21262, a SQL Server elevation of privilege vulnerability. This isnβt just any elevation of privilege vulnerability, either; the advisory notes that an authorized attacker can elevate privileges to sysadmin over a network. The CVSS v3 base score of 8.8 is just below the threshold for critical severity, since low-level privileges are required.
Microsoft is aware of public disclosure, so while they assess the likelihood of exploitation as less likely, it would be a courageous defender who shrugged and deferred the patches for this one. Most SQL Server admins and security teams concluded many years ago that exposing SQL Server directly to the internet was not a good idea. Then again, popular search engines for internet-connected devices describe tens of thousands of SQL Server instances, and they canβt all be honeypots.
What could an attacker do as SQL Server sysadmin? Beyond exfiltrating or interfering with the database itself, the obvious target is xp_cmdshell, which allows direct callouts to the underlying OS. The good news is that xp_cmdshell is disabled by default as far back as SQL Server 2005; the bad news is that anyone acting as SQL Server sysadmin can enable it in seconds. At that point, the attacker is acting with the full privileges of the security context under which SQL Server runs, which is ideally a purpose-built account designed with least privilege in mind. If you want to hear some hair-raising stories, you have only to ask any incident response veteran if theyβve ever seen it set up differently.
Anyone paying for Extended Security Updates (ESU) for SQL Server 2014 or SQL Server 2012 may be forgiven for wondering why thereβs no security update for those venerable versions of the worldβs most widely deployed closed-source database product. We can hope that the vulnerability described by CVE-2026-21262 was introduced in newer codebases only.
.NET: zero-day DoS
Attackers fond of low-effort denial of service attacks against .NET applications will be checking out CVE-2026-26127 today. Microsoft is aware of public disclosure. While the immediate impact of exploitation is likely contained to denial of service by triggering a crash, opportunities for other types of attacks might emerge during a service reboot. Alternatively, if a log forwarder or security agent is impacted, even for a brief period of time, an attacker might carry out an attack in that moment hoping to evade detection under cover of this artificial darkness. Even if a low-skilled attacker simply causes downtime, in some contexts that could be enough to cause an SLA breach or loss of revenue, or at the very least cause a bleary-eyed defender to get paged in the middle of the night.
Authenticator: QR code impersonation
Microsoft Authenticator mobile app users on both iOS and Android should update to the latest version to prevent exploitation of CVE-2026-26123, which involves a malicious app disguising itself as Microsoft Authenticator. Exploitation succeeds when the malicious app receives enough information to impersonate the user.
Authenticator-type apps are often installed on a personal device, but it's not unusual for them to provide multi-factor authentication (MFA) codes for production services in a bring-your-own-device context. This is as good a time as any for defenders to consider how well their mobile device management policy covers app choice enforcement and patching for MFA apps.
The CVSS v3 base score of 5.5 might appear unremarkable, and exploitation requires user interaction, since the user must install the malicious app in the first place. However, exploitation could begin via an attacker-controlled link, or even a malicious QR code that drives users to the malicious app, and a motivated attacker with a physical presence near the user base might well consider this option.
According to Khaled Mohamed, the researcher who discovered this vulnerability, the legitimate Microsoft Authenticator app did not previously register itself as the handler for deep links into its own custom URL scheme. A malicious app could exploit this gap by simply registering itself as the default handler. He further notes that in this scenario, a user of a mobile device with a malicious app installed only needs to click a generic βOpen linkβ dialog, rather than expressly selecting the malicious app each time. This means that the Microsoft advisory is perhaps too optimistic about how much user interaction is required to trigger exploitation.
Microsoft ranks this vulnerability as important on their proprietary severity scale. The advisory also provides a brief peek behind the curtain, since the executive summary notes that βCwe is not in rcaβ. The weakness listed on the advisory is CWE-939: Improper Authorization in Handler for Custom URL Scheme.
Microsoft lifecycle update
There are no significant Microsoft product lifecycle changes this month, unless you are responsible for a Microsoft SQL Server 2012 Parallel Data Warehouse instance, which moves beyond extended support as of March 31st. It would be wise not to count on a last-minute extension, since Microsoft has already granted a six month reprieve.