Common Weakness Enumeration

CWE-755

Discouraged

Improper Handling of Exceptional Conditions

Abstraction: Class · Status: Incomplete

The product does not handle or incorrectly handles an exceptional condition.

686 vulnerabilities reference this CWE, most recent first.

GHSA-3WP9-GVWQ-96MC

Vulnerability from github – Published: 2023-01-03 21:30 – Updated: 2023-01-10 03:30
VLAI
Details

In Wi-Fi driver, there is a possible undefined behavior due to incorrect error handling. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: GN20220705042; Issue ID: GN20220705042.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-32657"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-03T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Wi-Fi driver, there is a possible undefined behavior due to incorrect error handling. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: GN20220705042; Issue ID: GN20220705042.",
  "id": "GHSA-3wp9-gvwq-96mc",
  "modified": "2023-01-10T03:30:26Z",
  "published": "2023-01-03T21:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32657"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/January-2023"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3X4W-V43M-F5M7

Vulnerability from github – Published: 2024-10-11 18:32 – Updated: 2024-10-15 15:30
VLAI
Details

An Improper Handling of Exceptional Conditions vulnerability in the Packet Forwarding Engine (pfe) of the Juniper Networks Junos OS Evolved on ACX Series devices allows an unauthenticated, network based attacker sending specific transit protocol traffic to cause a partial Denial of Service (DoS) to downstream devices.

Receipt of specific transit protocol packets is incorrectly processed by the Routing Engine (RE), filling up the DDoS protection queue which is shared between routing protocols. This influx of transit protocol packets causes DDoS protection violations, resulting in protocol flaps which can affect connectivity to networking devices.

This issue affects both IPv4 and IPv6. This issue does not require any specific routing protocol to be configured or enabled.

The following commands can be used to monitor the DDoS protection queue:

labuser@re0> show evo-pfemand host pkt-stats

labuser@re0> show host-path ddos all-policers

This issue affects Junos OS Evolved: 

  • All versions before 21.4R3-S8-EVO, 
  • from 22.2 before 22.2R3-S4-EVO, 
  • from 22.3 before 22.3R3-S4-EVO, 
  • from 22.4 before 22.4R3-S3-EVO, 
  • from 23.2 before 23.2R2-EVO, 
  • from 23.4 before 23.4R1-S1-EVO, 23.4R2-EVO, 
  • from 24.2 before 24.2R2-EVO.
Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-47489"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-11T16:15:08Z",
    "severity": "MODERATE"
  },
  "details": "An Improper Handling of Exceptional Conditions vulnerability in the Packet Forwarding Engine (pfe) of the Juniper Networks Junos OS Evolved on ACX Series devices allows an unauthenticated, network based attacker sending specific transit protocol traffic to cause a partial Denial of Service (DoS) to downstream devices.\n\nReceipt of specific transit protocol packets is incorrectly processed by the Routing Engine (RE), filling up the DDoS protection queue which is shared between routing protocols.\u00a0This influx of transit protocol packets causes DDoS protection violations,\u00a0resulting in protocol flaps which can affect connectivity to networking devices.\n\nThis issue affects both IPv4 and IPv6. This issue does not require any specific routing protocol to be configured or enabled.\n\nThe following commands can be used to monitor the DDoS protection queue:\n\n\u00a0 \u00a0 \u00a0 \u00a0labuser@re0\u003e show evo-pfemand host pkt-stats\n\n\u2003\u2003\u00a0 labuser@re0\u003e show host-path ddos all-policers\n\nThis issue affects Junos OS Evolved:\u00a0\n\n\n\n  *  All versions before 21.4R3-S8-EVO,\u00a0\n  *  from 22.2 before 22.2R3-S4-EVO,\u00a0\n  *  from 22.3 before 22.3R3-S4-EVO,\u00a0\n  *  from 22.4 before 22.4R3-S3-EVO,\u00a0\n  *  from 23.2 before 23.2R2-EVO,\u00a0\n  *  from 23.4 before 23.4R1-S1-EVO, 23.4R2-EVO,\u00a0\n  *  from 24.2 before 24.2R2-EVO.",
  "id": "GHSA-3x4w-v43m-f5m7",
  "modified": "2024-10-15T15:30:49Z",
  "published": "2024-10-11T18:32:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47489"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/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:X/R:A/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-42XW-2XVC-QX8M

