N-able N-Central Critical Authentication Bypass: CVE-2026-86206 and CVE-2026-86207 Chained Attack

Executive Summary

Rapid7 Labs has disclosed two critical vulnerabilities affecting N-able N-Central, a widely-deployed Remote Monitoring and Management (RMM) platform used by Managed Service Providers and enterprise IT teams. Discovered during research into an earlier N-Central authentication bypass (CVE-2026-18577), these vulnerabilities represent a fundamental breakdown in access control when chained together. An unauthenticated, remote attacker can bypass authentication entirely and create a new System administrator account with full platform privileges on vulnerable on-premise N-Central installations. Both flaws have been patched in N-Central 2026.3 Hotfix 3, released September 5, 2026.

The attack chain exploits two distinct mechanisms: first, a path normalization discrepancy between the Envoy reverse proxy and the underlying Jetty web server that allows restricted SOAP endpoints to be accessed; second, a logic flaw in the two-factor authentication routine that persists user bindings even when authentication fails. The combination of these issues creates a perfect storm for account takeover—attackers can directly access the ServerUI interface, bind themselves to a built-in privileged user account (without needing credentials), and fail authentication in a way that leaves the binding active for subsequent exploitation.

About N-able N-Central

N-able N-Central is an enterprise-grade Remote Monitoring and Management (RMM) platform designed for Managed Service Providers (MSPs) and IT departments. It provides centralized monitoring, management, and security capabilities for complex, large-scale networks through a web-based dashboard. Organizations rely on N-Central for device discovery, patch management, threat detection, and incident response across thousands of endpoints. Given its trusted role in enterprise security operations, vulnerabilities in N-Central directly impact the security posture of all managed infrastructure.

Vulnerability Summary

Technical Analysis: CVE-2026-86206

CVE-2026-86206 is a path normalization bypass that exploits differing interpretations of HTTP URIs between two adjacent network components. N-Central’s architecture places an Envoy reverse proxy in front of a Jetty application server. The proxy is intended to block access to administrative SOAP endpoints under /dms/services, but the vulnerability allows these restrictions to be circumvented through a combination of two encoding tricks.

The Semicolon Gets the Request Past Envoy

Envoy’s path matching rules use string prefix comparison to determine whether a request should be blocked. The configuration specifies that any request whose path begins with /dms/services should be rejected. However, Envoy’s prefix matcher does not account for RFC 3986 path parameter syntax: the semicolon character (`;`), when used in a URI, denotes the start of path parameters that are distinct from the actual path hierarchy.

By crafting a request to /dms;/services/ServerUI, an attacker bypasses Envoy’s prefix check because the path technically does not start with `/dms/services`—it starts with `/dms;`. Envoy sees this as a different path segment entirely and allows the request through to Jetty.

Once the request reaches Jetty, the servlet container correctly interprets RFC 3986 and treats the semicolon as a path parameter separator. The server removes the parameter portion (`;`) and processes the request as if it were directed to `/dms/services/ServerUI`—the exact endpoint Envoy was meant to block.

Attacker Request:  /dms;/services/ServerUI
Envoy sees:        /dms (does not match /dms/services prefix) → ALLOW
Jetty sees:        /dms/services/ServerUI (path parameters stripped) → ROUTE TO SERVLET

The Forwarded Header Makes the Remote Client Look Local

Even if an attacker reaches the ServerUI servlet, Jetty enforces additional access control: the request must appear to come from a loopback address (127.0.0.1 or ::1). This check is meant to ensure only local administrative tools can access the servlet. Attackers can spoof this check using a malicious HTTP Forwarded header, exploiting a parsing discrepancy between two components of the authentication logic.

The Forwarded header follows RFC 7239 HTTP grammar, which uses quoted-string syntax where backslashes escape the following character. N-Central’s own header parser (in LocalHostUtils) does not properly implement this escape handling. By sending `Forwarded: for=”127.0.0.\1″`, an attacker creates a situation where:

