Common Weakness Enumeration

CWE-248

Allowed

Uncaught Exception

Abstraction: Base · Status: Draft

An exception is thrown from a function, but it is not caught.

420 vulnerabilities reference this CWE, most recent first.

GHSA-3MFM-PFV2-VMRP

Vulnerability from github – Published: 2022-10-01 00:00 – Updated: 2022-10-06 00:00
VLAI
Details

A vulnerability in the processing of malformed Common Industrial Protocol (CIP) packets that are sent to Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause an affected device to unexpectedly reload, resulting in a denial of service (DoS) condition. This vulnerability is due to insufficient input validation during processing of CIP packets. An attacker could exploit this vulnerability by sending a malformed CIP packet to an affected device. A successful exploit could allow the attacker to cause the affected device to unexpectedly reload, resulting in a DoS condition.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-20919"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-248",
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-30T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the processing of malformed Common Industrial Protocol (CIP) packets that are sent to Cisco IOS Software and Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause an affected device to unexpectedly reload, resulting in a denial of service (DoS) condition. This vulnerability is due to insufficient input validation during processing of CIP packets. An attacker could exploit this vulnerability by sending a malformed CIP packet to an affected device. A successful exploit could allow the attacker to cause the affected device to unexpectedly reload, resulting in a DoS condition.",
  "id": "GHSA-3mfm-pfv2-vmrp",
  "modified": "2022-10-06T00:00:55Z",
  "published": "2022-10-01T00:00:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20919"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-cip-dos-9rTbKLt9"
    }
  ],
  "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-3Q6M-V84F-6P9H

Vulnerability from github – Published: 2023-10-30 15:08 – Updated: 2023-11-01 06:07
VLAI
Summary
quic-go vulnerable to pointer dereference that can lead to panic
Details

quic-go is an implementation of the QUIC transport protocol in Go. By serializing an ACK frame after the CRYTPO that allows a node to complete the handshake, a remote node could trigger a nil pointer dereference (leading to a panic) when the node attempted to drop the Handshake packet number space.

Impact

An attacker can bring down a quic-go node with very minimal effort. Completing the QUIC handshake only requires sending and receiving a few packets.

Patches

v0.37.3 contains a patch. Versions before v0.37.0 are not affected.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/quic-go/quic-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.37.0"
            },
            {
              "fixed": "0.37.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-46239"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-30T15:08:05Z",
    "nvd_published_at": "2023-10-31T16:15:09Z",
    "severity": "HIGH"
  },
  "details": "quic-go is an implementation of the [QUIC](https://datatracker.ietf.org/doc/html/rfc9000) transport protocol in Go. By serializing an ACK frame after the CRYTPO that allows a node to complete the handshake, a remote node could trigger a nil pointer dereference (leading to a panic) when the node attempted to drop the Handshake packet number space.\n\n**Impact**\n\nAn attacker can bring down a quic-go node with very minimal effort. Completing the QUIC handshake only requires sending and receiving a few packets.\n\n**Patches**\n\n[v0.37.3](https://github.com/quic-go/quic-go/releases/tag/v0.37.3) contains a patch. Versions before v0.37.0 are not affected.",
  "id": "GHSA-3q6m-v84f-6p9h",
  "modified": "2023-11-01T06:07:08Z",
  "published": "2023-10-30T15:08:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/security/advisories/GHSA-3q6m-v84f-6p9h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46239"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/commit/b6a4725b60f1fe04e8f1ddcc3114e290fcea1617"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/quic-go/quic-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/quic-go/quic-go/releases/tag/v0.37.3"
    }
  ],
  "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 vulnerable to pointer dereference that can lead to panic"
}

GHSA-3QHF-M339-9G5V

Vulnerability from github – Published: 2025-07-04 22:06 – Updated: 2026-07-16 18:30
VLAI
Summary
MCP Python SDK vulnerability in the FastMCP Server causes validation error, leading to DoS
Details

A validation error in the MCP SDK can cause an unhandled exception when processing malformed requests, resulting in service unavailability (500 errors) until manually restarted. Impact may vary depending on the deployment conditions, and presence of infrastructure-level resilience measures.