Vulnerability from github – Published: 2019-05-29 18:04 – Updated: 2021-07-27 20:36
VLAI
Summary
Denial of Service in axios
Details

Versions of axios prior to 0.18.1 are vulnerable to Denial of Service. If a request exceeds the maxContentLength property, the package prints an error but does not stop the request. This may cause high CPU usage and lead to Denial of Service.

Recommendation

Upgrade to 0.18.1 or later.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.18.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.18.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10742"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2019-05-14T15:22:47Z",
    "nvd_published_at": "2019-05-07T19:29:00Z",
    "severity": "HIGH"
  },
  "details": "Versions of `axios` prior to 0.18.1 are vulnerable to Denial of Service. If a request exceeds the `maxContentLength` property, the package prints an error but does not stop the request. This may cause high CPU usage and lead to Denial of Service.\n\n\n## Recommendation\n\nUpgrade to 0.18.1 or later.",
  "id": "GHSA-42xw-2xvc-qx8m",
  "modified": "2021-07-27T20:36:18Z",
  "published": "2019-05-29T18:04:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10742"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/issues/1098"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/pull/1485"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/acabfbdf00a58bb866c9d070e8a10d1d0dbeb572"
    },
    {
      "type": "WEB",
      "url": "https://app.snyk.io/vuln/SNYK-JS-AXIOS-174505"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-AXIOS-174505"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/880"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Denial of Service in axios"
}

GHSA-437M-6WFG-J372

Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-09-21 00:00
VLAI
Details

A privilege escalation vulnerability exists in the Duo Authentication for Windows Logon and RDP implementation. This vulnerability could allow an authenticated local attacker to overwrite files in privileged directories.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-3427"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-14T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "A privilege escalation vulnerability exists in the Duo Authentication for Windows Logon and RDP implementation. This vulnerability could allow an authenticated local attacker to overwrite files in privileged directories.",
  "id": "GHSA-437m-6wfg-j372",
  "modified": "2022-09-21T00:00:43Z",
  "published": "2022-05-24T17:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3427"
    },
    {
      "type": "WEB",
      "url": "https://duo.com/docs/rdp-notes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-43MV-M2VR-RQQC

Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2022-07-13 00:00
VLAI
Details

An attacker-controlled memory allocation size can be passed to the C++ new operator in RnaDaSvr.dll by sending a specially crafted ConfigureItems message to TCP port 4241. This will cause an unhandled exception, resulting in termination of RSLinxNG.exe. Observed in FactoryTalk 6.11. All versions of FactoryTalk Linx are affected.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-5802"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-29T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "An attacker-controlled memory allocation size can be passed to the C++ new operator in RnaDaSvr.dll by sending a specially crafted ConfigureItems message to TCP port 4241. This will cause an unhandled exception, resulting in termination of RSLinxNG.exe. Observed in FactoryTalk 6.11. All versions of FactoryTalk Linx are affected.",
  "id": "GHSA-43mv-m2vr-rqqc",
  "modified": "2022-07-13T00:00:51Z",
  "published": "2022-05-24T17:37:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5802"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2020-71"
    }
  ],
  "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-43WC-6Q3Q-Q349

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

