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.

909 vulnerabilities reference this CWE, most recent first.

GHSA-9C4H-PWMF-M6FJ

Vulnerability from github – Published: 2026-03-10 01:19 – Updated: 2026-03-10 18:40
VLAI
Summary
RSSN has Arbitrary Code Execution via Unvalidated JIT Instruction Generation in C-FFI Interface
Details

Impact

Vulnerability Type: Improper Control of Generation of Code ('Code Injection') (CWE-94) / Improper Check for Unusual or Exceptional Conditions (CWE-754) / Improper Input Validation (CWE-20) / Use of Low-Level Functionality (CWE-695) / Improper Privilege Management (CWE-269) / External Control of System or Configuration Setting (CWE-15).

Technical Details: The vulnerability exists in the JIT (Just-In-Time) compilation engine, which is fully exposed via the CFFI (Foreign Function Interface). Due to Improper Input Validation and External Control of Code Generation, an attacker can supply malicious parameters or instruction sequences through the CFFI layer. Since the library often operates with elevated privileges or within high-performance computing contexts, this allows for Arbitrary Code Execution (ACE) at the privilege level of the host process.

Who is Impacted?

  • Developers using the library as a dynamic linked library (.so, .dll, .dylib) in multi-language environments (e.g., Python, Node.js, C++).
  • Cloud Service Providers running the library in multi-tenant environments or automated model-training pipelines.
  • Users processing untrusted or third-party datasets/models that may trigger malicious JIT instruction generation. Patches
  • Affected versions: < 0.2.8
  • Patched version: 0.2.9

Workarounds

If you cannot upgrade immediately, please consider the following mitigations: * Strict Sandboxing: Run the library within a restricted sandbox (e.g., WebAssembly, Docker with non-root user, or seccomp profiles) to limit system call access. * Principle of Least Privilege: Ensure the process calling the library does not have administrative or root privileges. * Input Filtering: If possible, implement an application-level validation layer to sanitize any data passed to the CFFI interfaces. * Disable JIT (if applicable): If your workload allows, use the interpreter-only mode (if provided by the library) to bypass the JIT engine entirely. CVSS Score * Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H * Base Score: 9.4 (Critical)

References

Apich Organization Security Team Homepage

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "rssn"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-30960"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-15",
      "CWE-20",
      "CWE-269",
      "CWE-695",
      "CWE-754",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-10T01:19:29Z",
    "nvd_published_at": "2026-03-10T18:18:55Z",
    "severity": "CRITICAL"
  },
  "details": "## Impact\n\n**Vulnerability Type**: \nImproper Control of Generation of Code (\u0027Code Injection\u0027) (CWE-94) / Improper Check for Unusual or Exceptional Conditions (CWE-754) / Improper Input Validation (CWE-20) / Use of Low-Level Functionality (CWE-695) / Improper Privilege Management (CWE-269) / External Control of System or Configuration Setting (CWE-15).\n\n**Technical Details**:\nThe vulnerability exists in the JIT (Just-In-Time) compilation engine, which is fully exposed via the CFFI (Foreign Function Interface). Due to Improper Input Validation and External Control of Code Generation, an attacker can supply malicious parameters or instruction sequences through the CFFI layer. Since the library often operates with elevated privileges or within high-performance computing contexts, this allows for Arbitrary Code Execution (ACE) at the privilege level of the host process.\n\n## Who is Impacted?\n\n * Developers using the library as a dynamic linked library (.so, .dll, .dylib) in multi-language environments (e.g., Python, Node.js, C++).\n * Cloud Service Providers running the library in multi-tenant environments or automated model-training pipelines.\n * Users processing untrusted or third-party datasets/models that may trigger malicious JIT instruction generation.\nPatches\n * Affected versions: \u003c 0.2.8\n * Patched version: 0.2.9\n\n## Workarounds\n\nIf you cannot upgrade immediately, please consider the following mitigations:\n * Strict Sandboxing: Run the library within a restricted sandbox (e.g., WebAssembly, Docker with non-root user, or seccomp profiles) to limit system call access.\n * Principle of Least Privilege: Ensure the process calling the library does not have administrative or root privileges.\n * Input Filtering: If possible, implement an application-level validation layer to sanitize any data passed to the CFFI interfaces.\n * Disable JIT (if applicable): If your workload allows, use the interpreter-only mode (if provided by the library) to bypass the JIT engine entirely.\nCVSS Score\n * Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H\n * Base Score: 9.4 (Critical)\n\n## References\n\n[Apich Organization Security Team Homepage](https://security.apich.org/)",
  "id": "GHSA-9c4h-pwmf-m6fj",
  "modified": "2026-03-10T18:40:24Z",
  "published": "2026-03-10T01:19:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Apich-Organization/rssn/security/advisories/GHSA-9c4h-pwmf-m6fj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30960"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Apich-Organization/rssn"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Apich-Organization/rssn/releases/tag/v0.2.9"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0038.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "RSSN has Arbitrary Code Execution via Unvalidated JIT Instruction Generation in C-FFI Interface"
}

