OpenSSL 4.0.0 < 4.0.1 Multiple Vulnerabilities

#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
##

include('compat.inc');

if (description)
{
  script_id(320140);
  script_version("1.2");
  script_set_attribute(attribute:"plugin_modification_date", value:"2026/06/10");

  script_cve_id(
    "CVE-2026-7383",
    "CVE-2026-9076",
    "CVE-2026-34180",
    "CVE-2026-34181",
    "CVE-2026-34182",
    "CVE-2026-34183",
    "CVE-2026-35188",
    "CVE-2026-42764",
    "CVE-2026-42765",
    "CVE-2026-42766",
    "CVE-2026-42767",
    "CVE-2026-42768",
    "CVE-2026-42769",
    "CVE-2026-42770",
    "CVE-2026-42771",
    "CVE-2026-45445",
    "CVE-2026-45446",
    "CVE-2026-45447"
  );

  script_name(english:"OpenSSL 4.0.0 < 4.0.1 Multiple Vulnerabilities");

  script_set_attribute(attribute:"synopsis", value:
"The remote service is affected by multiple vulnerabilities.");
  script_set_attribute(attribute:"description", value:
"The version of OpenSSL installed on the remote host is prior to 4.0.1. It is, therefore, affected by multiple
vulnerabilities as referenced in the 4.0.1 advisory.

  - 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. (CVE-2026-42768)

  - Issue summary: A signed integer overflow when sizing the destination buffer for Unicode output in
    ASN1_mbstring_ncopy() can lead to a heap buffer overflow. Impact summary: A heap buffer overflow may lead
    to a crash or possibly attacker controlled code execution or other undefined behaviour. In
    ASN1_mbstring_copy() and ASN1_mbstring_ncopy() the destination size for Unicode output is computed in a
    signed int: by left shift of the input character count for BMPSTRING (UTF-16) and UNIVERSALSTRING
    (UTF-32), and by summing per-character byte counts for UTF8STRING. The calculation overflows when the
    input reaches around 2^30 characters. In the worst case (UNIVERSALSTRING at 2^30 characters) the size
    wraps to zero, OPENSSL_malloc(1) is called, and the subsequent character copy writes several gigabytes
    past the one-byte allocation. X.509 certificate processing routes through ASN1_STRING_set_by_NID(), whose
    DIRSTRING_TYPE mask excludes UNIVERSALSTRING and whose per-NID size limits cap the input length; no
    network protocol or certificate-handling path in OpenSSL exercises the overflow. Triggering the bug
    requires an application that calls ASN1_mbstring_copy() or ASN1_mbstring_ncopy() directly, or registers a
    custom string type via ASN1_STRING_TABLE_add(), with attacker-controlled input on the order of half a
    gigabyte or more. For these reasons this issue was assigned Low severity. The FIPS modules in 4.0, 3.6,
    3.5, 3.4 and 3.0 are not affected by this issue, as the affected code is outside the OpenSSL FIPS module
    boundary. (CVE-2026-7383)

  - Issue summary: When CMS password-based decryption (RFC 3211 / PWRI key unwrap) processes attacker-supplied
    CMS data, an attacker-chosen stream-mode KEK cipher can trigger a heap out-of-bounds read in
    kek_unwrap_key(). Impact summary: A heap buffer over-read may trigger a crash which leads to Denial of
    Service for an application if the input buffer ends at a memory page boundary and the following page is
    unmapped. There is no information disclosure as the over-read bytes are not revealed to the attacker. The
    key unwrapping function performs a check-byte test as specified in the RFC that reads 7 bytes from a heap
    allocation that is based on the wrapped key length from the message. There is a minimum length check based
    on the block length of the wrapping cipher. However the cipher is selected from an OID carried in the
    attacker's PWRI keyEncryptionAlgorithm with no requirement that the cipher be a block cipher. When an
    attacker selects a stream-mode cipher the guard will be ineffective and the allocated buffer containing
    the unwrapped key can be too small to fit the check-bytes specified in the RFC and a buffer over-read can
    happen. Applications calling CMS_decrypt() or CMS_decrypt_set1_password() (equivalently openssl cms
    -decrypt -pwri_password ...) on untrusted CMS data are vulnerable to this issue. No password knowledge is
    required: the over-read happens during the unwrap attempt before any authentication succeeds. The over-
    read is limited to a few bytes and is not written to output, so there is no information disclosure.
    Triggering a crash requires the allocation to border unmapped memory, which is unlikely with the normal
    allocator. The FIPS modules are not affected by this issue. (CVE-2026-9076)

  - Issue summary: A specially crafted PKCS#7 or S/MIME signed message could trigger a use-after-free during
    PKCS#7 signature verification. Impact summary: A use-after-free may result in process crashes, heap
    corruption, or potentially remote code execution. When processing a PKCS#7 or S/MIME signed message, if
    the SignedData digestAlgorithms field is present as an empty ASN.1 SET, OpenSSL may incorrectly free a
    caller-owned BIO during PKCS7_verify(). A subsequent use of the BIO by the calling application results in
    a use-after-free condition. In the common case this occurs when the application later calls BIO_free() on
    the BIO originally passed to PKCS7_verify(). Depending on allocator behavior and application-specific BIO
    usage patterns, this may result in a crash or other memory corruption. In some application contexts this
    may potentially be exploitable for remote code execution. Applications that process PKCS#7 or S/MIME
    signed messages using OpenSSL PKCS#7 APIs may be affected. Applications using the CMS APIs for this
    processing are not affected. The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
    issue, as the affected code is outside the OpenSSL FIPS module boundary. (CVE-2026-45447)

  - Issue summary: The implementations of AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) mishandle the
    authentication of AAD (Additional Authenticated Data) with an empty ciphertext allowing a forgery of such
    messages. Impact summary: An attacker can forge empty messages with arbitrary AAD to the victim's
    application using these ciphers. AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) are nonce-misuse-resistant
    AEAD modes: they accept a key, nonce, optional AAD (bytes that are authenticated but not encrypted), and
    plaintext, and produces ciphertext plus a 16-byte tag. On decrypt, `EVP_DecryptFinal_ex()` is documented
    to return success only if the tag is verified succesfully. In OpenSSL's provider implementation of these
    ciphers, the expected tag is computed only when decryption function is invoked with non-empty data. If the
    caller supplies AAD and then calls `EVP_DecryptFinal_ex()` without invocation of the ciphertext update,
    which can happen when the received ciphertext length is zero, the tag is never recalculated and still
    holds its all-zeros value. When AES-GCM-SIV is used, an attacker who sends arbitrary AAD, empty
    ciphertext, and all-zeros tag passes authentication under any key they do not know, single-shot. When AES-
    SIV is used, for mounting the attack it's necessary for the application to reuse the decryption context
    without resetting the key. AES-SIV is implemented since OpenSSL 3.0. AES-GCM-SIV is implemented since
    OpenSSL 3.2. No protocols implemented in OpenSSL itself (TLS/CMS/PKCS7/HPKE/QUIC) support either AES-GCM-
    SIV or AES-SIV. To mount an attack, the applications must implement their own protocol and use the EVP
    interface. Also they must skip the ciphertext update when a message with an empty ciphertext arrives. The
    FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this issue, as these algorithms are not
    FIPS approved and the affected code is outside the OpenSSL FIPS module boundary. (CVE-2026-45446)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version
