CWE-354 CVEs

14 CVEs

Look up CVE IDs Status Exploitation Severity

Reset

Overview 14 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5

14matches 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%

Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 14 100.0%

Critical 0 0.0% High 9 64.3% Medium 4 28.6% Low 1 7.1% None 0 0.0% Unknown 0 0.0%

blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 14 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 14 100.0%

split by StatusSeverityProtectionExploit maturity peak 10 / year

20171 No exploit published1 Low1 not blocked1 No public exploit1 20181 No exploit published1 Medium1 not blocked1 No public exploit1 20190 20200 20210 20220 20230 20242 No exploit published2 High1 Medium1 not blocked2 No public exploit2 20250 202610 No exploit published10 High8 Medium2 not blocked10 No public exploit10

2017201820192020202120222023202420252026

14 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.

CVE	Severity	Published▾	Status	Exploitation	Description
CVE-2026-85243	Medium	2026-10-19	No exploit published	No public exploit	Improper Validation of Integrity Check Value vulnerability in Apache Camel Crypto PGP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. unmarshal() verified the modification detection code only when the message was an OpenPGP symmetrically encrypted integrity protected data packet. The older symmetrically encrypted data packet carries no such code, and OpenPGP's CFB mode is malleable without one, so a message using that packet skipped the check altogether. The packet type is chosen by whoever produced the message, which left the sender - or anyone able to rewrite the message in transit - deciding whether the integrity check applied at all. The existing integrity option governs marshalling only and had no decrypt-side counterpart, so a deployment could not require integrity protection on the messages it accepted. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A requireIntegrityProtection option, defaulting to true, now rejects a message that is not integrity protected. Note that signatureVerificationOption still defaults to optional, so a message carrying no signature is accepted; the two options together are what give a decrypted message authenticity and not only confidentiality. For deployments that cannot upgrade immediately, reject messages that do not use the integrity protected packet before they reach the data format. Routes that must interoperate with a sender still emitting the legacy packet should set requireIntegrityProtection=false after upgrading, and treat the decrypted content as unauthenticated.
CVE-2026-85515	High	2026-10-03	No exploit published	No public exploit	In Bouncy Castle for Java before 1.86, a truncated OpenPGP encrypted message was accepted with no error reported, and on the SEIPD version 1 path with no integrity check performed at all. RFC 9580 sec. 13.7 permits an implementation to release the cleartext of the fully authenticated chunks when streaming but requires it to indicate a clear error as soon as the truncation is detected, and to report suspect integrity when it discovers malleable ciphertext. The truncation was detected and then discarded: when a message is truncated but the length field of the enclosing packet is left unchanged, BCPGInputStream.PartialInputStream raises an EOFException for the missing ciphertext, and BCPGInputStream.nextPacketTag() reports an EOFException as a clean end of message, so the packet stream above it stopped as though no packets remained. On the AEAD path (SEIPD version 2 and the version 5 AEAD packet), when the literal data packet ended on an AEAD chunk boundary and the consumer read in increments smaller than one chunk, the look-ahead for the packet after the literal triggered the truncated chunk read, so BcAEADUtil and JceAEADUtil never reached the trailing message tag of sec. 5.13.2 that authenticates the total plaintext length; the caller received the plaintext of the fully authenticated chunks, every packet following the literal was silently dropped, and no exception was raised, so a signed and encrypted message read back as a well-formed unsigned one. Every byte released on that path remained individually authenticated, making this a missing truncation error rather than a forgery, and it is a residual of CVE-2026-12817, which closed the same outcome for an attacker who corrects the outer packet length. On the SEIPD version 1 path the consequence was more serious: IntegrityProtectedInputStream verifies the modification detection code from close(), and reached close() only by closing itself when a read of it returned -1, which a truncated message never produces, so PGPEncryptedData.verify() never ran and the recipient was handed CFB-decrypted plaintext on which no integrity check of any kind had been performed. Measured on a message truncated into that shape, 136 distinct single-byte modifications of the ciphertext produced accepted, altered plaintext with no exception raised. Reachability is a property of the message rather than of attacker-supplied input: the AEAD shape held for 3 of 131 consecutive payload lengths measured, and the SEIPD version 1 shape for one payload length in sixteen, at a truncation offset that did not move with the payload length. The low-level API is unaffected, a caller that invokes PGPEncryptedData.verify() directly getting the check regardless, as are consumers reading in increments of a whole AEAD chunk or more. The AEAD decryption streams now re-throw such an EOFException as a plain IOException, which nextPacketTag() does not launder; OpenPGPMessageInputStream.close() now closes its layer's integrity-protected stream itself rather than relying on that stream having seen the end of its data; and IntegrityProtectedInputStream.close() was made idempotent, as java.io.Closeable requires, which that depends on, since the stream is genuinely closed twice on the ordinary path and PGPEncryptedData.verify() consumes the digest state behind it and cannot be run a second time. This issue also affects Bouncy Castle for Java LTS before 2.73.13, on the AEAD route only, as that edition does not ship the high-level OpenPGP API the SEIPDv1 route runs through. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.14 (1.0.X series), 2.0.14.1 (2.0.X series) and 2.1.14 (2.1.X series), on the AEAD route only, as those editions do not ship the high-level OpenPGP API.
CVE-2026-71888	High	2026-10-03	No exploit published	No public exploit	In Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about whether authenticated attributes were present. RFC 5652 sec. 9.1 pairs the two, requiring that authAttrs be present whenever digestAlgorithm is, and sec. 9.2 makes the MAC cover the DER encoding of authAttrs when they are present and the eContent OCTET STRING directly when they are not. CMSAuthenticatedDataParser has to choose between those two in its constructor, before it can reach authAttrs, which comes later in the SEQUENCE, so it chose on digestAlgorithm alone: for a message with digestAlgorithm absent but authAttrs present it verified the content MAC and then returned the attributes through getAuthAttrs() as though they had been authenticated, when the MAC had never covered them. An attacker able to modify a message in transit could insert an authenticated attribute, such as an RFC 2634 ESSSecurityLabel, into an otherwise valid message while holding neither the key-encryption key nor the content-MAC key, and an application taking an authorization, routing or labelling decision from those attributes would act on attacker-chosen values. The content itself remained MAC-bound. asn1.cms.AuthenticatedData now rejects the mismatched pairing when parsing and CMSAuthenticatedDataParser cross-checks the two fields once authAttrs is read. This is a variant of CVE-2026-59642, which bound the content to the MAC for messages that legitimately carry authAttrs, and which does not address this case. This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series), and bcutil-fips 2.0.8 (2.0.X series) and 2.1.8 (2.1.X series).
CVE-2026-59642	High	2026-08-03	No exploit published	No public exploit	In Bouncy Castle for Java before 1.85, CMS AuthenticatedData content not bound to MAC when authAttrs present. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.12 (1.0.X series), 2.0.12 (2.0.X series) and 2.1.12 (2.1.X series).
CVE-2026-58061	High	2026-08-03	No exploit published	No public exploit	In Bouncy Castle for Java before 1.85, CCM-family modes write plaintext to caller buffer before tag check. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
CVE-2026-12817	High	2026-08-03	No exploit published	No public exploit	In Bouncy Castle for Java before 1.85, OpenPGP AEAD decryption skips final tag on chunk-aligned data. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).
CVE-2026-12816	High	2026-08-03	No exploit published	No public exploit	In Bouncy Castle for Java before 1.85, IESEngine stream-mode MAC forgery via length-dependent KDF split. This issue also affects Bouncy Castle for Java LTS before 2.73.12.
CVE-2026-12803	High	2026-08-03	No exploit published	No public exploit	In Bouncy Castle for Java before 1.85, KCCMBlockCipher MAC does not bind nonce when AAD is absent (cross-nonce AEAD forgery). This issue also affects Bouncy Castle for Java LTS before 2.73.12.
CVE-2026-12802	High	2026-08-03	No exploit published	No public exploit	In Bouncy Castle for Java before 1.85, CMS AuthEnvelopedData fails to enforce tag-length on decryption. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.12 (1.0.X series), 2.0.12 (2.0.X series) and 2.1.12 (2.1.X series).
CVE-2026-8149	Medium	2026-05-08	No exploit published	No public exploit	A vulnerability in Legion of the Bouncy Castle Inc. BC-LTS bcprov-lts8on on X86_64, AVX, AVX-512f, Linux, Legion of the Bouncy Castle Inc. BC-FJA bc-fips on Linux, X86_64, AVX, AVX-512f. This vulnerability is associated with program files gcm128w, gcm512w, gcm128w.C, gcm512w.C. This issue affects BC-LTS: from 2.73.0 before 2.73.11; BC-FJA: from 2.1.0 before 2.1.3.
CVE-2024-52550	High	2024-11-13	No exploit published	No public exploit	Jenkins Pipeline: Groovy Plugin 3990.vd281dd77a_388 and earlier, except 3975.3977.v478dd9e956c3 does not check whether the main (Jenkinsfile) script for a rebuilt build is approved, allowing attackers with Item/Build permission to rebuild a previous build whose (Jenkinsfile) script is no longer approved.
CVE-2024-41909	Medium	2024-08-12	No exploit published	No public exploit	Like many other SSH implementations, Apache MINA SSHD suffered from the issue that is more widely known as CVE-2023-48795. An attacker that can intercept traffic between client and server could drop certain packets from the stream, potentially causing client and server to consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack The mitigations to prevent this type of attack were implemented in Apache MINA SSHD 2.12.0, both client and server side. Users are recommended to upgrade to at least this version. Note that both the client and the server implementation must have mitigations applied against this issue, otherwise the connection may still be affected.
CVE-2018-5382	Medium	2018-04-16	No exploit published	No public exploit	The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.
CVE-2017-12973	Low	2017-08-20	No exploit published	No public exploit	Nimbus JOSE+JWT before 4.39 proceeds improperly after detection of an invalid HMAC in authenticated AES-CBC decryption, which allows attackers to conduct a padding oracle attack.