GHSA-9CMH-QH3J-RRP8

Vulnerability from github – Published: 2025-01-28 00:32 – Updated: 2025-11-03 21:32
VLAI
Details

The issue was addressed with improved checks. This issue is fixed in iPadOS 17.7.4, macOS Sonoma 14.7.3, visionOS 2.3, iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, watchOS 11.3, tvOS 18.3. Parsing a file may lead to an unexpected app termination.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-24161"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-27T22:15:20Z",
    "severity": "MODERATE"
  },
  "details": "The issue was addressed with improved checks. This issue is fixed in iPadOS 17.7.4, macOS Sonoma 14.7.3, visionOS 2.3, iOS 18.3 and iPadOS 18.3, macOS Sequoia 15.3, watchOS 11.3, tvOS 18.3. Parsing a file may lead to an unexpected app termination.",
  "id": "GHSA-9cmh-qh3j-rrp8",
  "modified": "2025-11-03T21:32:29Z",
  "published": "2025-01-28T00:32:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24161"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122066"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122067"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122068"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122069"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122071"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122072"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122073"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jan/13"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jan/14"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jan/15"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jan/16"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jan/18"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jan/19"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9CQR-G7FQ-8JF6

Vulnerability from github – Published: 2026-04-10 00:30 – Updated: 2026-04-10 00:30
VLAI
Details

An Improper Check for Unusual or Exceptional Conditions vulnerability in the flow daemon (flowd) of Juniper Networks Junos OS on SRX Series allows an attacker sending a specific, malformed ICMPv6 packet to cause the srxpfe process to crash and restart. Continued receipt and processing of these packets will repeatedly crash the srxpfe process and sustain the Denial of Service (DoS) condition.

During NAT64 translation, receipt of a specific, malformed ICMPv6 packet destined to the device will cause the srxpfe process to crash and restart.

This issue cannot be triggered using IPv4 nor other IPv6 traffic.

