How a broken certificate check let anyone impersonate any user on Cisco Webex

The Context

Most large organizations don't ask employees to log in to every application separately. Instead, they use a system called single sign-on: the employee logs in once through a central identity provider, and that provider issues a digital token that says "this person is who they claim to be." Every application the employee uses checks that token instead of asking for a separate password.

The security of this entire system depends on one thing: the applications need to verify that the token is authentic. They do this by checking a digital certificate attached to the token, the same way a border agent checks the watermark on a passport. If the certificate is valid, the token is trusted. If not, access is denied.

Webex's SSO integration with Cisco Control Hub had a flaw in exactly that verification step. The system was not properly validating the certificates on incoming tokens. An attacker who understood this could craft a token that looked valid, present it to Webex, and the system would accept it without question.

How the Vulnerability Worked

The flaw is a single missing check in a chain of trust that's supposed to be airtight.

Here's how SSO normally works: an employee logs in through their organization's identity provider. The identity provider verifies who they are (password, multi-factor authentication, biometrics, whatever the organization requires) and issues a signed token. The employee's browser sends that token to Webex. Webex checks the certificate on the token against a known trusted certificate. If they match, the employee is in.

The vulnerability was in the last step. Webex was not properly validating the certificate. An attacker could connect to a Webex service endpoint, supply a token with a forged or invalid certificate, and the system would accept it as if it were legitimate.

The attacker didn't need to know the victim's password. They didn't need to compromise the identity provider. They didn't need the victim to click anything. They just needed to reach the Webex service endpoint (which is on the public internet) and send a crafted token claiming to be whoever they wanted to impersonate.

Once inside, the attacker would appear in every system log as the impersonated user. Audit trails, access records, meeting attendance lists: everything would show the real user's name, not the attacker's. Detection would be extremely difficult because nothing about the session would look abnormal from the inside.

What Made This Possible

Certificate validation is one of the oldest and most fundamental security checks in computing. It exists in every TLS connection, every code-signing system, every SSO integration. The entire internet's security model depends on certificates being checked correctly.

The reason this specific failure is so consequential is that Webex is not a small tool used by a few teams. It's an enterprise communication platform used by governments, hospitals, banks, and Fortune 500 companies for confidential meetings and sensitive file sharing. A single verification skip in this context doesn't just affect one feature. It dissolves the identity boundary for the entire organization's Webex environment.

This pattern repeats across the industry. Certificate validation failures have caused critical vulnerabilities in Apple's SSL implementation (the "goto fail" bug), in OpenSSL (Heartbleed's cousin CVE-2015-1793), and now in Cisco Webex. The mechanism is always the same: a verification step that should never be skipped gets skipped, and the entire trust chain collapses.

What Should Have Stopped This

One defense exists for this class of vulnerability: rigorous testing of the certificate validation path. Specifically, automated tests that submit tokens with invalid, expired, self-signed, and mismatched certificates, and verify that every one of them is rejected. These tests are well-understood and widely documented in security engineering literature.

Cisco found this vulnerability during internal security testing, which means the test coverage eventually caught it. The question is why the gap existed in the first place. Certificate validation is a critical security boundary, and any change to the SSO integration code should trigger automated validation tests as part of the development pipeline. When those tests are missing or incomplete, vulnerabilities like this one slip through.

The Takeaway

Certificate validation failures are not exotic. They're one of the most common classes of critical vulnerability in enterprise software, and they keep happening because the code that checks certificates is easy to get wrong and hard to test thoroughly. The fix for this specific Webex flaw is straightforward (upload a new certificate), but the pattern it represents is systemic. Every application that accepts identity tokens is only as secure as its certificate checking code, and most organizations have no visibility into whether that code is correct.

Pattern to remember: When a system skips a single verification step in the identity chain, the attacker doesn't need to break in. They walk in as someone who already belongs.

What changed: Enterprise SSO integrations can no longer be treated as inherently secure. The identity provider might be locked down, but every application that consumes its tokens is a potential point of failure.

The Technical Mechanism

CVE-2026-20184 is classified under CWE-295 (Improper Certificate Validation). The vulnerability existed in the SSO integration between Cisco Webex Services and Cisco Control Hub, specifically in how Webex validated the SAML assertions received from identity providers.

When an organization configures SSO with trust anchors in Control Hub, the IdP signs SAML assertions with a certificate that Webex is supposed to validate against a known trusted root. The flaw meant that an attacker could supply a crafted SAML token with a certificate that should have been rejected, and the Webex service endpoint would accept it as valid.

The attack required no authentication (CVSS:3.1/AV:N/AC:L/PR:N/UI:N — network-accessible, low complexity, no privileges required, no user interaction). An attacker connecting to the service endpoint could impersonate any user within the affected Webex organization.

Cisco addressed the vulnerability on the cloud-side infrastructure. However, organizations using trust anchors must upload a new IdP SAML certificate to Control Hub to complete the remediation. Failure to do so may result in continued exposure and potential service disruption.

CVE and Advisories

Cisco published the advisory as cisco-sa-webex-cui-cert-8jSZYhWL on April 15, 2026 (updated April 16, 2026). The vulnerability is tracked as CVE-2026-20184 with a CVSS base score of 9.8. The associated bug ID is CSCwt37111. No workarounds are available.

MITRE ATT&CK Mapping

Indicators of Compromise

This vulnerability was discovered during Cisco's internal security testing. Cisco PSIRT confirmed no evidence of exploitation in the wild at the time of disclosure. Because exploitation would appear as legitimate user activity in Webex logs, detection through standard log review would be extremely difficult. Organizations concerned about potential exploitation should review Webex access logs for anomalous session patterns (unusual login times, geographic impossibilities, concurrent sessions) and consult Cisco's advisory for remediation steps.

Primary Sources