CVE-2026-42768 (GCVE-0-2026-42768)
Vulnerability from cvelistv5 – Published: 2026-06-09 16:03 – Updated: 2026-06-10 07:48
VLAI
Title
Multi-RecipientInfo Bleichenbacher Oracle in CMS_decrypt() and PKCS7_decrypt()
Summary
Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to
Bleichenbacher-style attack when an attacker is able to provide the CMS or
S/MIME messages and observe the error code and/or decryption output.
Impact summary: The Bleichenbacher-style attack allows an attacker to use the
victim's vulnerable application as a way to decrypt or sign messages with the
victim's private RSA key.
The attack is possible in 2 variants.
1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without
providing the recipient certificate. In this case OpenSSL iterates over every
KeyTransRecipientInfo (KTRI) without stopping at the first success.
An attacker who authors a message with two KTRI entries — the first one
wrapping a real CEK under the victim's public key, the second with an
arbitrary probe ciphertext — obtains opportunity to iterate the 2nd KTRI to
get a valid PKCS#1 v1.5 padding if the error code of the application is
available.
That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an
adaptive-chosen-ciphertext side channel from which the attacker decrypts any
RSA ciphertext to the victim's key or forges any PKCS#1 v1.5 signature under
it.
2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with
the recipient certificate, and the recipient is not found, a random
key is substituted.
An attacker who authors a message and is able to compare both error code and
the result of the decryption, can mount a Bleichenbacher oracle.
We are not aware of any applications that provide a remote attacker
an opportunity to mount an attack described in these scenarios. We consider
the existence of such application very unlikely, and for this reason this
CVE has been evaluated as Low severity.
To avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the
invoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described
in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit
rejection was explicitly disabled.
The implicit rejection mechanism always returns a plaintext value,
the symmetric key. This result is deterministic for the ciphertext and the
private key. The length of the decryption result can happen to match the
length of the key of the symmetric cipher that was used for the content
encryption. When a certificate is not provided, the last RecipientInfo
producing a key that looks valid will be used. It may cause getting garbage
content on decryption. As a proper way to deal with this a recipient
certificate has to be provided to identify the particular RecipientInfo for
decryption.
The FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as
CMS and S/MIME processing happens outside the OpenSSL FIPS module boundary.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator (v2.0.3)
CWE
- CWE-514 - Covert Channel
Assigner
References
5 references
Impacted products
Date Public
2026-06-09 14:00
Credits
{
"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\u003cbr\u003eBleichenbacher-style attack when an attacker is able to provide the CMS or\u003cbr\u003eS/MIME messages and observe the error code and/or decryption output.\u003cbr\u003e\u003cbr\u003eImpact summary: The Bleichenbacher-style attack allows an attacker to use the\u003cbr\u003evictim\u0027s vulnerable application as a way to decrypt or sign messages with the\u003cbr\u003evictim\u0027s private RSA key.\u003cbr\u003e\u003cbr\u003eThe attack is possible in 2 variants.\u003cbr\u003e\u003cbr\u003e1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without\u003cbr\u003eproviding the recipient certificate. In this case OpenSSL iterates over every\u003cbr\u003eKeyTransRecipientInfo (KTRI) without stopping at the first success.\u003cbr\u003e\u003cbr\u003eAn attacker who authors a message with two KTRI entries \u2014 the first one\u003cbr\u003ewrapping a real CEK under the victim\u0027s public key, the second with an\u003cbr\u003earbitrary probe ciphertext \u2014 obtains opportunity to iterate the 2nd KTRI to\u003cbr\u003eget a valid PKCS#1 v1.5 padding if the error code of the application is\u003cbr\u003eavailable.\u003cbr\u003e\u003cbr\u003eThat is a Bleichenbacher oracle (Bleichenbacher, CRYPTO \u002798): an\u003cbr\u003eadaptive-chosen-ciphertext side channel from which the attacker decrypts any\u003cbr\u003eRSA ciphertext to the victim\u0027s key or forges any PKCS#1 v1.5 signature under\u003cbr\u003eit.\u003cbr\u003e\u003cbr\u003e2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with\u003cbr\u003ethe recipient certificate, and the recipient is not found, a random\u003cbr\u003ekey is substituted.\u003cbr\u003e\u003cbr\u003eAn attacker who authors a message and is able to compare both error code and\u003cbr\u003ethe result of the decryption, can mount a Bleichenbacher oracle.\u003cbr\u003e\u003cbr\u003eWe are not aware of any applications that provide a remote attacker\u003cbr\u003ean opportunity to mount an attack described in these scenarios. We consider\u003cbr\u003ethe existence of such application very unlikely, and for this reason this\u003cbr\u003eCVE has been evaluated as Low severity.\u003cbr\u003e\u003cbr\u003eTo avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the\u003cbr\u003einvoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described\u003cbr\u003ein draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit\u003cbr\u003erejection was explicitly disabled.\u003cbr\u003e\u003cbr\u003eThe implicit rejection mechanism always returns a plaintext value,\u003cbr\u003ethe symmetric key. This result is deterministic for the ciphertext and the\u003cbr\u003eprivate key. The length of the decryption result can happen to match the\u003cbr\u003elength of the key of the symmetric cipher that was used for the content\u003cbr\u003eencryption. When a certificate is not provided, the last RecipientInfo\u003cbr\u003eproducing a key that looks valid will be used. It may cause getting garbage\u003cbr\u003econtent on decryption. As a proper way to deal with this a recipient\u003cbr\u003ecertificate has to be provided to identify the particular RecipientInfo for\u003cbr\u003edecryption.\u003cbr\u003e\u003cbr\u003eThe FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as\u003cbr\u003eCMS 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\u0027s vulnerable application as a way to decrypt or sign messages with the\nvictim\u0027s 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 \u2014 the first one\nwrapping a real CEK under the victim\u0027s public key, the second with an\narbitrary probe ciphertext \u2014 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 \u002798): an\nadaptive-chosen-ciphertext side channel from which the attacker decrypts any\nRSA ciphertext to the victim\u0027s 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-10T07:48:04.770Z",
"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/openssl/commit/f04b377be3d821741c86d1f4bf84dee09f3d5c3e"
},
{
"name": "3.6.3 git commit",
"tags": [
"patch"
],
"url": "https://github.com/openssl/openssl/commit/a2ca7b2d73e0ffc1eae183fe6e1741dac767cb4f"
},
{
"name": "3.5.7 git commit",
"tags": [
"patch"
],
"url": "https://github.com/openssl/openssl/commit/bbb151a83041705d9d001ed2f9c12f5523e1b54d"
},
{
"name": "3.4.6 git commit",
"tags": [
"patch"
],
"url": "https://github.com/openssl/openssl/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-10T07:48:04.770Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-42768",
"date": "2026-06-10",
"epss": "0.00012",
"percentile": "0.01778"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2026-42768\",\"sourceIdentifier\":\"openssl-security@openssl.org\",\"published\":\"2026-06-09T17:17:08.223\",\"lastModified\":\"2026-06-10T08:16:23.840\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"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\u0027s vulnerable application as a way to decrypt or sign messages with the\\nvictim\u0027s 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 \u2014 the first one\\nwrapping a real CEK under the victim\u0027s public key, the second with an\\narbitrary probe ciphertext \u2014 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 \u002798): an\\nadaptive-chosen-ciphertext side channel from which the attacker decrypts any\\nRSA ciphertext to the victim\u0027s 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\":{\"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}]},\"weaknesses\":[{\"source\":\"openssl-security@openssl.org\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-514\"}]}],\"references\":[{\"url\":\"https://github.com/openssl/openssl/commit/a2ca7b2d73e0ffc1eae183fe6e1741dac767cb4f\",\"source\":\"openssl-security@openssl.org\"},{\"url\":\"https://github.com/openssl/openssl/commit/bbb151a83041705d9d001ed2f9c12f5523e1b54d\",\"source\":\"openssl-security@openssl.org\"},{\"url\":\"https://github.com/openssl/openssl/commit/dd68364107a58841c0a2546812518b65d3a23abd\",\"source\":\"openssl-security@openssl.org\"},{\"url\":\"https://github.com/openssl/openssl/commit/f04b377be3d821741c86d1f4bf84dee09f3d5c3e\",\"source\":\"openssl-security@openssl.org\"},{\"url\":\"https://openssl-library.org/news/secadv/20260609.txt\",\"source\":\"openssl-security@openssl.org\"}]}}",
"vulnrichment": {
"containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 3.7, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"LOW\", \"vectorString\": \"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N\", \"integrityImpact\": \"NONE\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"HIGH\", \"availabilityImpact\": \"NONE\", \"privilegesRequired\": \"NONE\", \"confidentialityImpact\": \"LOW\"}}, {\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-42768\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-06-09T19:40:18.647253Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-06-09T19:40:13.927Z\"}}], \"cna\": {\"title\": \"Multi-RecipientInfo Bleichenbacher Oracle in CMS_decrypt() and PKCS7_decrypt()\", \"source\": {\"discovery\": \"UNKNOWN\"}, \"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)\"}], \"metrics\": [{\"other\": {\"type\": \"https://openssl-library.org/policies/general/security-policy/\", \"content\": {\"text\": \"Low\"}}, \"format\": \"other\"}], \"affected\": [{\"vendor\": \"OpenSSL\", \"product\": \"OpenSSL\", \"versions\": [{\"status\": \"affected\", \"version\": \"4.0.0\", \"lessThan\": \"4.0.1\", \"versionType\": \"semver\"}, {\"status\": \"affected\", \"version\": \"3.6.0\", \"lessThan\": \"3.6.3\", \"versionType\": \"semver\"}, {\"status\": \"affected\", \"version\": \"3.5.0\", \"lessThan\": \"3.5.7\", \"versionType\": \"semver\"}, {\"status\": \"affected\", \"version\": \"3.4.0\", \"lessThan\": \"3.4.6\", \"versionType\": \"semver\"}], \"defaultStatus\": \"unaffected\"}], \"datePublic\": \"2026-06-09T14:00:00.000Z\", \"references\": [{\"url\": \"https://openssl-library.org/news/secadv/20260609.txt\", \"name\": \"OpenSSL Advisory\", \"tags\": [\"vendor-advisory\"]}, {\"url\": \"https://github.com/openssl/openssl/commit/f04b377be3d821741c86d1f4bf84dee09f3d5c3e\", \"name\": \"4.0.1 git commit\", \"tags\": [\"patch\"]}, {\"url\": \"https://github.com/openssl/openssl/commit/a2ca7b2d73e0ffc1eae183fe6e1741dac767cb4f\", \"name\": \"3.6.3 git commit\", \"tags\": [\"patch\"]}, {\"url\": \"https://github.com/openssl/openssl/commit/bbb151a83041705d9d001ed2f9c12f5523e1b54d\", \"name\": \"3.5.7 git commit\", \"tags\": [\"patch\"]}, {\"url\": \"https://github.com/openssl/openssl/commit/dd68364107a58841c0a2546812518b65d3a23abd\", \"name\": \"3.4.6 git commit\", \"tags\": [\"patch\"]}], \"x_generator\": {\"engine\": \"Vulnogram 0.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"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\u0027s vulnerable application as a way to decrypt or sign messages with the\\nvictim\u0027s 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 \\u2014 the first one\\nwrapping a real CEK under the victim\u0027s public key, the second with an\\narbitrary probe ciphertext \\u2014 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 \u002798): an\\nadaptive-chosen-ciphertext side channel from which the attacker decrypts any\\nRSA ciphertext to the victim\u0027s 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.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to\u003cbr\u003eBleichenbacher-style attack when an attacker is able to provide the CMS or\u003cbr\u003eS/MIME messages and observe the error code and/or decryption output.\u003cbr\u003e\u003cbr\u003eImpact summary: The Bleichenbacher-style attack allows an attacker to use the\u003cbr\u003evictim\u0027s vulnerable application as a way to decrypt or sign messages with the\u003cbr\u003evictim\u0027s private RSA key.\u003cbr\u003e\u003cbr\u003eThe attack is possible in 2 variants.\u003cbr\u003e\u003cbr\u003e1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without\u003cbr\u003eproviding the recipient certificate. In this case OpenSSL iterates over every\u003cbr\u003eKeyTransRecipientInfo (KTRI) without stopping at the first success.\u003cbr\u003e\u003cbr\u003eAn attacker who authors a message with two KTRI entries \\u2014 the first one\u003cbr\u003ewrapping a real CEK under the victim\u0027s public key, the second with an\u003cbr\u003earbitrary probe ciphertext \\u2014 obtains opportunity to iterate the 2nd KTRI to\u003cbr\u003eget a valid PKCS#1 v1.5 padding if the error code of the application is\u003cbr\u003eavailable.\u003cbr\u003e\u003cbr\u003eThat is a Bleichenbacher oracle (Bleichenbacher, CRYPTO \u002798): an\u003cbr\u003eadaptive-chosen-ciphertext side channel from which the attacker decrypts any\u003cbr\u003eRSA ciphertext to the victim\u0027s key or forges any PKCS#1 v1.5 signature under\u003cbr\u003eit.\u003cbr\u003e\u003cbr\u003e2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is provided with\u003cbr\u003ethe recipient certificate, and the recipient is not found, a random\u003cbr\u003ekey is substituted.\u003cbr\u003e\u003cbr\u003eAn attacker who authors a message and is able to compare both error code and\u003cbr\u003ethe result of the decryption, can mount a Bleichenbacher oracle.\u003cbr\u003e\u003cbr\u003eWe are not aware of any applications that provide a remote attacker\u003cbr\u003ean opportunity to mount an attack described in these scenarios. We consider\u003cbr\u003ethe existence of such application very unlikely, and for this reason this\u003cbr\u003eCVE has been evaluated as Low severity.\u003cbr\u003e\u003cbr\u003eTo avoid these attacks, when RSA PKCS#1 v1.5 Key Transport is in use, the\u003cbr\u003einvoked EVP_PKEY_decrypt() will use the implicit rejection mechanism described\u003cbr\u003ein draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit\u003cbr\u003erejection was explicitly disabled.\u003cbr\u003e\u003cbr\u003eThe implicit rejection mechanism always returns a plaintext value,\u003cbr\u003ethe symmetric key. This result is deterministic for the ciphertext and the\u003cbr\u003eprivate key. The length of the decryption result can happen to match the\u003cbr\u003elength of the key of the symmetric cipher that was used for the content\u003cbr\u003eencryption. When a certificate is not provided, the last RecipientInfo\u003cbr\u003eproducing a key that looks valid will be used. It may cause getting garbage\u003cbr\u003econtent on decryption. As a proper way to deal with this a recipient\u003cbr\u003ecertificate has to be provided to identify the particular RecipientInfo for\u003cbr\u003edecryption.\u003cbr\u003e\u003cbr\u003eThe FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as\u003cbr\u003eCMS and S/MIME processing happens outside the OpenSSL FIPS module boundary.\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-514\", \"description\": \"CWE-514 Covert Channel\"}]}], \"providerMetadata\": {\"orgId\": \"3a12439a-ef3a-4c79-92e6-6081a721f1e5\", \"shortName\": \"openssl\", \"dateUpdated\": \"2026-06-10T07:48:04.770Z\"}}}",
"cveMetadata": "{\"cveId\": \"CVE-2026-42768\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-06-10T07:48:04.770Z\", \"dateReserved\": \"2026-04-29T09:22:27.969Z\", \"assignerOrgId\": \"3a12439a-ef3a-4c79-92e6-6081a721f1e5\", \"datePublished\": \"2026-06-09T16:03:28.206Z\", \"assignerShortName\": \"openssl\"}",
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
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.
Loading…
Loading…