This issue affects Junos OS on SRX Series: * all versions before 21.2R3-S10, * all versions of 21.3, * from 21.4 before 21.4R3-S12, * all versions of 22.1, * from 22.2 before 22.2R3-S8, * all versions of 22.4, * from 22.4 before 22.4R3-S9, * from 23.2 before 23.2R2-S6, * from 23.4 before 23.4R2-S7, * from 24.2 before 24.2R2-S3, * from 24.4 before 24.4R2-S3, * from 25.2 before 25.2R1-S2, 25.2R2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-33790"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-09T22:16:28Z",
    "severity": "HIGH"
  },
  "details": "An Improper Check for Unusual or Exceptional Conditions vulnerability in the flow daemon (flowd) of Juniper Networks Junos OS on SRX Series allows an attacker sending a specific, malformed ICMPv6 packet to cause the srxpfe process to crash and restart.\u00a0Continued receipt and processing of these packets will repeatedly crash the srxpfe process and sustain the Denial of Service (DoS) condition.\n\nDuring NAT64 translation, receipt of a specific, malformed ICMPv6 packet destined to the device will cause the srxpfe process to crash and restart.\n\nThis issue cannot be triggered using IPv4 nor other IPv6 traffic.\n\n\n\nThis issue affects Junos OS on SRX Series:\n  *  all versions before 21.2R3-S10,\n  *  all versions of 21.3,\n  *  from 21.4 before 21.4R3-S12,\n  *  all versions of 22.1,\n  *  from 22.2 before 22.2R3-S8,\n  *  all versions of 22.4,\n  *  from 22.4 before 22.4R3-S9,\n  *  from 23.2 before 23.2R2-S6,\n  *  from 23.4 before 23.4R2-S7,\n  *  from 24.2 before 24.2R2-S3,\n  *  from 24.4 before 24.4R2-S3,\n  *  from 25.2 before 25.2R1-S2, 25.2R2.",
  "id": "GHSA-9cqr-g7fq-8jf6",
  "modified": "2026-04-10T00:30:29Z",
  "published": "2026-04-10T00:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33790"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA107874"
    }
  ],
  "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"
    },
    {
      "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: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:A/V:C/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-9CX6-37PM-9JFF

Vulnerability from github – Published: 2026-03-27 18:21 – Updated: 2026-03-30 20:08
VLAI
Summary
Handlebars.js has Denial of Service via Malformed Decorator Syntax in Template Compilation
Details

Summary

When a Handlebars template contains decorator syntax referencing an unregistered decorator (e.g. {{*n}}), the compiled template calls lookupProperty(decorators, "n"), which returns undefined. The runtime then immediately invokes the result as a function, causing an unhandled TypeError: ... is not a function that crashes the Node.js process. Any application that compiles user-supplied templates without wrapping the call in a try/catch is vulnerable to a single-request Denial of Service.

Description

In lib/handlebars/compiler/javascript-compiler.js, the code generated for a decorator invocation looks like:

fn = lookupProperty(decorators, "n")(fn, props, container, options) || fn;

When "n" is not a registered decorator, lookupProperty(decorators, "n") returns undefined. The expression immediately attempts to call undefined as a function, producing:

TypeError: lookupProperty(...) is not a function

Because the error is thrown inside the compiled template function and is not caught by the runtime, it propagates up as an unhandled exception and — when not caught by the application — crashes the Node.js process.

This inconsistency is notable: references to unregistered helpers produce a clean "Missing helper: ..." error, while references to unregistered decorators cause a hard crash.

Attack scenario: An attacker submits {{*n}} as template content to any endpoint that calls Handlebars.compile(userInput)(). Each request crashes the server process; with process managers that auto-restart (PM2, systemd), repeated submissions create a persistent DoS.

Proof of Concept

const Handlebars = require('handlebars'); // Handlebars 4.7.8, Node.js v22.x

// Any of these payloads crash the process
Handlebars.compile('{{*n}}')({});
Handlebars.compile('{{*decorator}}')({});
Handlebars.compile('{{*constructor}}')({});

Expected crash output:

TypeError: lookupProperty(...) is not a function
    at Function.eval [as decorator] (eval at compile (...javascript-compiler.js:134:36))

Workarounds

  • Wrap compilation and rendering in try/catch: javascript try { const result = Handlebars.compile(userInput)(context); res.send(result); } catch (err) { res.status(400).send('Invalid template'); }
  • Validate template input before passing it to compile(). Reject templates containing decorator syntax ({{*...}}) if decorators are not used in your application.
  • Use the pre-compilation workflow: compile templates at build time and serve only pre-compiled templates; do not call compile() at request time.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.7.8"
      },
      "package": {
        "ecosystem": "npm",
        "name": "handlebars"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.7.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-27T18:21:15Z",
    "nvd_published_at": "2026-03-27T22:16:20Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nWhen a Handlebars template contains decorator syntax referencing an unregistered decorator (e.g. `{{*n}}`), the compiled template calls `lookupProperty(decorators, \"n\")`, which returns `undefined`. The runtime then immediately invokes the result as a function, causing an unhandled `TypeError: ... is not a function` that crashes the Node.js process. Any application that compiles user-supplied templates without wrapping the call in a `try/catch` is vulnerable to a single-request Denial of Service.\n\n## Description\n\nIn `lib/handlebars/compiler/javascript-compiler.js`, the code generated for a decorator invocation looks like:\n\n```javascript\nfn = lookupProperty(decorators, \"n\")(fn, props, container, options) || fn;\n```\n\nWhen `\"n\"` is not a registered decorator, `lookupProperty(decorators, \"n\")` returns `undefined`. The expression immediately attempts to call `undefined` as a function, producing:\n\n```\nTypeError: lookupProperty(...) is not a function\n```\n\nBecause the error is thrown inside the compiled template function and is not caught by the runtime, it propagates up as an unhandled exception and \u2014 when not caught by the application \u2014 crashes the Node.js process.\n\nThis inconsistency is notable: references to unregistered **helpers** produce a clean `\"Missing helper: ...\"` error, while references to unregistered **decorators** cause a hard crash.\n\n**Attack scenario:** An attacker submits `{{*n}}` as template content to any endpoint that calls `Handlebars.compile(userInput)()`. Each request crashes the server process; with process managers that auto-restart (PM2, systemd), repeated submissions create a persistent DoS.\n\n## Proof of Concept\n\n```javascript\nconst Handlebars = require(\u0027handlebars\u0027); // Handlebars 4.7.8, Node.js v22.x\n\n// Any of these payloads crash the process\nHandlebars.compile(\u0027{{*n}}\u0027)({});\nHandlebars.compile(\u0027{{*decorator}}\u0027)({});\nHandlebars.compile(\u0027{{*constructor}}\u0027)({});\n```\n\nExpected crash output:\n```\nTypeError: lookupProperty(...) is not a function\n    at Function.eval [as decorator] (eval at compile (...javascript-compiler.js:134:36))\n```\n\n## Workarounds\n\n- **Wrap compilation and rendering in `try/catch`:**\n  ```javascript\n  try {\n    const result = Handlebars.compile(userInput)(context);\n    res.send(result);\n  } catch (err) {\n    res.status(400).send(\u0027Invalid template\u0027);\n  }\n  ```\n- **Validate template input** before passing it to `compile()`. Reject templates containing  decorator syntax (`{{*...}}`) if decorators are not used in your application.\n- **Use the pre-compilation workflow:** compile templates at build time and serve only pre-compiled  templates; do not call `compile()` at request time.",
  "id": "GHSA-9cx6-37pm-9jff",
  "modified": "2026-03-30T20:08:14Z",
  "published": "2026-03-27T18:21:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/handlebars-lang/handlebars.js/security/advisories/GHSA-9cx6-37pm-9jff"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33939"
    },
    {
      "type": "WEB",
      "url": "https://github.com/handlebars-lang/handlebars.js/commit/68d8df5a88e0a26fe9e6084c5c6aaebe67b07da2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/handlebars-lang/handlebars.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/handlebars-lang/handlebars.js/releases/tag/v4.7.9"
    }
  ],
  "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": "Handlebars.js has Denial of Service via Malformed Decorator Syntax in Template Compilation"
}

