Openpgp
Monthly
Signature misattribution in the high-level OpenPGP API of Bouncy Castle for Java before 1.86 lets an attacker who holds a third party's public signing subkey - entirely public material - graft that subkey onto their own primary key with a Subkey Binding signature that omits both the Key Flags subpacket and the embedded Primary Key Binding (cross-certification) signature. Because OpenPGPCertificate.isSigningKey() and verifyEmbeddedPrimaryKeyBinding() resolved the subkey's key flags two different ways, the grafted subkey was treated as signing-capable while being exempt from the cross-certification requirement, so OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true for a message the subkey genuinely signed and reported the attacker's certificate as its issuer; GnuPG rejects the identical certificate and message. This yields misattribution of an existing genuine signature under an attacker-chosen, self-asserted identity - no private key is recovered and no new signature can be forged - and only affects relying parties that pin trust on the subkey's fingerprint or key ID while taking the signer identity from the enclosing certificate. The vendor rates it 8.2 (CVSS 4.0) with integrity-only impact; an independent assessment scores it CVSS 3.1 8.2-equivalent integrity-only (AC:H, PR:N, UI:N), no public exploit code and no confirmed active exploitation (not in CISA KEV) were identified at time of analysis.
Truncated OpenPGP messages are silently accepted by Bouncy Castle for Java's OpenPGP decryption streams, letting an attacker who can deliver or truncate a message strip trailing packets and, on the SEIPD version 1 path, suppress the modification detection code check entirely, so recipients are handed unauthenticated CFB-decrypted plaintext. The AEAD route (SEIPD v2 and the version 5 AEAD packet) fails open when a literal data packet ends exactly on an AEAD chunk boundary and the consumer reads in increments smaller than one chunk, while the more severe SEIPDv1 route affects only the high-level org.bouncycastle.openpgp.api present in bc-java, not the LTS or FIPS editions. The vendor rates this CVSS 4.0 8.2 (VI:H, with no confidentiality or availability impact), and the fix is released in bc-java 1.86, bc-lts-java 2.73.13, and bcpg-fips 1.0.14 / 2.0.14.1 / 2.1.14; no public exploit identified at time of analysis.
Denial of service in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows unauthenticated remote attackers to exhaust process memory by supplying crafted OpenPGP public keys, certificates, or signatures, because a subpacket header using the five-octet (0xFF) length form declares an oversized body length that is used directly to size a buffer before any subpacket data is read. The flaw lives in SignatureSubpacketsParser.ReadPacket and UserAttributeSubpacketsParser.ReadPacket (CWE-789, memory allocation with excessive size value) and is rated CVSS 4.0 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) and an independently assessed CVSS 3.1 of A:H with no confidentiality or integrity impact; a handful of input bytes can demand an allocation of up to roughly 2 GB (the 32-bit length field permits up to ~4 GB in principle), so any service that imports or verifies untrusted PGP material is exposed. Vendor patches are available (bc-csharp 2.7.0) and no public exploit code has been identified at time of analysis, though the upstream regression test does illustrate the malicious packet format.
Signature misattribution in the high-level OpenPGP API of Bouncy Castle for Java before 1.86 lets an attacker who holds a third party's public signing subkey - entirely public material - graft that subkey onto their own primary key with a Subkey Binding signature that omits both the Key Flags subpacket and the embedded Primary Key Binding (cross-certification) signature. Because OpenPGPCertificate.isSigningKey() and verifyEmbeddedPrimaryKeyBinding() resolved the subkey's key flags two different ways, the grafted subkey was treated as signing-capable while being exempt from the cross-certification requirement, so OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true for a message the subkey genuinely signed and reported the attacker's certificate as its issuer; GnuPG rejects the identical certificate and message. This yields misattribution of an existing genuine signature under an attacker-chosen, self-asserted identity - no private key is recovered and no new signature can be forged - and only affects relying parties that pin trust on the subkey's fingerprint or key ID while taking the signer identity from the enclosing certificate. The vendor rates it 8.2 (CVSS 4.0) with integrity-only impact; an independent assessment scores it CVSS 3.1 8.2-equivalent integrity-only (AC:H, PR:N, UI:N), no public exploit code and no confirmed active exploitation (not in CISA KEV) were identified at time of analysis.
Truncated OpenPGP messages are silently accepted by Bouncy Castle for Java's OpenPGP decryption streams, letting an attacker who can deliver or truncate a message strip trailing packets and, on the SEIPD version 1 path, suppress the modification detection code check entirely, so recipients are handed unauthenticated CFB-decrypted plaintext. The AEAD route (SEIPD v2 and the version 5 AEAD packet) fails open when a literal data packet ends exactly on an AEAD chunk boundary and the consumer reads in increments smaller than one chunk, while the more severe SEIPDv1 route affects only the high-level org.bouncycastle.openpgp.api present in bc-java, not the LTS or FIPS editions. The vendor rates this CVSS 4.0 8.2 (VI:H, with no confidentiality or availability impact), and the fix is released in bc-java 1.86, bc-lts-java 2.73.13, and bcpg-fips 1.0.14 / 2.0.14.1 / 2.1.14; no public exploit identified at time of analysis.
Denial of service in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows unauthenticated remote attackers to exhaust process memory by supplying crafted OpenPGP public keys, certificates, or signatures, because a subpacket header using the five-octet (0xFF) length form declares an oversized body length that is used directly to size a buffer before any subpacket data is read. The flaw lives in SignatureSubpacketsParser.ReadPacket and UserAttributeSubpacketsParser.ReadPacket (CWE-789, memory allocation with excessive size value) and is rated CVSS 4.0 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) and an independently assessed CVSS 3.1 of A:H with no confidentiality or integrity impact; a handful of input bytes can demand an allocation of up to roughly 2 GB (the 32-bit length field permits up to ~4 GB in principle), so any service that imports or verifies untrusted PGP material is exposed. Vendor patches are available (bc-csharp 2.7.0) and no public exploit code has been identified at time of analysis, though the upstream regression test does illustrate the malicious packet format.