Vulnerability-Lookup

CVE-2026-71887 (GCVE-0-2026-71887)

Vulnerability from cvelistv5 – Published: 2026-10-03 08:39 – Updated: 2026-10-03 08:39

Title

OpenPGP data signature accepted from a signing subkey without cross-certification

Summary

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.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim's public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey's private key, and a relying party verifying one of the victim's genuinely signed messages against that certificate is told the signature is valid and given the attacker's certificate as its issuer. Because a certificate's User IDs are self-asserted, a verifier that pins on the subkey's fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary's, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected.

Severity

8.2 (High)


                        
                          CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber

CWE

CWE-347 - Improper Verification of Cryptographic Signature
CWE-345 - Insufficient Verification of Data Authenticity

Assigner

bcorg mitre root Scorecard

References

2 references

URL	Tags
https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9…	vendor-advisory
https://github.com/bcgit/bc-java/commit/b51452fa4…	patch

Impacted products

1 product

Vendor	Product	Version	CPE status
Legion of the Bouncy Castle Inc.	BC-JAVA	Affected: 1.81 , < 1.86 (maven)	guessed

Credits

Arpan Sharma

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
          "defaultStatus": "unaffected",
          "modules": [
            "pg"
          ],
          "packageName": "bcpg",
          "packageURL": "pkg:maven/org.bouncycastle/bcpg-jdk18on",
          "platforms": [
            "all"
          ],
          "product": "BC-JAVA",
          "programFiles": [
            "OpenPGPCertificate"
          ],
          "repo": "https://github.com/bcgit/bc-java",
          "vendor": "Legion of the Bouncy Castle Inc.",
          "versions": [
            {
              "lessThan": "1.86",
              "status": "affected",
              "version": "1.81",
              "versionType": "maven"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Arpan Sharma"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eIn 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\u0027s own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey\u0027s key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key\u0027s direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary\u0027s SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature\u0027s 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.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim\u0027s public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey\u0027s private key, and a relying party verifying one of the victim\u0027s genuinely signed messages against that certificate is told the signature is valid and given the attacker\u0027s certificate as its issuer. Because a certificate\u0027s User IDs are self-asserted, a verifier that pins on the subkey\u0027s fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary\u0027s, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected.\u003c/p\u003e"
            }
          ],
          "value": "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\u0027s own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey\u0027s key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key\u0027s direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary\u0027s SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature\u0027s 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.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim\u0027s public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey\u0027s private key, and a relying party verifying one of the victim\u0027s genuinely signed messages against that certificate is told the signature is valid and given the attacker\u0027s certificate as its issuer. Because a certificate\u0027s User IDs are self-asserted, a verifier that pins on the subkey\u0027s fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary\u0027s, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "exploitMaturity": "NOT_DEFINED",
            "privilegesRequired": "NONE",
            "providerUrgency": "AMBER",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-347",
              "description": "CWE-347 Improper Verification of Cryptographic Signature",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-345",
              "description": "CWE-345 Insufficient Verification of Data Authenticity",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-03T08:39:07.997Z",
        "orgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
        "shortName": "bcorg"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071887"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/bcgit/bc-java/commit/b51452fa48ccb578fc16b8222fce9eedf92c94d6"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "OpenPGP data signature accepted from a signing subkey without cross-certification",
      "x_generator": {
        "engine": "bc release-notes template"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
    "assignerShortName": "bcorg",
    "cveId": "CVE-2026-71887",
    "datePublished": "2026-10-03T08:39:07.997Z",
    "dateReserved": "2026-08-08T00:06:06.982Z",
    "dateUpdated": "2026-10-03T08:39:07.997Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-71887",
      "date": "2026-10-03",
      "epss": "0.0009",
      "percentile": "0.00414"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
                "defaultStatus": "unaffected",
                "modules": [
                  "pg"
                ],
                "packageName": "bcpg",
                "packageURL": "pkg:maven/org.bouncycastle/bcpg-jdk18on",
                "platforms": [
                  "all"
                ],
                "product": "BC-JAVA",
                "programFiles": [
                  "OpenPGPCertificate"
                ],
                "repo": "https://github.com/bcgit/bc-java",
                "vendor": "Legion of the Bouncy Castle Inc.",
                "versions": [
                  {
                    "lessThan": "1.86",
                    "status": "affected",
                    "version": "1.81",
                    "versionType": "maven"
                  }
                ]
              }
            ],
            "source": "91579145-5d7b-4cc5-b925-a0262ff19630"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "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\u0027s own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey\u0027s key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key\u0027s direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary\u0027s SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature\u0027s 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.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim\u0027s public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey\u0027s private key, and a relying party verifying one of the victim\u0027s genuinely signed messages against that certificate is told the signature is valid and given the attacker\u0027s certificate as its issuer. Because a certificate\u0027s User IDs are self-asserted, a verifier that pins on the subkey\u0027s fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary\u0027s, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected."
          }
        ],
        "id": "CVE-2026-71887",
        "lastModified": "2026-10-03T09:17:05.067",
        "metrics": {
          "cvssMetricV40": [
            {
              "cvssData": {
                "Automatable": "NOT_DEFINED",
                "Recovery": "NOT_DEFINED",
                "Safety": "NOT_DEFINED",
                "attackComplexity": "LOW",
                "attackRequirements": "PRESENT",
                "attackVector": "NETWORK",
                "availabilityRequirement": "NOT_DEFINED",
                "baseScore": 8.2,
                "baseSeverity": "HIGH",
                "confidentialityRequirement": "NOT_DEFINED",
                "exploitMaturity": "NOT_DEFINED",
                "integrityRequirement": "NOT_DEFINED",
                "modifiedAttackComplexity": "NOT_DEFINED",
                "modifiedAttackRequirements": "NOT_DEFINED",
                "modifiedAttackVector": "NOT_DEFINED",
                "modifiedPrivilegesRequired": "NOT_DEFINED",
                "modifiedSubAvailabilityImpact": "NOT_DEFINED",
                "modifiedSubConfidentialityImpact": "NOT_DEFINED",
                "modifiedSubIntegrityImpact": "NOT_DEFINED",
                "modifiedUserInteraction": "NOT_DEFINED",
                "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
                "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
                "modifiedVulnIntegrityImpact": "NOT_DEFINED",
                "privilegesRequired": "NONE",
                "providerUrgency": "AMBER",
                "subAvailabilityImpact": "NONE",
                "subConfidentialityImpact": "NONE",
                "subIntegrityImpact": "NONE",
                "userInteraction": "NONE",
                "valueDensity": "NOT_DEFINED",
                "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber",
                "version": "4.0",
                "vulnAvailabilityImpact": "NONE",
                "vulnConfidentialityImpact": "NONE",
                "vulnIntegrityImpact": "HIGH",
                "vulnerabilityResponseEffort": "NOT_DEFINED"
              },
              "source": "91579145-5d7b-4cc5-b925-a0262ff19630",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-10-03T09:17:05.067",
        "references": [
          {
            "source": "91579145-5d7b-4cc5-b925-a0262ff19630",
            "url": "https://github.com/bcgit/bc-java/commit/b51452fa48ccb578fc16b8222fce9eedf92c94d6"
          },
          {
            "source": "91579145-5d7b-4cc5-b925-a0262ff19630",
            "url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071887"
          }
        ],
        "sourceIdentifier": "91579145-5d7b-4cc5-b925-a0262ff19630",
        "vulnStatus": "Received",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-345"
              },
              {
                "lang": "en",
                "value": "CWE-347"
              }
            ],
            "source": "91579145-5d7b-4cc5-b925-a0262ff19630",
            "type": "Secondary"
          }
        ]
      }
    }
  }
}