GHSA-9G34-2MP9-R344

Vulnerability from github – Published: 2024-11-28 18:38 – Updated: 2024-11-28 18:38
VLAI
Details

Mattermost versions 10.0.x <= 10.0.1, 10.1.x <= 10.1.1, 9.11.x <= 9.11.3, 9.5.x <= 9.5.11 fail to properly validate email addresses which allows an unauthenticated user to bypass email domain restrictions via carefully crafted input on email registration.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-11599"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-28T10:15:06Z",
    "severity": "HIGH"
  },
  "details": "Mattermost versions 10.0.x \u003c= 10.0.1, 10.1.x \u003c= 10.1.1, 9.11.x \u003c= 9.11.3, 9.5.x \u003c= 9.5.11 fail to properly validate email addresses which allows an unauthenticated user to bypass email domain restrictions via carefully crafted input on email registration.",
  "id": "GHSA-9g34-2mp9-r344",
  "modified": "2024-11-28T18:38:36Z",
  "published": "2024-11-28T18:38:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11599"
    },
    {
      "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:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9GG8-XVHP-2Q7G

Vulnerability from github – Published: 2022-05-24 17:29 – Updated: 2023-05-22 21:30
VLAI
Details

Multiple vulnerabilities in the Zone-Based Firewall feature of Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause the device to reload or stop forwarding traffic through the firewall. The vulnerabilities are due to incomplete handling of Layer 4 packets through the device. An attacker could exploit these vulnerabilities by sending a certain sequence of traffic patterns through the device. A successful exploit could allow the attacker to cause the device to reload or stop forwarding traffic through the firewall, resulting in a denial of service. For more information about these vulnerabilities, see the Details section of this advisory.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-3421"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-24T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "Multiple vulnerabilities in the Zone-Based Firewall feature of Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause the device to reload or stop forwarding traffic through the firewall. The vulnerabilities are due to incomplete handling of Layer 4 packets through the device. An attacker could exploit these vulnerabilities by sending a certain sequence of traffic patterns through the device. A successful exploit could allow the attacker to cause the device to reload or stop forwarding traffic through the firewall, resulting in a denial of service. For more information about these vulnerabilities, see the Details section of this advisory.",
  "id": "GHSA-9gg8-xvhp-2q7g",
  "modified": "2023-05-22T21:30:16Z",
  "published": "2022-05-24T17:29:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3421"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-zbfw-94ckG4G"
    }
  ],
  "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-9GQV-WP59-FQ42