CVE

Severity

Published▾

Status

Exploitation

Description

CVE-2026-85243

Medium

2026-10-19

No exploit published

No public exploit

Improper Validation of Integrity Check Value vulnerability in Apache Camel Crypto PGP component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.1. unmarshal() verified the modification detection code only when the message was an OpenPGP symmetrically encrypted integrity protected data packet. The older symmetrically encrypted data packet carries no such code, and OpenPGP's CFB mode is malleable without one, so a message using that packet skipped the check altogether. The packet type is chosen by whoever produced the message, which left the sender - or anyone able to rewrite the message in transit - deciding whether the integrity check applied at all. The existing integrity option governs marshalling only and had no decrypt-side counterpart, so a deployment could not require integrity protection on the messages it accepted. Upgrade to Apache Camel 4.23.0, which fixes the issue. Users on the 4.18.x LTS releases stream should upgrade to 4.18.5. Users on the 4.22.x LTS releases stream should upgrade to 4.22.1. A requireIntegrityProtection option, defaulting to true, now rejects a message that is not integrity protected. Note that signatureVerificationOption still defaults to optional, so a message carrying no signature is accepted; the two options together are what give a decrypted message authenticity and not only confidentiality. For deployments that cannot upgrade immediately, reject messages that do not use the integrity protected packet before they reach the data format. Routes that must interoperate with a sender still emitting the legacy packet should set requireIntegrityProtection=false after upgrading, and treat the decrypted content as unauthenticated.