Thank you to Rich Harang for reporting this issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53366"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-04T22:06:49Z",
    "nvd_published_at": "2025-07-04T22:15:22Z",
    "severity": "HIGH"
  },
  "details": "A validation error in the MCP SDK can cause an unhandled exception when processing malformed requests, resulting in service unavailability (500 errors) until manually restarted. Impact may vary depending on the deployment conditions, and presence of infrastructure-level resilience measures.\n\nThank you to Rich Harang for reporting this issue.",
  "id": "GHSA-3qhf-m339-9g5v",
  "modified": "2026-07-16T18:30:56Z",
  "published": "2025-07-04T22:06:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-3qhf-m339-9g5v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53366"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/pull/822"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/commit/29c69e6a47d0104d0afcea6ac35e7ab02fde809a"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-3qhf-m339-9g5v"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/python-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.9.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/mcp/PYSEC-2026-1616.yaml"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/mcp"
    }
  ],
  "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": "MCP Python SDK vulnerability in the FastMCP Server causes validation error, leading to DoS"
}

GHSA-3XCM-H7JG-4XM5

Vulnerability from github – Published: 2024-02-17 00:31 – Updated: 2024-02-17 00:31
VLAI
Details

StorageGRID (formerly StorageGRID Webscale) versions prior to 11.8 are susceptible to a Denial of Service (DoS) vulnerability. Successful exploit by an authenticated attacker could lead to an out of memory condition or node reboot.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21983"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-16T23:15:07Z",
    "severity": "MODERATE"
  },
  "details": "StorageGRID (formerly StorageGRID Webscale) versions prior to 11.8 \nare susceptible to a Denial of Service (DoS) vulnerability. Successful \nexploit by an authenticated attacker could lead to an out of memory \ncondition or node reboot.\n\n",
  "id": "GHSA-3xcm-h7jg-4xm5",
  "modified": "2024-02-17T00:31:38Z",
  "published": "2024-02-17T00:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21983"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240216-0012"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-42WG-38GX-85RH

Vulnerability from github – Published: 2026-02-26 15:23 – Updated: 2026-02-26 15:23
VLAI
Summary
Vikunja has Path Traversal in CLI Restore
Details

Summary

Path Traversal (Zip Slip) and Denial of Service (DoS) vulnerability discovered in the Vikunja CLI's restore functionality.

Details

The restoreConfig function in vikunja/pkg/modules/dump/restore.go of the https://github.com/go-vikunja/vikunja/tree/main repository fails to sanitize file paths within the provided ZIP archive. A maliciously crafted ZIP can bypass the intended extraction directory to overwrite arbitrary files on the host system. Additionally, we’ve discovered that a malformed archive triggers a runtime panic, crashing the process immediately after the database has been wiped permanently.

The application trusts the metadata in the ZIP archive. It uses the Name attribute of the zip.File struct directly in os.OpenFile calls without validation, allowing files to be written outside the intended directory.

The restoration logic assumes a specific directory structure within the ZIP. When provided with a "minimalist" malicious ZIP, the application fails to validate the length of slices derived from the archive contents. Specifically, at line 154, the code attempts to access an index of len(ms)-2 on an insufficiently populated slice, triggering a panic.

PoC

When provided with a ZIP containing a traversal path (e.g., ../../../pwned.txt) and a missing migration structure, the application wipes the existing database and then panics due to unsafe index manipulation at line 154 of restore.go.

Reproduction Steps: 1. Preparation: Generate vikunja_critical_poc.zip. 2. Execution: Run echo "Yes, I understand" | vikunja restore vikunja_critical_poc.zip. 3. Observation: a. The application logs INFO: Wiped database. b. The application immediately follows with: panic: runtime error: index out of range [-2]. 4. The database is effectively deleted (Wiped), and the restoration process fails to complete, leaving the application in a non-functional state with total data loss for that instance.

Reproduction Python Script:

import zipfile

VIKUNJA_VERSION = "v1.1.0" 
ZIP_NAME = "vikunja_critical_poc.zip"

def create_poc():
    with zipfile.ZipFile(ZIP_NAME, 'w') as zipf:
        # Mandatory version file to pass initial check
        zipf.writestr('VERSION', VIKUNJA_VERSION)

        # Malicious traversal path
        # This triggers the traversal logic and the index panic simultaneously
        zipf.writestr('../../../pwned.txt', "Vulnerability Confirmed.")
    print(f"[+] {ZIP_NAME} created.")

if __name__ == "__main__":
    create_poc()

Stack Trace: time=2026-02-21T23:07:22.707Z level=INFO msg="Wiped database." panic: runtime error: index out of range [-2] goroutine 1 [running]: code.vikunja.io/api/pkg/modules/dump.Restore(...) /go/src/code.vikunja.io/api/pkg/modules/dump/restore.go:154 +0x1085