D-Link G416 httpd Improper Handling of Exceptional Conditions Information Disclosure Vulnerability. This vulnerability allows network-adjacent attackers to disclose sensitive information on affected installations of D-Link G416 routers. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the HTTP service listening on TCP port 80. The issue results from the lack of proper handling of error conditions. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of root. Was ZDI-CAN-21664.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-50212"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-03T03:16:08Z",
    "severity": "MODERATE"
  },
  "details": "D-Link G416 httpd Improper Handling of Exceptional Conditions Information Disclosure Vulnerability. This vulnerability allows network-adjacent attackers to disclose sensitive information on affected installations of D-Link G416 routers. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the HTTP service listening on TCP port 80. The issue results from the lack of proper handling of error conditions. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of root. Was ZDI-CAN-21664.",
  "id": "GHSA-43wc-6q3q-q349",
  "modified": "2024-05-03T03:31:06Z",
  "published": "2024-05-03T03:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50212"
    },
    {
      "type": "WEB",
      "url": "https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10367"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-23-1828"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-444H-8MR2-WM66

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2026-06-02 21:30
VLAI
Details

A vulnerability has been identified in SIMATIC HMI Comfort Outdoor Panels 7\" & 15\" (incl. SIPLUS variants) (All versions < V16 Update 4), SIMATIC HMI Comfort Panels 4\" - 22\" (incl. SIPLUS variants) (All versions < V16 Update 4), SIMATIC HMI KTP Mobile Panels KTP400F, KTP700, KTP700F, KTP900 and KTP900F (All versions < V16 Update 4), SIMATIC WinCC Runtime Advanced (All versions < V16 Update 4). SmartVNC client fails to handle an exception properly if the program execution process is modified after sending a packet from the server, which could result in a Denial-of-Service condition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-25662"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-12T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SIMATIC HMI Comfort Outdoor Panels 7\\\" \u0026 15\\\" (incl. SIPLUS variants) (All versions \u003c V16 Update 4), SIMATIC HMI Comfort Panels 4\\\" - 22\\\" (incl. SIPLUS variants) (All versions \u003c V16 Update 4), SIMATIC HMI KTP Mobile Panels KTP400F, KTP700, KTP700F, KTP900 and KTP900F (All versions \u003c V16 Update 4), SIMATIC WinCC Runtime Advanced (All versions \u003c V16 Update 4). SmartVNC client fails to handle an exception properly if the program execution process is modified after sending a packet from the server, which could result in a Denial-of-Service condition.",
  "id": "GHSA-444h-8mr2-wm66",
  "modified": "2026-06-02T21:30:31Z",
  "published": "2022-05-24T19:02:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25662"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-538778.pdf"
    },
    {
      "type": "WEB",
      "url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-131-12"
    }
  ],
  "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-44QP-QHFV-C7F6

Vulnerability from github – Published: 2021-08-13 15:21 – Updated: 2022-02-08 21:20
VLAI
Summary
Improper Handling of Exceptional Conditions in Apache Tomcat
Details

A vulnerability in Apache Tomcat allows an attacker to remotely trigger a denial of service. An error introduced as part of a change to improve error handling during non-blocking I/O meant that the error flag associated with the Request object was not reset between requests. This meant that once a non-blocking I/O error occurred, all future requests handled by that request object would fail. Users were able to trigger non-blocking I/O errors, e.g. by dropping a connection, thereby creating the possibility of triggering a DoS. Applications that do not use non-blocking I/O are not exposed to this vulnerability. This issue affects Apache Tomcat 10.0.3 to 10.0.4; 9.0.44; 8.5.64.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.3"
            },
            {
              "fixed": "10.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.0.45"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.5.65"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-30639"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-07-13T20:59:46Z",
    "nvd_published_at": "2021-07-12T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in Apache Tomcat allows an attacker to remotely trigger a denial of service. An error introduced as part of a change to improve error handling during non-blocking I/O meant that the error flag associated with the Request object was not reset between requests. This meant that once a non-blocking I/O error occurred, all future requests handled by that request object would fail. Users were able to trigger non-blocking I/O errors, e.g. by dropping a connection, thereby creating the possibility of triggering a DoS. Applications that do not use non-blocking I/O are not exposed to this vulnerability. This issue affects Apache Tomcat 10.0.3 to 10.0.4; 9.0.44; 8.5.64.",
  "id": "GHSA-44qp-qhfv-c7f6",
  "modified": "2022-02-08T21:20:55Z",
  "published": "2021-08-13T15:21:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30639"
    },
    {
      "type": "WEB",
      "url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10366"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r79a7c019712b39aedf7cf4da9276d80610f04441b2a4f6506cb2daaf@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r79a7c019712b39aedf7cf4da9276d80610f04441b2a4f6506cb2daaf@%3Cusers.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd84fae1f474597bdf358f5bdc0a5c453c507bd527b83e8be6b5ea3f4%40%3Cannounce.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202208-34"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210827-0007"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    }
  ],
  "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": "Improper Handling of Exceptional Conditions in Apache Tomcat"
}

