tink java CVEs | Waratek

Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 1 50.0% Outside Waratek scope 0 0.0% Not applicable 1 50.0% Withdrawn CVE 0 0.0%

Critical 0 0.0% High 1 50.0% Medium 1 50.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%

blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 2 100.0% not established 0 0.0% unrecorded 0 0.0%

Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 2 100.0%

split by StatusSeverityProtectionExploit maturity peak 1 / quarter

Q4 201 No exploit published1 Medium1 not blocked1 No public exploit1 Q1 210 Q2 210 Q3 210 Q4 210 Q1 220 Q2 220 Q3 220 Q4 220 Q1 230 Q2 230 Q3 230 Q4 230 Q1 240 Q2 240 Q3 240 Q4 240 Q1 250 Q2 250 Q3 250 Q4 250 Q1 260 Q2 260 Q3 261 Not applicable1 High1 not blocked1 No public exploit1

Q1 21Q3 21Q1 22Q3 22Q1 23Q3 23Q1 24Q3 24Q1 25Q3 25Q1 26Q3 26

CVE	Severity	Published▾	Status	Exploitation	Description
CVE-2026-15432	High	2026-07-21	Not applicable	No public exploit	When verifying a mac with a ChunkedMacVerification object, Tink compares the resulting tag with non constant time comparison. This potentially allows an attacker to use timinig information as a side channel in order to get information how many bytes of a given tag match the correct tag. This in turn could allow to find a correct tag bytewise.
CVE-2020-8929	Medium	2020-10-19	No exploit published	No public exploit	A mis-handling of invalid unicode characters in the Java implementation of Tink versions prior to 1.5 allows an attacker to change the ID part of a ciphertext, which result in the creation of a second ciphertext that can decrypt to the same plaintext. This can be a problem with encrypting deterministic AEAD with a single key, and rely on a unique ciphertext-per-plaintext.

CVE

Severity

Published▾

Status

Exploitation

Description

CVE-2026-15432

High

2026-07-21

Not applicable

No public exploit

When verifying a mac with a ChunkedMacVerification object, Tink compares the resulting tag with non constant time comparison. This potentially allows an attacker to use timinig information as a side channel in order to get information how many bytes of a given tag match the correct tag. This in turn could allow to find a correct tag bytewise.

CVE-2020-8929

Medium

2020-10-19

No exploit published

No public exploit

A mis-handling of invalid unicode characters in the Java implementation of Tink versions prior to 1.5 allows an attacker to change the ID part of a ciphertext, which result in the creation of a second ciphertext that can decrypt to the same plaintext. This can be a problem with encrypting deterministic AEAD with a single key, and rely on a unique ciphertext-per-plaintext.