Remediation: Sanitize Paths: Use filepath.Base() to strip all directory information from ZIP entries before processing. Implement Bounds Checking: Ensure slices have sufficient length before performing index arithmetic.

Proposed Fix for restore.go:

// 1. Sanitize the filename
filename := filepath.Base(configFile.Name)
dstPath := filepath.Join(extractionDir, filename)

// ...

// 2. Prevent Index Out of Range Panic (Line 154)
if len(ms) < 2 {
    return fmt.Errorf("invalid migration sequence in backup archive")
}
lastMigration := ms[len(ms)-2]

Impact

Vulnerability Type: CWE-22 (Path Traversal) / CWE-248 (Uncaught Exception) Affected Component: pkg/modules/dump/restore.go Impact: Arbitrary File Write and Permanent Data Loss Status: Vikunja has not found an existing CVE for these issues; they appear to be undisclosed Zero-Days. Source File: pkg/modules/dump/restore.go Functions: Restore, restoreConfig Line Number: 154 (v1.1.0) Command: vikunja restore

Affected Party: Any administrator or automated process utilizing the vikunja restore CLI command. 1. Specifically, instances where a user may be socially engineered into restoring a backup from an untrusted source are at high risk. 2. Additionally, because the database is wiped before archive validation, even a failed exploitation attempt results in a complete loss of application data for that instance, impacting all end-users of the affected Vikunja installation.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.24.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-26T15:23:30Z",
    "nvd_published_at": "2026-02-25T22:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nPath Traversal (Zip Slip) and Denial of Service (DoS) vulnerability discovered in the Vikunja CLI\u0027s restore functionality.\n\n### Details\n\nThe restoreConfig function in vikunja/pkg/modules/dump/restore.go of the https://github.com/go-vikunja/vikunja/tree/main repository fails to sanitize file paths within the provided ZIP archive. A maliciously crafted ZIP can bypass the intended extraction directory to overwrite arbitrary files on the host system. Additionally, we\u2019ve discovered that a malformed archive triggers a runtime panic, crashing the process immediately after the database has been wiped permanently.\n\nThe application trusts the metadata in the ZIP archive. It uses the Name attribute of the zip.File struct directly in os.OpenFile calls without validation, allowing files to be written outside the intended directory.\n\nThe restoration logic assumes a specific directory structure within the ZIP. When provided with a \"minimalist\" malicious ZIP, the application fails to validate the length of slices derived from the archive contents. Specifically, at line 154, the code attempts to access an index of len(ms)-2 on an insufficiently populated slice, triggering a panic.\n\n### PoC\n\nWhen provided with a ZIP containing a traversal path (e.g., ../../../pwned.txt) and a missing migration structure, the application wipes the existing database and then panics due to unsafe index manipulation at line 154 of restore.go.\n\nReproduction Steps:\n1. Preparation: Generate vikunja_critical_poc.zip.\n2. Execution: Run echo \"Yes, I understand\" | vikunja restore vikunja_critical_poc.zip.\n3. Observation:\na. The application logs INFO: Wiped database.\nb. The application immediately follows with: panic: runtime error: index out of range [-2].\n4. The database is effectively deleted (Wiped), and the restoration process fails to complete, leaving the application in a non-functional state with total data loss for that instance.\n\nReproduction Python Script:\n\n    import zipfile\n\n    VIKUNJA_VERSION = \"v1.1.0\" \n    ZIP_NAME = \"vikunja_critical_poc.zip\"\n\n    def create_poc():\n        with zipfile.ZipFile(ZIP_NAME, \u0027w\u0027) as zipf:\n            # Mandatory version file to pass initial check\n            zipf.writestr(\u0027VERSION\u0027, VIKUNJA_VERSION)\n\n            # Malicious traversal path\n            # This triggers the traversal logic and the index panic simultaneously\n            zipf.writestr(\u0027../../../pwned.txt\u0027, \"Vulnerability Confirmed.\")\n        print(f\"[+] {ZIP_NAME} created.\")\n\n    if __name__ == \"__main__\":\n        create_poc()\n\n\nStack Trace:\ntime=2026-02-21T23:07:22.707Z level=INFO msg=\"Wiped database.\" panic: runtime error: index out of range [-2] goroutine 1 [running]: code.vikunja.io/api/pkg/modules/dump.Restore(...) /go/src/code.vikunja.io/api/pkg/modules/dump/restore.go:154 +0x1085\n\n\nRemediation:\nSanitize Paths: Use filepath.Base() to strip all directory information from ZIP entries before processing.\nImplement Bounds Checking: Ensure slices have sufficient length before performing index arithmetic.\n\nProposed Fix for restore.go:\n\n    // 1. Sanitize the filename\n    filename := filepath.Base(configFile.Name)\n    dstPath := filepath.Join(extractionDir, filename)\n\n    // ...\n\n    // 2. Prevent Index Out of Range Panic (Line 154)\n    if len(ms) \u003c 2 {\n        return fmt.Errorf(\"invalid migration sequence in backup archive\")\n    }\n    lastMigration := ms[len(ms)-2]\n\n### Impact\n\nVulnerability Type: CWE-22 (Path Traversal) / CWE-248 (Uncaught Exception)\nAffected Component: pkg/modules/dump/restore.go\nImpact: Arbitrary File Write and Permanent Data Loss\nStatus: Vikunja has not found an existing CVE for these issues; they appear to be undisclosed Zero-Days.\nSource File: pkg/modules/dump/restore.go\nFunctions: Restore, restoreConfig\nLine Number: 154 (v1.1.0)\nCommand: vikunja restore \u003cpath_to_zip\u003e\n\nAffected Party: Any administrator or automated process utilizing the vikunja restore CLI command.\n1. Specifically, instances where a user may be socially engineered into restoring a backup from an untrusted source are at high risk.\n2. Additionally, because the database is wiped before archive validation, even a failed exploitation attempt results in a complete loss of application data for that instance, impacting all end-users of the affected Vikunja installation.",
  "id": "GHSA-42wg-38gx-85rh",
  "modified": "2026-02-26T15:23:30Z",
  "published": "2026-02-26T15:23:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-42wg-38gx-85rh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27819"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/1b3d8dc59cb5f2b759ab0ad2bc9915b993e3cb73"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://vikunja.io/changelog/vikunja-v2.0.0-was-released"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikunja has Path Traversal in CLI Restore"
}

