FlatBuffers

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 45 % Parsing/validation 30 % Denial of service 15 % Info disclosure 5 % Latest advisories Loading the feed Overview FlatBuffers is the serialisation format for TFLite model files, which puts it on every Android device running on-device ML, and it is also used in Android system services, in game engines such as Cocos2d-x and a wide range of shipped titles that chose it for zero-copy asset loading, in Facebook's client applications, in ArangoDB, and across embedded and automotive stacks. The security property that matters is structural: FlatBuffers is designed for zero-copy access to untrusted bytes, so all of its safety rests on the verifier. A verifier bypass is therefore not one bug: it is a type-confusion primitive against every consumer that trusted the verifier's guarantee, including the TFLite interpreter parsing a model it just downloaded. Google prices it at Tier OT1 on the Bug Hunters open-source VRP, $101 to $3,133.70 for a product vulnerability at a panel's discretion. 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/flatbuffers 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 C++ runtime: flatbuffers::Verifier and its depth, size and alignment accounting, table and vtable access, FlatBufferBuilder , and the string and vector readers Zero-copy accessor generation and vtable offset handling, where a bad offset turns a read into an out-of-bounds access The flatc schema compiler: the .fbs grammar it accepts, schema parsing, includes and namespaces, and the code it generates for each target language The generated code itself, since the bounds checks a consumer relies on are the ones flatc chose to emit JSON to FlatBuffer conversion, the reflection API and FlexBuffers, all of which build buffers from input the caller did not author The language runtimes shipped in-repo: Java, Kotlin, C#, Go, Python, Rust, Swift, TypeScript, PHP, Dart, Lua and C The gRPC integration the repository ships alongside the runtimes Build and release publishing configuration across the package ecosystems the project pushes to, which falls under the supply-chain reward category Out of scope Consuming an unverified buffer without calling the verifier, which the documentation explicitly requires you to do Third-party FlatBuffers implementations that are not in the tier file Schema evolution and compatibility issues with no security impact Performance characteristics of the zero-copy design itself 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 A buffer that passes flatbuffers::Verifier and still produces an out-of-bounds read or write in a generated accessor: memory safety is 45% of the profile here, and a verified-but-unsafe buffer is the single finding that reaches the top of the $3,133.70 band because it breaks the guarantee every consumer builds on Vtable offset or alignment handling that lets one field be read as another type, giving type confusion against the TFLite interpreter loading a downloaded model Verifier depth or size accounting that can be under-counted, so a nested buffer exhausts the stack or allocates unboundedly while still verifying A flatc code-generation flaw that emits accessors missing a bounds check, since that ships the bug into every project that regenerated its bindings Parity gaps between the in-repo language runtimes, where the C++ verifier rejects a buffer that the Java, Go or Rust runtime accepts 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 Consuming a buffer without calling the verifier is out of scope: the documentation requires the verifier, so a crash on unverified input is the caller's bug, not the library's Memory-corruption reports need OSS-Fuzz reproduction steps or a merged patch, which in practice means shipping the crafted buffer that triggers 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 propagating out to the language packages. Because the program's rules can be read as barring a third-party hand-off before the fix, file with Google directly and hold the detail: a verifier bypass has to reach TFLite and the embedded consumers before it is safe to describe. 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