CVE-2026-85515

High

2026-10-03

No exploit published

No public exploit

In Bouncy Castle for Java before 1.86, a truncated OpenPGP encrypted message was accepted with no error reported, and on the SEIPD version 1 path with no integrity check performed at all. RFC 9580 sec. 13.7 permits an implementation to release the cleartext of the fully authenticated chunks when streaming but requires it to indicate a clear error as soon as the truncation is detected, and to report suspect integrity when it discovers malleable ciphertext. The truncation was detected and then discarded: when a message is truncated but the length field of the enclosing packet is left unchanged, BCPGInputStream.PartialInputStream raises an EOFException for the missing ciphertext, and BCPGInputStream.nextPacketTag() reports an EOFException as a clean end of message, so the packet stream above it stopped as though no packets remained. On the AEAD path (SEIPD version 2 and the version 5 AEAD packet), when the literal data packet ended on an AEAD chunk boundary and the consumer read in increments smaller than one chunk, the look-ahead for the packet after the literal triggered the truncated chunk read, so BcAEADUtil and JceAEADUtil never reached the trailing message tag of sec. 5.13.2 that authenticates the total plaintext length; the caller received the plaintext of the fully authenticated chunks, every packet following the literal was silently dropped, and no exception was raised, so a signed and encrypted message read back as a well-formed unsigned one. Every byte released on that path remained individually authenticated, making this a missing truncation error rather than a forgery, and it is a residual of CVE-2026-12817, which closed the same outcome for an attacker who corrects the outer packet length. On the SEIPD version 1 path the consequence was more serious: IntegrityProtectedInputStream verifies the modification detection code from close(), and reached close() only by closing itself when a read of it returned -1, which a truncated message never produces, so PGPEncryptedData.verify() never ran and the recipient was handed CFB-decrypted plaintext on which no integrity check of any kind had been performed. Measured on a message truncated into that shape, 136 distinct single-byte modifications of the ciphertext produced accepted, altered plaintext with no exception raised. Reachability is a property of the message rather than of attacker-supplied input: the AEAD shape held for 3 of 131 consecutive payload lengths measured, and the SEIPD version 1 shape for one payload length in sixteen, at a truncation offset that did not move with the payload length. The low-level API is unaffected, a caller that invokes PGPEncryptedData.verify() directly getting the check regardless, as are consumers reading in increments of a whole AEAD chunk or more. The AEAD decryption streams now re-throw such an EOFException as a plain IOException, which nextPacketTag() does not launder; OpenPGPMessageInputStream.close() now closes its layer's integrity-protected stream itself rather than relying on that stream having seen the end of its data; and IntegrityProtectedInputStream.close() was made idempotent, as java.io.Closeable requires, which that depends on, since the stream is genuinely closed twice on the ordinary path and PGPEncryptedData.verify() consumes the digest state behind it and cannot be run a second time. This issue also affects Bouncy Castle for Java LTS before 2.73.13, on the AEAD route only, as that edition does not ship the high-level OpenPGP API the SEIPDv1 route runs through. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.14 (1.0.X series), 2.0.14.1 (2.0.X series) and 2.1.14 (2.1.X series), on the AEAD route only, as those editions do not ship the high-level OpenPGP API.

