{"api_version":"1","generated_at":"2026-06-10T05:58:51+00:00","cve":"CVE-2026-42768","urls":{"html":"https://cve.report/CVE-2026-42768","api":"https://cve.report/api/cve/CVE-2026-42768.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-42768","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-42768"},"summary":{"title":"Multi-RecipientInfo Bleichenbacher Oracle in CMS_decrypt() and PKCS7_decrypt()","description":"Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to\nBleichenbacher-style attack when an attacker is able to provide the CMS or\nS/MIME messages and observe the error code and/or decryption output.\n\nImpact summary: The Bleichenbacher-style attack allows an attacker to use the\nvictim's vulnerable application as a way to decrypt or sign messages with the\nvictim's private RSA key.\n\nThe attack is possible in 2 variants.\n\n1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without\nproviding the recipient certificate. In this case OpenSSL iterates over every\nKeyTransRecipientInfo (KTRI) without stopping at the first success.\n\nAn attacker who authors a message with two KTRI entries — the first one\nwrapping a real CEK under the victim's public key, the second with an\narbitrary probe ciphertext — obtains opportunity to iterate the 2nd KTRI to\nget a valid PKCS#1 v1.5 padding if the error code of the application is\navailable.\n\nThat is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an\nadaptive-chosen-ciphertext side channel from which the attacker decrypts any\nRSA ciphertext to the victim's key or forges any PKCS#1 v1.5 signature under\nit.\n\n2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with\nthe recipient certificate, and the recipient is not found, a random\nkey is substituted.\n\nAn attacker who authors a message and is able to compare both error code and\nthe result of the decryption, can mount a Bleichenbacher oracle.\n\nWe are not aware of any applications that provide a remote attacker\nan opportunity to mount an attack described in these scenarios. We consider\nthe existence of such application very unlikely, and for this reason this\nCVE has been evaluated as Low severity.\n\nTo avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the\ninvoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described\nin draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit\nrejection was explicitly disabled.\n\nThe implicit rejection mechanism always returns a plaintext value,\nthe symmetric key. This result is deterministic for the ciphertext and the\nprivate key.  The length of the decryption result can happen to match the\nlength of the key of the symmetric cipher that was used for the content\nencryption. When a certificate is not provided, the last RecipientInfo\nproducing a key that looks valid will be used. It may cause getting garbage\ncontent on decryption. As a proper way to deal with this a recipient\ncertificate has to be provided to identify the particular RecipientInfo for\ndecryption.\n\nThe FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as\nCMS and S/MIME processing happens outside the OpenSSL FIPS module boundary.","state":"PUBLISHED","assigner":"openssl","published_at":"2026-06-09 17:17:08","updated_at":"2026-06-09 21:17:17"},"problem_types":["CWE-514","CWE-514 CWE-514 Covert Channel"],"metrics":[{"version":"3.1","source":"ADP","type":"DECLARED","score":"3.7","severity":"LOW","vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","data":{"attackComplexity":"HIGH","attackVector":"NETWORK","availabilityImpact":"NONE","baseScore":3.7,"baseSeverity":"LOW","confidentialityImpact":"LOW","integrityImpact":"NONE","privilegesRequired":"NONE","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","version":"3.1"}},{"version":"3.1","source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","type":"Secondary","score":"3.7","severity":"LOW","vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","baseScore":3.7,"baseSeverity":"LOW","attackVector":"NETWORK","attackComplexity":"HIGH","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"LOW","integrityImpact":"NONE","availabilityImpact":"NONE"}}],"references":[{"url":"https://github.com/openssl/security/commit/f04b377be3d821741c86d1f4bf84dee09f3d5c3e","name":"https://github.com/openssl/security/commit/f04b377be3d821741c86d1f4bf84dee09f3d5c3e","refsource":"openssl-security@openssl.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/openssl/security/commit/dd68364107a58841c0a2546812518b65d3a23abd","name":"https://github.com/openssl/security/commit/dd68364107a58841c0a2546812518b65d3a23abd","refsource":"openssl-security@openssl.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/openssl/security/commit/bbb151a83041705d9d001ed2f9c12f5523e1b54d","name":"https://github.com/openssl/security/commit/bbb151a83041705d9d001ed2f9c12f5523e1b54d","refsource":"openssl-security@openssl.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://openssl-library.org/news/secadv/20260609.txt","name":"https://openssl-library.org/news/secadv/20260609.txt","refsource":"openssl-security@openssl.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/openssl/security/commit/a2ca7b2d73e0ffc1eae183fe6e1741dac767cb4f","name":"https://github.com/openssl/security/commit/a2ca7b2d73e0ffc1eae183fe6e1741dac767cb4f","refsource":"openssl-security@openssl.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-42768","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-42768","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"OpenSSL","product":"OpenSSL","version":"affected 4.0.0 4.0.1 semver","platforms":[]},{"source":"CNA","vendor":"OpenSSL","product":"OpenSSL","version":"affected 3.6.0 3.6.3 semver","platforms":[]},{"source":"CNA","vendor":"OpenSSL","product":"OpenSSL","version":"affected 3.5.0 3.5.7 semver","platforms":[]},{"source":"CNA","vendor":"OpenSSL","product":"OpenSSL","version":"affected 3.4.0 3.4.6 semver","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"Alex Gaynor (Anthropic)","lang":"en"},{"source":"CNA","value":"Dmitry Belyavskiy (Red Hat)","lang":"en"},{"source":"CNA","value":"Alicja Kario (Red Hat)","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"adp":[{"metrics":[{"cvssV3_1":{"attackComplexity":"HIGH","attackVector":"NETWORK","availabilityImpact":"NONE","baseScore":3.7,"baseSeverity":"LOW","confidentialityImpact":"LOW","integrityImpact":"NONE","privilegesRequired":"NONE","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","version":"3.1"}},{"other":{"content":{"id":"CVE-2026-42768","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"partial"}],"role":"CISA Coordinator","timestamp":"2026-06-09T19:40:18.647253Z","version":"2.0.3"},"type":"ssvc"}}],"providerMetadata":{"dateUpdated":"2026-06-09T19:40:22.532Z","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP"},"title":"CISA ADP Vulnrichment"}],"cna":{"affected":[{"defaultStatus":"unaffected","product":"OpenSSL","vendor":"OpenSSL","versions":[{"lessThan":"4.0.1","status":"affected","version":"4.0.0","versionType":"semver"},{"lessThan":"3.6.3","status":"affected","version":"3.6.0","versionType":"semver"},{"lessThan":"3.5.7","status":"affected","version":"3.5.0","versionType":"semver"},{"lessThan":"3.4.6","status":"affected","version":"3.4.0","versionType":"semver"}]}],"credits":[{"lang":"en","type":"reporter","value":"Alex Gaynor (Anthropic)"},{"lang":"en","type":"remediation developer","value":"Dmitry Belyavskiy (Red Hat)"},{"lang":"en","type":"remediation developer","value":"Alicja Kario (Red Hat)"}],"datePublic":"2026-06-09T14:00:00.000Z","descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to<br>Bleichenbacher-style attack when an attacker is able to provide the CMS or<br>S/MIME messages and observe the error code and/or decryption output.<br><br>Impact summary: The Bleichenbacher-style attack allows an attacker to use the<br>victim's vulnerable application as a way to decrypt or sign messages with the<br>victim's private RSA key.<br><br>The attack is possible in 2 variants.<br><br>1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without<br>providing the recipient certificate. In this case OpenSSL iterates over every<br>KeyTransRecipientInfo (KTRI) without stopping at the first success.<br><br>An attacker who authors a message with two KTRI entries — the first one<br>wrapping a real CEK under the victim's public key, the second with an<br>arbitrary probe ciphertext — obtains opportunity to iterate the 2nd KTRI to<br>get a valid PKCS#1 v1.5 padding if the error code of the application is<br>available.<br><br>That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an<br>adaptive-chosen-ciphertext side channel from which the attacker decrypts any<br>RSA ciphertext to the victim's key or forges any PKCS#1 v1.5 signature under<br>it.<br><br>2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with<br>the recipient certificate, and the recipient is not found, a random<br>key is substituted.<br><br>An attacker who authors a message and is able to compare both error code and<br>the result of the decryption, can mount a Bleichenbacher oracle.<br><br>We are not aware of any applications that provide a remote attacker<br>an opportunity to mount an attack described in these scenarios. We consider<br>the existence of such application very unlikely, and for this reason this<br>CVE has been evaluated as Low severity.<br><br>To avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the<br>invoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described<br>in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit<br>rejection was explicitly disabled.<br><br>The implicit rejection mechanism always returns a plaintext value,<br>the symmetric key. This result is deterministic for the ciphertext and the<br>private key.  The length of the decryption result can happen to match the<br>length of the key of the symmetric cipher that was used for the content<br>encryption. When a certificate is not provided, the last RecipientInfo<br>producing a key that looks valid will be used. It may cause getting garbage<br>content on decryption. As a proper way to deal with this a recipient<br>certificate has to be provided to identify the particular RecipientInfo for<br>decryption.<br><br>The FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as<br>CMS and S/MIME processing happens outside the OpenSSL FIPS module boundary."}],"value":"Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to\nBleichenbacher-style attack when an attacker is able to provide the CMS or\nS/MIME messages and observe the error code and/or decryption output.\n\nImpact summary: The Bleichenbacher-style attack allows an attacker to use the\nvictim's vulnerable application as a way to decrypt or sign messages with the\nvictim's private RSA key.\n\nThe attack is possible in 2 variants.\n\n1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without\nproviding the recipient certificate. In this case OpenSSL iterates over every\nKeyTransRecipientInfo (KTRI) without stopping at the first success.\n\nAn attacker who authors a message with two KTRI entries — the first one\nwrapping a real CEK under the victim's public key, the second with an\narbitrary probe ciphertext — obtains opportunity to iterate the 2nd KTRI to\nget a valid PKCS#1 v1.5 padding if the error code of the application is\navailable.\n\nThat is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an\nadaptive-chosen-ciphertext side channel from which the attacker decrypts any\nRSA ciphertext to the victim's key or forges any PKCS#1 v1.5 signature under\nit.\n\n2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with\nthe recipient certificate, and the recipient is not found, a random\nkey is substituted.\n\nAn attacker who authors a message and is able to compare both error code and\nthe result of the decryption, can mount a Bleichenbacher oracle.\n\nWe are not aware of any applications that provide a remote attacker\nan opportunity to mount an attack described in these scenarios. We consider\nthe existence of such application very unlikely, and for this reason this\nCVE has been evaluated as Low severity.\n\nTo avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the\ninvoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described\nin draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit\nrejection was explicitly disabled.\n\nThe implicit rejection mechanism always returns a plaintext value,\nthe symmetric key. This result is deterministic for the ciphertext and the\nprivate key.  The length of the decryption result can happen to match the\nlength of the key of the symmetric cipher that was used for the content\nencryption. When a certificate is not provided, the last RecipientInfo\nproducing a key that looks valid will be used. It may cause getting garbage\ncontent on decryption. As a proper way to deal with this a recipient\ncertificate has to be provided to identify the particular RecipientInfo for\ndecryption.\n\nThe FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as\nCMS and S/MIME processing happens outside the OpenSSL FIPS module boundary."}],"metrics":[{"format":"other","other":{"content":{"text":"Low"},"type":"https://openssl-library.org/policies/general/security-policy/"}}],"problemTypes":[{"descriptions":[{"cweId":"CWE-514","description":"CWE-514 Covert Channel","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-06-09T16:03:28.206Z","orgId":"3a12439a-ef3a-4c79-92e6-6081a721f1e5","shortName":"openssl"},"references":[{"name":"OpenSSL Advisory","tags":["vendor-advisory"],"url":"https://openssl-library.org/news/secadv/20260609.txt"},{"name":"4.0.1 git commit","tags":["patch"],"url":"https://github.com/openssl/security/commit/f04b377be3d821741c86d1f4bf84dee09f3d5c3e"},{"name":"3.6.3 git commit","tags":["patch"],"url":"https://github.com/openssl/security/commit/a2ca7b2d73e0ffc1eae183fe6e1741dac767cb4f"},{"name":"3.5.7 git commit","tags":["patch"],"url":"https://github.com/openssl/security/commit/bbb151a83041705d9d001ed2f9c12f5523e1b54d"},{"name":"3.4.6 git commit","tags":["patch"],"url":"https://github.com/openssl/security/commit/dd68364107a58841c0a2546812518b65d3a23abd"}],"source":{"discovery":"UNKNOWN"},"title":"Multi-RecipientInfo Bleichenbacher Oracle in CMS_decrypt() and PKCS7_decrypt()","x_generator":{"engine":"Vulnogram 0.2.0"}}},"cveMetadata":{"assignerOrgId":"3a12439a-ef3a-4c79-92e6-6081a721f1e5","assignerShortName":"openssl","cveId":"CVE-2026-42768","datePublished":"2026-06-09T16:03:28.206Z","dateReserved":"2026-04-29T09:22:27.969Z","dateUpdated":"2026-06-09T19:40:22.532Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-06-09 17:17:08","lastModifiedDate":"2026-06-09 21:17:17","problem_types":["CWE-514","CWE-514 CWE-514 Covert Channel"],"metrics":{"cvssMetricV31":[{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N","baseScore":3.7,"baseSeverity":"LOW","attackVector":"NETWORK","attackComplexity":"HIGH","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"LOW","integrityImpact":"NONE","availabilityImpact":"NONE"},"exploitabilityScore":2.2,"impactScore":1.4}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"42768","Ordinal":"1","Title":"Multi-RecipientInfo Bleichenbacher Oracle in CMS_decrypt() and P","CVE":"CVE-2026-42768","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"42768","Ordinal":"1","NoteData":"Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to\nBleichenbacher-style attack when an attacker is able to provide the CMS or\nS/MIME messages and observe the error code and/or decryption output.\n\nImpact summary: The Bleichenbacher-style attack allows an attacker to use the\nvictim's vulnerable application as a way to decrypt or sign messages with the\nvictim's private RSA key.\n\nThe attack is possible in 2 variants.\n\n1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without\nproviding the recipient certificate. In this case OpenSSL iterates over every\nKeyTransRecipientInfo (KTRI) without stopping at the first success.\n\nAn attacker who authors a message with two KTRI entries — the first one\nwrapping a real CEK under the victim's public key, the second with an\narbitrary probe ciphertext — obtains opportunity to iterate the 2nd KTRI to\nget a valid PKCS#1 v1.5 padding if the error code of the application is\navailable.\n\nThat is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an\nadaptive-chosen-ciphertext side channel from which the attacker decrypts any\nRSA ciphertext to the victim's key or forges any PKCS#1 v1.5 signature under\nit.\n\n2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with\nthe recipient certificate, and the recipient is not found, a random\nkey is substituted.\n\nAn attacker who authors a message and is able to compare both error code and\nthe result of the decryption, can mount a Bleichenbacher oracle.\n\nWe are not aware of any applications that provide a remote attacker\nan opportunity to mount an attack described in these scenarios. We consider\nthe existence of such application very unlikely, and for this reason this\nCVE has been evaluated as Low severity.\n\nTo avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the\ninvoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described\nin draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit\nrejection was explicitly disabled.\n\nThe implicit rejection mechanism always returns a plaintext value,\nthe symmetric key. This result is deterministic for the ciphertext and the\nprivate key.  The length of the decryption result can happen to match the\nlength of the key of the symmetric cipher that was used for the content\nencryption. When a certificate is not provided, the last RecipientInfo\nproducing a key that looks valid will be used. It may cause getting garbage\ncontent on decryption. As a proper way to deal with this a recipient\ncertificate has to be provided to identify the particular RecipientInfo for\ndecryption.\n\nThe FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as\nCMS and S/MIME processing happens outside the OpenSSL FIPS module boundary.","Type":"Description","Title":"Multi-RecipientInfo Bleichenbacher Oracle in CMS_decrypt() and P"}]}}}