Common Weakness Enumeration

CWE-754

Allowed-with-Review

Improper Check for Unusual or Exceptional Conditions

Abstraction: Class · Status: Incomplete

The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

905 vulnerabilities reference this CWE, most recent first.

GHSA-V787-C3F2-P88R

Vulnerability from github – Published: 2024-11-08 06:30 – Updated: 2025-11-04 00:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

posix-clock: Fix missing timespec64 check in pc_clock_settime()

As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64().

As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid.

There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-50195"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-08T06:15:16Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nposix-clock: Fix missing timespec64 check in pc_clock_settime()\n\nAs Andrew pointed out, it will make sense that the PTP core\nchecked timespec64 struct\u0027s tv_sec and tv_nsec range before calling\nptp-\u003einfo-\u003esettime64().\n\nAs the man manual of clock_settime() said, if tp.tv_sec is negative or\ntp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,\nwhich include dynamic clocks which handles PTP clock, and the condition is\nconsistent with timespec64_valid(). As Thomas suggested, timespec64_valid()\nonly check the timespec is valid, but not ensure that the time is\nin a valid range, so check it ahead using timespec64_valid_strict()\nin pc_clock_settime() and return -EINVAL if not valid.\n\nThere are some drivers that use tp-\u003etv_sec and tp-\u003etv_nsec directly to\nwrite registers without validity checks and assume that the higher layer\nhas checked it, which is dangerous and will benefit from this, such as\nhclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),\nand some drivers can remove the checks of itself.",
  "id": "GHSA-v787-c3f2-p88r",
  "modified": "2025-11-04T00:31:57Z",
  "published": "2024-11-08T06:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50195"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1ff7247101af723731ea42ed565d54fb8f341264"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/27abbde44b6e71ee3891de13e1a228aa7ce95bfe"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/29f085345cde24566efb751f39e5d367c381c584"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/673a1c5a2998acbd429d6286e6cad10f17f4f073"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a3f169e398215e71361774d13bf91a0101283ac2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c8789fbe2bbf75845e45302cba6ffa44e1884d01"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d8794ac20a299b647ba9958f6d657051fc51a540"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e0c966bd3e31911b57ef76cec4c5796ebd88e512"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V8G7-64M9-F7WF

Vulnerability from github – Published: 2022-02-11 00:00 – Updated: 2025-05-05 18:31
VLAI
Details

Improper conditions check in the Intel(R) IPP Crypto library before version 2021.2 may allow an authenticated user to potentially enable information disclosure via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-33147"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-09T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper conditions check in the Intel(R) IPP Crypto library before version 2021.2 may allow an authenticated user to potentially enable information disclosure via local access.",
  "id": "GHSA-v8g7-64m9-f7wf",
  "modified": "2025-05-05T18:31:34Z",
  "published": "2022-02-11T00:00:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33147"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00600.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V9J6-RMVQ-8674

Vulnerability from github – Published: 2024-01-12 03:30 – Updated: 2024-01-12 03:30
VLAI
Details

An Improper Check for Unusual or Exceptional Conditions vulnerability in Routing Protocol Daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows a network-based, unauthenticated attacker to cause rpd to crash, leading to Denial of Service (DoS).

On all Junos OS and Junos OS Evolved platforms, when NETCONF and gRPC are enabled, and a specific query is executed via Dynamic Rendering (DREND), rpd will crash and restart. Continuous execution of this specific query will cause a sustained Denial of Service (DoS) condition.

This issue affects:

Juniper Networks Junos OS

  • 22.2 versions earlier than 22.2R2-S2, 22.2R3;
  • 22.3 versions earlier than 22.3R2, 22.3R3.

Juniper Networks Junos OS Evolved

  • 22.2 versions earlier than 22.2R2-S2-EVO, 22.2R3-EVO;
  • 22.3 versions earlier than 22.3R2-EVO, 22.3R3-EVO.

This issue does not affect Juniper Networks:

Junos OS versions earlier than 22.2R1;