• Jetty’s ForwardedRequestCustomizer (which correctly implements RFC 7239 grammar) interprets the backslash as an escape character and removes it, reading the value as `127.0.0.1` (a valid loopback address).
• N-Central’s LocalHostUtils parser does not implement RFC 7239 escape sequences correctly and reads the value as `127.0.0.\1` (an invalid address).

Because N-Central’s parser receives an invalid loopback address, the isLoopbackAddress() check fails. However, this failure triggers a “fail open” condition in the xffCheck() function—if loopback validation fails for any reason, the entire check is bypassed, allowing the request through.

// dmsservice-11.0.1-SNAPSHOT.jar
// com.nable.util.LocalHostUtils.xffCheck()
List<String> forwardedAddresses =
    LocalHostUtils.getForAddressesFromForwardedHeaders(httpRequest);
for (String addr : forwardedAddresses) {
    if (!LocalHostUtils.isLoopbackAddress(addr.trim())) continue;
    return false;
}
return true;

The logic here is the vulnerability: if no valid loopback address is found (because the parser returned an invalid escaped string), the loop completes without finding a match, and the function returns true—effectively allowing access.

// dmsservice-11.0.1-SNAPSHOT.jar
// com.nable.server.ServletPathFilter.isAllowedRequest()
boolean isAllowedRequest(HttpServletRequest httpRequest) {
    if (!LocalHostUtils.xffCheck(httpRequest)) {
        return false;
    }
    if (LocalHostUtils.isLocalhost(httpRequest)) {
        return true;
    }
    String path = this.removeTrailingSlashes(httpRequest.getRequestURI());
    return this.pathFilterService != null
        && this.pathFilterService.isPathAllowed(path);
}

Technical Analysis: CVE-2026-86207

With CVE-2026-86206 granting access to the protected ServerUI SOAP interface, an attacker can initiate a SOAP session via the Session.Hello operation. This creates a pre-login session (unauthenticated but valid). However, further SOAP operations require authentication. The vulnerability in CVE-2026-86207 exists in the UserTwoFactorLogin method, which handles legacy two-factor authentication.

The flaw occurs in the order of operations: the method binds a user ID to the session before attempting authentication. If the authentication attempt fails (for any reason, including invalid credentials or a missing 2FA profile), the method throws an exception. However, in N-Central’s default configuration, three built-in user accounts do not have legacy two-factor authentication profiles configured:

• User ID 1: N-able Administrator (system owner account)
• User ID 50: Product Administrator (vendor support account)
• User ID 51: N-able Support (vendor support account)

When an attacker calls UserTwoFactorLogin with a request to bind to User ID 1 (the System administrator) and provides any dummy password, the method:

1. Calls updateSession(sessionID, userID) to bind User ID 1 to the session.
2. Retrieves the T_User record for User ID 1.
3. Calls authenticate(user, password) with the dummy password.
4. The authenticate method checks for a 2FA profile. Finding none, it raises an exception.
5. The exception is caught, an audit log entry is written, and the method returns without re-validating the user binding.

The critical flaw: once updateSession() has been called, the session is permanently bound to User ID 1, even though authentication failed. Subsequent SOAP calls on that session will operate as User ID 1—a System administrator—without the attacker ever providing valid credentials.

// dmsservice-11.0.1-SNAPSHOT.jar
// com.nable.server.ui.UserTwoFactorLogin
public final String twoFactorLogin(int sessionID, int userID, String password) 
    throws RemoteException {
    String response = null;
    try {
        this.updateSession(sessionID, userID);  // ← User binding happens FIRST
        T_User user = this.getUser(userID);
        response = this.authenticate(user, password);  // ← Auth can fail
        Trace.info((Object)this, (String)("2FA authentication response for user '" 
            + user.getUsername() + "': " + response));
        if (response != null && "ACCESS_OK".equals(response)) {
            String audit = "TWO FACTOR LOGIN SUCCESSFUL: UserID [" + userID 
                + "] successfully logged in.";
            this.addSessionAuditEntry(sessionID, audit);
        } else {
            String audit = "TWO FACTOR LOGIN FAILED: UserID [" + userID 
                + "] attempted to login with invalid PIN.";
            this.addSessionAuditEntry(sessionID, audit);
            this.makeSessionInvalid(sessionID);  // ← But session binding remains
        }
    }
    catch (RemoteException re) {
        throw re;
    }
    catch (Exception ex) {
        throw DMSError.getFault((String)CommonError.GENERIC_ERROR.getCodeAsString(), 
            (String)ex.toString(), (Throwable)ex);
    }
    return response;
}