number.");
  # https://github.com/openssl/security/commit/0300eb9ddce7a0895bf301a4b0c03a9da2313a0f
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?221d46c0");
  # https://github.com/openssl/security/commit/12bc26ffb3a2be728c9b86e1cae277de5b33dfa4
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?00163a03");
  # https://github.com/openssl/security/commit/14340b7fa1d444615486bc137014b064e64ec334
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?64fe7e81");
  # https://github.com/openssl/security/commit/25b32cd9d41d2bc01b6abc425bb4baf2c2236fdc
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?dbad3dad");
  # https://github.com/openssl/security/commit/3aad5eb7af4de4ee0633c30a8541a54d9bbde63c
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?e81fec23");
  # https://github.com/openssl/security/commit/3d8d5bc1056b2f62da9fede23fedbf47e85187b0
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?0276d2ec");
  # https://github.com/openssl/security/commit/3da5a516cd2635a320ff748503db2cef7c4b0f02
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?24f75bb8");
  # https://github.com/openssl/security/commit/6cd187689f8180c1f8a3acde21f88190c4a20de7
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?ef03aa0e");
  # https://github.com/openssl/security/commit/78d0154cffda03aaaac63a087cc523a6b35fa8fd
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?60f2cf7e");
  # https://github.com/openssl/security/commit/843c9b94ca9c2ed248bb30127bb4f3d7af0d607c
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?9ee60a59");
  # https://github.com/openssl/security/commit/9fd97f8cfdc2c0be214998de3b2b55c8edf6c7ac
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?60f83afc");
  # https://github.com/openssl/security/commit/b90ff3b1bd33b1c18e6a09936d097c2eddef8873
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?7747ea96");
  # https://github.com/openssl/security/commit/bf29a458c1a231eca87e384c62b9c2553fa57a91
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?2ed57117");
  # https://github.com/openssl/security/commit/d32350ae8ef7426718f5aa9e383d4b51398ee255
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?8f47c108");
  # https://github.com/openssl/security/commit/d531f21c0fe99067a66fc0ff1161ef127f9cd70b
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?ee8b4e2a");
  # https://github.com/openssl/security/commit/f04b377be3d821741c86d1f4bf84dee09f3d5c3e
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?c2713e1a");
  # https://github.com/openssl/security/commit/f696c73c3e61b8c502d040af62e690c060908a16
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?7bfc861d");
  # https://github.com/openssl/security/commit/fbaa83859c01ad64f497b757aaf51be7d05ed9eb
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?65c90fcd");
  script_set_attribute(attribute:"see_also", value:"https://openssl-library.org/news/secadv/20260609.txt");
  # https://openssl-library.org/policies/general/security-policy/index.html
  script_set_attribute(attribute:"see_also", value:"http://www.nessus.org/u?eac4598c");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-34180");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-34181");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-34182");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-34183");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-35188");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-42764");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-42765");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-42766");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-42767");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-42768");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-42769");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-42770");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-42771");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-45445");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-45446");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-45447");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-7383");
  script_set_attribute(attribute:"see_also", value:"https://www.cve.org/CVERecord?id=CVE-2026-9076");
  script_set_attribute(attribute:"solution", value:
"Upgrade to OpenSSL version 4.0.1 or later.");
  script_set_attribute(attribute:"agent", value:"all");
  script_set_cvss_base_vector("CVSS2#AV:N/AC:M/Au:N/C:P/I:N/A:N");
  script_set_cvss_temporal_vector("CVSS2#E:U/RL:OF/RC:C");
  script_set_cvss3_base_vector("CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H");
  script_set_cvss3_temporal_vector("CVSS:3.0/E:U/RL:O/RC:C");
  script_set_attribute(attribute:"cvss_score_source", value:"CVE-2026-42768");
  script_set_attribute(attribute:"cvss3_score_source", value:"CVE-2026-45447");

  script_set_attribute(attribute:"exploitability_ease", value:"No known exploits are available");
  script_set_attribute(attribute:"exploit_available", value:"false");

  script_set_attribute(attribute:"vuln_publication_date", value:"2026/06/09");
  script_set_attribute(attribute:"patch_publication_date", value:"2026/06/09");
  script_set_attribute(attribute:"plugin_publication_date", value:"2026/06/09");

  script_set_attribute(attribute:"plugin_type", value:"combined");
  script_set_attribute(attribute:"cpe", value:"cpe:/a:openssl:openssl");
  script_set_attribute(attribute:"generated_plugin", value:"current");
  script_set_attribute(attribute:"thorough_tests", value:"true");
  script_end_attributes();

  script_category(ACT_GATHER_INFO);
  script_family(english:"Web Servers");

  script_copyright(english:"This script is Copyright (C) 2026 and is owned by Tenable, Inc. or an Affiliate thereof.");

  script_dependencies("openssl_version.nasl", "openssl_nix_installed.nbin", "openssl_win_installed.nbin");
  script_require_keys("installed_sw/OpenSSL");

  exit(0);
}

include('vcf.inc');
include('vcf_extras_openssl.inc');

var app_info = vcf::combined_get_app_info(app:'OpenSSL');

vcf::check_all_backporting(app_info:app_info);

var constraints = [
  { 'min_version' : '4.0.0', 'fixed_version' : '4.0.1' }
];

vcf::openssl::check_version_and_report(
    app_info:app_info,
    constraints:constraints,
    severity:SECURITY_WARNING
);