Vulnerability from github – Published: 2025-04-15 03:30 – Updated: 2025-04-28 14:28
VLAI
Summary
http-proxy-middleware allows fixRequestBody to proceed even if bodyParser has failed
Details

In http-proxy-middleware before 2.0.9 and 3.x before 3.0.5, fixRequestBody proceeds even if bodyParser has failed.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "http-proxy-middleware"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "2.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "http-proxy-middleware"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-32997"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-16T15:24:43Z",
    "nvd_published_at": "2025-04-15T03:15:18Z",
    "severity": "MODERATE"
  },
  "details": "In http-proxy-middleware before 2.0.9 and 3.x before 3.0.5, fixRequestBody proceeds even if bodyParser has failed.",
  "id": "GHSA-9gqv-wp59-fq42",
  "modified": "2025-04-28T14:28:53Z",
  "published": "2025-04-15T03:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32997"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chimurai/http-proxy-middleware/pull/1096"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chimurai/http-proxy-middleware/commit/1bdccbeec243850f1d2bb50ea0ff2151e725d67e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/chimurai/http-proxy-middleware"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chimurai/http-proxy-middleware/releases/tag/v2.0.9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chimurai/http-proxy-middleware/releases/tag/v3.0.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "http-proxy-middleware allows fixRequestBody to proceed even if bodyParser has failed"
}

GHSA-9GV2-H67Q-4H2V

Vulnerability from github – Published: 2024-03-27 06:30 – Updated: 2025-11-04 21:31
VLAI
Details

glx_pbuffer.c in Mesa 23.0.4 was discovered to contain a segmentation violation when calling __glXGetDrawableAttribute(). NOTE: this is disputed because there are no common situations in which users require uninterrupted operation with an attacker-controller server.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-45922"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-27T05:15:47Z",
    "severity": "MODERATE"
  },
  "details": "glx_pbuffer.c in Mesa 23.0.4 was discovered to contain a segmentation violation when calling __glXGetDrawableAttribute(). NOTE: this is disputed because there are no common situations in which users require uninterrupted operation with an attacker-controller server.",
  "id": "GHSA-9gv2-h67q-4h2v",
  "modified": "2025-11-04T21:31:22Z",
  "published": "2024-03-27T06:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-45922"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.freedesktop.org/mesa/mesa/-/issues/9857"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/176805/Mesa-23.0.4-Buffer-Overflow-Null-Pointer.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jan/50"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jan/71"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9HFR-GW99-8RHX

Vulnerability from github – Published: 2026-04-09 20:28 – Updated: 2026-05-13 16:22
VLAI
Summary
bsv-sdk ARC broadcaster treats INVALID/MALFORMED/ORPHAN responses as successful broadcasts
Details

ARC broadcaster treats failure statuses as successful broadcasts

Summary

BSV::Network::ARC's failure detection only recognises REJECTED and DOUBLE_SPEND_ATTEMPTED. ARC responses with txStatus values of INVALID, MALFORMED, MINED_IN_STALE_BLOCK, or any ORPHAN-containing extraInfo / txStatus are silently treated as successful broadcasts. Applications that gate actions on broadcaster success are tricked into trusting transactions that were never accepted by the network.

Details

lib/bsv/network/arc.rb (lines ~74-100 in the affected code) uses a narrow failure predicate compared to the TypeScript reference SDK. The TS broadcaster additionally recognises:

  • INVALID
  • MALFORMED
  • MINED_IN_STALE_BLOCK
  • Any response containing ORPHAN in extraInfo or txStatus

The Ruby implementation omits all of these, so ARC responses carrying any of these statuses are returned to the caller as successful broadcasts.