CVE-2026-71888

High

2026-10-03

No exploit published

No public exploit

In Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about whether authenticated attributes were present. RFC 5652 sec. 9.1 pairs the two, requiring that authAttrs be present whenever digestAlgorithm is, and sec. 9.2 makes the MAC cover the DER encoding of authAttrs when they are present and the eContent OCTET STRING directly when they are not. CMSAuthenticatedDataParser has to choose between those two in its constructor, before it can reach authAttrs, which comes later in the SEQUENCE, so it chose on digestAlgorithm alone: for a message with digestAlgorithm absent but authAttrs present it verified the content MAC and then returned the attributes through getAuthAttrs() as though they had been authenticated, when the MAC had never covered them. An attacker able to modify a message in transit could insert an authenticated attribute, such as an RFC 2634 ESSSecurityLabel, into an otherwise valid message while holding neither the key-encryption key nor the content-MAC key, and an application taking an authorization, routing or labelling decision from those attributes would act on attacker-chosen values. The content itself remained MAC-bound. asn1.cms.AuthenticatedData now rejects the mismatched pairing when parsing and CMSAuthenticatedDataParser cross-checks the two fields once authAttrs is read. This is a variant of CVE-2026-59642, which bound the content to the MAC for messages that legitimately carry authAttrs, and which does not address this case. This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series), and bcutil-fips 2.0.8 (2.0.X series) and 2.1.8 (2.1.X series).

