CONFIDENTIALITY
Who can read the packet?
SRTP turns voice or video into a stream that an observer without the key cannot read.
KEY / CONTENT
INTELLIGENCE OBJECT / COMMS ASSURANCE
Encrypted for whom?
A call can keep a padlock on its packets and still reach the wrong party. In a USENIX Security '26 study, 19 of 33 WebRTC media servers failed DTLS authentication; in 9 cases, researchers retrieved media or protected data. [1]
FIELD PLATE / 01A key can be shared with the wrong person.
A
Participant⌁
encrypted mediaM
Media server33media-server implementations tested
19failed DTLS authentication
9allowed media or protected-data retrieval
01 / MECHANISM
Toggle the one link that changes the outcome: identity verification. The rest of the scene stays the same so the difference is visible.
Identity check
activeIdentity verified / media stays on the expected path
A
PARTICIPANTI
INTERMEDIARY / FALSE CERTIFICATEM
MEDIA SERVERThe certificate matches.
The server compares the presented identity with the expected one. An intermediary with another certificate is stopped before the media key is used.
Without JavaScript, the scene below shows the identity-verified case.
02 / TWO QUESTIONS
Encryption and authentication answer different questions.
The confusion starts when we see the padlock and assume we have also verified the other party.
AUTHENTICITY
With whom did you negotiate the key?
DTLS must bind the key to the correct identity. If the intermediary's certificate is accepted, encryption can continue with the adversary already installed in the conversation.
IDENTITY / KEY
When you assess a call, ask who was verified before the key was used.
03 / EVIDENCE
19 measures the failure. 9 measures the demonstrated impact.
The study does not turn every authentication error into a full interception. It separates a failed test from a case where media or protected data were actually retrieved.
The researchers tested 33 media-server implementations used by 24 providers. Chromium, Firefox and Safari did not show the same direct authentication bypass; the issue appeared in the server-side composition of the protocol. [1]
The 19 failed tests tell us something about identity. The 9 cases that reached media or protected data tell us something about consequence. The two counts answer different questions.
EVIDENCE SCALE
33
implementations tested
19
DTLS authentication failures
9
media or protected-data retrieval
DOCUMENTED
Vulnerabilities and test results reported in the paper
INFERENCE
A media server is a critical part of the call's security guarantee
UNKNOWN
Whether any intelligence service used these paths
04 / CASES
What the implementations revealed
The rows below place historical tests beside the fixes vendors reported. A fix in one product does not remove the design risk from every product.
| System | Observation | Media / data | Public disposition |
|---|---|---|---|
| Webex | An empty certificate was accepted; Cisco's PoC received audio from a test meeting. | Audio retrieved in the controlled scenario | CVE-2025-20215 / fixed in cloud |
| Zoom | The client authentication required by the server was not requested. | High-severity authentication bypass | Fixed / reported through bug bounty |
| Discord | Two bypass paths were found in 2022 and 2024 tests. | Impact reported and confirmed by the provider | Fixed / bounty |
| Steam | A media server continued after the bypass. | Media available to the researchers | Confirmed / fixed |
| Vonage | The web client's certificate was not correctly requested or validated. | Media available to the researchers | Confirmed / fixed |
| RingCentral | Client authentication was not requested on the tested path. | RTP available after the bypass | Confirmed / fixed |
| Teams | An empty or arbitrary certificate was accepted; RTP was not retrieved. | Plaintext RTCP metadata; RTP media not demonstrated | Outside bounty scope / limited case |
| Browsers | Chromium, Firefox and Safari showed no comparable direct bypass. | No media-server result | Control comparison |
For each row's details and disclosure nuances, read the paper and the Cisco advisory. [2] [3]
05 / REQUIRED POSITION
A meeting ID is not enough.
The demonstrated path requires a man-in-the-middle position. The attacker must be able to observe and modify traffic between the participant and the media infrastructure.
A stranger with only a meeting ID cannot use this path. It matters after someone controls part of the network path.
DISTANT / NO POSITION
The stranger with only the meeting ID
They can try to join through the service's normal paths. From the ID alone, they do not have the position required to insert a handshake between the participant and the media server.
DEMONSTRATED CAPABILITY: NO
LOCAL / ADJACENT
A compromised router or Wi-Fi segment
A compromised device on the local path can observe and modify traffic. Cisco describes a local or adjacent network condition for Webex, together with traffic interception.
DEMONSTRATED CAPABILITY: YES, UNDER CONTROLLED CONDITIONS
CONTROLLED SEGMENT
An ISP or monitored segment
Someone controlling a network segment may be able to observe more traffic, depending on routing and how the participant reaches the service. The study does not say that an intelligence service used this capability.
RISK INFERENCE: PLAUSIBLE / UNOBSERVED
For CVE-2025-20215, Cisco said the attacker must be network-proximate, intercept traffic and that PSIRT was unaware of malicious exploitation. [3]
06 / INTELLIGENCE READING
What to ask before calling a conversation secure
The research keeps protocol behavior, infrastructure and adversary capability separate.
PROTOCOL / INFRASTRUCTURE / CAPABILITY
Three layers keep the assessment proportionate.
- Where does media terminate: at the participants or at a server that negotiates separately with each side?
- Which identity does the server verify before accepting the key?
- What happens when certificate verification fails? Does the handshake stop, or does the session continue?
- What network position is required to modify that handshake?
- Is there a primary advisory and a verifiable fix?
The paper supports a precise conclusion: part of a call's security guarantee can live in the media server, and an authentication defect can leave encryption intact while changing who holds the key. We do not know whether an intelligence service used these paths.
The question to remember: who verifies the identity before the key is used?
07 / SOURCES AND LIMITS
Read the sources
The paper is the central source. Cisco's advisory checks a concrete case and its remediation. WebRTC documentation explains the difference between media encryption and authentication.
Each card says what the source supports and where it stops.
01 / primary
Breaking and Entering: How Media Servers Compromise the Security of WebRTC
The 24-provider, 33-media-server study; 19 DTLS-layer client-authentication failures; nine affected implementations with demonstrated media or protected-data retrieval; the Webex proof of concept; vendor outcomes and the browser comparison.
Limit: The tests used controlled accounts and sessions. They show what an attacker can do from a required man-in-the-middle position; they do not establish widespread interception or use by an intelligence service.
Open source ↗02 / primary
Breaking and Entering: How Media Servers Compromise the Security of WebRTC, prepublication PDF
The call sequence, DTLS and SRTP relationship, test taxonomy, packet-level evidence, Webex packet flow, responsible-disclosure record and the artifact archive.
Limit: The PDF is the research record. It does not provide a live status page for every vendor or prove that a historical implementation remains exposed.
Open source ↗03 / primary
Cisco Webex App Vulnerability Could Allow Unauthenticated Join
CVE-2025-20215, the network-proximate prerequisite, the Webex remediation status and Cisco's statement that PSIRT was unaware of malicious use at publication.
Limit: A vendor advisory covers the affected product and its fix. It cannot establish whether an unrelated actor used the capability.
Open source ↗04 / secondary
Paper accepted at USENIX Security 2026
The public research context and the scale framing around providers, media servers and network interception.
Limit: This is a summary page. The peer-reviewed paper remains the authority for methods, counts and individual case details.
Open source ↗05 / primary
SRTP in WebRTC
The protocol distinction that WebRTC media uses SRTP and that DTLS-SRTP negotiates the keys used by the media channel.
Limit: Protocol documentation explains the intended mechanism. It does not certify that every server composition validates identities correctly.
Open source ↗06 / primary
Breaking and Entering: supplementary artifacts
The paper's released supporting material, including traces and artifacts associated with the study.
Limit: Artifacts make the research inspectable; they still represent controlled experiments rather than an operational threat-intelligence collection.
Open source ↗Editorial status: updated 14 August 2026. The paper reports historical tests and remediation where providers confirmed it; review is triggered by a new primary research version, a material advisory or a vendor-status change.