GHSA-4CCP-5QCJ-7F48

Vulnerability from github – Published: 2026-05-29 15:30 – Updated: 2026-05-29 15:30
VLAI
Details

An unhandled exception in Suprema BioStar 2 (Server), versions 2.9.8, 2.9.10, and 2.9.11, that allows an unauthenticated remote attacker to cause a denial of service (DoS) by sending HTTP POST requests to the ‘/api/migration’ endpoint. This request triggers a failure that halts critical processes, leaving the system offline until the services or server are manually restarted. As a result, access control readers cease to function, and potential failures may occur in third-party integrations. Since the exploit requires no privileges or user interaction and is trivial to automate, the impact on availability is high, and the effect extends to interconnected systems.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-9509"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-29T13:16:24Z",
    "severity": "HIGH"
  },
  "details": "An unhandled exception in Suprema BioStar 2 (Server), versions 2.9.8, 2.9.10, and 2.9.11, that allows an unauthenticated remote attacker to cause a denial of service (DoS) by sending HTTP POST requests to the \u2018/api/migration\u2019 endpoint. This request triggers a failure that halts critical processes, leaving the system offline until the services or server are manually restarted. As a result, access control readers cease to function, and potential failures may occur in third-party integrations. Since the exploit requires no privileges or user interaction and is trivial to automate, the impact on availability is high, and the effect extends to interconnected systems.",
  "id": "GHSA-4ccp-5qcj-7f48",
  "modified": "2026-05-29T15:30:33Z",
  "published": "2026-05-29T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9509"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-supremas-biostar"
    }
  ],
  "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/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:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-4HGP-59H5-GVRJ

Vulnerability from github – Published: 2026-07-07 23:39 – Updated: 2026-07-07 23:39
VLAI
Summary
ratex-parser panics on `\verb` with a multibyte delimiter (UTF-8 byte-boundary slice)
Details

Summary

The public parser entrypoint ratex_parser::parse(&str) panics on the 9-byte input \verbéxé (i.e. \verb followed by the non-ASCII delimiter é). When handling a \verb command, the parser slices the verbatim argument with byte indices (arg[1..arg.len() - 1]); if the delimiter character is multibyte UTF-8, index 1 lands inside that character and Rust panics with “byte index 1 is not a char boundary”. Because RaTeX’s release profile sets panic = "abort" (Cargo.toml:48), the panic aborts the entire process — not just the current request/thread — making this a hard denial of service for any service that renders untrusted LaTeX.