GHSA-47M2-4CR7-MHCW

Vulnerability from github – Published: 2025-10-10 17:03 – Updated: 2025-11-05 22:06
VLAI
Summary
quic-go: Panic occurs when queuing undecryptable packets after handshake completion
Details

Summary

A misbehaving or malicious server can trigger an assertion in a quic-go client (and crash the process) by sending a premature HANDSHAKE_DONE frame during the handshake.

Impact

A misbehaving or malicious server can cause a denial-of-service (DoS) attack on the quic-go client by triggering an assertion failure, leading to a process crash. This requires no authentication and can be exploited during the handshake phase. Observed in the wild with certain server implementations (e.g. Solana's Firedancer QUIC).

Affected Versions

  • All versions prior to v0.49.1 (for the 0.49 branch)
  • Versions v0.50.0 to v0.54.0 (inclusive)
  • Fixed in v0.49.1, v0.54.1, and v0.55.0 onward

Users are recommended to upgrade to the latest patched version in their respective maintenance branch or to v0.55.0 or later.

Details

For a regular 1-RTT handshake, QUIC uses three sets of keys to encrypt / decrypt QUIC packets:

  • Initial keys (derived from a static key and the connection ID)
  • Handshake keys (derived from the client's and server's key shares in the TLS handshake)
  • 1-RTT keys (derived when the TLS handshake finishes)

On the client side, Initial keys are discarded when the first Handshake packet is sent. Handshake keys are discarded when the server's HANDSHAKE_DONE frame is received, as specified in section 4.9.2 of RFC 9001. Crucially, Initial keys are always dropped before Handshake keys in a standard handshake.

Due to packet reordering, it is possible to receive a packet with a higher encryption level before the key for that encryption level has been derived. For example, the server's Handshake packets (containing, among others, the TLS certificate) might arrive before the server's Initial packet (which contains the TLS ServerHello). In that case, the client queues the Handshake packets and decrypts them as soon as it has processed the ServerHello and derived Handshake keys.

After completion of the handshake, Initial and Handshake packets are not needed anymore and will be dropped. quic-go implements an assertion that no packets are queued after completion of the handshake.

A misbehaving or malicious server can trigger this assertion, and thereby cause a panic, by sending a HANDSHAKE_DONE frame before actually completing the handshake. In that case, Handshake keys would be dropped before Initial keys.

This can only happen if the server implementation is misbehaving: the server can only complete the handshake after receiving the client's TLS Finished message (which is sent in Handshake packets).

The Fix

quic-go needs to be able to handle misbehaving server implementations, including those that prematurely send a HANDSHAKE_DONE frame. We now discard Initial keys when receiving a HANDSHAKE_DONE frame, thereby correctly handling premature HANDSHAKE_DONE frames. The fix was implemented in https://github.com/quic-go/quic-go/pull/5354.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/quic-go/quic-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.49.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/quic-go/quic-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.50.0"
            },
            {
              "fixed": "0.54.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59530"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-617",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-10T17:03:01Z",
    "nvd_published_at": "2025-10-10T16:15:52Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nA misbehaving or malicious server can trigger an assertion in a quic-go client (and crash the process) by sending a premature HANDSHAKE_DONE frame during the handshake.\n\n## Impact\n\nA misbehaving or malicious server can cause a denial-of-service (DoS) attack on the quic-go client by triggering an assertion failure, leading to a process crash. This requires no authentication and can be exploited during the handshake phase. Observed in the wild with certain server implementations (e.g. Solana\u0027s Firedancer QUIC).\n\n## Affected Versions\n\n- All versions prior to v0.49.1 (for the 0.49 branch)\n- Versions v0.50.0 to v0.54.0 (inclusive)\n- Fixed in v0.49.1, v0.54.1, and v0.55.0 onward\n\nUsers are recommended to upgrade to the latest patched version in their respective maintenance branch or to v0.55.0 or later.\n\n## Details\n\nFor a regular 1-RTT handshake, QUIC uses three sets of keys to encrypt / decrypt QUIC packets:\n\n- Initial keys (derived from a static key and the connection ID)\n- Handshake keys (derived from the client\u0027s and server\u0027s key shares in the TLS handshake)\n- 1-RTT keys (derived when the TLS handshake finishes)\n\nOn the client side, Initial keys are discarded when the first Handshake packet is sent. Handshake keys are discarded when the server\u0027s HANDSHAKE_DONE frame is received, as specified in section 4.9.2 of RFC 9001. Crucially, Initial keys are always dropped before Handshake keys in a standard handshake.\n\nDue to packet reordering, it is possible to receive a packet with a higher encryption level before the key for that encryption level has been derived. For example, the server\u0027s Handshake packets (containing, among others, the TLS certificate) might arrive before the server\u0027s Initial packet (which contains the TLS ServerHello). In that case, the client queues the Handshake packets and decrypts them as soon as it has processed the ServerHello and derived Handshake keys.\n\nAfter completion of the handshake, Initial and Handshake packets are not needed anymore and will be dropped. quic-go implements an [assertion](https://github.com/quic-go/quic-go/blob/v0.55.0/connection.go#L2682-L2685) that no packets are queued after completion of the handshake.\n\nA misbehaving or malicious server can trigger this assertion, and thereby cause a panic, by sending a HANDSHAKE_DONE frame before actually completing the handshake. In that case, Handshake keys would be dropped before Initial keys.\n\nThis can only happen if the server implementation is misbehaving: the server can only complete the handshake after receiving the client\u0027s TLS Finished message (which is sent in Handshake packets).\n\n## The Fix\n\nquic-go needs to be able to handle misbehaving server implementations, including those that prematurely send a HANDSHAKE_DONE frame. We now discard Initial keys when receiving a HANDSHAKE_DONE frame, thereby correctly handling premature HANDSHAKE_DONE frames. The fix was implemented in https://github.com/quic-go/quic-go/pull/5354.",
  "id": "GHSA-47m2-4cr7-mhcw",
  "modified": "2025-11-05T22:06:25Z",
  "published": "2025-10-10T17:03:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/security/advisories/GHSA-47m2-4cr7-mhcw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59530"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/pull/5354"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/commit/bc5bccf10fd02728eef150683eb4dfaa5c0e749c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/commit/ce7c9ea8834b9d2ed79efa9269467f02c0895d42"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/quic-go/quic-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/blob/v0.55.0/connection.go#L2682-L2685"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-4017"
    }
  ],
  "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": "quic-go: Panic occurs when queuing undecryptable packets after handshake completion"
}