Junos OS Evolved versions earlier than 22.2R1-EVO.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21614"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-12T01:15:49Z",
    "severity": "HIGH"
  },
  "details": "\nAn Improper Check for Unusual or Exceptional Conditions vulnerability in Routing Protocol Daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows a network-based, unauthenticated attacker to cause rpd to crash, leading to Denial of Service (DoS).\n\nOn all Junos OS and Junos OS Evolved platforms, when NETCONF and gRPC are enabled, and a specific query is executed via Dynamic Rendering (DREND), rpd will crash and restart. Continuous execution of this specific query will cause a sustained Denial of Service (DoS) condition.\n\nThis issue affects:\n\nJuniper Networks Junos OS\n\n\n\n  *  22.2 versions earlier than 22.2R2-S2, 22.2R3;\n  *  22.3 versions earlier than 22.3R2, 22.3R3.\n\n\n\n\nJuniper Networks Junos OS Evolved\n\n\n\n  *  22.2 versions earlier than 22.2R2-S2-EVO, 22.2R3-EVO;\n  *  22.3 versions earlier than 22.3R2-EVO, 22.3R3-EVO.\n\n\n\n\nThis issue does not affect Juniper Networks:\n\nJunos OS versions earlier than 22.2R1;\n\nJunos OS Evolved versions earlier than 22.2R1-EVO.\n\n\n\n",
  "id": "GHSA-v9j6-rmvq-8674",
  "modified": "2024-01-12T03:30:49Z",
  "published": "2024-01-12T03:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21614"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA75755"
    },
    {
      "type": "WEB",
      "url": "https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V9X7-5MRP-4M42

Vulnerability from github – Published: 2024-07-30 09:32 – Updated: 2024-08-05 21:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

gve: Account for stopped queues when reading NIC stats

We now account for the fact that the NIC might send us stats for a subset of queues. Without this change, gve_get_ethtool_stats might make an invalid access on the priv->stats_report->stats array.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-42162"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-30T08:15:07Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngve: Account for stopped queues when reading NIC stats\n\nWe now account for the fact that the NIC might send us stats for a\nsubset of queues. Without this change, gve_get_ethtool_stats might make\nan invalid access on the priv-\u003estats_report-\u003estats array.",
  "id": "GHSA-v9x7-5mrp-4m42",
  "modified": "2024-08-05T21:31:19Z",
  "published": "2024-07-30T09:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42162"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/32675d828c8a392e20d5b42375ed112c407e4b62"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/af9bcf910b1f86244f39e15e701b2dc564b469a6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VC77-C2HX-H5X2

Vulnerability from github – Published: 2025-08-11 21:31 – Updated: 2025-08-11 23:19
VLAI
Summary
Mattermost Confluence Plugin has Improper Check for Unusual or Exceptional Conditions
Details

Mattermost Confluence Plugin versions < 1.5.0 fails to handle unexpected request bodies, allowing attackers to crash the plugin via constant hits to the update channel subscription endpoint with an invalid request body.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-plugin-confluence"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-52931"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-11T23:19:15Z",
    "nvd_published_at": "2025-08-11T19:15:28Z",
    "severity": "HIGH"
  },
  "details": "Mattermost Confluence Plugin versions \u003c 1.5.0 fails to handle unexpected request bodies, allowing attackers to crash the plugin via constant hits to the update channel subscription endpoint with an invalid request body.",
  "id": "GHSA-vc77-c2hx-h5x2",
  "modified": "2025-08-11T23:19:15Z",
  "published": "2025-08-11T21:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52931"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost-plugin-confluence"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost Confluence Plugin has Improper Check for Unusual or Exceptional Conditions"
}

GHSA-VCGP-9326-PQCP

Vulnerability from github – Published: 2026-05-04 22:01 – Updated: 2026-05-14 20:48
VLAI
Summary
net-imap vulnerable to STARTTLS stripping via invalid response timing
Details

Summary

A man-in-the-middle attacker can cause Net::IMAP#starttls to return "successfully", without starting TLS.

Details

When using Net::IMAP#starttls to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged OK response with an easily predictable tag. By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered. This allows #starttls to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.

This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks Net::IMAP#tls_verified?.

Impact

TLS bypass, leading to cleartext transmission of sensitive information.