The fix for this vulnerability is to validate that the 2FA profile exists before binding the user to the session, or to explicitly clear the session binding if authentication fails. Rapid7’s advisory notes that N-Central 2026.3 Hotfix 3 addresses both flaws: CVE-2026-86206 is patched by correcting the Forwarded header parsing in LocalHostUtils, and CVE-2026-86207 is patched by fixing the order of operations in UserTwoFactorLogin.

Putting It Together: The Attack Chain

An unauthenticated attacker executing this exploit follows this sequence:

1. Craft an HTTP request to POST /dms;/services/ServerUI with the malicious Forwarded header for="127.0.0.\1".
2. Send a SOAP Session.Hello request to establish a pre-login session. Receive back a valid SessionID.
3. Send a SOAP User.TwoFactorLogin request with the SessionID, specifying User ID 1 (System Administrator), and any dummy password.
4. The method binds the session to User ID 1, attempts authentication with the dummy password, receives an exception (no 2FA profile), and the binding persists.
5. Subsequent SOAP calls on that SessionID now execute with System Administrator privileges.
6. The attacker can now create a new administrator account, modify configurations, extract data, or establish persistence.

POST /dms;/services/ServerUI HTTP/1.1
Forwarded: for="127.0.0.\1"
Content-Type: text/xml; charset=utf-8
SOAPAction: ""

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ns2:Hello xmlns:ns2="http://ws.nable.products.ncentral/services/common/session">
      </ns2:Hello>
  </soap:Body>
</soap:Envelope>

Remediation

N-able released N-Central 2026.3 Hotfix 3 (version 2026.3.1.13) on September 5, 2026, addressing both CVE-2026-86206 and CVE-2026-86207. All on-premise N-Central installations running versions prior to 2026.3.1.13 are vulnerable. On-premise customers are urged to apply the update immediately, outside of normal patching windows if necessary.

For N-able’s hosted N-Central service, the vendor has already deployed the patched version, and no customer action is required.

Detection for N-able customers using Rapid7’s InsightVM, Nexpose, or Exposure Command will be available in the September 8, 2026 vulnerability content release, enabling organizations to identify affected N-Central instances.

Key Takeaways

• Path Normalization Bugs Are Gateways: Discrepancies in how different components interpret URIs (semicolons, path parameters, escape sequences) can completely bypass access control layers. Both the proxy and the backend must agree on URI semantics.
• Order of Operations Matters in Authentication: The UserTwoFactorLogin flaw is a classic example of performing privilege escalation (binding a user to a session) before validation (confirming authentication succeeds). User binding should be conditional on successful authentication.
• Fail-Open Logic Is Dangerous: The xffCheck() function’s implicit fail-open behavior (returning true when no valid loopback address is found) was likely intended to be permissive, but it actually inverts the security model. Failed checks should fail closed, not open.
• Built-In Accounts Require Extra Scrutiny: The three built-in user IDs (1, 50, 51) lacking 2FA profiles created a shortcut for attackers. Hardened default configurations should require 2FA for all administrative accounts, including built-ins, or the authentication logic must handle missing profiles gracefully.
• RFC Compliance in Parsers Is Critical: N-Central’s LocalHostUtils parser failed to implement RFC 7239 escape sequence handling correctly, creating a divergence from Jetty’s implementation. All HTTP header parsing should conform to published RFCs, and deviations should be intentional and audited.
• Chained Vulnerabilities Scale Impact: CVE-2026-86206 alone would be a moderate access control bypass (Medium severity). CVE-2026-86207 alone would be a pre-authentication user binding flaw (High severity, but hard to exploit without the first flaw). Chained together, they create unauthenticated admin account takeover (Critical impact).
• Architecture Matters: Proxy-based access control only works if the proxy and backend agree on request interpretation. Defense-in-depth requires that the backend also enforce restrictions, not assume the proxy has already filtered malicious requests.