Additional divergences in the same module compound the risk:

  • Content-Type is sent as application/octet-stream; the TS reference sends application/json with a { rawTx: <hex> } body (EF form where source transactions are available).
  • The headers XDeployment-ID, X-CallbackUrl, and X-CallbackToken are not sent.

The immediate security-relevant defect is the missing failure statuses; the other divergences are fixed in the same patch for protocol compliance.

Impact

Integrity: callers receive a success response for broadcasts that were actually rejected by the ARC endpoint. Applications and downstream gems that gate actions on broadcaster success — releasing goods, marking invoices paid, treating a token as minted, progressing a workflow — are tricked into trusting transactions that were never broadcast.

This is an integrity bug with security consequences. It does not disclose information (confidentiality unaffected) and does not affect availability.

CVSS rationale

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N7.5 (High)

  • AV:N — network-reachable.
  • AC:L — no specialised access conditions are required. Triggering any of the unhandled failure statuses is not meaningfully harder than broadcasting a transaction at all: a malformed or invalid transaction, an orphan condition from a transient fork, or a hostile/misbehaving ARC endpoint returning one of these statuses is sufficient. The attacker does not need to defeat any mitigation or race a specific window — the bug is that the code path doesn't exist at all.
  • PR:N — no privileges required.
  • UI:N — no user interaction.
  • C:N — no confidentiality impact.
  • I:H — downstream integrity decisions are taken on non-broadcast transactions.
  • A:N — no availability impact.

Affected versions

The ARC broadcaster was introduced in commit a1f2e62 ("feat(network): add ARC broadcaster with injectable HTTP client") on 2026-02-08 and first released in v0.1.0. The narrow failure predicate has been present since introduction. Every release up to and including v0.8.1 is affected.

Affected range: >= 0.1.0, < 0.8.2.

Patches

Upgrade to bsv-sdk >= 0.8.2. The fix:

  • Expands the failure predicate (REJECTED_STATUSES + ORPHAN substring check on both txStatus and extraInfo) to include INVALID, MALFORMED, MINED_IN_STALE_BLOCK, and any orphan-containing response, matching the TypeScript reference.
  • Switches Content-Type to application/json with a { rawTx: <hex> } body, preferring Extended Format (BRC-30) hex when every input has source_satoshis and source_locking_script populated and falling back to plain raw-tx hex otherwise.
  • Adds support for the XDeployment-ID (default: random bsv-ruby-sdk-<hex>), X-CallbackUrl, and X-CallbackToken headers via new constructor keyword arguments.

Fixed in sgbett/bsv-ruby-sdk#306.

Note for bsv-wallet consumers

The sibling gem bsv-wallet (published from the same repository) is not independently vulnerable — lib/bsv/network/arc.rb is not bundled into the wallet gem's files list. However, bsv-wallet runtime-depends on bsv-sdk, so a consumer of bsv-wallet that also invokes the ARC broadcaster is transitively exposed whenever Gemfile.lock resolves to a vulnerable bsv-sdk version. bsv-wallet >= 0.3.4 tightens its bsv-sdk constraint to >= 0.8.2, < 1.0, so upgrading either gem is sufficient to pull in the fix.

Workarounds

If upgrading is not immediately possible:

  • Verify broadcast results out-of-band (e.g. query a block explorer or WhatsOnChain) before treating a transaction as broadcast.
  • Do not gate integrity-critical actions solely on the ARC broadcaster's success response.

Credit

Identified during the 2026-04-08 cross-SDK compliance review, tracked as finding F5.13.