CVE-2026-59642

High

2026-08-03

No exploit published

No public exploit

In Bouncy Castle for Java before 1.85, CMS AuthenticatedData content not bound to MAC when authAttrs present. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.12 (1.0.X series), 2.0.12 (2.0.X series) and 2.1.12 (2.1.X series).

CVE-2026-58061

High

2026-08-03

No exploit published

No public exploit

In Bouncy Castle for Java before 1.85, CCM-family modes write plaintext to caller buffer before tag check. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).

CVE-2026-12817

High

2026-08-03

No exploit published

No public exploit

In Bouncy Castle for Java before 1.85, OpenPGP AEAD decryption skips final tag on chunk-aligned data. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).

CVE-2026-12816

High

2026-08-03

No exploit published

No public exploit

In Bouncy Castle for Java before 1.85, IESEngine stream-mode MAC forgery via length-dependent KDF split. This issue also affects Bouncy Castle for Java LTS before 2.73.12.

CVE-2026-12803

High

2026-08-03

No exploit published

No public exploit

In Bouncy Castle for Java before 1.85, KCCMBlockCipher MAC does not bind nonce when AAD is absent (cross-nonce AEAD forgery). This issue also affects Bouncy Castle for Java LTS before 2.73.12.

CVE-2026-12802

High

2026-08-03

No exploit published

No public exploit

In Bouncy Castle for Java before 1.85, CMS AuthEnvelopedData fails to enforce tag-length on decryption. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.12 (1.0.X series), 2.0.12 (2.0.X series) and 2.1.12 (2.1.X series).

CVE-2026-8149

Medium

2026-05-08

No exploit published

No public exploit

A vulnerability in Legion of the Bouncy Castle Inc. BC-LTS bcprov-lts8on on X86_64, AVX, AVX-512f, Linux, Legion of the Bouncy Castle Inc. BC-FJA bc-fips on Linux, X86_64, AVX, AVX-512f. This vulnerability is associated with program files gcm128w, gcm512w, gcm128w.C, gcm512w.C. This issue affects BC-LTS: from 2.73.0 before 2.73.11; BC-FJA: from 2.1.0 before 2.1.3.

CVE-2024-52550

High

2024-11-13

No exploit published

No public exploit

Jenkins Pipeline: Groovy Plugin 3990.vd281dd77a_388 and earlier, except 3975.3977.v478dd9e956c3 does not check whether the main (Jenkinsfile) script for a rebuilt build is approved, allowing attackers with Item/Build permission to rebuild a previous build whose (Jenkinsfile) script is no longer approved.

CVE-2024-41909

Medium

2024-08-12

No exploit published

No public exploit

Like many other SSH implementations, Apache MINA SSHD suffered from the issue that is more widely known as CVE-2023-48795. An attacker that can intercept traffic between client and server could drop certain packets from the stream, potentially causing client and server to consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack The mitigations to prevent this type of attack were implemented in Apache MINA SSHD 2.12.0, both client and server side. Users are recommended to upgrade to at least this version. Note that both the client and the server implementation must have mitigations applied against this issue, otherwise the connection may still be affected.

CVE-2018-5382

Medium

2018-04-16

No exploit published

No public exploit

The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.

CVE-2017-12973

Low

2017-08-20

No exploit published

No public exploit

Nimbus JOSE+JWT before 4.39 proceeds improperly after detection of an invalid HMAC in authenticated AES-CBC decryption, which allows attackers to conduct a padding oracle attack.