EUVD-2026-30486
GHSA-qwfw-ggxw-577c
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
6DescriptionGitHub Advisory
Summary
Missing DTLS peer certificate fingerprint validation in the DTLS client (active) role removes one side of WebRTC's mutual authentication. The bug is not independently exploitable for media interception in standard deployments, but enables a full man-in-the-middle attack when chained with insecure signalling or a peer with similar validation gaps.
Details
ex_webrtc validates the DTLS peer's certificate fingerprint against the value advertised in the SDP offer/answer when acting as the DTLS server (passive role). When acting as the DTLS client (active role) -- the default when answering a remote offer with a=setup:actpass, which is what browsers always send -- the fingerprint check was skipped on the handshake-completion code path that returns no outgoing packets. This is the most common deployment mode (e.g., an SFU or media server answering a browser's offer).
All released versions prior to 0.15.1 and 0.16.1 are affected. No backports to older lines are planned -- users should upgrade to 0.15.1 or 0.16.1.
Impact
The bug eliminates one half of WebRTC's mutual DTLS authentication. The security of the media and data-channel encryption then rests entirely on the remote peer's fingerprint check.
On its own, the bug does not allow:
- Passive eavesdropping on SRTP media.
- A network-positioned attacker to intercept media against a standards-compliant browser peer over a TLS-protected signalling channel -- the browser's fingerprint check prevents the second leg of the MITM from succeeding.
The bug does enable a full MITM on media and data channels when combined with any of:
- Insecure signalling (HTTP / plain WebSocket) allowing SDP rewrite in transit.
- A compromised or malicious signalling server.
- A peer implementation with a similar fingerprint-validation gap.
Both audio/video media (SRTP) and data channels (SCTP-over-DTLS) are affected.
Patches
0.15.1(for the 0.15.x line)0.16.1(for the 0.16.x line)
Workarounds
None. Upgrade is required.
Resources
AnalysisAI
ex_webrtc library for Erlang/Elixir fails to validate DTLS peer certificate fingerprints when operating in client (active) role during WebRTC handshakes, breaking mutual authentication. Versions prior to 0.15.1 and 0.16.1 are affected. While not independently exploitable against standard browser peers over secure signaling, this flaw enables man-in-the-middle attacks when combined with insecure signaling channels (HTTP/plain WebSocket), compromised signaling servers, or non-compliant peer implementations. Vendor-released patches (0.15.1, 0.16.1) available with no workarounds. No public exploit identified at time of analysis, but the high CVSS score (8.7, AV:N/AC:L/PR:N/UI:N) reflects the network attack vector and low complexity when prerequisites are met.
Technical ContextAI
This vulnerability affects ex_webrtc, an Erlang/Elixir library implementing WebRTC protocols. The root cause is CWE-295 (Improper Certificate Validation), specifically in the DTLS (Datagram Transport Layer Security) handshake layer. WebRTC mandates mutual DTLS authentication where both peers validate each other's certificate fingerprints against values exchanged in SDP (Session Description Protocol) offer/answer signaling. DTLS roles are negotiated via the SDP 'a=setup' attribute: 'actpass' (can be client or server), 'active' (client), or 'passive' (server). The library correctly validated fingerprints when acting as DTLS server (passive role) but skipped validation on a specific code path when acting as DTLS client (active role) - the default behavior when answering browser offers with 'a=setup:actpass'. This is the most common deployment pattern for SFUs (Selective Forwarding Units), media servers, and backend WebRTC endpoints. The bug occurs in the handshake-completion logic that processes incoming packets without generating outgoing responses, leaving one side of the mutual authentication broken. CPE data identifies the affected package as pkg:erlang/ex_webrtc across versions below 0.15.1 and specifically version 0.16.0.
RemediationAI
Upgrade to patched versions immediately: ex_webrtc 0.15.1 (for 0.15.x deployments) or 0.16.1 (for 0.16.x deployments) per vendor advisory https://github.com/elixir-webrtc/ex_webrtc/security/advisories/GHSA-qwfw-ggxw-577c. The fix (commit 658c63221a869fb12bb9989599c3688751b0531b) refactors handshake-completion logic to enforce fingerprint validation on all DTLS client code paths via a new peer_fingerprint_matching? function. No workarounds exist - the vendor explicitly states upgrade is required. As compensating controls until patching (which carry operational trade-offs): (1) enforce TLS 1.2+ with certificate pinning on all signaling channels (HTTPS/WSS) to prevent SDP tampering - this blocks the primary attack vector but adds complexity to certificate management; (2) implement additional out-of-band verification of peer identities if architecturally feasible, though this requires custom signaling protocol changes; (3) deploy network segmentation to restrict media endpoint access only to authenticated signaling servers, reducing exposure to compromised signaling infrastructure but not eliminating the core validation gap. These mitigations reduce but do not eliminate risk. Prioritize immediate patching for any ex_webrtc deployment with non-TLS signaling or unaudited peer implementations.
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today