GHSA-47WW-FF84-4JRG

Vulnerability from github – Published: 2025-03-12 19:28 – Updated: 2025-08-20 17:39
VLAI
Summary
Cosmos SDK: x/group can halt when erroring in EndBlocker
Details

Name: ISA-2025-002: x/group can halt when erroring in EndBlocker Component: CosmosSDK Criticality: High (Considerable Impact; Likely Likelihood per ACMv1.2) Affected versions: <= v0.47.16, <= 0.50.12 Affected users: Validators, Full nodes, Users on chains that utilize the groups module Cosmos SDK chains in unpatched releases that use the x/group module are affected.

Description

An issue was discovered in the groups module where malicious proposals would result in an errors triggered in the module's end blocker that could result in a chain halt. Any set of users that can interact with the groups module could introduce this state.

Patches

Has the problem been patched? What versions should users upgrade to?

The new Cosmos SDK release v0.50.13 and v0.47.17 fix this issue.

Testing

Testing we have done to gain more confidence in this release:

In addition to testing Cosmos SDK we also did the following:

  • Ran a patched node in a local v0.50 testnet with the failing state and did not halt (an unpatched network confirmed to halt)
  • Ran a patched node on Xion Mainnet (uses x/group)
  • Ran a patched node on Zetachain Mainnet (uses x/xgroup)

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

