Threats Tagged 'cwe-354'

Bouncy Castle for Java versions before 1.85 and LTS versions before 2.73.12 have a vulnerability in the KCCMBlockCipher MAC implementation where the nonce is not bound when Additional Authenticated Data (AAD) is absent. This flaw allows a cross-nonce AEAD forgery attack, undermining the integrity guarantees of the cipher.

A vulnerability exists in Bouncy Castle for Java before version 1.85 and in the LTS version before 2.73.12, where the IESEngine stream-mode MAC can be forged due to a length-dependent key derivation function (KDF) split. This issue is tracked as CVE-2026-12816 and is classified under CWE-354 (Improper Validation of Integrity Check Value).

Bouncy Castle for Java versions before 1.85 have a vulnerability in OpenPGP AEAD decryption where the final authentication tag is skipped on chunk-aligned data. This flaw also affects Bouncy Castle for Java LTS before 2.73.12 and Bouncy Castle for Java FIPS versions prior to bcpg-fips 1.0.13, 2.0.13, and 2.1.13 in their respective series. The issue can lead to improper verification of encrypted data integrity.

Bouncy Castle for Java versions prior to 1.85, including certain LTS and FIPS releases, have a vulnerability in CCM-family encryption modes where plaintext is written to the caller's buffer before the authentication tag is verified. This behavior can lead to potential exposure of plaintext data if the tag check fails.

CVE-2026-12802 is a high-severity vulnerability in Legion of the Bouncy Castle Inc.'s BC-JAVA library. It involves improper validation of the integrity check value in the CMS AuthEnvelopedData decryption process, specifically failing to enforce tag-length. This affects versions of Bouncy Castle for Java before 1.85 and certain LTS and FIPS versions prior to specified patch releases.

CVE-2026-59642 is a high-severity vulnerability in Bouncy Castle for Java (BC-JAVA) affecting versions before 1.85 and certain LTS and FIPS versions prior to specified patch releases. The issue involves improper validation of the integrity check value in CMS AuthenticatedData when authenticated attributes are present, meaning the content is not properly bound to the MAC. This could undermine the integrity guarantees of the cryptographic message syntax implementation.

In NLnet Labs Unbound up to and including version 1.25.1, when the validator builds the canonical RDATA form for an RRSIG-covered PX/RP/MINFO/SOA RRset, it computes the address of the second embedded domain name as 'datstart + dname_valid(datstart, ...)' and passes it straight to 'query_dname_tolower()' without checking that a second name is actually present in the RDATA. The wire-format parser accepts multi-dname RRs whose RDATA ends after the first name, so an attacker who runs a DNSSEC-signed authoritative server can deliver a record with an absent second domain name (e.g. SOA record) and cause 'query_dname_tolower()' to walk label-by-label through stale bytes in the per-worker 'env->scratch_buffer', past the end of that heap allocation if 'msg-buffer-size' has been lowered from the default. This leads to heap buffer overflow and on a release build the outcome relies heavily on the contents of the buffer tail and the adjacent heap chunk.