Mitigation

  • Upgrade to a patched version of net-imap that raises an exception whenever #starttls does not establish TLS.
  • Connect to an implicit TLS port, rather than use STARTTLS with a cleartext port. This is strongly recommended anyway:
  • RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
  • NO STARTTLS: Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context
  • Explicitly verify Net::IMAP#tls_verified? is true, before using the connection after #starttls.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.3"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "0.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.13"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.5.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.23"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.4.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.9"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42246"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-392",
      "CWE-393",
      "CWE-636",
      "CWE-754",
      "CWE-841"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T22:01:52Z",
    "nvd_published_at": "2026-05-09T20:16:28Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA man-in-the-middle attacker can cause `Net::IMAP#starttls` to return \"successfully\", without starting TLS.\n\n### Details\n\nWhen using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag.  By sending the response before the client finishes sending the command, the command completes \"successfully\" before the response handler is registered.  This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted.\n\nThis allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.\n\n### Impact\n\nTLS bypass, leading to cleartext transmission of sensitive information.\n\n### Mitigation\n\n* Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS.\n* Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port.\n  This is strongly recommended anyway:\n  * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access\n  * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context\n* Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connection after `#starttls`.",
  "id": "GHSA-vcgp-9326-pqcp",
  "modified": "2026-05-14T20:48:01Z",
  "published": "2026-05-04T22:01:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-vcgp-9326-pqcp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42246"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/0ede4c40b1523dfeaf95777b2678e54cc0fd9618"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/24a4e770b43230286a05aa2a9746cdbb3eb8485e"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/97e2488fb5401a1783bddd959dde007d9fbce42c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/f79d35bf5833f186e81044c57c843eda30c873da"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.3.10"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.4.24"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.5.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/releases/tag/v0.6.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2026-42246.yml"
    },
    {
      "type": "WEB",
      "url": "https://nostarttls.secvuln.info"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/info/rfc8314"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "net-imap vulnerable to STARTTLS stripping via invalid response timing"
}

GHSA-VF99-3R9R-PP36

Vulnerability from github – Published: 2022-05-24 16:46 – Updated: 2026-05-29 15:30
VLAI
Details

