« Volver al listado

CVE-2026-42768

Estado: AnalizadaBaja (3.7)—

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.

Leer descripción completaMostrar menos

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.

CVSS

Probabilidad de explotación (EPSS)

EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).

Tecnologías afectadas (1)

Openssl — Openssl

CWE

Referencias

JSON original (NVD)

Mostrar
{
  "id": "CVE-2026-42768",
  "cveTags": [],
  "metrics": {
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-42768",
          "role": "CISA Coordinator",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "version": "2.0.3",
          "timestamp": "2026-06-09T19:40:18.647253Z"
        }
      }
    ],
    "cvssMetricV31": [
      {
        "type": "Secondary",
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "cvssData": {
          "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"
        },
        "impactScore": 1.4,
        "exploitabilityScore": 2.2
      }
    ]
  },
  "affected": [
    {
      "source": "openssl-security@openssl.org",
      "affectedData": [
        {
          "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"
        }
      ]
    }
  ],
  "published": "2026-06-09T17:17:08.223",
  "references": [
    {
      "url": "https://github.com/openssl/openssl/commit/a2ca7b2d73e0ffc1eae183fe6e1741dac767cb4f",
      "tags": [
        "Patch"
      ],
      "source": "openssl-security@openssl.org"
    },
    {
      "url": "https://github.com/openssl/openssl/commit/bbb151a83041705d9d001ed2f9c12f5523e1b54d",
      "tags": [
        "Patch"
      ],
      "source": "openssl-security@openssl.org"
    },
    {
      "url": "https://github.com/openssl/openssl/commit/dd68364107a58841c0a2546812518b65d3a23abd",
      "tags": [
        "Patch"
      ],
      "source": "openssl-security@openssl.org"
    },
    {
      "url": "https://github.com/openssl/openssl/commit/f04b377be3d821741c86d1f4bf84dee09f3d5c3e",
      "tags": [
        "Patch"
      ],
      "source": "openssl-security@openssl.org"
    },
    {
      "url": "https://openssl-library.org/news/secadv/20260609.txt",
      "tags": [
        "Vendor Advisory"
      ],
      "source": "openssl-security@openssl.org"
    }
  ],
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "type": "Secondary",
      "source": "openssl-security@openssl.org",
      "description": [
        {
          "lang": "en",
          "value": "CWE-514"
        }
      ]
    }
  ],
  "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'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."
    },
    {
      "lang": "es",
      "value": "Resumen del problema: Las funciones CMS_decrypt y PKCS7_decrypt son vulnerables a un ataque de estilo Bleichenbacher cuando un atacante es capaz de proporcionar los mensajes CMS o S/MIME y observar el código de error y/o la salida del descifrado.\n\nResumen del impacto: El ataque de estilo Bleichenbacher permite a un atacante usar la aplicación vulnerable de la víctima como una forma de descifrar o firmar mensajes con la clave RSA privada de la víctima.\n\nEl ataque es posible en 2 variantes.\n\n1. La API de descifrado (CMS_decrypt(), PKCS7_decrypt()) se utiliza sin proporcionar el certificado del destinatario. En este caso, OpenSSL itera sobre cada KeyTransRecipientInfo (KTRI) sin detenerse en el primer éxito.\n\nUn atacante que crea un mensaje con dos entradas KTRI - la primera envolviendo una CEK real bajo la clave pública de la víctima, la segunda con un texto cifrado de sondeo arbitrario - obtiene la oportunidad de iterar la segunda KTRI para obtener un relleno PKCS#1 v1.5 válido si el código de error de la aplicación está disponible.\n\nEso es un oráculo de Bleichenbacher (Bleichenbacher, CRYPTO '98): un canal lateral de texto cifrado elegido adaptativo desde el cual el atacante descifra cualquier texto cifrado RSA a la clave de la víctima o falsifica cualquier firma PKCS#1 v1.5 bajo ella.\n\n2. Cuando la API de descifrado (CMS_decrypt(), PKCS7_decrypt()) se proporciona con el certificado del destinatario, y el destinatario no se encuentra, se sustituye una clave aleatoria.\n\nUn atacante que crea un mensaje y es capaz de comparar tanto el código de error como el resultado del descifrado, puede montar un oráculo de Bleichenbacher.\n\nNo tenemos conocimiento de ninguna aplicación que proporcione a un atacante remoto la oportunidad de montar un ataque descrito en estos escenarios. Consideramos muy improbable la existencia de dicha aplicación, y por esta razón este CVE ha sido evaluado como de severidad Baja.\n\nPara evitar estos ataques, cuando el transporte de clave RSA PKCS#1 v1.5 está en uso, la función EVP_PKEY_decrypt() invocada utilizará el mecanismo de rechazo implícito descrito en draft-irtf-cfrg-rsa-guidance. En versiones anteriores de OpenSSL, el rechazo implícito estaba explícitamente deshabilitado.\n\nEl mecanismo de rechazo implícito siempre devuelve un valor de texto plano, la clave simétrica. Este resultado es determinista para el texto cifrado y la clave privada. La longitud del resultado del descifrado puede coincidir con la longitud de la clave del cifrado simétrico que se utilizó para el cifrado del contenido. Cuando no se proporciona un certificado, se utilizará el último RecipientInfo que produzca una clave que parezca válida. Puede causar la obtención de contenido basura en el descifrado. Como una forma adecuada de lidiar con esto, se debe proporcionar un certificado de destinatario para identificar el RecipientInfo particular para el descifrado.\n\nLos módulos FIPS en 4.0, 3.6, 3.5 y 3.4 no se ven afectados por este problema, ya que el procesamiento de CMS y S/MIME ocurre fuera del límite del módulo FIPS de OpenSSL."
    }
  ],
  "lastModified": "2026-07-23T08:10:00.137",
  "configurations": [
    {
      "nodes": [
        {
          "negate": false,
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "BF7E21E7-AEC0-4882-B1F1-2D056B506F22",
              "versionEndExcluding": "3.4.6",
              "versionStartIncluding": "3.4.0"
            },
            {
              "criteria": "cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "6B6B9930-C549-4D88-9784-AF32CCDDB87A",
              "versionEndExcluding": "3.5.7",
              "versionStartIncluding": "3.5.0"
            },
            {
              "criteria": "cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "D41B3C45-EC73-4DC8-989D-B2E2792E102F",
              "versionEndExcluding": "3.6.3",
              "versionStartIncluding": "3.6.0"
            },
            {
              "criteria": "cpe:2.3:a:openssl:openssl:4.0.0:-:*:*:*:*:*:*",
              "vulnerable": true,
              "matchCriteriaId": "6E881B9A-1A0A-4BC0-8160-20C00561167D"
            }
          ],
          "operator": "OR"
        }
      ]
    }
  ],
  "sourceIdentifier": "openssl-security@openssl.org"
}