References

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "bsv-sdk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "fixed": "0.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40069"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-09T20:28:26Z",
    "nvd_published_at": "2026-04-09T18:17:03Z",
    "severity": "HIGH"
  },
  "details": "# ARC broadcaster treats failure statuses as successful broadcasts\n\n## Summary\n\n`BSV::Network::ARC`\u0027s failure detection only recognises `REJECTED` and `DOUBLE_SPEND_ATTEMPTED`. ARC responses with `txStatus` values of `INVALID`, `MALFORMED`, `MINED_IN_STALE_BLOCK`, or any `ORPHAN`-containing `extraInfo` / `txStatus` are silently treated as successful broadcasts. Applications that gate actions on broadcaster success are tricked into trusting transactions that were never accepted by the network.\n\n## Details\n\n`lib/bsv/network/arc.rb` (lines ~74-100 in the affected code) uses a narrow failure predicate compared to the TypeScript reference SDK. The TS broadcaster additionally recognises:\n\n- `INVALID`\n- `MALFORMED`\n- `MINED_IN_STALE_BLOCK`\n- Any response containing `ORPHAN` in `extraInfo` or `txStatus`\n\nThe Ruby implementation omits all of these, so ARC responses carrying any of these statuses are returned to the caller as successful broadcasts.\n\nAdditional divergences in the same module compound the risk:\n\n- `Content-Type` is sent as `application/octet-stream`; the TS reference sends `application/json` with a `{ rawTx: \u003chex\u003e }` body (EF form where source transactions are available).\n- The headers `XDeployment-ID`, `X-CallbackUrl`, and `X-CallbackToken` are not sent.\n\nThe immediate security-relevant defect is the missing failure statuses; the other divergences are fixed in the same patch for protocol compliance.\n\n## Impact\n\nIntegrity: callers receive a success response for broadcasts that were actually rejected by the ARC endpoint. Applications and downstream gems that gate actions on broadcaster success \u2014 releasing goods, marking invoices paid, treating a token as minted, progressing a workflow \u2014 are tricked into trusting transactions that were never broadcast.\n\nThis is an integrity bug with security consequences. It does not disclose information (confidentiality unaffected) and does not affect availability.\n\n## CVSS rationale\n\n`AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N` \u2192 **7.5 (High)**\n\n- **AV:N** \u2014 network-reachable.\n- **AC:L** \u2014 no specialised access conditions are required. Triggering any of the unhandled failure statuses is not meaningfully harder than broadcasting a transaction at all: a malformed or invalid transaction, an orphan condition from a transient fork, or a hostile/misbehaving ARC endpoint returning one of these statuses is sufficient. The attacker does not need to defeat any mitigation or race a specific window \u2014 the bug is that the code path doesn\u0027t exist at all.\n- **PR:N** \u2014 no privileges required.\n- **UI:N** \u2014 no user interaction.\n- **C:N** \u2014 no confidentiality impact.\n- **I:H** \u2014 downstream integrity decisions are taken on non-broadcast transactions.\n- **A:N** \u2014 no availability impact.\n\n## Affected versions\n\nThe ARC broadcaster was introduced in commit `a1f2e62` (\"feat(network): add ARC broadcaster with injectable HTTP client\") on 2026-02-08 and first released in **v0.1.0**. The narrow failure predicate has been present since introduction. Every release up to and including **v0.8.1** is affected.\n\nAffected range: `\u003e= 0.1.0, \u003c 0.8.2`.\n\n## Patches\n\nUpgrade to `bsv-sdk \u003e= 0.8.2`. The fix:\n\n- Expands the failure predicate (`REJECTED_STATUSES` + `ORPHAN` substring check on both `txStatus` and `extraInfo`) to include `INVALID`, `MALFORMED`, `MINED_IN_STALE_BLOCK`, and any orphan-containing response, matching the TypeScript reference.\n- Switches `Content-Type` to `application/json` with a `{ rawTx: \u003chex\u003e }` body, preferring Extended Format (BRC-30) hex when every input has `source_satoshis` and `source_locking_script` populated and falling back to plain raw-tx hex otherwise.\n- Adds support for the `XDeployment-ID` (default: random `bsv-ruby-sdk-\u003chex\u003e`), `X-CallbackUrl`, and `X-CallbackToken` headers via new constructor keyword arguments.\n\nFixed in sgbett/bsv-ruby-sdk#306.\n\n### Note for `bsv-wallet` consumers\n\nThe sibling gem `bsv-wallet` (published from the same repository) is not independently vulnerable \u2014 `lib/bsv/network/arc.rb` is not bundled into the wallet gem\u0027s `files` list. However, `bsv-wallet` runtime-depends on `bsv-sdk`, so a consumer of `bsv-wallet` that also invokes the ARC broadcaster is transitively exposed whenever `Gemfile.lock` resolves to a vulnerable `bsv-sdk` version. `bsv-wallet \u003e= 0.3.4` tightens its `bsv-sdk` constraint to `\u003e= 0.8.2, \u003c 1.0`, so upgrading either gem is sufficient to pull in the fix.\n\n## Workarounds\n\nIf upgrading is not immediately possible:\n\n- Verify broadcast results out-of-band (e.g. query a block explorer or WhatsOnChain) before treating a transaction as broadcast.\n- Do not gate integrity-critical actions solely on the ARC broadcaster\u0027s success response.\n\n## Credit\n\nIdentified during the 2026-04-08 cross-SDK compliance review, tracked as finding F5.13.\n\n## References\n\n- HLR: sgbett/bsv-ruby-sdk#305\n- Fix PR: sgbett/bsv-ruby-sdk#306\n- Compliance review: [`.architecture/reviews/20260408-cross-sdk-compliance-review.md`](../../.architecture/reviews/20260408-cross-sdk-compliance-review.md)\n- TypeScript reference: `ARC` class in `@bsv/sdk`",
  "id": "GHSA-9hfr-gw99-8rhx",
  "modified": "2026-05-13T16:22:10Z",
  "published": "2026-04-09T20:28:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sgbett/bsv-ruby-sdk/security/advisories/GHSA-9hfr-gw99-8rhx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40069"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sgbett/bsv-ruby-sdk/issues/305"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sgbett/bsv-ruby-sdk/pull/306"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sgbett/bsv-ruby-sdk/commit/4992e8a265fd914a7eeb0405c69d1ff0122a84cc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/bsv-sdk/CVE-2026-40069.yml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sgbett/bsv-ruby-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sgbett/bsv-ruby-sdk/releases/tag/v0.8.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "bsv-sdk ARC broadcaster treats INVALID/MALFORMED/ORPHAN responses as successful broadcasts"
}

