{"id":"CVE-2020-8929","aliases":["EUVD-2020-0220","GHSA-g5vf-v6wf-7w2r","PYSEC-2020-142"],"status":"published","title":"Ciphertext integrity weakness in Tink","description":"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.","severity":{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00463,"percentile":0.4044,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-176","CWE-327"],"published":"2020-10-16T00:51:24Z","modified":"2026-10-24T14:12:09Z","fixes":[{"ecosystem":"Maven","package":"com.google.crypto.tink:tink","fixed_in":["1.5.0"],"sources":["ghsa","osv"]},{"ecosystem":"PyPI","package":"tink","fixed_in":["1.5.0"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Maven","package":"com.google.crypto.tink:tink","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.5.0"}]}]},{"source":"osv","ecosystem":"Maven","package":"com.google.crypto.tink:tink","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.5.0"}]}],"versions":["1.0.0","1.1.0","1.1.1","1.2.0","1.2.0-rc2","1.2.0-rc3","1.2.0-rc4","1.2.1","1.2.2","1.3.0","1.3.0-rc1","1.3.0-rc2","1.3.0-rc3","1.3.0-rc4","1.4.0","1.4.0-rc1","1.4.0-rc2"]},{"source":"osv","ecosystem":"PyPI","package":"tink","ranges":[{"type":"GIT","events":[{"introduced":"0"},{"fixed":"93d839a5865b9d950dffdc9d0bc99b71280a8899"}]},{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.5.0"}]}],"versions":["1.4.0"]}],"products":[{"vendor":"google","product":"tink"},{"vendor":"google","product":"tink_java"},{"vendor":"google llc","product":"tink"}],"references":[{"url":"https://github.com/google/tink/commit/93d839a5865b9d950dffdc9d0bc99b71280a8899","tags":["x_refsource_CONFIRM","x_transferred","Patch","Third Party Advisory","fix","web"]},{"url":"https://github.com/google/tink/security/advisories/GHSA-g5vf-v6wf-7w2r","tags":["x_refsource_CONFIRM","x_transferred","Patch","Third Party Advisory","fix","web","advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2020-8929","tags":["advisory"]},{"url":"https://github.com/pypa/advisory-database/tree/main/vulns/tink/PYSEC-2020-142.yaml","tags":["web"]},{"url":"https://github.com/advisories/GHSA-g5vf-v6wf-7w2r"}],"sources":{"cve":[{"id":"CVE-2020-8929","title":"Ciphertext integrity weakness in Tink","description":"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.","status":"published","published":"2020-10-19T12:15:16Z","modified":"2024-08-04T10:12:11.052Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-176"],"updated_at":"2026-11-02T14:35:50.88562Z"}],"euvd":[{"id":"EUVD-2020-0220","description":"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.","status":"published","published":"2020-10-19T12:15:16Z","modified":"2024-08-04T10:12:11Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"updated_at":"2026-11-03T03:07:55.71159Z"}],"ghsa":[{"id":"GHSA-g5vf-v6wf-7w2r","title":"Ciphertext Malleability Issue in Tink Java","description":"### Impact\nTink's Java version before 1.5 under some circumstances allowed attackers to change the key ID part of the ciphertext, resulting in the attacker creating a second ciphertext that will decrypt to the same plaintext. This can be a problem in particular in the case of encrypting with a deterministic AEAD with a single key, and relying on the fact that there is only a single valid ciphertext per plaintext.\n\nNo loss of confidentiality or loss of plaintext integrity occurs due to this problem, only ciphertext integrity is compromised.\n\n### Patches\nThe issue was fixed in this [pull request](https://github.com/google/tink/commit/93d839a5865b9d950dffdc9d0bc99b71280a8899).\n\n### Workarounds\nThe only workaround is to backport the fixing [pull request](https://github.com/google/tink/commit/93d839a5865b9d950dffdc9d0bc99b71280a8899).\n\n### Details\nTink uses the first five bytes of a ciphertext for a version byte and a four byte key ID. Since each key has a well defined prefix, this extends non-malleability properties (but technically not indistinguishability). However, in the Java version this prefix lookup used a hash map indexed by unicode strings instead of the byte array, which means that invalid Unicode characters would be [replaced by U+FFFD](https://en.wikipedia.org/wiki/UTF-8#Invalid_sequences_and_error_handling) by the [Java API's default behavior](https://docs.oracle.com/javase/7/docs/api/java/lang/String.html#String(byte[],%20java.nio.charset.Charset)). This means several different values for the five bytes would result in the same hash table key, which allows an attacker to exchange one invalid byte sequence for another, creating a mutated ciphertext that still decrypts (to the same plaintext).\n\n### Acknowledgements\nWe'd like to thank Peter Esbensen for finding this issue and raising it internally.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Tink](https://github.com/google/tink/issues)","status":"published","published":"2020-10-16T00:51:24Z","modified":"2025-06-05T16:44:53Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium"},{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"cwes":["CWE-176","CWE-327"],"updated_at":"2026-11-02T14:38:45.948817Z"}],"nvd":[{"id":"CVE-2020-8929","description":"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.","status":"published","published":"2020-10-19T13:15:13.437Z","modified":"2026-06-17T03:27:11.487Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium","assessor":"secondary"},{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium","assessor":"primary"},{"version":"2.0","score":5,"vector":"AV:N/AC:L/Au:N/C:N/I:P/A:N","level":"medium","assessor":"primary"}],"cwes":["CWE-176"],"updated_at":"2026-11-02T14:06:19.351389Z"}],"osv":[{"id":"CVE-2020-8929","description":"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.","status":"published","published":"2020-10-19T13:15:13.437Z","modified":"2026-10-24T14:12:09.205963029Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"updated_at":"2026-11-02T15:44:17.663289Z"},{"id":"GHSA-g5vf-v6wf-7w2r","title":"Ciphertext Malleability Issue in Tink Java","description":"### Impact\nTink's Java version before 1.5 under some circumstances allowed attackers to change the key ID part of the ciphertext, resulting in the attacker creating a second ciphertext that will decrypt to the same plaintext. This can be a problem in particular in the case of encrypting with a deterministic AEAD with a single key, and relying on the fact that there is only a single valid ciphertext per plaintext.\n\nNo loss of confidentiality or loss of plaintext integrity occurs due to this problem, only ciphertext integrity is compromised.\n\n### Patches\nThe issue was fixed in this [pull request](https://github.com/google/tink/commit/93d839a5865b9d950dffdc9d0bc99b71280a8899).\n\n### Workarounds\nThe only workaround is to backport the fixing [pull request](https://github.com/google/tink/commit/93d839a5865b9d950dffdc9d0bc99b71280a8899).\n\n### Details\nTink uses the first five bytes of a ciphertext for a version byte and a four byte key ID. Since each key has a well defined prefix, this extends non-malleability properties (but technically not indistinguishability). However, in the Java version this prefix lookup used a hash map indexed by unicode strings instead of the byte array, which means that invalid Unicode characters would be [replaced by U+FFFD](https://en.wikipedia.org/wiki/UTF-8#Invalid_sequences_and_error_handling) by the [Java API's default behavior](https://docs.oracle.com/javase/7/docs/api/java/lang/String.html#String(byte[],%20java.nio.charset.Charset)). This means several different values for the five bytes would result in the same hash table key, which allows an attacker to exchange one invalid byte sequence for another, creating a mutated ciphertext that still decrypts (to the same plaintext).\n\n### Acknowledgements\nWe'd like to thank Peter Esbensen for finding this issue and raising it internally.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Tink](https://github.com/google/tink/issues)","status":"published","published":"2020-10-16T00:51:24Z","modified":"2026-07-08T06:00:03.1459756Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"medium"},{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-176","CWE-327"],"updated_at":"2026-11-02T15:46:47.472172Z"},{"id":"PYSEC-2020-142","description":"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.","status":"published","published":"2020-10-19T13:15:00Z","modified":"2023-11-08T04:04:19.465376Z","updated_at":"2026-11-02T15:52:52.192131Z"}]}}