Details

Affected code

crates/ratex-parser/src/parser.rs, parse_symbol_inner:

if let Some(stripped) = text.strip_prefix("\\verb") {       // parser.rs:901
    self.consume();
    let arg = stripped.to_string();                         // e.g. "éxé"
    let star = arg.starts_with('*');
    let arg = if star { &arg[1..] } else { &arg };          // parser.rs:905  (also byte-sliced)
    if arg.len() < 2 {                                      // byte length
        return Err(ParseError::new("\\verb assertion failed", Some(&nucleus)));
    }
    let body = arg[1..arg.len() - 1].to_string();           // parser.rs:910  <-- PANIC on multibyte delimiter
    ...
}

For input \verbéxé: arg = "éxé", where é = U+00E9 (bytes C3 A9). arg.len() is the byte length (5), the < 2 guard passes, and arg[1..4] starts at byte index 1 — inside the first é (bytes 0..2) — so the slice panics. The lexer groups \verb<delim>…<delim> correctly with char semantics (lexer.rs lex_verb); only the parser mishandles it.

PoC

image

$ printf '\\verb\xc3\xa9x\xc3\xa9\n' | ./target/release/parse
thread 'main' panicked at crates/ratex-parser/src/parser.rs:910:27:
start byte index 1 is not a char boundary; it is inside 'é' (bytes 0..2 of string)
Aborted (core dumped)            # exit 134 — panic=abort kills the whole process

Impact

Any application that renders untrusted LaTeX through RaTeX (web “render this math” endpoint, WASM in-browser use, the FFI embedded in another app) can be crashed by a tiny string. With panic = "abort" in release builds, the crash takes down the whole process / server, so a single malicious formula causes a full-service DoS (and, in batch pipelines, drops all queued work).

Remediation

Slice by character boundaries instead of byte indices, mirroring the UTF-8-correct logic the lexer already uses. For example:

let chars: Vec<char> = arg.chars().collect();
if chars.len() < 2 { return Err(ParseError::new("\\verb assertion failed", Some(&nucleus))); }
let body: String = chars[1..chars.len() - 1].iter().collect();