There are no known workarounds for this issue. It is advised that chains apply the update.

This issue was reported to the Cosmos Bug Bounty Program by wbowling on HackerOne on February 28, 2025. If you believe you have found a bug in the Interchain Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.

If you have questions about Interchain security efforts, please reach out to our official communication channel at security@interchain.io. For more information about the Interchain Foundation’s engagement with Amulet, and to sign up for security notification emails, please see https://github.com/interchainio/security.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.50.12"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cosmos/cosmos-sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.50.0-alpha.0"
            },
            {
              "fixed": "0.50.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.47.16"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cosmos/cosmos-sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.47.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-12T19:28:42Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Name: ISA-2025-002: x/group can halt when erroring in EndBlocker\nComponent: CosmosSDK\nCriticality: High (Considerable Impact; Likely Likelihood per [ACMv1.2](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md))\nAffected versions: \u003c= v0.47.16, \u003c= 0.50.12\nAffected users: Validators, Full nodes, Users on chains that utilize the groups module\nCosmos SDK chains in unpatched releases that use the `x/group` module are affected.\n\n### Description\n\nAn issue was discovered in the groups module where malicious proposals would result in an errors triggered in the module\u0027s end blocker that could result in a chain halt.  Any set of users that can interact with the groups module could introduce this state.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nThe new Cosmos SDK release [v0.50.13](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.13) and [v0.47.17](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.47.17) fix this issue.\n\n### Testing\n\nTesting we have done to gain more confidence in this release:\n\nIn addition to testing Cosmos SDK we also did the following:\n\n- Ran a patched node in a local `v0.50` testnet with the failing state and did not halt (an unpatched network confirmed to halt)\n- Ran a patched node on Xion Mainnet (uses `x/group`)\n- Ran a patched node on Zetachain Mainnet (uses `x/xgroup`)\n    \n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nThere are no known workarounds for this issue. It is advised that chains apply the update.\n\nThis issue was reported to the Cosmos Bug Bounty Program by [wbowling](https://github.com/wbowling) on HackerOne on February 28, 2025. If you believe you have found a bug in the Interchain Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.\n\nIf you have questions about Interchain security efforts, please reach out to our official communication channel at [security@interchain.io](mailto:security@interchain.io). For more information about the Interchain Foundation\u2019s engagement with Amulet, and to sign up for security notification emails, please see https://github.com/interchainio/security.",
  "id": "GHSA-47ww-ff84-4jrg",
  "modified": "2025-08-20T17:39:56Z",
  "published": "2025-03-12T19:28:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-47ww-ff84-4jrg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cosmos/cosmos-sdk/commit/cbd69fb1f4fac418c1f8c6253f5f91fb1263776a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cosmos/cosmos-sdk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Cosmos SDK: x/group can halt when erroring in EndBlocker"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.