Tink

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 OT0; supply-chain compromise is a separate category) │ $500 - $7,500 │ $625 - $8,500 Other security issue (Tier OT0 flat award) │ $1,000 │ $1,250 Submit a vulnerability CVE history 1 Last 12 months 2 Lifetime Auth bypass 35 % Info disclosure 30 % Parsing/validation 20 % Memory safety 10 % Latest advisories Loading the feed Overview Tink is Google's answer to developers repeatedly misusing crypto libraries: a misuse-resistant API over AEAD, MAC, hybrid encryption and signatures, and the crypto layer inside a large amount of Google product code plus a growing set of external users who wanted an alternative to raw JCA or OpenSSL bindings. Its raw install count is smaller than Guava's or Gson's, but the severity multiplier is higher than either, because a Tink defect is a break in the confidentiality or integrity primitive itself rather than in something built on top of it. Google rated all three language bindings Tier OT0 on the Bug Hunters open-source VRP, which is a deliberate signal about how it prices this code: $500 to $7,500 for a product vulnerability, set by a discretionary panel that reserves room to go higher for findings it considers unusually clever, severe or wide-reaching. 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's tier file names three repositories at TIER_OT0: tink-crypto/tink-cc , tink-crypto/tink-java and tink-crypto/tink-go . A security bug anywhere in that code is a product vulnerability the open-source VRP prices at $500 to $7,500, and those tier lines are what put a non- google/* org in scope at that rate Every primitive the library exposes: AEAD, deterministic AEAD, streaming AEAD, MAC, PRF, digital signatures, hybrid encryption and JWT, together with the subtle layer each of them is built on Key and keyset management in full: KeysetHandle , keyset serialisation and parsing, key derivation, key rotation, and the Registry and KeyManager machinery that resolves a key type to an implementation The KMS integrations that wrap and unwrap keysets, following the tink-java-awskms and tink-java-gcpkms patterns Randomness sourcing and nonce generation across all three bindings, including how a nonce is tracked and kept from repeating The bindings as code rather than as a shared design: C++ memory handling in tink-cc, JNI and JCA interaction in tink-java, and the Go implementation, each carrying its own safety argument Cross-language behaviour, where two bindings read the same keyset or the same ciphertext and disagree about it The three repositories and the release pipeline behind them, which the program prices as a separate supply-chain-compromise category rather than as a product vulnerability Out of scope Cryptanalysis of the standard primitives themselves with no Tink-specific exploitation path, which attacks the algorithm rather than this code Key-management failures in the integrating application, such as a caller writing an unencrypted keyset to disk Third-party Tink ports and reimplementations, which carry no tier-file line and therefore no price Memory-corruption reports against tink-cc that arrive without OSS-Fuzz reproduction steps or a merged patch, since the program will not price them in that form Anything privately disclosed to a third party before Google: the VRP states that such reports will typically not qualify for a reward Most-valued findings A break in an AEAD or signature primitive that lets an attacker forge or decrypt without the key. Auth bypass is 35% of the recorded profile, and this is the class the discretionary panel is most likely to price at or above the top of the $7,500 band, because it invalidates the guarantee the whole library exists to provide Nonce reuse or predictable nonce derivation in AES-GCM or XChaCha20-Poly1305, which collapses confidentiality across every message encrypted under the affected key Keyset parsing or KeysetHandle flaws that let a crafted keyset select an unintended key type or primitive, since keysets travel between systems and are not always fully trusted A cross-language mismatch where tink-cc, tink-java and tink-go disagree about the same keyset or ciphertext, which the project treats as a vulnerability rather than a compatibility bug A practical side channel in a supported operation that actually recovers key material, as opposed to a measurable timing difference with nothing recovered Memory-safety defects in tink-cc submitted with OSS-Fuzz reproduction steps, the only form of that report the program will price 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. tink-cc, tink-java and tink-go are each rated TIER_OT0, so a finding has to land in one of those three repositories to be priced at this band Product vulnerabilities cap at $7,500; the $31,337 ceiling requires a supply-chain compromise of the repository or release pipeline, which is a different reward category Memory-corruption reports against tink-cc need OSS-Fuzz reproduction steps or a merged patch; the Java and Go bindings carry no such prerequisite The award is set by a discretionary panel, and this is the entry where the panel's room to exceed the band for an unusually severe or wide-reaching finding most plausibly comes into play 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 fixes landing across the three language repositories and an advisory published once they have. 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 break in a primitive gives every Tink deployment a rekeying problem, not just a patching one. 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