A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists which could cause a possible Denial of Service when specific Modbus frames are sent to the controller in the products: Modicon M340 - firmware versions prior to V3.01, Modicon M580 - firmware versions prior to V2.80, All firmware versions of Modicon Quantum and Modicon Premium.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-6819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-05-22T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "A CWE-754: Improper Check for Unusual or Exceptional Conditions vulnerability exists which could cause a possible Denial of Service when specific Modbus frames are sent to the controller in the products: Modicon M340 - firmware versions prior to V3.01, Modicon M580 - firmware versions prior to V2.80, All firmware versions of Modicon Quantum and Modicon Premium.",
  "id": "GHSA-vf99-3r9r-pp36",
  "modified": "2026-05-29T15:30:21Z",
  "published": "2022-05-24T16:46:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6819"
    },
    {
      "type": "WEB",
      "url": "https://www.schneider-electric.com/en/download/document/SEVD-2019-134-05"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/109004"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VGXX-5XJ5-Q97X

Vulnerability from github – Published: 2026-04-08 00:30 – Updated: 2026-05-12 15:31
VLAI
Details

Issue summary: Applications using RSASVE key encapsulation to establish a secret encryption key can send contents of an uninitialized memory buffer to a malicious peer.

Impact summary: The uninitialized buffer might contain sensitive data from the previous execution of the application process which leads to sensitive data leakage to an attacker.

RSA_public_encrypt() returns the number of bytes written on success and -1 on error. The affected code tests only whether the return value is non-zero. As a result, if RSA encryption fails, encapsulation can still return success to the caller, set the output lengths, and leave the caller to use the contents of the ciphertext buffer as if a valid KEM ciphertext had been produced.

If applications use EVP_PKEY_encapsulate() with RSA/RSASVE on an attacker-supplied invalid RSA public key without first validating that key, then this may cause stale or uninitialized contents of the caller-provided ciphertext buffer to be disclosed to the attacker in place of the KEM ciphertext.

As a workaround calling EVP_PKEY_public_check() or EVP_PKEY_public_check_quick() before EVP_PKEY_encapsulate() will mitigate the issue.

The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.1 and 3.0 are affected by this issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-31790"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-07T22:16:21Z",
    "severity": "HIGH"
  },
  "details": "Issue summary: Applications using RSASVE key encapsulation to establish\na secret encryption key can send contents of an uninitialized memory buffer to\na malicious peer.\n\nImpact summary: The uninitialized buffer might contain sensitive data from the\nprevious execution of the application process which leads to sensitive data\nleakage to an attacker.\n\nRSA_public_encrypt() returns the number of bytes written on success and -1\non error. The affected code tests only whether the return value is non-zero.\nAs a result, if RSA encryption fails, encapsulation can still return success to\nthe caller, set the output lengths, and leave the caller to use the contents of\nthe ciphertext buffer as if a valid KEM ciphertext had been produced.\n\nIf applications use EVP_PKEY_encapsulate() with RSA/RSASVE on an\nattacker-supplied invalid RSA public key without first validating that key,\nthen this may cause stale or uninitialized contents of the caller-provided\nciphertext buffer to be disclosed to the attacker in place of the KEM\nciphertext.\n\nAs a workaround calling EVP_PKEY_public_check() or\nEVP_PKEY_public_check_quick() before EVP_PKEY_encapsulate() will mitigate\nthe issue.\n\nThe FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.1 and 3.0 are affected by this issue.",
  "id": "GHSA-vgxx-5xj5-q97x",
  "modified": "2026-05-12T15:31:15Z",
  "published": "2026-04-08T00:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31790"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/001e01db3e996e13ffc72386fe79d03a6683b5ac"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/abd8b2eec7e3f3fda60ecfb68498b246b52af482"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/b922e24e5b23ffb9cb9e14cadff23d91e9f7e406"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/d5f8e71cd0a54e961d0c3b174348f8308486f790"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openssl/openssl/commit/eed200f58cd8645ed77e46b7e9f764e284df379e"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
    },
    {
      "type": "WEB",
      "url": "https://openssl-library.org/news/secadv/20260407.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VHF9-X75X-QGV5

Vulnerability from github – Published: 2026-07-10 00:31 – Updated: 2026-07-10 00:31
VLAI
Details

An Improper Check for Unusual or Exceptional Conditions vulnerability in the packet forwarding engine (pfe) of Juniper Networks Junos OS on QFX10000 Series allows an unauthenticated, adjacent attacker to cause a Denial-of-Service (DoS).

On all QFX10000 platforms in an EVPN-VxLAN scenario, if an attacker sends IPv6 multicast traffic and these packets reach the non-IRB interface of a spine switch it floods the packet to other spines and all Ethernet Segment Identifier (ESI) leaf switches. This flooding causes the packet to be forwarded in a endless loop, which can lead to saturation of the involved links and in turn impact to legitimate traffic.

This issue affects Junos OS on QFX10000 Series:

  • all versions before 23.2R2-S7,
  • 23.4 versions before 23.4R2-S8,
  • 24.2 versions before 24.2R2-S4,
  • 24.4 versions before 24.4R2-S4.

This issue does not affect Junos version after 24.4 as the QFX10000 Series devices are not supported on newer versions anymore.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-57020"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-09T22:17:06Z",
    "severity": "HIGH"
  },
  "details": "An Improper Check for Unusual or Exceptional Conditions vulnerability in the packet forwarding engine (pfe) of Juniper Networks Junos OS on QFX10000 Series allows an unauthenticated, adjacent attacker to cause a Denial-of-Service (DoS).\n\nOn all QFX10000 platforms in an EVPN-VxLAN scenario, if an attacker sends IPv6 multicast traffic and these packets reach the non-IRB interface of a spine switch it floods the packet to other spines and all Ethernet Segment Identifier (ESI)\u00a0leaf switches. This flooding causes the packet to be forwarded in a endless loop, which can lead to saturation of the involved links and in turn impact to legitimate traffic.\n\n\n\nThis issue affects Junos OS on QFX10000 Series:\n\n\n  *  all versions before 23.2R2-S7,\n  *  23.4 versions before 23.4R2-S8,\n  *  24.2 versions before 24.2R2-S4,\n  *  24.4 versions before 24.4R2-S4.\n\n\n\nThis issue does not affect Junos version after 24.4 as the QFX10000 Series devices are not supported on newer versions anymore.",
  "id": "GHSA-vhf9-x75x-qgv5",
  "modified": "2026-07-10T00:31:26Z",
  "published": "2026-07-10T00:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57020"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA110080"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:Y/R:U/V:X/RE:M/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VM59-55F6-4QP9

Vulnerability from github – Published: 2024-02-05 18:31 – Updated: 2024-02-05 18:31
VLAI
Details

Prior to v7.4.0, Ember ZNet is vulnerable to a denial of service attack through manipulation of the NWK sequence number

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-6874"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-312",
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-05T18:15:51Z",
    "severity": "HIGH"
  },
  "details": "Prior to v7.4.0, Ember ZNet is vulnerable to a denial of service attack through manipulation of the NWK sequence number",
  "id": "GHSA-vm59-55f6-4qp9",
  "modified": "2024-02-05T18:31:37Z",
  "published": "2024-02-05T18:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6874"
    },
    {
      "type": "WEB",
      "url": "https://community.silabs.com/069Vm000000WXaOIAW"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SiliconLabs/gecko_sdk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation MIT-3
Requirements

Strategy: Language Selection

  • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
Mitigation
Implementation

Check the results of all functions that return a value and verify that the value is expected.

Mitigation
Implementation

If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).

Mitigation MIT-39
Implementation
  • Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
  • If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
  • Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
  • Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-38
Architecture and Design Implementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.

Mitigation
Architecture and Design

Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.

No CAPEC attack patterns related to this CWE.