Cisco warns of exploited authentication bypass in SD-WAN Manager

Cisco disclosed a critical authentication bypass vulnerability in its Catalyst SD-WAN Manager on September 30, 2026, which attackers are currently exploiting to gain administrative access ^[3].

The flaw allows unauthenticated remote attackers to bypass security rules and take control of high-value network management platforms ^[3]. Because identity systems are increasingly targeted to circumvent multi-factor authentication (MFA), the distinction between accidental vulnerabilities and intentional bypass features has become a focal point for security administrators.

Cisco Discloses Critical SD-WAN Manager Bypass Under Active Attack

The vulnerability, tracked as CVE-2026-76504, carries a CVSS score of 9.8, indicating extreme severity ^[3]. According to Cisco, the flaw affects all system configurations of the Catalyst SD-WAN Manager regardless of how the system is set up ^[3].

Cisco confirmed it became aware of active exploitation in September and released its official advisory (cisco-sa-sdwan-webauth-xr8beuuU) on September 30, 2026 ^[3]. Successful exploitation grants an intruder administrator-level privileges, which Cisco says could enable network configuration changes, access to connected infrastructure, and further compromise of enterprise environments ^[3].

To remediate the flaw, Cisco released patches in versions 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1, and 26.2.1 ^[3]. The company noted that Cisco SD-WAN Cloud Hosted environments already have the mitigation deployed, and Cisco SD-WAN Cloud Managed Release 20.15.605 also fixes the issue with no customer action required ^[3]. For on-premises deployments, Cisco recommends restricting manager access from the public internet to known and trusted hosts and utilizing filtering devices such as firewalls ^[3].

Technical Breakdown of the CVE-2026-76504 Flaw

The vulnerability exists within the API session-based authentication management component of the manager ^[3]. It stems from the improper handling of URI encoding—the process of converting characters into a format that can be transmitted over the internet—in HTTP requests ^[3].

Attackers can send specially crafted requests to the j_security_check endpoint to bypass authentication rules ^[3]. Cisco noted that using encoded characters, such as %6a to represent the letter "j," can trigger the bypass ^[3]. "Any single character encoded in the request could potentially trigger the authentication bypass," Cisco stated ^[3].

To detect attacks, Cisco recommends that administrators review serviceproxy-access.log (located at /var/log/nms/containers/service-proxy/serviceproxy-access.log) and vmanage-server.log (located at /var/log/nms/vmanage-server.log) for suspicious requests involving j_security_check or system service accounts beginning with viptela-reserved- ^[3]. Customers who suspect a compromise are urged to open a Severity 3 TAC case referencing the CVE and collect an admin-tech file using the request admin-tech command ^[3].

Contrasting Risks: NinjaOne's Managed MFA Bypass Feature

While the Cisco flaw is an unintentional security gap, some platforms implement intentional "conditional MFA bypass" to improve usability ^[1]. NinjaOne provides such a feature, termed "Skip Login MFA," to prevent users from having to perform MFA twice during a single single sign-on (SSO) login—once at the Identity Provider (IdP) and once at NinjaOne ^[1][4].

This intentional bypass works by detecting a specific SAML (Security Assertion Markup Language) attribute in the cryptographically signed response from an IdP ^[1][4]. This attribute serves as evidence that MFA was already performed during the initial login session ^[1]. Because the SAML response is signed, it cannot be modified between the IdP and NinjaOne without detection ^[1]. Currently, NinjaOne supports this bypass for Azure (where it looks for URLs containing .microsoftonline.com) and Okta (where it looks for URLs containing .okta.com) ^[1].

NinjaOne stated that this login bypass does not remove MFA requirements for security-sensitive operations performed after the user has logged in ^[1]. The company clarified that all technicians and end users should still have NinjaOne MFA configured regardless of the login bypass ^[1].

Compliance Implications for High-Risk Sectors

Authentication failures and the removal of MFA controls carry significant regulatory risks for certain industries. For tax and accounting firms, the FTC Safeguards Rule treats these firms as financial institutions, regardless of their size ^[2]. Section 314.4(c)(5) of the rule requires the use of MFA for any individual accessing information systems that hold client data, unless a firm's Qualified Individual approves an equivalent control in writing ^[2].

Failure to maintain these controls can lead to mandatory FTC notifications if a security event exposes unencrypted information for 500 or more people; such notifications must be made within 30 days ^[2]. The IRS and its Security Summit partners have also explicitly stated that MFA is a federal requirement for tax professionals ^[2].

To mitigate the "MFA fatigue" that often leads staff to request that security be disabled, industry guidance suggests using "conditional access" to reduce prompts on trusted, firm-managed devices ^[2]. Additionally, the Cybersecurity and Infrastructure Security Agency (CISA) recommends phishing-resistant MFA, such as FIDO2 security keys and passkeys, as the gold standard, while suggesting "number matching" for those using push notifications to prevent blind approvals ^[2].

What we don't know

• Which specific versions of Cisco Catalyst SD-WAN Manager are most frequently targeted by the active exploitation?
• What specific 'security-sensitive operations' in NinjaOne still require MFA after a login bypass?
• How many organizations have already been compromised by CVE-2026-76504 before the September 30 advisory?