Updated 8 h ago

Vulnerability database

Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.

1,762exploited flaws on CISA’s list

34added in the last 30 days

343new WordPress flaws this week

390,080entries in the database

114 results · page 1 of 3

Oct 9, 2026In Bouncy Castle for Java LTS before 2.73.13, the native one-shot CTR packet cipher did not check that the requested input length fitted the counter space the ICVE-2026-71884 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
In Bouncy Castle for Java LTS before 2.73.13, the native one-shot CTR packet cipher did not check that the requested input length fitted the counter space the IV left. In CTR mode the IV and the block counter share one 16-byte block, so an IV of 13 to 15 bytes leaves a counter of only 1 to 3 bytes, addressing 256, 65536 or 16777216 blocks respectively. Given a longer input the counter wrapped and the keystream repeated from the start of the same packet, and the call then returned the full input length as though every byte had been correctly transformed. Two segments of the message were therefore encrypted under the same keystream, so their plaintexts can be recovered from the ciphertext alone, without the key, while the caller saw neither an exception nor a short length to indicate it. The streaming implementation validates at init and again while processing, and the portable AESCTRPacketCipher rejects such a request with "Counter in CTR/SIC mode out of range.", but the native one-shot path has a single entry point and performed no counter-range validation there. It now preflights the IV-derived counter range and rejects an over-long request before any output is written, so the ope
Product
BC-LTS-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com
Oct 3, 2026In Bouncy Castle for Java before 1.86, the raw JCA provider's legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families ran their password-based key derivation wiCVE-2026-97873 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630Medium 5.3
In Bouncy Castle for Java before 1.86, the raw JCA provider's legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families ran their password-based key derivation with an iteration count taken from untrusted input without bounding it, so a small input could dictate an arbitrary amount of work before anything could be verified. The AlgorithmParameters implementations (PKCS12PBE and its object identifier aliases, and PBKDF1) accepted any count from an encoded PKCS12PBEParams or PBEParameter, narrowing a value beyond the int range with intValue(), and every Cipher, Mac and SecretKeyFactory in these families derived with whatever count it was given, including one decoded by another provider's AlgorithmParameters, as when javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() decrypts a PKCS#12 PBE-protected private key with BC. Both the parameter parse and the derivations now reject a negative or over-limit count under the org.bouncycastle.pbe.max_iteration_count property (default 10,000,000) that already bounded PBKDF2 (CVE-2026-17508), and the parse rejects a count beyond the int range rather than narrowing it. This issue also affects Bouncy Castle for Java LTS before 2.73.13.
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 3, 2026In 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 integrCVE-2026-85515 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
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 tha
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 3, 2026In Bouncy Castle for Java before 1.86, the opt-in key-size validation on CMS key-transport recipients, org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySiCVE-2026-71892 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630Medium 6.9
In Bouncy Castle for Java before 1.86, the opt-in key-size validation on CMS key-transport recipients, org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true), never ran for a message using RFC 9709 content-encryption key derivation (id-alg-cek-hkdf-sha256). The branch that should have selected the actual content-encryption algorithm carried in the key derivation AlgorithmIdentifier's parameters compared the encrypted-key byte array against the id-alg-cek-hkdf-sha256 object identifier, a comparison between a byte array and an ASN1ObjectIdentifier that is false for every possible input, so the check fell through to a key-size lookup on the outer wrapper OID. That OID identifies a key-derivation construction rather than a cipher and has no registered key size, so the size comparison was skipped entirely. A key-transport EnvelopedData or AuthEnvelopedData whose transported, HKDF-derived content-encryption key did not match the key size of the advertised content-encryption algorithm was therefore accepted even with validation explicitly enabled, silently defeating the only mechanism the API offers for enforcing recovered key size. The recipient now dispatches on the
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 3, 2026In Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.keyValidate, and so BLSPublicKeyParameters and every BasicScheme, MessageAugmentation and ProofOfPosCVE-2026-71891 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 7.1
In Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.keyValidate, and so BLSPublicKeyParameters and every BasicScheme, MessageAugmentation and ProofOfPossession verify and aggregateVerify that gate on it, accepted a public key built on a foreign ECCurve that merely shares BLS12-381's field characteristic. The prime-order subgroup check trusts a point's own curve to name its cofactor, since ECPoint.satisfiesOrder returns true outright when the curve's cofactor is one, so a point on a curve with a different equation and a cofactor forged to one passed keyValidate despite not being a G1 point at all. In BC's pairing implementation such a point contributes the identity in the target group, so an aggregate signature verified against a set of public keys including it is accepted even though it contains no signature for that key and message pair, admitting a phantom signer. keyValidate now first confirms that the point's curve carries exactly the canonical G1 field, equation, order and cofactor before any subgroup check. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key; the standard
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 3, 2026In Bouncy Castle for Java before 1.86, validation of an MLS (RFC 9420) external commit's proposal list, org.bouncycastle.mls.protocol.Group.validateExternalCachCVE-2026-71890 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
In Bouncy Castle for Java before 1.86, validation of an MLS (RFC 9420) external commit's proposal list, org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals, counted the proposals by type and bounded the removed leaf index but never established that the removed leaf had anything to do with the joiner. RFC 9420 sec. 12.2 permits at most one Remove proposal in an external commit, with which the joiner removes an old version of themselves, and requires that where one is present the LeafNode in the commit's path field meet the criteria it would have to meet in an Update for the removed leaf, in particular that its credential present identifiers acceptable for the removed participant. The ordinary proposal-list validator's self-remove rule is deliberately not applied on this path, because a resync commit legitimately removes a leaf the joiner owns, but nothing was put in its place. Any party holding the group's public GroupInfo, which is precisely what an external joiner is meant to be given, could therefore commit a Remove naming any member's LeafIndex and have every member apply it, evicting that member and taking over their slot in the ratchet tree. The credential chec
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 3, 2026In Bouncy Castle for Java before 1.86, neither copy of PKIXCertPathReviewer - org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer nor the legacy org.bouncycastle.CVE-2026-71889 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
In Bouncy Castle for Java before 1.86, neither copy of PKIXCertPathReviewer - org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer nor the legacy org.bouncycastle.x509.PKIXCertPathReviewer - applied X.509 name constraints to the end-entity certificate. checkNameConstraints walked the path with a loop bound of index greater than zero, which is the bound the CA-only steps require, but index zero is the target certificate under the standard CertPath ordering, so the permitted and excluded subtree checks of RFC 5280 sec. 6.1.3 (b) and (c) never ran against the leaf's subject DN or its subjectAltName. A chain whose leaf violated a NameConstraints extension imposed by its own issuing CA therefore reported isValidCertPath() true with an empty error list, while CertPathValidator.getInstance("PKIX", "BC"), which shares no code with the reviewer, rejected the identical chain against the identical trust anchor. An application using the reviewer to make the trust decision rather than for diagnostics alongside a real validation accepted a certificate the constrained CA was never authorised to issue. Both copies now check every certificate in the path including the target, waive the sec. 4.2.1.10 s
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 3, 2026In Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about CVE-2026-71888 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
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 attacke
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 3, 2026In Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no eCVE-2026-71887 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
In Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no embedded Primary Key Binding (cross-certification) signature, in the case where that binding omits a Key Flags subpacket. RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require the embedded Primary Key Binding signature on any subkey that can issue signatures; it is the subkey's own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey's key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key's direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary's SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature's own hashed subpackets, found no SIGN_DATA there, and returned early as a non-signing key without ever demanding the back signature. The same subkey was therefore signing-capable - so its signatures were attributed to the certificate and OpenPGPSignature
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 3, 2026In Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key ofCVE-2026-71886 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
In Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key of the issuing certificate, without requiring that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key of the third-party certificate, then verify the issuing component's binding chain and the signature itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online signing subkey of exactly the offline-primary arrangement those key flags exist to express - could therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision wo
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 3, 2026In Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode's signature_keCVE-2026-71885 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630Critical 9.2
In Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode's signature_key. LeafNode.verify() checked a leaf's signature against the signature_key carried in the leaf itself, while the credential's X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate's public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. A party could therefore present another party's certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party's identity through KeyPackage.verify() and the Group leaf-validation path. In a deployment that admits external commits without an independent credential-admission check, an unauthenticated attacker could be admitted under a victim's X.509 identity, evict the victim (resynchronization compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. TreeKEM.LeafNode now requires the end-entity certificate's subject public key, in the cipher sui
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 3, 2026In Bouncy Castle for Java LTS before 2.73.13, the one-shot native packet ciphers for AES-CBC, CCM, CFB, CTR, GCM and GCM-SIV released the caller's key, IV and aCVE-2026-71883 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
In Bouncy Castle for Java LTS before 2.73.13, the one-shot native packet ciphers for AES-CBC, CCM, CFB, CTR, GCM and GCM-SIV released the caller's key, IV and additional authenticated data arrays with JNI's ReleaseByteArrayElements in mode 0, which commits the native copy back into the Java array. Those arrays are read-only to the native code, and on a JVM that returns a copy rather than a pin the copy still holds the input bytes as they were read. The output buffer is taken through a separate critical region and committed first, so where an application passed the same Java array as both an input and the destination - encrypting in place over KeyParameter.getKey(), for example - the later mode-0 release of the key wrote the unchanged key bytes over the ciphertext that had just been produced. The call still returned the correct output length, so an application encrypting in place over its own key array was handed the raw AES key where it expected ciphertext, with nothing in the API to indicate it, and would transmit or store the key in place of the message. The read-only input arrays are now released with JNI_ABORT, freeing the native copy without copying it back, and mode 0 is rese
Product
BC-LTS-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com
Oct 3, 2026In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elemCVE-2026-18040 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630Medium 5.9
In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged.
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Allocation of resources without limits in password-based private-key decryption (PbeUtilities.GenerateCipherParameters) in Legion of the Bouncy Castle Inc.CVE-2026-63578 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 7.1
Allocation of resources without limits in password-based private-key decryption (PbeUtilities.GenerateCipherParameters) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who can supply an encrypted private key, such as a PKCS#8 EncryptedPrivateKeyInfo or "ENCRYPTED PRIVATE KEY" PEM file, to cause a denial of service through CPU exhaustion via an iteration count close to 2^31, because the count is taken from the unauthenticated algorithm parameters without an upper bound and the key derivation runs before the password or the data can be checked. PKCS#5 PBES1 and PBES2 (PBKDF2), the PKCS#12 PBE algorithms and CMS password recipients (CmsPbeKey) are affected. Loading PKCS#12 files with Pkcs12Store is covered by CVE-2026-63572, and a zero or negative count with the PKCS#12 algorithms by CVE-2026-63575.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Improper certificate validation in the directoryName name-constraint check (PkixNameConstraintValidator.WithinDNSubtree) in Legion of the Bouncy Castle Inc.CVE-2026-63577 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
Improper certificate validation in the directoryName name-constraint check (PkixNameConstraintValidator.WithinDNSubtree) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who controls, or can have certificates issued by, a name-constrained intermediate CA to get certificates accepted by PKIX path validation whose subject distinguished name, or a directoryName subjectAltName, lies outside the CA's permitted subtrees, via a name that places other RDNs ahead of a copy of the permitted RDN sequence, because the check looks for the constraint's first RDN anywhere in the name and compares the remaining RDNs from that position, instead of requiring the constraint to be an initial prefix of the name as RFC 5280 sections 4.2.1.10 and 7.1 require.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Improper certificate validation in PkixNameConstraintValidator (ExtractHostFromURL) in Legion of the Bouncy Castle Inc.CVE-2026-63576 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
Improper certificate validation in PkixNameConstraintValidator (ExtractHostFromURL) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a name-constrained subordinate CA, or anyone able to obtain certificates with chosen subjectAltName URIs from such a CA, to bypass permitted or excluded uniformResourceIdentifier name constraints during certification path validation via a URI whose path, query, fragment or userinfo contains characters such as '@' or ':', because the host was extracted by string slicing without first isolating the RFC 3986 authority component, so the host compared against the constraints could differ from the URI's actual host.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Loop with unreachable exit condition in the PKCS#12 key derivation (Pkcs12ParametersGenerator) in Legion of the Bouncy Castle Inc.CVE-2026-63575 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 7.1
Loop with unreachable exit condition in the PKCS#12 key derivation (Pkcs12ParametersGenerator) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who can supply a PKCS#12 (PFX) file, or a PKCS#8 encrypted private key that uses a PKCS#12 password-based encryption algorithm, to cause a denial of service through CPU exhaustion via an iteration count of zero or below, because the derivation loop ran until its counter equalled the count, so for such a count it wrapped through about 2^32 iterations before the MAC or the password could be checked. A 75-byte PFX file with a negative MacData iteration count kept Pkcs12Store.Load busy for many minutes.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Memory allocation with excessive size value in the OpenPGP signature and user attribute subpacket parsers (SignatureSubpacketsParser.ReadPacket, UserAttributeSuCVE-2026-63574 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
Memory allocation with excessive size value in the OpenPGP signature and user attribute subpacket parsers (SignatureSubpacketsParser.ReadPacket, UserAttributeSubpacketsParser.ReadPacket) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote, unauthenticated attacker who can supply a crafted OpenPGP public key, certificate or signature to cause a denial of service (OutOfMemoryException or memory exhaustion in the parsing process) via a subpacket header using the five-octet length form, because the declared length was used to size the subpacket buffer with no upper bound and without being compared with the size of the enclosing subpacket area or packet, so a few bytes of input could demand an allocation of up to about 2 GB before any subpacket data was read.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Observable discrepancy in the CMS RSA PKCS#1 v1.5 key-transport unwrap (KeyTransRecipientInformation.UnwrapKey) in Legion of the Bouncy Castle Inc.CVE-2026-63573 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
Observable discrepancy in the CMS RSA PKCS#1 v1.5 key-transport unwrap (KeyTransRecipientInformation.UnwrapKey) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker who holds a captured CMS EnvelopedData message, and who can submit many modified messages to an application that decrypts them with the recipient's RSA private key and reveals how decryption failed, to recover the captured message's content-encryption key and so its content, via a Bleichenbacher-style adaptive chosen-ciphertext attack, because a key-transport ciphertext with invalid PKCS#1 v1.5 padding is rejected during unwrap with a distinct "bad padding in message." CmsException instead of being replaced by a random key, so it can be told apart from a correctly padded ciphertext, which fails only later at content decryption.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Allocation of resources without limits in PKCS#12 keystore loading (Pkcs12Store.Load) in Legion of the Bouncy Castle Inc.CVE-2026-63572 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 7.1
Allocation of resources without limits in PKCS#12 keystore loading (Pkcs12Store.Load) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who can supply a PKCS#12 (PFX) file to cause a denial of service through CPU exhaustion via an iteration count close to 2^31 in the file's MacData or in the PBE parameters of an encrypted SafeContents or shrouded key bag, because the counts are taken from the file without an upper bound and the key derivation runs before the MAC or the password can be checked. A zero or negative count is covered by CVE-2026-63575. Pkcs12Utilities.ConvertToDefiniteLength is also affected.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Improper verification of cryptographic signature in the attribute certificate path validator (PkixAttrCertPathValidator, also used by PkixAttrCertPathBuilder) iCVE-2026-63571 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
Improper verification of cryptographic signature in the attribute certificate path validator (PkixAttrCertPathValidator, also used by PkixAttrCertPathBuilder) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker to have a forged X.509 attribute certificate accepted as valid, and so obtain whatever roles or privileges an application grants on the strength of its attributes, via an attribute certificate that names a trusted attribute authority as its issuer but was not signed by it, because the RFC 3281 validation steps check the holder and issuer certification paths, validity period, extensions and revocation status but never verify the attribute certificate's signature with the issuer's public key. Only applications that use these classes to validate attribute certificates are affected.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Loop with unreachable exit condition in Pkcs12Store.GetCertificateChain in Legion of the Bouncy Castle Inc.CVE-2026-63570 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 7.1
Loop with unreachable exit condition in Pkcs12Store.GetCertificateChain in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who can supply a crafted PKCS#12 file to an application that loads it and requests a key entry's certificate chain to cause a denial of service, in which the call never returns and consumes CPU and memory until an OutOfMemoryException, via certificates whose issuer links form a cycle, for example two certificates whose AuthorityKeyIdentifier extensions each identify the other's public key. This happens because the chain-building loop stops only when no issuer is found or a certificate links to itself, and keeps no record of certificates already visited. The key-identifier links are followed without checking signatures.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026In Bouncy Castle for Java before 1.86, NTRU reduced secret values with the % operator in three helpers whose reference implementations are deliberately divisionCVE-2026-18036 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
In Bouncy Castle for Java before 1.86, NTRU reduced secret values with the % operator in three helpers whose reference implementations are deliberately division-free, so each reduction was carried out by an integer division whose latency depends on the secret operand. Polynomial.modQ divided by a variable divisor, which a compiler cannot strength-reduce to a multiply the way it can a constant one, so it emitted a division on every call including on the decapsulation path where the dividend derives from the private key; Polynomial.mod3 and NTRUSampling.mod3 divided the secret key polynomials f and g during key generation, the message polynomials r and m during encapsulation, and coefficients recovered during decapsulation. An attacker able to measure that timing can recover information about the NTRU private key. modQ now masks, which is exact because q is always a power of two, and mod3 uses the reference implementation's division-free fold and select; the results are unchanged.
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026In Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being CVE-2026-17508 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630Medium 5.3
In Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, which took the PBKDF2 iteration count and derived-key length straight out of PBMAC1Params (JcePBMac1CalculatorBuilder, and PKCS12PBEUtils.createPBMac1Calculator reached from PKCS12PfxPdu.isMacValid); the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, which bounded only the cost parameter N and the block size r even though the scratch buffer scales with r times p, so the configured memory ceiling could be evaded entirely; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); and the bcrypt round count read from an encrypted OpenSSH v1 private key's own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_r
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026In Bouncy Castle for Java before 1.86, the MLS implementation (org.bouncycastle.mls) holds RFC 9420's uint32 leaf_index in a signed int, so a wire value with thCVE-2026-17507 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
In Bouncy Castle for Java before 1.86, the MLS implementation (org.bouncycastle.mls) holds RFC 9420's uint32 leaf_index in a signed int, so a wire value with the top bit set decodes to a negative number. That is a legitimate encoding rather than malformed input, and it must still decode, since the MLS interop test vectors round-trip the full range. GroupKeySet.SecretTree.hasLeaf and Group.validateRemove compared the decoded value directly against the tree's leaf count, and a signed comparison treats any negative int as less than a positive bound, so an out-of-range sender passed the membership check. In the hasLeaf case the SenderData of an unprotected PrivateMessage could then drive LeafIndex.directPath through NodeIndex.parent() arithmetic that never reaches the tree root, growing the resulting node list without bound until the JVM exhausted its heap. A single small message from any current group member could therefore deny service to every other member of the group. Both comparisons now interpret the value as unsigned via Integer.toUnsignedLong, rejecting an out-of-range sender however it was encoded; well-formed leaf indices are unaffected.
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Inefficient algorithmic complexity in X.509 distinguished name string conversion (X509Name.ToString and IetfUtilities.ValueToString) in Legion of the Bouncy CasCVE-2026-103604 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
Inefficient algorithmic complexity in X.509 distinguished name string conversion (X509Name.ToString and IetfUtilities.ValueToString) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated attacker to cause a denial of service through CPU exhaustion via a certificate, CRL, certification request or other structure whose name contains a long attribute value made up of characters that must be escaped, such as commas, or of leading or trailing spaces, because each escaping backslash was inserted into the buffer being scanned, so the work grew quadratically with the length of the value. Applications are exposed when they convert such a name to a string, for example to log or display it, or compare it with IetfUtilities.RdnAreEqual, as PKIX path validation does for directoryName name constraints.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Memory allocation with excessive size value in the HSS/LMS signature code (HssPublicKeyParameters, HssSignature) in Legion of the Bouncy Castle Inc.CVE-2026-103603 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
Memory allocation with excessive size value in the HSS/LMS signature code (HssPublicKeyParameters, HssSignature) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated attacker who can supply both an HSS public key and a signature to cause a denial of service through memory exhaustion via a public key encoding with an excessive level count, because the level count L read when parsing an HSS public key was not checked against the RFC 8554 maximum of 8, and signature parsing then allocated an array of L - 1 entries before reading any further signature data. A single verification can commit up to about 17 GB of memory or fail with an OutOfMemoryException.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Improper certificate validation in PkixNameConstraintValidator in Legion of the Bouncy Castle Inc.CVE-2026-103602 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
Improper certificate validation in PkixNameConstraintValidator in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who controls, or can obtain certificates from, a name-constrained intermediate CA to have certificates accepted during PKIX certification path validation for email addresses, DNS names or URI hosts that lie within excluded subtrees applying to that CA, via an rfc822Name, dNSName or uniformResourceIdentifier name whose host ends with a dot, because names and constraints were compared without first removing the RFC 1034 root-label trailing dot, so a fully qualified host name did not match an excluded subtree for the same host written without the dot.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Release of unverified plaintext in the CCM (CcmBlockCipher) and DSTU 7624 CCM (KCcmBlockCipher) AEAD modes in Legion of the Bouncy Castle Inc.CVE-2026-103601 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
Release of unverified plaintext in the CCM (CcmBlockCipher) and DSTU 7624 CCM (KCcmBlockCipher) AEAD modes in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker to obtain decryptions of ciphertexts of their choosing via forged messages sent to an application that lets the output buffer of a failed decryption be observed, for example through buffer reuse or logging, because decryption wrote the recovered plaintext into the caller-supplied output buffer before checking the authentication tag and left it there when the check failed. Only decryption into a caller-supplied buffer is affected; methods that return a newly allocated array are not.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Uncontrolled recursion in the ASN.1 parser (Asn1InputStream, Asn1StreamParser) in Legion of the Bouncy Castle Inc.CVE-2026-103600 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
Uncontrolled recursion in the ASN.1 parser (Asn1InputStream, Asn1StreamParser) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated attacker to cause a denial of service via a crafted ASN.1 encoding of deeply nested constructed elements (for example SEQUENCE inside SEQUENCE, in definite-length DER or indefinite-length BER form), because each nesting level is parsed by a further recursive call with no bound on depth. About 2,000 levels (8 KB of DER) are enough to exhaust a 1.5 MB thread stack, the .NET main-thread default on Windows, and raise a StackOverflowException, which .NET cannot catch and which terminates the whole process; on threads with larger stacks, parse time instead grows quadratically with depth (about 9 seconds of CPU for a 64 KB input). Any path that parses untrusted ASN.1 is exposed, including X.509 certificates and CRLs, CMS/PKCS#7, PKCS#8/PKCS#12, OCSP and TLS Certificate messages.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Improper input validation in DHAgreement.CalculateAgreement (MTI/A0 two-pass Diffie-Hellman) in Legion of the Bouncy Castle Inc.CVE-2026-63569 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630Critical 9.1
Improper input validation in DHAgreement.CalculateAgreement (MTI/A0 two-pass Diffie-Hellman) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an on-path attacker to make the local party compute an agreed value the attacker already knows, defeating the key authentication MTI/A0 is meant to provide. It also allows a malicious peer to learn the local static private key modulo the small factors of p-1, and to recover it entirely in groups with many such factors. The attack uses a crafted out-of-range or small-order ephemeral value, and works because that value is raised to the static private key without the range and subgroup-membership checks applied to DH public keys. Only applications that call DHAgreement directly are affected.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Allocation of resources without limits or throttling in the CMP/CRMF password-based MAC verifier (PKMacBuilder) in Legion of the Bouncy Castle Inc.CVE-2026-63568 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
Allocation of resources without limits or throttling in the CMP/CRMF password-based MAC verifier (PKMacBuilder) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated attacker to cause a denial of service through CPU exhaustion via a CMP message or CRMF certificate request whose PBMParameter declares a very large iteration count, because PKMacBuilder enforced its iteration-count ceiling only when the caller had supplied an explicit maximum through the PKMacBuilder(IPKMacPrimitivesProvider, int) constructor. With any other constructor, ProtectedPkiMessage.Verify and CertificateRequestMessage.IsValidSigningKeyPop performed as many hash iterations as the sender requested, up to about 2^31, before the MAC could be checked.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Observable discrepancy in IesEngine.DecryptBlock in Legion of the Bouncy Castle Inc.CVE-2026-63567 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
Observable discrepancy in IesEngine.DecryptBlock in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker who has captured an IES or ECIES ciphertext, and who can submit modified ciphertexts for decryption under the same key pair, to recover its plaintext via a CBC padding-oracle attack, because in block-cipher mode the engine decrypts the ciphertext and removes its padding before verifying the MAC. A padding failure is therefore reported with a different error message, and without the MAC computation, compared with a MAC failure. Only applications that construct IesEngine directly with a padded block cipher, such as AES in CBC mode with PKCS#7 padding, are affected; stream-mode IES is not.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Memory allocation with excessive size value in the DTLS handshake reassembly (DtlsReliableHandshake, DtlsReassembler) in Legion of the Bouncy Castle Inc.CVE-2026-63566 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
Memory allocation with excessive size value in the DTLS handshake reassembly (DtlsReliableHandshake, DtlsReassembler) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated DTLS peer to cause a denial of service through memory exhaustion via crafted handshake message fragments, because the reassembly buffer for each incoming handshake message was allocated at the 24-bit length declared in the fragment header, without the check against the peer's maximum handshake message size that TLS already applied. A fragment carrying no payload can force an allocation of almost 16 MB, for each of up to 16 pending messages per handshake, before the handshake is authenticated. DTLS servers and DTLS clients are both affected; TLS is not.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Exposure of the message authentication key through the encryption keystream in the stream mode of IesEngine (an IesEngine constructed without a block cipher) inCVE-2026-16001 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
Exposure of the message authentication key through the encryption keystream in the stream mode of IesEngine (an IesEngine constructed without a block cipher) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker who has observed one encrypted message with known plaintext to forge shorter messages of their choosing that the recipient accepts as authentic, via a crafted ciphertext and MAC tag, because the MAC key was taken from the key derivation output directly after a keystream as long as the message, while the derivation input depends only on the static key pair and fixed parameters. The keystream revealed by that one message therefore contains the MAC key for every sufficiently shorter message.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Missing cryptographic step in the DSTU 7624 CCM mode implementation (KCcmBlockCipher) in Legion of the Bouncy Castle Inc.CVE-2026-16000 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
Missing cryptographic step in the DSTU 7624 CCM mode implementation (KCcmBlockCipher) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an attacker who can observe encrypted messages of known or chosen content to forge ciphertexts with valid authentication tags, via messages encrypted without associated data. The cause is that the G1 block, which binds the nonce, the message length and the parameter flags into the CBC-MAC, was processed only when associated data was present. Without associated data the tag was a CBC-MAC of the plaintext alone, independent of the nonce. Only applications that use KCcmBlockCipher directly and supply no associated data are affected.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Oct 2, 2026Improper validation of integrity check value in the AES-CCM implementation (CcmParameters and CcmBlockCipher) in Legion of the Bouncy Castle Inc.CVE-2026-15999 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.2
Improper validation of integrity check value in the AES-CCM implementation (CcmParameters and CcmBlockCipher) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows an on-path attacker to modify CCM-encrypted content without detection via an AlgorithmIdentifier whose CCMParameters declare an authentication tag (aes-ICVlen) of zero or another length outside the RFC 5084 set, because CcmParameters accepted any value and CcmBlockCipher validated the tag length only when encrypting, so decryption compared a zero-length or very short tag. Affected paths include ParameterUtilities.GetCipherParameters, used by CmsEnvelopedData and CmsEnvelopedDataParser for EnvelopedData encrypted with AES-CCM, and any caller passing an unchecked tag length to CcmBlockCipher for decryption.
Product
bc-csharp
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 7, 2026In 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), sensitive key material held by theCVE-2026-13505 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
In 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), sensitive key material held by the AES and DESede engines, the SP 800-90A DRBGs, SymmetricSecretKey and the PBKD and scrypt parameter classes was zeroised on garbage collection by overriding Object.finalize. Finalization runs at an unspecified time and in an unspecified order and is serviced by a single finalizer thread, so where objects carrying a finalizer are allocated faster than that thread retires them the pending-finalization queue grows without bound: disposal falls arbitrarily far behind, which can contribute to an OutOfMemoryError under load, and the key material those objects hold stays resident in the heap for as long as they are queued, defeating the purpose of the zeroisation. The behaviour was not a problem on Java 8 or Java 11; it is later JVMs, on which finalization has been deprecated and progressively de-emphasised, where it becomes one. Disposal of these classes now runs from a java.lang.ref.Cleaner registered in the multi-release jdk1.9 overlay, so on Java 9 and later it no longer depends on the finalizer being scheduled. Bouncy Castle f
Product
BC-FJA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com
Aug 7, 2026In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.1.3, the native entropy source used on Intel platforms retried the CPU entropy instructions without anyCVE-2026-8798 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.1.3, the native entropy source used on Intel platforms retried the CPU entropy instructions without any bound. RDSEED and RDRAND report failure through their carry flag, and the JNI seeding routine spun re-issuing the instruction for as long as that flag stayed clear, so a persistent failure of the on-chip entropy source - whether from a hardware fault, from the underlying DRBG being exhausted by contention across many cores, or from a hypervisor that does not provide the instruction - left the calling thread looping indefinitely inside the JNI call, where it could be neither interrupted nor timed out. Any operation drawing from the native entropy source could therefore hang, denying service to the application. The retry loops are now bounded (200 attempts for RDSEED and 20 for RDRAND, twice the baselines given in Intel's Digital Random Number Generator software implementation guide), pausing between attempts and, on exhaustion, clearing any partially written buffer and throwing rather than continuing to spin. The clear is performed by an un-elidable memzero, which uses a volatile pointer and an assembly memory barrier so tha
Product
BC-FJA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com
Aug 3, 2026In Bouncy Castle for Java before 1.85, Possible OOM from unbounded up-front allocation on a definite-length read.CVE-2026-14682 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
In Bouncy Castle for Java before 1.85, Possible OOM from unbounded up-front allocation on a definite-length read. 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), and before bctls-fips 1.0.24.
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 3, 2026In Bouncy Castle for Java before 1.85, PKCS#12 MAC and bag-decryption KDF iteration-count bound (DoS).CVE-2026-13586 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630Medium 5.3
In Bouncy Castle for Java before 1.85, PKCS#12 MAC and bag-decryption KDF iteration-count bound (DoS). 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).
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 3, 2026In Bouncy Castle for Java before 1.85, Lazy ASN.1 sequence forcing resets nesting-depth guard.CVE-2026-13506 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
In Bouncy Castle for Java before 1.85, Lazy ASN.1 sequence forcing resets nesting-depth guard. 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).
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 3, 2026In Bouncy Castle for Java before 1.85, RSA PKCS#1 verification skips last two hash bytes in NULL-omitted path.CVE-2026-12860 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
In Bouncy Castle for Java before 1.85, RSA PKCS#1 verification skips last two hash bytes in NULL-omitted path. This issue also affects Bouncy Castle for Java LTS before 2.73.12.
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 3, 2026In Bouncy Castle for Java before 1.85, MLS wire decoder allocates attacker-declared opaque length before bounds check.CVE-2026-12852 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
In Bouncy Castle for Java before 1.85, MLS wire decoder allocates attacker-declared opaque length before bounds check.
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 3, 2026In Bouncy Castle for Java before 1.85, OpenPGP AEAD decryption skips final tag on chunk-aligned data.CVE-2026-12817 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
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).
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 3, 2026In Bouncy Castle for Java before 1.85, IESEngine stream-mode MAC forgery via length-dependent KDF split.CVE-2026-12816 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
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.
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 3, 2026In Bouncy Castle for Java before 1.85, KCCMBlockCipher MAC does not bind nonce when AAD is absent (cross-nonce AEAD forgery).CVE-2026-12803 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
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.
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 3, 2026In Bouncy Castle for Java before 1.85, CMS AuthEnvelopedData fails to enforce tag-length on decryption.CVE-2026-12802 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630High 8.7
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).
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 2, 2026In Bouncy Castle for Java before 1.85, BCFKS keystore load honours unbounded KDF cost from untrusted file.CVE-2026-58063 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630Medium 5.3
In Bouncy Castle for Java before 1.85, BCFKS keystore load honours unbounded KDF cost from untrusted file. 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).
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 2, 2026In Bouncy Castle for Java before 1.85, Stapled OCSP response accepted without binding to the checked certificate.CVE-2026-58062 · Other software · Legion of the Bouncy Castle Inc. · reported by 91579145-5d7b-4cc5-b925-a0262ff19630Critical 9.3
In Bouncy Castle for Java before 1.85, Stapled OCSP response accepted without binding to the checked certificate. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
Product
BC-JAVA
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com

Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.

Weekly security brief

The flaws that hit local websites, every Friday.

One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.

Vulnerability database

The flaws that hit local websites, every Friday.

Tell us what you're building.