(Apply the same char-aware handling to the * strip at parser.rs:905.) More broadly, consider not using panic = "abort" for builds embedded in long-running services, and/or wrapping parsing in catch_unwind at the FFI/WASM boundary — but the byte-slice fix is the direct correction.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "ratex-parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53530"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1285",
      "CWE-248",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-07T23:39:12Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe public parser entrypoint `ratex_parser::parse(\u0026str)` panics on the **9-byte** input `\\verb\u00e9x\u00e9` (i.e. `\\verb` followed by the non-ASCII delimiter `\u00e9`). When handling a `\\verb` command, the parser slices the verbatim argument with **byte** indices (`arg[1..arg.len() - 1]`); if the delimiter character is multibyte UTF-8, index `1` lands inside that character and Rust panics with *\u201cbyte index 1 is not a char boundary\u201d*. Because RaTeX\u2019s release profile sets `panic = \"abort\"` (`Cargo.toml:48`), the panic aborts the **entire process** \u2014 not just the current request/thread \u2014 making this a hard denial of service for any service that renders untrusted LaTeX.\n\n\n\n### Details\n\n\n## Affected code\n\n`crates/ratex-parser/src/parser.rs`, `parse_symbol_inner`:\n\n```rust\nif let Some(stripped) = text.strip_prefix(\"\\\\verb\") {       // parser.rs:901\n    self.consume();\n    let arg = stripped.to_string();                         // e.g. \"\u00e9x\u00e9\"\n    let star = arg.starts_with(\u0027*\u0027);\n    let arg = if star { \u0026arg[1..] } else { \u0026arg };          // parser.rs:905  (also byte-sliced)\n    if arg.len() \u003c 2 {                                      // byte length\n        return Err(ParseError::new(\"\\\\verb assertion failed\", Some(\u0026nucleus)));\n    }\n    let body = arg[1..arg.len() - 1].to_string();           // parser.rs:910  \u003c-- PANIC on multibyte delimiter\n    ...\n}\n```\n\nFor input `\\verb\u00e9x\u00e9`: `arg = \"\u00e9x\u00e9\"`, where `\u00e9` = `U+00E9` (bytes `C3 A9`). `arg.len()` is the **byte** length (5), the `\u003c 2` guard passes, and `arg[1..4]` starts at byte index 1 \u2014 inside the first `\u00e9` (bytes 0..2) \u2014 so the slice panics. The lexer groups `\\verb\u003cdelim\u003e\u2026\u003cdelim\u003e` correctly with char semantics (`lexer.rs` `lex_verb`); only the parser mishandles it.\n\n### PoC\n\n\u003cimg width=\"1109\" height=\"205\" alt=\"image\" src=\"https://github.com/user-attachments/assets/cd4bc6ae-23dd-458f-826c-6ce4e85c7005\" /\u003e\n\n\n```\n$ printf \u0027\\\\verb\\xc3\\xa9x\\xc3\\xa9\\n\u0027 | ./target/release/parse\nthread \u0027main\u0027 panicked at crates/ratex-parser/src/parser.rs:910:27:\nstart byte index 1 is not a char boundary; it is inside \u0027\u00e9\u0027 (bytes 0..2 of string)\nAborted (core dumped)            # exit 134 \u2014 panic=abort kills the whole process\n```\n\n### Impact\n\nAny application that renders untrusted LaTeX through RaTeX (web \u201crender this math\u201d endpoint, WASM in-browser use, the FFI embedded in another app) can be crashed by a tiny string. With `panic = \"abort\"` in release builds, the crash takes down the whole process / server, so a single malicious formula causes a full-service DoS (and, in batch pipelines, drops all queued work).\n\n## Remediation\n\nSlice by character boundaries instead of byte indices, mirroring the UTF-8-correct logic the lexer already uses. For example:\n\n```rust\nlet chars: Vec\u003cchar\u003e = arg.chars().collect();\nif chars.len() \u003c 2 { return Err(ParseError::new(\"\\\\verb assertion failed\", Some(\u0026nucleus))); }\nlet body: String = chars[1..chars.len() - 1].iter().collect();\n```\n\n(Apply the same char-aware handling to the `*` strip at `parser.rs:905`.) More broadly, consider not using `panic = \"abort\"` for builds embedded in long-running services, and/or wrapping parsing in `catch_unwind` at the FFI/WASM boundary \u2014 but the byte-slice fix is the direct correction.",
  "id": "GHSA-4hgp-59h5-gvrj",
  "modified": "2026-07-07T23:39:12Z",
  "published": "2026-07-07T23:39:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/erweixin/RaTeX/security/advisories/GHSA-4hgp-59h5-gvrj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/erweixin/RaTeX"
    }
  ],
  "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": "ratex-parser panics on `\\verb` with a multibyte delimiter (UTF-8 byte-boundary slice)"
}

GHSA-4PCG-WR6C-H9CQ

Vulnerability from github – Published: 2022-11-07 21:13 – Updated: 2022-11-07 21:13
VLAI
Summary
fastify/websocket vulnerable to uncaught exception via crash on malformed packet
Details

Impact

Any application using @fastify/websocket could crash if a specific, malformed packet is sent.

All versions of fastify-websocket are also impacted. That module is deprecated, so it will not be patched.

Patches

This has been patched in v7.1.1 (fastify v4) and v5.0.1 (fastify v3).

Workarounds

No known workaround is available. However, it should be possible to attach the error handler manually. The recommended path is upgrading to the patched versions.

Credits

marcolanaro for finding and patching this vulnerability

For more information

If you have any questions or comments about this advisory: * Open an issue in @fastify/websocket * Email us at hello@matteocollina.com

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fastify/websocket"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@fastify/websocket"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "7.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "fastify-websocket"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "4.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-39386"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-07T21:13:57Z",
    "nvd_published_at": "2022-11-08T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAny application using @fastify/websocket could crash if a specific, malformed packet is sent. \n\nAll versions of fastify-websocket are also impacted. That module is deprecated, so it will not be patched.\n\n### Patches\n\nThis has been patched in v7.1.1 (fastify v4) and v5.0.1 (fastify v3).\n\n### Workarounds\n\nNo known workaround is available. However, it should be possible to attach the error handler manually.\nThe recommended path is upgrading to the patched versions.\n\n## Credits\n\n[marcolanaro](https://github.com/marcolanaro) for finding and patching this vulnerability\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [@fastify/websocket](https://github.com/fastify/fastify-websocket)\n* Email us at [hello@matteocollina.com](mailto:hello@matteocollina.com)\n",
  "id": "GHSA-4pcg-wr6c-h9cq",
  "modified": "2022-11-07T21:13:57Z",
  "published": "2022-11-07T21:13:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-websocket/security/advisories/GHSA-4pcg-wr6c-h9cq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39386"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-websocket/pull/228"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-websocket/commit/7e8c41a51c101c3d5ce88caee4f71d9c29eb2863"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-websocket/commit/c24adeb3efd57a18b2f287c35d029e88b5a47194"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fastify/fastify-websocket"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-websocket/releases/tag/v5.0.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify-websocket/releases/tag/v7.1.1"
    }
  ],
  "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": "fastify/websocket vulnerable to uncaught exception via crash on malformed packet"
}