Defensive Recommendations

• Immediate: Apply N-Central 2026.3 Hotfix 3 or later to all on-premise N-Central installations. If deployment windows are a constraint, prioritize internet-facing instances. Consider temporarily restricting network access to N-Central management interfaces to trusted VPNs or administrative segments until patched.
• Detection: Use Rapid7’s InsightVM or Nexpose to scan for CVE-2026-86206 and CVE-2026-86207. Correlate findings with N-Central version numbers to confirm exposure. Check N-Central logs for SOAP requests to `/dms/services/ServerUI` from remote clients (all legitimate requests should originate locally).
• Hardening: Enforce network-layer restrictions: only allow administrative interfaces (HTTP/HTTPS to N-Central) from known IP ranges (management subnets, VPN endpoints). Do not expose RMM platforms directly to the internet without additional authentication (VPN gateway, zero-trust network access).
• Access Control Architecture Review: Audit any N-Central customizations or add-ons that parse HTTP headers or URIs. Verify RFC compliance in custom parsers and ensure consistency between multiple parsing locations. Run proxy/backend integration tests that specifically exercise edge cases (semicolons, escaped characters, non-ASCII).
• Authentication Logic Audit: Review other authentication flows in N-Central for similar patterns: user binding before validation, fail-open conditions, or built-in account bypass logic. The 2FA bypass suggests a broader architectural issue that may affect other authentication methods.
• Monitoring: Enable detailed logging for SOAP operations involving User.TwoFactorLogin and Session.Hello. Alert on failed 2FA attempts that originate from remote (non-local) addresses. Track session creation and privilege escalation events to identify unauthorized admin account creation.
• Segmentation: If N-Central manages critical infrastructure, place its database and management interface on a separate network segment with strict egress filtering. This limits the blast radius if N-Central itself is compromised.

Disclosure Timeline

• August 27, 2026: Rapid7 initiates contact with N-able, disclosing CVE-2026-86206 and CVE-2026-86207.
• August 28, 2026: Rapid7 provides detailed technical analysis and a working proof-of-concept exploit script to N-able.
• September 5, 2026: N-able releases N-Central 2026.3 Hotfix 3 (version 2026.3.1.13), fixing both vulnerabilities.
• September 7, 2026: Rapid7 requests clarification on patch completeness; N-able confirms the fix is comprehensive and ready.
• September 8, 2026: Public disclosure of CVE-2026-86206 and CVE-2026-86207 via Rapid7’s security blog.

Conclusion

CVE-2026-86206 and CVE-2026-86207 represent a reminder that security mechanisms are only as strong as their weakest component. Path normalization discrepancies and authentication logic flaws, individually moderate issues, combine to create a critical unauthenticated admin account takeover. For organizations running N-able N-Central, particularly on-premise deployments, prompt patching is essential. The vulnerability window is narrow—N-able responded quickly with a fix, and responsible disclosure timelines allow the security community to validate and deploy patches before public exploit code appears. However, the underlying lessons extend beyond this specific issue: proxy-based access control requires backend validation, authentication must precede privilege binding, and HTTP parsers must conform to published specifications. Organizations deploying N-Central should use this disclosure as a trigger for broader architectural reviews of their RMM platform deployments, testing not only for these specific CVEs but also for similar patterns in custom code and third-party integrations.

Original text: “CVE-2026-86206, CVE-2026-86207: N-able N-central Authentication Bypass (FIXED)” by Stephen Fewer at Rapid7.

“