Bouncy Castle CVE-2026-103604

Exploitation requires that the victim application (1) parses an attacker-supplied X.509 structure - certificate, CRL, certification request, or other DN-bearing structure - using bc-csharp before 2.7.0, AND (2) subsequently converts that name to a string via X509Name.ToString / IetfUtilities.ValueToString (for logging or display) OR compares it with IetfUtilities.RdnAreEqual, as PKIX path validation does when enforcing directoryName name constraints. The malicious attribute value must contain a long sequence of characters that must be escaped (commas, quotes, backslashes, +, =, <, >, ;) or long runs of leading/trailing spaces, so that the quadratic work dominates. The principal LIMITING factor is that merely accepting a certificate is insufficient - the vulnerable string-conversion or RDN-comparison code path must actually execute on the untrusted name; services that validate certificates without stringifying/comparing attacker-controlled DNs are not exposed.

This is a genuine availability-impact denial-of-service issue rather than a high-CVSS-but-low-real-risk artifact, but its real-world severity is heavily mediated by application behavior. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) and the equivalent 3.1 profile both indicate a remote, unauthenticated, low-complexity vector with no confidentiality or integrity impact and HIGH availability impact - consistent with the CWE-407 (algorithmic complexity) root cause: a quadratic O(n^2) escaping loop in X509Name.ToString / IetfUtilities.ValueToString confirmed directly by the vendor commit diff (bd03e38). No EPSS score was supplied and the CVE is NOT in CISA KEV, so there is no evidence of active exploitation; the GitHub commit demonstrates the fix but no standalone weaponized POC is referenced. The 8.7 score is plausible for a network-reachable DoS, but note a key caveat: the attacker does not trigger the cost merely by sending a certificate - the victim application must convert the malicious name to a string (to log/display) or compare it via RdnAreEqual/PKIX directoryName name-constraint validation. Where that processing does not occur on untrusted input, real risk is substantially lower than the raw score implies. Treat as a patch-soon issue for any .NET service that parses and logs/validates externally-supplied X.509 material.

A remote unauthenticated attacker submits a certificate, CRL, or certification request containing a distinguished name whose attribute value is a very long run of characters requiring RFC 4514 escaping (e.g. thousands of commas or leading/trailing spaces) to a .NET service that uses bc-csharp. When the service converts that name to a string to log or display it, or compares it during PKIX path validation of directoryName name constraints, the quadratic escaping routine consumes CPU proportional to n^2, exhausting a core and degrading or hanging the service. No public exploit is identified at time of analysis, but the vendor commit clearly documents the quadratic character-move cost.