GHSA-4PG4-QVPC-4Q3H

Vulnerability from github – Published: 2025-05-19 22:16 – Updated: 2025-05-19 22:16
VLAI
Summary
Multer vulnerable to Denial of Service from maliciously crafted requests
Details

Impact

A vulnerability in Multer versions >=1.4.4-lts.1 allows an attacker to trigger a Denial of Service (DoS) by sending a malformed multi-part upload request. This request causes an unhandled exception, leading to a crash of the process.

Patches

Users should upgrade to 2.0.0

Workarounds

None

References

  • https://github.com/expressjs/multer/issues/1176
  • https://github.com/expressjs/multer/commit/2c8505f207d923dd8de13a9f93a4563e59933665
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "multer"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.4-lts.1"
            },
            {
              "fixed": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-47944"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-19T22:16:30Z",
    "nvd_published_at": "2025-05-19T20:15:26Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nA vulnerability in Multer versions \u003e=1.4.4-lts.1 allows an attacker to trigger a Denial of Service (DoS) by sending a malformed multi-part upload request. This request causes an unhandled exception, leading to a crash of the process.\n\n### Patches\nUsers should upgrade to `2.0.0`\n\n### Workarounds\nNone\n\n### References\n\n- https://github.com/expressjs/multer/issues/1176\n- https://github.com/expressjs/multer/commit/2c8505f207d923dd8de13a9f93a4563e59933665",
  "id": "GHSA-4pg4-qvpc-4q3h",
  "modified": "2025-05-19T22:16:30Z",
  "published": "2025-05-19T22:16:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/expressjs/multer/security/advisories/GHSA-4pg4-qvpc-4q3h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47944"
    },
    {
      "type": "WEB",
      "url": "https://github.com/expressjs/multer/issues/1176"
    },
    {
      "type": "WEB",
      "url": "https://github.com/expressjs/multer/commit/2c8505f207d923dd8de13a9f93a4563e59933665"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/expressjs/multer"
    }
  ],
  "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": "Multer vulnerable to Denial of Service from maliciously crafted requests"
}

GHSA-4RQ4-8R9H-8884

Vulnerability from github – Published: 2023-01-17 18:30 – Updated: 2023-01-25 00:30
VLAI
Details

NLnet Labs Krill supports direct access to the RRDP repository content through its built-in web server at the "/rrdp" endpoint. Prior to 0.12.1 a direct query for any existing directory under "/rrdp/", rather than an RRDP file such as "/rrdp/notification.xml" as would be expected, causes Krill to crash. If the built-in "/rrdp" endpoint is exposed directly to the internet, then malicious remote parties can cause the publication server to crash. The repository content is not affected by this, but the availability of the server and repository can cause issues if this attack is persistent and is not mitigated.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-0158"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-17T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "NLnet Labs Krill supports direct access to the RRDP repository content through its built-in web server at the \"/rrdp\" endpoint. Prior to 0.12.1 a direct query for any existing directory under \"/rrdp/\", rather than an RRDP file such as \"/rrdp/notification.xml\" as would be expected, causes Krill to crash. If the built-in \"/rrdp\" endpoint is exposed directly to the internet, then malicious remote parties can cause the publication server to crash. The repository content is not affected by this, but the availability of the server and repository can cause issues if this attack is persistent and is not mitigated.",
  "id": "GHSA-4rq4-8r9h-8884",
  "modified": "2023-01-25T00:30:39Z",
  "published": "2023-01-17T18:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0158"
    },
    {
      "type": "WEB",
      "url": "https://www.nlnetlabs.nl/downloads/krill/CVE-2023-0158.txt"
    }
  ],
  "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"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.