FKIE_CVE-2026-71887

Vulnerability from fkie_nvd - Published: 2026-10-03 09:17 - Updated: 2026-10-03 09:17

Severity

8.2 (High) - CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber

Summary

References

	URL	Tags
	91579145-5d7b-4cc5-b925-a0262ff19630	https://github.com/bcgit/bc-java/commit/b51452fa48ccb578fc16b8222fce9eedf92c94d6
	91579145-5d7b-4cc5-b925-a0262ff19630	https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071887

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
          "defaultStatus": "unaffected",
          "modules": [
            "pg"
          ],
          "packageName": "bcpg",
          "packageURL": "pkg:maven/org.bouncycastle/bcpg-jdk18on",
          "platforms": [
            "all"
          ],
          "product": "BC-JAVA",
          "programFiles": [
            "OpenPGPCertificate"
          ],
          "repo": "https://github.com/bcgit/bc-java",
          "vendor": "Legion of the Bouncy Castle Inc.",
          "versions": [
            {
              "lessThan": "1.86",
              "status": "affected",
              "version": "1.81",
              "versionType": "maven"
            }
          ]
        }
      ],
      "source": "91579145-5d7b-4cc5-b925-a0262ff19630"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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\u0027s own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey\u0027s key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key\u0027s direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary\u0027s SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature\u0027s 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.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim\u0027s public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey\u0027s private key, and a relying party verifying one of the victim\u0027s genuinely signed messages against that certificate is told the signature is valid and given the attacker\u0027s certificate as its issuer. Because a certificate\u0027s User IDs are self-asserted, a verifier that pins on the subkey\u0027s fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary\u0027s, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected."
    }
  ],
  "id": "CVE-2026-71887",
  "lastModified": "2026-10-03T09:17:05.067",
  "metrics": {
    "cvssMetricV40": [
      {
        "cvssData": {
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "attackComplexity": "LOW",
          "attackRequirements": "PRESENT",
          "attackVector": "NETWORK",
          "availabilityRequirement": "NOT_DEFINED",
          "baseScore": 8.2,
          "baseSeverity": "HIGH",
          "confidentialityRequirement": "NOT_DEFINED",
          "exploitMaturity": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "privilegesRequired": "NONE",
          "providerUrgency": "AMBER",
          "subAvailabilityImpact": "NONE",
          "subConfidentialityImpact": "NONE",
          "subIntegrityImpact": "NONE",
          "userInteraction": "NONE",
          "valueDensity": "NOT_DEFINED",
          "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber",
          "version": "4.0",
          "vulnAvailabilityImpact": "NONE",
          "vulnConfidentialityImpact": "NONE",
          "vulnIntegrityImpact": "HIGH",
          "vulnerabilityResponseEffort": "NOT_DEFINED"
        },
        "source": "91579145-5d7b-4cc5-b925-a0262ff19630",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-10-03T09:17:05.067",
  "references": [
    {
      "source": "91579145-5d7b-4cc5-b925-a0262ff19630",
      "url": "https://github.com/bcgit/bc-java/commit/b51452fa48ccb578fc16b8222fce9eedf92c94d6"
    },
    {
      "source": "91579145-5d7b-4cc5-b925-a0262ff19630",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071887"
    }
  ],
  "sourceIdentifier": "91579145-5d7b-4cc5-b925-a0262ff19630",
  "vulnStatus": "Received",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-345"
        },
        {
          "lang": "en",
          "value": "CWE-347"
        }
      ],
      "source": "91579145-5d7b-4cc5-b925-a0262ff19630",
      "type": "Secondary"
    }
  ]
}

GHSA-CWF6-PGHV-HQ93

Vulnerability from github – Published: 2026-10-03 09:31 – Updated: 2026-10-03 09:31

Details

Severity

8.2 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-71887"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-03T09:17:05Z",
    "severity": "HIGH"
  },
  "details": "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\u0027s own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey\u0027s key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key\u0027s direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary\u0027s SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature\u0027s 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.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim\u0027s public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey\u0027s private key, and a relying party verifying one of the victim\u0027s genuinely signed messages against that certificate is told the signature is valid and given the attacker\u0027s certificate as its issuer. Because a certificate\u0027s User IDs are self-asserted, a verifier that pins on the subkey\u0027s fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary\u0027s, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected.",
  "id": "GHSA-cwf6-pghv-hq93",
  "modified": "2026-10-03T09:31:18Z",
  "published": "2026-10-03T09:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71887"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/commit/b51452fa48ccb578fc16b8222fce9eedf92c94d6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071887"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2026-71887 (GCVE-0-2026-71887)

FKIE_CVE-2026-71887

GHSA-CWF6-PGHV-HQ93

Tags

Sightings

Nomenclature

Related by attack behaviour