FKIE_CVE-2026-42768

Vulnerability from fkie_nvd - Published: 2026-06-09 17:17 - Updated: 2026-07-23 08:10
Severity
3.7 (Low) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
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.
References
openssl-security@openssl.orghttps://github.com/openssl/openssl/commit/a2ca7b2d73e0ffc1eae183fe6e1741dac767cb4fPatch
openssl-security@openssl.orghttps://github.com/openssl/openssl/commit/bbb151a83041705d9d001ed2f9c12f5523e1b54dPatch
openssl-security@openssl.orghttps://github.com/openssl/openssl/commit/dd68364107a58841c0a2546812518b65d3a23abdPatch
openssl-security@openssl.orghttps://github.com/openssl/openssl/commit/f04b377be3d821741c86d1f4bf84dee09f3d5c3ePatch
openssl-security@openssl.orghttps://openssl-library.org/news/secadv/20260609.txtVendor Advisory
Impacted products
Vendor Product Version
openssl openssl *
openssl openssl *
openssl openssl *
openssl openssl 4.0.0
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "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"
            }
          ]
        }
      ],
      "source": "openssl-security@openssl.org"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "BF7E21E7-AEC0-4882-B1F1-2D056B506F22",
              "versionEndExcluding": "3.4.6",
              "versionStartIncluding": "3.4.0",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "6B6B9930-C549-4D88-9784-AF32CCDDB87A",
              "versionEndExcluding": "3.5.7",
              "versionStartIncluding": "3.5.0",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "D41B3C45-EC73-4DC8-989D-B2E2792E102F",
              "versionEndExcluding": "3.6.3",
              "versionStartIncluding": "3.6.0",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:a:openssl:openssl:4.0.0:-:*:*:*:*:*:*",
              "matchCriteriaId": "6E881B9A-1A0A-4BC0-8160-20C00561167D",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "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."
    },
    {
      "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\u00f3digo de error y/o la salida del descifrado.\n\nResumen del impacto: El ataque de estilo Bleichenbacher permite a un atacante usar la aplicaci\u00f3n vulnerable de la v\u00edctima como una forma de descifrar o firmar mensajes con la clave RSA privada de la v\u00edctima.\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 \u00e9xito.\n\nUn atacante que crea un mensaje con dos entradas KTRI - la primera envolviendo una CEK real bajo la clave p\u00fablica de la v\u00edctima, 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\u00e1lido si el c\u00f3digo de error de la aplicaci\u00f3n est\u00e1 disponible.\n\nEso es un or\u00e1culo de Bleichenbacher (Bleichenbacher, CRYPTO \u002798): un canal lateral de texto cifrado elegido adaptativo desde el cual el atacante descifra cualquier texto cifrado RSA a la clave de la v\u00edctima 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\u00f3digo de error como el resultado del descifrado, puede montar un or\u00e1culo de Bleichenbacher.\n\nNo tenemos conocimiento de ninguna aplicaci\u00f3n que proporcione a un atacante remoto la oportunidad de montar un ataque descrito en estos escenarios. Consideramos muy improbable la existencia de dicha aplicaci\u00f3n, y por esta raz\u00f3n 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\u00e1 en uso, la funci\u00f3n EVP_PKEY_decrypt() invocada utilizar\u00e1 el mecanismo de rechazo impl\u00edcito descrito en draft-irtf-cfrg-rsa-guidance. En versiones anteriores de OpenSSL, el rechazo impl\u00edcito estaba expl\u00edcitamente deshabilitado.\n\nEl mecanismo de rechazo impl\u00edcito siempre devuelve un valor de texto plano, la clave sim\u00e9trica. 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\u00e9trico que se utiliz\u00f3 para el cifrado del contenido. Cuando no se proporciona un certificado, se utilizar\u00e1 el \u00faltimo RecipientInfo que produzca una clave que parezca v\u00e1lida. Puede causar la obtenci\u00f3n 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\u00f3dulos 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\u00edmite del m\u00f3dulo FIPS de OpenSSL."
    }
  ],
  "id": "CVE-2026-42768",
  "lastModified": "2026-07-23T08:10:00.137",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "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"
        },
        "exploitabilityScore": 2.2,
        "impactScore": 1.4,
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-42768",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-06-09T19:40:18.647253Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-06-09T17:17:08.223",
  "references": [
    {
      "source": "openssl-security@openssl.org",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/openssl/openssl/commit/a2ca7b2d73e0ffc1eae183fe6e1741dac767cb4f"
    },
    {
      "source": "openssl-security@openssl.org",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/openssl/openssl/commit/bbb151a83041705d9d001ed2f9c12f5523e1b54d"
    },
    {
      "source": "openssl-security@openssl.org",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/openssl/openssl/commit/dd68364107a58841c0a2546812518b65d3a23abd"
    },
    {
      "source": "openssl-security@openssl.org",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/openssl/openssl/commit/f04b377be3d821741c86d1f4bf84dee09f3d5c3e"
    },
    {
      "source": "openssl-security@openssl.org",
      "tags": [
        "Vendor Advisory"
      ],
      "url": "https://openssl-library.org/news/secadv/20260609.txt"
    }
  ],
  "sourceIdentifier": "openssl-security@openssl.org",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-514"
        }
      ],
      "source": "openssl-security@openssl.org",
      "type": "Secondary"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.


Detection rules are retrieved from Rulezet.