WebRTC

Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Memory corruption from web contents, controlled write in the browser, network or GPU process (this project's ceiling; the $250,000 full-chain rungs need a complete Chromium exploit) │ $5,000 │ $6,000 Memory corruption from web contents, ASAN write or use-after-free │ $2,500 │ $3,125 Memory corruption from web contents, controlled read │ $2,500 │ $3,125 Memory corruption from web contents, ASAN read │ $1,000 │ $1,250 Base reward (below-baseline report, mitigated issue, or no harness available) │ $500 │ $625 Submit a vulnerability CVE history 36 Last 12 months 93 Lifetime Memory safety 60 % Parsing/validation 18 % Denial of service 12 % Info disclosure 6 % Latest advisories Loading the feed Overview libwebrtc is the real-time media stack for essentially all browser-based calling, and it reaches far beyond the browser. It is inside Chrome, Edge, Firefox and Safari; inside the web and Electron clients of Zoom, Google Meet, Discord and Slack; inside Jitsi, LiveKit, Janus, mediasoup and Twilio's SDKs; inside Matrix and Element calls; and inside a large share of IoT camera and doorbell firmware that adopted it for peer-to-peer streaming. That matters because of where the untrusted data arrives: an RTP parser bug is remotely reachable by anyone who can get a media packet to the victim, with no page to visit and no file to open. Sixty per cent of its 93 Chrome CVEs are memory-safety defects and 36 landed in a single recent quarter. Google pays $500 for a below-baseline report and up to $5,000 on the standard table for a controlled write reached from web contents, with a full chain built on the bug separately eligible for $250,000. sorona.xyz adds 1.25× on top of whatever Google awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope The Chrome VRP takes any High or Critical severity bug in Chrome Browser, and libwebrtc is Chromium project code, so it is covered directly rather than as a vendored dependency RTP, RTCP and SRTP packet parsing, the classic remote-attacker surface in this codebase, together with the DTLS-SRTP handshake that keys it SDP parsing and PeerConnection session negotiation, the first attacker-controlled input a call presents The ICE, STUN and TURN connectivity stack and its candidate handling Audio and video codec integration for VP8, VP9, AV1, H.264 and Opus, plus the packetisers and depacketisers around them, where a remote peer controls the bitstream The jitter buffer, frame reassembly, packet-loss concealment, FEC and retransmission paths, which run on deliberately incomplete input Data channels carried over SCTP through usrsctp Capture and rendering: the audio processing module, echo cancellation, and the getUserMedia, device-enumeration and screen-capture permission boundary Out of scope IP-address exposure through ICE candidates, which is documented WebRTC behaviour rather than a vulnerability Findings that need significant user interaction, which the mitigated-issues rule reduces to the $500 base amount Experimental features, debugging features and unsafe browser flags, per the program's standard exclusions Code on trunk less than seven days old, which has not reached any shipping channel Defects that only reproduce in a downstream libwebrtc consumer rather than in Chrome Speculative reports that do not demonstrate the bug actually manifesting in a shipping browser Anything below the High or Critical bar the scope sentence sets, along with low-quality submissions, which are capped at the $500 base amount Most-valued findings Memory corruption in RTP, RTCP or SRTP parsing triggered by a packet from an established peer. It is the highest-value class here, since it reaches the $5,000 controlled-write rung and needs nothing more than a call the victim already answered Use-after-free or heap overflow in the jitter buffer and frame reassembly, where a peer can choose exactly which fragments arrive and in what order Codec integration bugs on VP8, VP9, AV1 or H.264 bitstreams, which put a remote peer's bytes directly into a decoder SCTP data-channel defects in usrsctp, reachable without any media permission at all once a data channel is open Escapes from the getUserMedia and screen-capture permission boundary that reach the camera, microphone or screen without a grant, which is a privilege escalation rather than a crash Anything in the classes above demonstrated with at most one click, since Chrome's mitigated-issues rule collapses anything more interactive to the base amount Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. File to the Chrome VRP, not the Google OSS VRP, where a product vulnerability in this component pays nothing Demonstrate a path that needs at most one click: the highest-value bugs need the callee to accept a peer connection or grant camera or microphone permission, and Chrome's mitigated-issues rule cuts anything requiring significant user interaction back to the base amount IP-address exposure through ICE candidates is documented WebRTC behaviour, not a vulnerability, and reports about it are closed on that basis The bug must manifest in an active Stable, Beta or Dev channel on the latest operating system and 64-bit hardware, and code less than seven days old on trunk is excluded Show it in Chrome: a defect that only reproduces in a third-party libwebrtc consumer such as an SDK or a native client falls outside this program Disclosure Coordinated through the Chromium issue tracker, where reports are made public 14 weeks after being marked as fixed. Note that a fix landing in libwebrtc reaches downstream SDKs on their own schedule, so hold the detail well past the Chrome release. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability