org.bouncycastle:bcpg-fips 2.0.9

Direct Vulnerabilities

Known vulnerabilities in the org.bouncycastle:bcpg-fips package. This does not include vulnerabilities belonging to this package’s dependencies.

Fix vulnerabilities automatically

Snyk's AI Trust Platform automatically finds the best upgrade path and integrates with your development workflows. Secure your code at zero cost.

Fix for free

Vulnerability	Vulnerable Version
H Improper Validation of Integrity Check Value Affected versions of this package are vulnerable to Improper Validation of Integrity Check Value in the `readBlock()` method of `PGPAeadInputStream` (`BcAEADUtil`, mirrored in `JceAEADUtil`), which pre-reads the final 16 bytes but ignores the result and returns EOF without calling `doFinal()` when the data length is an exact multiple of the chunk size. An attacker can have truncated plaintext accepted as authentic by stripping trailing chunks and the final tag from an AEAD-encrypted message and adjusting the unauthenticated outer packet length. This applies only when the plaintext length is chunk-aligned, and it requires the attacker to modify the transmitted ciphertext and its packet length. How to fix Improper Validation of Integrity Check Value? Upgrade `org.bouncycastle:bcpg-fips` to version 1.0.13, 2.0.13, 2.1.13 or higher.	[,1.0.13)[2.0.0,2.0.13)[2.1.0,2.1.13)
H Exposure of Sensitive Information Through Metadata Affected versions of this package are vulnerable to Exposure of Sensitive Information Through Metadata via CFB quick-check decryption oracle in the `getDataStream()` method of `PGPSymmetricKeyEncryptedData`, reached through `PGPPBEEncryptedData`, `PGPSessionKeyEncryptedData`, and `OpenPGPMessageProcessor`, which checks the two repeated CFB IV bytes and throws `PGPDataValidationException` before MDC verification completes. An attacker with adaptive chosen-ciphertext access to a decryption endpoint can recover roughly two plaintext bytes per about 2^15 queries by distinguishing the early quick-check failure from a later MDC or parse failure. This affects only the symmetric and session-key decryption paths on SEIPDv1 messages, not `PGPPublicKeyEncryptedData` which already skips the check, and it requires the endpoint's early and late failures to be distinguishable to the attacker. How to fix Exposure of Sensitive Information Through Metadata? Upgrade `org.bouncycastle:bcpg-fips` to version 1.0.13, 2.0.13, 2.1.13 or higher.	[,1.0.13)[2.0.8,2.0.13)[2.1.10,2.1.13)
M Allocation of Resources Without Limits or Throttling Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the `S2K.Argon2Params` class and the `PGPUtil.makeKeyFromPassPhrase()` method, which read the one-byte OpenPGP Argon2 passes, parallelism, and memory-size exponent fields with only a default cap of `memorySizeExponent <= 30` (1 TiB) and feed them straight into `Argon2BytesGenerator`. An attacker can exhaust memory or stall the process with up to roughly 1 TiB of allocation and heavy CPU work before any authenticity check, by embedding these Argon2 parameters in a minimal SKESK or secret-key packet that the victim attempts to decrypt with a passphrase. This requires the victim to begin passphrase-based decryption of the attacker-supplied message or key, since the cost is incurred during S2K key derivation ahead of authentication. How to fix Allocation of Resources Without Limits or Throttling? A fix was pushed into the `master` branch but not yet published.	[1.0.6,1.0.13)[2.0.8,)
H Memory Allocation with Excessive Size Value Affected versions of this package are vulnerable to Memory Allocation with Excessive Size Value in the `readPacket()` method of `UserAttributeSubpacketInputStream`, which reads a 5-octet subpacket length up to `Integer.MAX_VALUE` and allocates `new byte[bodyLen-1]` after checking only against a `limit` derived from JVM maximum memory rather than the enclosing packet body length. An attacker can exhaust memory and trigger an `OutOfMemoryError` by getting a victim to import an OpenPGP public key whose user-attribute subpacket declares a length approaching the full heap, so a small key forces a near-heap-sized allocation. This requires the victim to import the attacker's public key, for example from a keyserver, WKD, or email attachment, and reaches the flaw through the single-argument `UserAttributePacket` stream construction where the limit is not bounded by the actual packet body. How to fix Memory Allocation with Excessive Size Value? Upgrade `org.bouncycastle:bcpg-fips` to version 1.0.13, 2.0.13, 2.1.13 or higher.	[,1.0.13)[2.0.0,2.0.13)[2.1.0,2.1.13)

Vulnerability

Vulnerable Version

Improper Validation of Integrity Check Value

Affected versions of this package are vulnerable to Improper Validation of Integrity Check Value in the readBlock() method of PGPAeadInputStream (BcAEADUtil, mirrored in JceAEADUtil), which pre-reads the final 16 bytes but ignores the result and returns EOF without calling doFinal() when the data length is an exact multiple of the chunk size. An attacker can have truncated plaintext accepted as authentic by stripping trailing chunks and the final tag from an AEAD-encrypted message and adjusting the unauthenticated outer packet length. This applies only when the plaintext length is chunk-aligned, and it requires the attacker to modify the transmitted ciphertext and its packet length.

How to fix Improper Validation of Integrity Check Value?

Upgrade org.bouncycastle:bcpg-fips to version 1.0.13, 2.0.13, 2.1.13 or higher.

[,1.0.13)[2.0.0,2.0.13)[2.1.0,2.1.13)

Exposure of Sensitive Information Through Metadata

Affected versions of this package are vulnerable to Exposure of Sensitive Information Through Metadata via CFB quick-check decryption oracle in the getDataStream() method of PGPSymmetricKeyEncryptedData, reached through PGPPBEEncryptedData, PGPSessionKeyEncryptedData, and OpenPGPMessageProcessor, which checks the two repeated CFB IV bytes and throws PGPDataValidationException before MDC verification completes. An attacker with adaptive chosen-ciphertext access to a decryption endpoint can recover roughly two plaintext bytes per about 2^15 queries by distinguishing the early quick-check failure from a later MDC or parse failure. This affects only the symmetric and session-key decryption paths on SEIPDv1 messages, not PGPPublicKeyEncryptedData which already skips the check, and it requires the endpoint's early and late failures to be distinguishable to the attacker.

How to fix Exposure of Sensitive Information Through Metadata?

Upgrade org.bouncycastle:bcpg-fips to version 1.0.13, 2.0.13, 2.1.13 or higher.

[,1.0.13)[2.0.8,2.0.13)[2.1.10,2.1.13)

Allocation of Resources Without Limits or Throttling

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the S2K.Argon2Params class and the PGPUtil.makeKeyFromPassPhrase() method, which read the one-byte OpenPGP Argon2 passes, parallelism, and memory-size exponent fields with only a default cap of memorySizeExponent <= 30 (1 TiB) and feed them straight into Argon2BytesGenerator. An attacker can exhaust memory or stall the process with up to roughly 1 TiB of allocation and heavy CPU work before any authenticity check, by embedding these Argon2 parameters in a minimal SKESK or secret-key packet that the victim attempts to decrypt with a passphrase. This requires the victim to begin passphrase-based decryption of the attacker-supplied message or key, since the cost is incurred during S2K key derivation ahead of authentication.

How to fix Allocation of Resources Without Limits or Throttling?

A fix was pushed into the master branch but not yet published.

[1.0.6,1.0.13)[2.0.8,)

Memory Allocation with Excessive Size Value

Affected versions of this package are vulnerable to Memory Allocation with Excessive Size Value in the readPacket() method of UserAttributeSubpacketInputStream, which reads a 5-octet subpacket length up to Integer.MAX_VALUE and allocates new byte[bodyLen-1] after checking only against a limit derived from JVM maximum memory rather than the enclosing packet body length. An attacker can exhaust memory and trigger an OutOfMemoryError by getting a victim to import an OpenPGP public key whose user-attribute subpacket declares a length approaching the full heap, so a small key forces a near-heap-sized allocation. This requires the victim to import the attacker's public key, for example from a keyserver, WKD, or email attachment, and reaches the flaw through the single-argument UserAttributePacket stream construction where the limit is not bounded by the actual packet body.

How to fix Memory Allocation with Excessive Size Value?

Upgrade org.bouncycastle:bcpg-fips to version 1.0.13, 2.0.13, 2.1.13 or higher.

[,1.0.13)[2.0.0,2.0.13)[2.1.0,2.1.13)

org.bouncycastle:bcpg-fips@2.0.9

latest version

latest non vulnerable version

first published

latest version published

licenses detected

package registry

Direct Vulnerabilities

Fix vulnerabilities automatically