Brotli

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 Product vulnerability (Tier OT1; supply-chain compromise is a separate category) │ $101 - $3,133.70 │ $126 - $3,916.70 Other security issue (Tier OT1 flat award) │ $500 │ $625 Submit a vulnerability CVE history 0 Last 12 months 3 Lifetime Memory safety 50 % Parsing/validation 25 % Denial of service 20 % Info disclosure 4 % Latest advisories Loading the feed Overview Brotli is the Content-Encoding: br implementation shipped inside every major browser, in nginx and Apache modules, on Cloudflare, Fastly and Akamai edge nodes, in curl, in Node.js's zlib module, and in the Android and iOS system frameworks. Any HTTPS response on the modern web can be Brotli-encoded, which means the decoder in this repository parses attacker-influenced bytes on effectively every internet-connected device: CVE-2020-8927, an integer overflow in ring-buffer sizing that led to a buffer overflow on crafted input, is what that looks like in practice. Among the OT1 repositories it has the widest gap between deployment footprint and reward band: Google prices a decoder overflow here at $101 to $3,133.70 on the Bug Hunters open-source VRP, at a panel's discretion, despite the code sitting in the browser parsing path. 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 google/brotli is named at OT1 in Google's tier file, and it sits in a Google-owned GitHub organisation, which the program's scope sentence covers as well. A product vulnerability anywhere in the repository is priced at $101 to $3,133.70 The decoder in dec/ : stream and metablock parsing, Huffman table construction, ring buffer management, and distance and copy handling, all driven directly by bytes an attacker chose The encoder in enc/ : block splitting, context modelling, the hash and backward-reference search at every quality level, and large-window mode The shared code in common/ : the static dictionary, the transform table and its application, context maps and the platform shims The public C API: the one-shot BrotliDecoderDecompress and BrotliEncoderCompress entry points, both streaming state machines, and the custom allocator hooks a caller can install The command line tool that distributions package as brotli The Java ( org.brotli ), Python and Rust binding layers shipped from this repository Build files, release artifacts and publishing configuration, which fall under the supply-chain reward category Out of scope Independent Brotli reimplementations such as brotli-rs or dropbox/rust-brotli , which are not in the tier file Compression-ratio and performance issues without security impact Downstream servers misconfiguring Brotli content encoding Compression side channels of the CRIME and BREACH family, which are a protocol-level property rather than a defect in this codec Memory-corruption reports without exact OSS-Fuzz reproduction steps against an existing fuzz target, or an already merged patch, which the program requires on every OT0 and OT1 repository Repositories the tier file does not name, and releases that are not current: the program covers the latest versions of the listed repositories, and any other repository in the same organisation counts only where the file names it. What the file omits sits at OT2 or OT3, where product vulnerabilities earn no monetary reward Reports filed by anyone other than the researcher: Google requires the submission under your own identity through bughunters.google.com, and treats routing around the designated channel as grounds to reject Awards to researchers on sanctions lists, in territories subject to sanctions, or located in Russia or Belarus, which Google states it will not issue Most-valued findings Heap corruption in the decoder reachable from a crafted compressed stream, with OSS-Fuzz reproduction steps attached: memory safety is 50% of this project's history, it is the CVE-2020-8927 shape, and it is the class that reaches the top of the $3,133.70 band because the same bytes travel over any HTTPS response Integer overflow in ring-buffer or window sizing, the arithmetic that has already produced one buffer overflow here and that governs every allocation the decoder makes Metablock or Huffman table parsing flaws that read past the end of the input or of a constructed table Static dictionary transform handling that writes more than the caller sized for, since dictionary output is derived from attacker-chosen references Decompression bombs or state-machine faults that hang or exhaust a streaming decoder mid-response, which is the denial-of-service share landing on an edge node rather than a browser Memory disclosure where uninitialised or stale ring-buffer contents end up in the decompressed output handed back to the caller 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. The repo is rated TIER_OT1, one band below the OT0 libraries, so product vulnerabilities cap at $3,133.70 rather than $7,500 The $13,337 figure quoted for OT1 is the supply-chain-compromise category, covering the repository or release pipeline rather than a code vulnerability in the repo This is C, so memory-corruption reports need exact OSS-Fuzz reproduction steps or a merged patch: send the compressed stream that triggers the fault, not a description of it The award is set by a discretionary panel, so the band is a range rather than a fixed table and a report that spells out real impact is what moves you up it Take the flaw to Google before anyone else: the VRP treats private disclosure to a third party for purposes other than fixing the bug as grounds to refuse the reward Disclosure Coordinated through Google Bug Hunters, with the fix landing in the repository and then flowing outward to browsers, CDNs, distributions and language bindings. That downstream chain is long, so file with Google directly and hold your writeup well past the upstream commit: the code shipping in browsers is usually a vendored copy on its own schedule. 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