GHSA-9J3F-4M2H-6F2H

Vulnerability from github – Published: 2026-01-15 21:31 – Updated: 2026-01-15 21:31
VLAI
Details

An Improper Check for Unusual or Exceptional Conditions vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, network-based attacker to cause an availability impact for downstream devices.

When an affected device receives a specific optional, transitive BGP attribute over an existing BGP session, it will be erroneously modified before propagation to peers. When the attribute is detected as malformed by the peers, these peers will most likely terminate the BGP sessions with the affected devices and thereby cause an availability impact due to the resulting routing churn.

This issue affects:

Junos OS:

  • all versions before 22.4R3-S8,
  • 23.2 versions before 23.2R2-S5
  • 23.4 versions before 23.4R2-S6,
  • 24.2 versions before 24.2R2-S2,
  • 24.4 versions before 24.4R2;

Junos OS Evolved: 

  • all versions before 22.4R3-S8-EVO,
  • 23.2 versions before 23.2R2-S5-EVO,
  • 23.4 versions before 23.4R2-S6-EVO,
  • 24.2 versions before 24.2R2-S2-EVO,
  • 24.4 versions before 24.4R2-EVO.
Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-60011"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-15T21:16:03Z",
    "severity": "MODERATE"
  },
  "details": "An Improper Check for Unusual or Exceptional Conditions vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, network-based attacker to cause an availability impact for downstream devices.\n\nWhen an affected device receives a specific optional, transitive BGP attribute over an existing BGP session, it will be erroneously modified before propagation to peers. When the attribute is detected as malformed by the peers, these peers will most likely terminate the BGP sessions with the affected devices and thereby cause an availability impact due to the resulting routing churn.\n\nThis issue affects:\n\nJunos OS:\n\n\n\n  *  all versions before 22.4R3-S8,\n  *  23.2 versions before 23.2R2-S5\n  *  23.4 versions before 23.4R2-S6,\n  *  24.2 versions before 24.2R2-S2,\n  *  24.4 versions before 24.4R2;\n\n\n\n\nJunos OS Evolved:\u00a0\n\n\n\n  *  all versions before 22.4R3-S8-EVO,\n  *  23.2 versions before 23.2R2-S5-EVO,\n  *  23.4 versions before 23.4R2-S6-EVO,\n  *  24.2 versions before 24.2R2-S2-EVO,\n  *  24.4 versions before 24.4R2-EVO.",
  "id": "GHSA-9j3f-4m2h-6f2h",
  "modified": "2026-01-15T21:31:47Z",
  "published": "2026-01-15T21:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60011"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA103161"
    },
    {
      "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:N/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:Y/R:U/V:X/RE:M/U:X",
      "type": "CVSS_V4"
    }
  ]
}

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.