Common Weakness Enumeration

CWE-248

Allowed

Uncaught Exception

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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

610 vulnerabilities reference this CWE, most recent first.

GHSA-42VR-XJ54-VC7V

Vulnerability from github – Published: 2026-09-30 15:41 – Updated: 2026-09-30 15:41
VLAI
Summary
PyJWT: Unauthenticated RecursionError DoS in pre-verification payload parse (PyJWKClient.get_signing_key_from_jwt / verify_signature=False)
Details

Summary

PyJWKClient.get_signing_key_from_jwt(token) — the first step of the JWKS verification flow documented in docs/usage.rst — must decode a token's payload before its signature can be checked, via jwt.api_jwt.decode_complete(token, options={"verify_signature": False}). That call parses the payload with json.loads in PyJWT._decode_payload (jwt/api_jwt.py:297-300), whose except clause catches only ValueError. A payload that is valid JSON but nested ~20,000 levels deep makes json.loads raise RecursionError, which is not a ValueError and escapes as a raw, undocumented exception type — not DecodeError, InvalidTokenError, or PyJWTError, so every documented error-handling pattern in docs/usage.rst misses it.

The token needs no valid signature and no network access — the crash happens during payload parsing, before the kid is even looked up. A single unauthenticated ~50KB request crashes the caller's auth handler (HTTP 500 / dead worker), repeatably. The same path is reachable through plain jwt.decode(token, options={"verify_signature": False}) too.

Notably, this project already fixed the identical bug class for the JWS header path — PyJWS._load catches (ValueError, RecursionError) and wraps it in DecodeError (jwt/api_jws.py:360-361), and CHANGELOG.rst (v2.14.0, "Security") states "Handle deeply nested and malformed JWS/JWK input without uncaught recursion errors." The payload path — the one part of a forged token an unauthenticated attacker fully controls — was left catching ValueError alone, so that security fix does not fully hold.

A second, related instance: PyJWKClient.fetch_data (jwt/jwks_client.py:168) parses a JWKS endpoint's response with json.load(response) inside a try that only catches (URLError, TimeoutError, http.client.HTTPException) — a deeply-nested JSON response from a JWKS endpoint raises the same raw RecursionError, uncaught entirely (worse than the payload path, which at least caught plain ValueError).

Affected versions: confirmed present in the current release, 2.14.0, and on the current master branch (commit 4adcd02722f5011c60079d3978dfc167b9a8eaa5).

Reproduction

import base64, json, jwt

def b64url(b):
    return base64.urlsafe_b64encode(b).rstrip(b"=")

header = b64url(json.dumps({"alg": "HS256", "typ": "JWT"}).encode())
payload = b64url(b"[" * 20_000 + b"]" * 20_000)
token = (header + b"." + payload + b"." + b64url(b"forged-sig")).decode()

jwt.decode(token, options={"verify_signature": False})
# raises: RecursionError (not DecodeError/InvalidTokenError/PyJWTError)

Control: the same deeply-nested structure moved into the token's header instead of its payload is correctly converted to jwt.DecodeError by the already-hardened jwt/api_jws.py:360 — confirming the payload path is specifically the missed half of the v2.14.0 hardening, not a general gap.

Impact assessment

Unauthenticated denial-of-service via unhandled exception on an auth path. Not an auth bypass — rated medium. With signature verification enabled, this parse runs after _verify_signature, so only the pre-verification paths (get_signing_key_from_jwt, explicit verify_signature=False) are attacker-reachable pre-auth; the JWKS-endpoint variant requires control of (or a MITM on) the configured JWKS endpoint rather than being reachable from an arbitrary client token.

Suggested fix

In jwt/api_jwt.py:299, change except ValueError as e: to except (ValueError, RecursionError) as e:, mirroring jwt/api_jws.py:360 exactly. In jwt/jwks_client.py, add the same (ValueError, RecursionError) handling around json.load(response) in fetch_data, raising PyJWKClientError (consistent with the method's existing documented error contract). A patch implementing both, verified against the full test suite (457 passed, 4 skipped — pre-existing, environment-related) and against the reproduction above (now correctly raises DecodeError), is attached (fix.patch).

Discovery method

Found and verified using scopegrep (https://github.com/not-ekalabya/scopegrep) — a semantic code-retrieval tool that surfaces every other call site of a symbol alongside relevance-ranked results, which is what surfaced the already-hardened header path as the direct comparison here — paired with an LLM coding agent (GLM-5.3) run as an open-ended security review of this repository. Independently reproduced against the exact commit above before this report was written. Happy to share the full session transcript on request.

Disclosure status

Not shared with any other party or published. Submitting through this private channel per the project's stated security policy; no planned public/conference disclosure ahead of a coordinated timeline.

Maintainer triage update (2026-09-22)

Confirmed finding and scope

We confirmed that an attacker-controlled recursively nested JWT payload can cause a raw Python RecursionError to escape PyJWT at PyJWT 2.14.0 and the tested current source. The confirmed in-scope paths are direct decoding with verify_signature=False and PyJWKClient.get_signing_key_from_jwt, where payload parsing occurs before key lookup.

The demonstrated impact is limited to an uncaught exception for the affected call, which may surface as an application HTTP 500 when the application does not catch it. Testing did not demonstrate a worker or process crash, persistent resource exhaustion, resource amplification, authentication bypass, or confidentiality or integrity impact.

The separate JWKS-response subclaim is out of scope under the policy boundary that requires the application to trust its configured JWKS source and transport. The confirmed payload finding is not a duplicate of the earlier protected-header parser finding: it occurs in a distinct payload parsing path that remained affected after the earlier header-only fix.

Version and remediation status

Historical testing reproduced the confirmed payload behavior in all 20 official supported PyJWT 2.x releases from 2.0.0a1 through 2.14.0, inclusive. Unsupported PyJWT 1.7.1 also reproduces the behavior, but it is excluded from the advisory range under the supported-2.x policy. No supported unaffected release and no patched release exists. The exact evidence is /Users/jpadilla/.codex/security-advisories/pyjwt/GHSA-42vr-xj54-vc7v-historical-range-20260922.md (SHA-256 c48f1ac35641e9382d53e6a879a71ad9a8fb4432bbe871f2b8330f8d166a2d81) and /Users/jpadilla/.codex/security-advisories/pyjwt/historical-range-42vr-20260922/historical-range-results.json (SHA-256 324997f231561bf6da39b8f9d1e272f69bfde8871a7863f5cb7b70e22e91f076). The evidence-backed supported affected range is >= 2.0.0a1, <= 2.14.0.

Historical range verification is complete. A local fix commit exists and has passed independent review and the complete local CI suite, but it has not been merged into master or released. Consequently, patched_versions remains empty and this advisory remains in triage. The remaining next step is a maintainer decision on remediation and merge. After a fix lands in master and is released, patched_versions and advisory lifecycle can be updated in a separate approved batch.

Maintainer remediation update (2026-09-23)

The confirmed payload-parser finding has been fixed on master. Commit 5fde08a6cf906aa7698de2d6391d88b73006b17b converts a recursive payload parse failure to the expected DecodeError; commit 9bc06658f875b9b40091539140bbbdc4639161c3 makes the regression tests deterministic across supported Python versions. This update supersedes the 2026-09-22 remediation-status statement that the fix had not landed.

The original pre-verification payload reproducer and the PyJWKClient.get_signing_key_from_jwt path were covered by regression tests. The exact landed tree passed the full 39-environment local tox matrix and GitHub CI for commit 9bc06658f875b9b40091539140bbbdc4639161c3 passed all 25 jobs, including Ubuntu Python 3.14 and 3.15. The demonstrated impact remains an uncaught request-level exception in affected releases; there is still no evidence of process termination, persistent resource exhaustion, authentication bypass, or confidentiality or integrity impact.

The supported affected range remains >= 2.0.0a1, <= 2.14.0. The latest released version is 2.14.0, which predates these commits; no released patched version exists yet, so patched_versions remains unset. CVSS v3.1 5.3 (Medium) and CWE-248 remain unchanged. The advisory may now move from triage to private draft. The next lifecycle step is a new supported 2.x release containing the fix, followed by separately approved patched-version and publication updates after release verification.

Maintainer release update (2026-09-23)

PyJWT 2.15.0 is the first released version containing the payload-parser fix. Its GitHub release tag points to commit 1d41a6478e1562e68ff667fcd703356acf085f68, which includes fix commit 5fde08a6cf906aa7698de2d6391d88b73006b17b and deterministic regression-test commit 9bc06658f875b9b40091539140bbbdc4639161c3. PyPI published both the wheel and source distribution from that release commit through the successful production workflow at https://github.com/jpadilla/pyjwt/actions/runs/35891602963.

The published PyPI wheel (pyjwt-2.15.0-py3-none-any.whl, SHA-256 7a3742debf6b879e912dbb9819ceec1594be812452b78c5f2e2dfc56564954f8) was checked directly: the deeply nested unsigned payload now raises DecodeError, while an ordinary unsigned payload still decodes. The supported affected range remains >= 2.0.0a1, <= 2.14.0; the patched version is 2.15.0. Earlier statements in this advisory that no released patched version exists are superseded by this update.

The confirmed impact remains an uncaught request-level exception in affected versions, not a demonstrated process crash or authentication bypass. The separate JWKS-response subclaim remains outside this advisory's confirmed PyJWT-owned scope.

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
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.14.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "PyJWT"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0a1"
            },
            {
              "fixed": "2.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-101918"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T15:41:05Z",
    "nvd_published_at": "2026-09-28T21:17:13Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`PyJWKClient.get_signing_key_from_jwt(token)` \u2014 the first step of the JWKS\nverification flow documented in `docs/usage.rst` \u2014 must decode a token\u0027s\npayload before its signature can be checked, via\n`jwt.api_jwt.decode_complete(token, options={\"verify_signature\": False})`.\nThat call parses the payload with `json.loads` in `PyJWT._decode_payload`\n(`jwt/api_jwt.py:297-300`), whose `except` clause catches only `ValueError`.\nA payload that is valid JSON but nested ~20,000 levels deep makes\n`json.loads` raise `RecursionError`, which is **not** a `ValueError` and\nescapes as a raw, undocumented exception type \u2014 not `DecodeError`,\n`InvalidTokenError`, or `PyJWTError`, so every documented error-handling\npattern in `docs/usage.rst` misses it.\n\nThe token needs no valid signature and no network access \u2014 the crash\nhappens during payload parsing, before the `kid` is even looked up. A\nsingle unauthenticated ~50KB request crashes the caller\u0027s auth handler\n(HTTP 500 / dead worker), repeatably. The same path is reachable through\nplain `jwt.decode(token, options={\"verify_signature\": False})` too.\n\nNotably, this project already fixed the **identical** bug class for the\nJWS **header** path \u2014 `PyJWS._load` catches `(ValueError, RecursionError)`\nand wraps it in `DecodeError` (`jwt/api_jws.py:360-361`), and\n`CHANGELOG.rst` (v2.14.0, \"Security\") states \"Handle deeply nested and\nmalformed JWS/JWK input without uncaught recursion errors.\" The payload\npath \u2014 the one part of a forged token an unauthenticated attacker fully\ncontrols \u2014 was left catching `ValueError` alone, so that security fix does\nnot fully hold.\n\nA second, related instance: `PyJWKClient.fetch_data` (`jwt/jwks_client.py:168`)\nparses a JWKS endpoint\u0027s response with `json.load(response)` inside a\n`try` that only catches `(URLError, TimeoutError, http.client.HTTPException)`\n\u2014 a deeply-nested JSON response from a JWKS endpoint raises the same raw\n`RecursionError`, uncaught entirely (worse than the payload path, which at\nleast caught plain `ValueError`).\n\n**Affected versions:** confirmed present in the current release, 2.14.0,\nand on the current `master` branch (commit `4adcd02722f5011c60079d3978dfc167b9a8eaa5`).\n\n## Reproduction\n\n```python\nimport base64, json, jwt\n\ndef b64url(b):\n    return base64.urlsafe_b64encode(b).rstrip(b\"=\")\n\nheader = b64url(json.dumps({\"alg\": \"HS256\", \"typ\": \"JWT\"}).encode())\npayload = b64url(b\"[\" * 20_000 + b\"]\" * 20_000)\ntoken = (header + b\".\" + payload + b\".\" + b64url(b\"forged-sig\")).decode()\n\njwt.decode(token, options={\"verify_signature\": False})\n# raises: RecursionError (not DecodeError/InvalidTokenError/PyJWTError)\n```\n\nControl: the same deeply-nested structure moved into the token\u0027s **header**\ninstead of its payload is correctly converted to `jwt.DecodeError` by the\nalready-hardened `jwt/api_jws.py:360` \u2014 confirming the payload path is\nspecifically the missed half of the v2.14.0 hardening, not a general gap.\n\n## Impact assessment\n\nUnauthenticated denial-of-service via unhandled exception on an auth path.\nNot an auth bypass \u2014 rated medium. With signature verification enabled,\nthis parse runs after `_verify_signature`, so only the pre-verification\npaths (`get_signing_key_from_jwt`, explicit `verify_signature=False`) are\nattacker-reachable pre-auth; the JWKS-endpoint variant requires control of\n(or a MITM on) the configured JWKS endpoint rather than being reachable\nfrom an arbitrary client token.\n\n## Suggested fix\n\nIn `jwt/api_jwt.py:299`, change `except ValueError as e:` to\n`except (ValueError, RecursionError) as e:`, mirroring\n`jwt/api_jws.py:360` exactly. In `jwt/jwks_client.py`, add the same\n`(ValueError, RecursionError)` handling around `json.load(response)` in\n`fetch_data`, raising `PyJWKClientError` (consistent with the method\u0027s\nexisting documented error contract). A patch implementing both, verified\nagainst the full test suite (457 passed, 4 skipped \u2014 pre-existing,\nenvironment-related) and against the reproduction above (now correctly\nraises `DecodeError`), is attached (`fix.patch`).\n\n## Discovery method\n\nFound and verified using `scopegrep` (https://github.com/not-ekalabya/scopegrep)\n\u2014 a semantic code-retrieval tool that surfaces every other call site of a\nsymbol alongside relevance-ranked results, which is what surfaced the\nalready-hardened header path as the direct comparison here \u2014 paired with\nan LLM coding agent (GLM-5.3) run as an open-ended security review of this\nrepository. Independently reproduced against the exact commit above before\nthis report was written. Happy to share the full session transcript on\nrequest.\n\n## Disclosure status\n\nNot shared with any other party or published. Submitting through this\nprivate channel per the project\u0027s stated security policy; no planned\npublic/conference disclosure ahead of a coordinated timeline.\n\n\n---\n\n## Maintainer triage update (2026-09-22)\n\n### Confirmed finding and scope\n\nWe confirmed that an attacker-controlled recursively nested JWT payload can cause a raw Python `RecursionError` to escape PyJWT at PyJWT 2.14.0 and the tested current source. The confirmed in-scope paths are direct decoding with `verify_signature=False` and `PyJWKClient.get_signing_key_from_jwt`, where payload parsing occurs before key lookup.\n\nThe demonstrated impact is limited to an uncaught exception for the affected call, which may surface as an application HTTP 500 when the application does not catch it. Testing did not demonstrate a worker or process crash, persistent resource exhaustion, resource amplification, authentication bypass, or confidentiality or integrity impact.\n\nThe separate JWKS-response subclaim is out of scope under the policy boundary that requires the application to trust its configured JWKS source and transport. The confirmed payload finding is not a duplicate of the earlier protected-header parser finding: it occurs in a distinct payload parsing path that remained affected after the earlier header-only fix.\n\n### Version and remediation status\n\nHistorical testing reproduced the confirmed payload behavior in all 20 official supported PyJWT 2.x releases from 2.0.0a1 through 2.14.0, inclusive. Unsupported PyJWT 1.7.1 also reproduces the behavior, but it is excluded from the advisory range under the supported-2.x policy. No supported unaffected release and no patched release exists. The exact evidence is `/Users/jpadilla/.codex/security-advisories/pyjwt/GHSA-42vr-xj54-vc7v-historical-range-20260922.md` (SHA-256 `c48f1ac35641e9382d53e6a879a71ad9a8fb4432bbe871f2b8330f8d166a2d81`) and `/Users/jpadilla/.codex/security-advisories/pyjwt/historical-range-42vr-20260922/historical-range-results.json` (SHA-256 `324997f231561bf6da39b8f9d1e272f69bfde8871a7863f5cb7b70e22e91f076`). The evidence-backed supported affected range is `\u003e= 2.0.0a1, \u003c= 2.14.0`.\n\nHistorical range verification is complete. A local fix commit exists and has passed independent review and the complete local CI suite, but it has not been merged into `master` or released. Consequently, `patched_versions` remains empty and this advisory remains in `triage`. The remaining next step is a maintainer decision on remediation and merge. After a fix lands in `master` and is released, `patched_versions` and advisory lifecycle can be updated in a separate approved batch.\n\n---\n\n## Maintainer remediation update (2026-09-23)\n\nThe confirmed payload-parser finding has been fixed on `master`. Commit\n`5fde08a6cf906aa7698de2d6391d88b73006b17b` converts a recursive\npayload parse failure to the expected `DecodeError`; commit\n`9bc06658f875b9b40091539140bbbdc4639161c3` makes the regression tests\ndeterministic across supported Python versions. This update supersedes the\n2026-09-22 remediation-status statement that the fix had not landed.\n\nThe original pre-verification payload reproducer and the\n`PyJWKClient.get_signing_key_from_jwt` path were covered by regression tests.\nThe exact landed tree passed the full 39-environment local tox matrix and\nGitHub CI for commit `9bc06658f875b9b40091539140bbbdc4639161c3` passed\nall 25 jobs, including Ubuntu Python 3.14 and 3.15. The demonstrated impact\nremains an uncaught request-level exception in affected releases; there is\nstill no evidence of process termination, persistent resource exhaustion,\nauthentication bypass, or confidentiality or integrity impact.\n\nThe supported affected range remains `\u003e= 2.0.0a1, \u003c= 2.14.0`. The latest\nreleased version is 2.14.0, which predates these commits; no released\npatched version exists yet, so `patched_versions` remains unset. CVSS v3.1\n5.3 (Medium) and CWE-248 remain unchanged. The advisory may now move from\ntriage to private draft. The next lifecycle step is a new supported 2.x\nrelease containing the fix, followed by separately approved patched-version\nand publication updates after release verification.\n\n---\n\n## Maintainer release update (2026-09-23)\n\nPyJWT 2.15.0 is the first released version containing the payload-parser fix. Its GitHub release tag points to commit `1d41a6478e1562e68ff667fcd703356acf085f68`, which includes fix commit `5fde08a6cf906aa7698de2d6391d88b73006b17b` and deterministic regression-test commit `9bc06658f875b9b40091539140bbbdc4639161c3`. PyPI published both the wheel and source distribution from that release commit through the successful production workflow at https://github.com/jpadilla/pyjwt/actions/runs/35891602963.\n\nThe published PyPI wheel (`pyjwt-2.15.0-py3-none-any.whl`, SHA-256 `7a3742debf6b879e912dbb9819ceec1594be812452b78c5f2e2dfc56564954f8`) was checked directly: the deeply nested unsigned payload now raises `DecodeError`, while an ordinary unsigned payload still decodes. The supported affected range remains `\u003e= 2.0.0a1, \u003c= 2.14.0`; the patched version is `2.15.0`. Earlier statements in this advisory that no released patched version exists are superseded by this update.\n\nThe confirmed impact remains an uncaught request-level exception in affected versions, not a demonstrated process crash or authentication bypass. The separate JWKS-response subclaim remains outside this advisory\u0027s confirmed PyJWT-owned scope.",
  "id": "GHSA-42vr-xj54-vc7v",
  "modified": "2026-09-30T15:41:05Z",
  "published": "2026-09-30T15:41:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-42vr-xj54-vc7v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101918"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/5fde08a6cf906aa7698de2d6391d88b73006b17b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jpadilla/pyjwt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/releases/tag/2.15.0"
    }
  ],
  "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"
    }
  ],
  "summary": "PyJWT: Unauthenticated RecursionError DoS in pre-verification payload parse (PyJWKClient.get_signing_key_from_jwt / verify_signature=False)"
}

GHSA-42WG-38GX-85RH

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

Summary

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

Details

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

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

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

PoC

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

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

Reproduction Python Script:

import zipfile

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

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

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

if __name__ == "__main__":
    create_poc()

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

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

Proposed Fix for restore.go:

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

// ...

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

Impact

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

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

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

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

GHSA-448J-QXG7-VQM3

Vulnerability from github – Published: 2026-08-13 21:36 – Updated: 2026-08-13 21:36
VLAI
Details

Uncaught Exception (CWE-248) in Kibana Cases can lead to denial of service via Input Data Manipulation (CAPEC-153). Malformed link syntax stored in a case comment was not rejected or sanitized when the comment was later formatted for display, and the resulting unhandled error prevented the affected case from being displayed. An authenticated user holding privileges to comment on a case could store such a comment, after which that case became inaccessible to every user who opened it until the stored comment was removed.

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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-49096"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-13T20:17:22Z",
    "severity": "MODERATE"
  },
  "details": "Uncaught Exception (CWE-248) in Kibana Cases can lead to denial of service via Input Data Manipulation (CAPEC-153). Malformed link syntax stored in a case comment was not rejected or sanitized when the comment was later formatted for display, and the resulting unhandled error prevented the affected case from being displayed. An authenticated user holding privileges to comment on a case could store such a comment, after which that case became inaccessible to every user who opened it until the stored comment was removed.",
  "id": "GHSA-448j-qxg7-vqm3",
  "modified": "2026-08-13T21:36:07Z",
  "published": "2026-08-13T21:36:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49096"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/kibana-8-19-20-9-3-5-9-4-2-security-update-esa-2026-136/389492"
    }
  ],
  "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-45RX-2JWX-CXFR

Vulnerability from github – Published: 2026-07-21 19:07 – Updated: 2026-07-21 19:07
VLAI
Summary
OpenTelemetry JavaScript: Denial of service in `JaegerPropagator` via unhandled exception on a malformed header
Details

Summary

@opentelemetry/propagator-jaeger decodes incoming HTTP header values with decodeURIComponent() without handling decode errors. A single request carrying a malformed percent-encoded value (for example a bare %) in an uber-trace-id or uberctx-* header throws an uncaught URIError, terminating any Node.js process that uses JaegerPropagator as its active propagator.

Impact

Denial of Service: Any unauthenticated remote attacker who can send an HTTP request to a service that has JaegerPropagator registered as the global propagator (e.g. via OTEL_PROPAGATORS=jaeger or propagation.setGlobalPropagator(new JaegerPropagator())) can terminate the process with a single request. Confidentiality and integrity are not affected.

Am I affected?

This issue affects only a specific, opt-in configuration. If you use OpenTelemetry's default propagators (W3C TraceContext and Baggage), you are not affected.

You are affected only if you have registered JaegerPropagator as the active propagator. Check for:

  • @opentelemetry/propagator-jaeger in your dependency tree, and
  • OTEL_PROPAGATORS set to jaeger (Jaeger only), or a direct propagation.setGlobalPropagator(new JaegerPropagator()) call in your code.

Note: if JaegerPropagator is combined with other propagators through a CompositePropagator (for example OTEL_PROPAGATORS=jaeger,tracecontext), the process does not terminate - the composite propagator catches the error - but affected requests silently fail to extract context. You should still upgrade.

Patched versions

  • @opentelemetry/propagator-jaeger 2.9.0

Remediation

Update @opentelemetry/propagator-jaeger to 2.9.0 or later. The propagator now ignores header values it cannot decode instead of throwing.

Interim mitigation (if you cannot update): Trace-context headers should never be accepted unfiltered from untrusted callers. Until you can upgrade, strip or validate the uber-trace-id and uberctx-* headers on inbound requests at your edge - for example with a reverse proxy, API gateway, or load balancer (nginx, Envoy, etc.) - so that only trusted upstream services can set them.

Details

JaegerPropagator.extract() calls decodeURIComponent() on raw header values at two unguarded call sites: the uber-trace-id trace header and each uberctx-* baggage value. decodeURIComponent() throws URIError: URI malformed on invalid percent-encoding. Because the HTTP instrumentation extracts context before its request-handler error wrapper, and a single configured propagator is not wrapped in a CompositePropagator (which would otherwise catch the error), the exception propagates as an uncaughtException and terminates the process.

Proof of concept

Against a service using JaegerPropagator:

curl -H 'uberctx-user: %' http://target/
# or
curl -H 'uber-trace-id: %' http://target/

The Node.js process exits with URIError: URI malformed and subsequent requests are refused.

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
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@opentelemetry/propagator-jaeger"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T19:07:28Z",
    "nvd_published_at": "2026-07-08T17:17:27Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`@opentelemetry/propagator-jaeger` decodes incoming HTTP header values with `decodeURIComponent()` without handling decode errors. A single request carrying a malformed percent-encoded value (for example a bare `%`) in an `uber-trace-id` or `uberctx-*` header throws an uncaught `URIError`, terminating any Node.js process that uses `JaegerPropagator` as its active propagator.\n\n\n## Impact\n\n**Denial of Service:** Any unauthenticated remote attacker who can send an HTTP request to a service that has `JaegerPropagator` registered as the global propagator (e.g. via `OTEL_PROPAGATORS=jaeger` or `propagation.setGlobalPropagator(new JaegerPropagator())`) can terminate the process with a single request. Confidentiality and integrity are not affected.\n\n## Am I affected?\n\nThis issue affects only a specific, opt-in configuration. If you use OpenTelemetry\u0027s default propagators (W3C TraceContext and Baggage), you are **not** affected.          \n\nYou are affected only if you have registered `JaegerPropagator` as the active propagator. Check for:\n\n- `@opentelemetry/propagator-jaeger` in your dependency tree, **and**\n- `OTEL_PROPAGATORS` set to `jaeger` (Jaeger only), **or** a direct `propagation.setGlobalPropagator(new JaegerPropagator())` call in your code.\n\nNote: if `JaegerPropagator` is combined with other propagators through a `CompositePropagator` (for example `OTEL_PROPAGATORS=jaeger,tracecontext`), the process does not terminate - the composite propagator catches the error - but affected requests silently fail to extract context. You should still upgrade.\n\n\n## Patched versions\n\n- `@opentelemetry/propagator-jaeger` 2.9.0\n\n## Remediation\n\nUpdate `@opentelemetry/propagator-jaeger` to 2.9.0 or later. The propagator now ignores header values it cannot decode instead of throwing.\n\n**Interim mitigation (if you cannot update):** Trace-context headers should never be accepted unfiltered from untrusted callers. Until you can upgrade, strip or validate the `uber-trace-id` and `uberctx-*` headers on inbound requests at your edge - for example with a reverse proxy, API gateway, or load balancer (nginx, Envoy, etc.) - so that only trusted upstream services can set them.\n\n## Details\n\n`JaegerPropagator.extract()` calls `decodeURIComponent()` on raw header values at two unguarded call sites: the `uber-trace-id` trace header and each `uberctx-*` baggage value. `decodeURIComponent()` throws `URIError: URI malformed` on invalid percent-encoding. Because the HTTP instrumentation extracts context before its request-handler error wrapper, and a single configured propagator is not wrapped in a `CompositePropagator` (which would otherwise catch the error), the exception propagates as an `uncaughtException` and terminates the process.\n\n## Proof of concept\n\nAgainst a service using `JaegerPropagator`:\n\n```bash\ncurl -H \u0027uberctx-user: %\u0027 http://target/\n# or\ncurl -H \u0027uber-trace-id: %\u0027 http://target/\n```\n\nThe Node.js process exits with `URIError: URI malformed` and subsequent requests are refused.",
  "id": "GHSA-45rx-2jwx-cxfr",
  "modified": "2026-07-21T19:07:28Z",
  "published": "2026-07-21T19:07:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-js/security/advisories/GHSA-45rx-2jwx-cxfr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59892"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-js/commit/b1c196d49d54caae59741cca0a9d57d101d7ea88"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-js/releases/tag/v2.9.0"
    }
  ],
  "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": "OpenTelemetry JavaScript: Denial of service in `JaegerPropagator` via unhandled exception on a malformed header"
}

GHSA-46WQ-28CX-MHW4

Vulnerability from github – Published: 2026-07-16 20:03 – Updated: 2026-07-16 20:03
VLAI
Summary
nimiq-primitives: Panic in TrieProof::verify via child_index unwrap on equal-length keys
Details

Impact

A malicious peer acting as a state-sync source can crash a syncing node by sending a crafted TrieChunk whose proof contains two TrieProofNodes with identical keys. TrieProof::verify() calls TrieProofNode::child_index() (primitives/src/trie/trie_proof_node.rs:94), which unconditionally unwraps KeyNibbles::get(self.key.len()). Because is_prefix_of returns true for two equal keys, execution reaches get(len), which returns None, and the unwrap() panics.

The panic is reached from untrusted network input (ResponseChunk → commit_chunks → put_chunk → proof.verify()) before any cryptographic proof verification, so the attacker does not need to produce a valid proof. Exploitation requires the attacker to be selected as the victim's sync peer while the victim is performing state sync, and the resulting crash is transient (the node restarts and re-syncs).

Affected: core-rs-albatross <= 1.5.1 (nimiq-primitives).

Patches

Fixed in 1.6.0 via https://github.com/nimiq/core-rs-albatross/pull/3789 (commit 41d35ace). child_index now rejects equal-length keys and returns MerkleRadixTrieError::WrongPrefix instead of unwrapping.

Workarounds

None other than syncing only from trusted peers. Upgrade to 1.6.0.

Severity
3.7 (Low)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "nimiq-primitives"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54541"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-16T20:03:00Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\n\nA malicious peer acting as a state-sync source can crash a syncing node by sending a crafted `TrieChunk` whose proof contains two `TrieProofNode`s with identical keys. `TrieProof::verify()` calls `TrieProofNode::child_index()` (`primitives/src/trie/trie_proof_node.rs:94`), which unconditionally unwraps `KeyNibbles::get(self.key.len())`. Because `is_prefix_of` returns `true` for two equal keys, execution reaches `get(len)`, which returns `None`, and the `unwrap()` panics.\n\nThe panic is reached from untrusted network input (`ResponseChunk` \u2192 `commit_chunks` \u2192 `put_chunk` \u2192 `proof.verify()`) **before** any cryptographic proof verification, so the attacker does not need to produce a valid proof. Exploitation requires the attacker to be selected as the victim\u0027s sync peer while the victim is performing state sync, and the resulting crash is transient (the node restarts and re-syncs).\n\nAffected: core-rs-albatross \u003c= 1.5.1 (`nimiq-primitives`).\n\n### Patches\n\nFixed in **1.6.0** via https://github.com/nimiq/core-rs-albatross/pull/3789 (commit `41d35ace`). `child_index` now rejects equal-length keys and returns `MerkleRadixTrieError::WrongPrefix` instead of unwrapping.\n\n### Workarounds\n\nNone other than syncing only from trusted peers. Upgrade to 1.6.0.",
  "id": "GHSA-46wq-28cx-mhw4",
  "modified": "2026-07-16T20:03:00Z",
  "published": "2026-07-16T20:03:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/security/advisories/GHSA-46wq-28cx-mhw4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/pull/3789"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/commit/41d35acee1b5cf3bc34ec3ddc1abbc03604e791e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nimiq/core-rs-albatross"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nimiq/core-rs-albatross/releases/tag/v1.6.0"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "nimiq-primitives: Panic in TrieProof::verify via child_index unwrap on equal-length keys"
}

GHSA-4CCP-5QCJ-7F48

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

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

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-9509"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-29T13:16:24Z",
    "severity": "HIGH"
  },
  "details": "An unhandled exception in Suprema BioStar 2 (Server), versions 2.9.8, 2.9.10, and 2.9.11, that allows an unauthenticated remote attacker to cause a denial of service (DoS) by sending HTTP POST requests to the \u2018/api/migration\u2019 endpoint. This request triggers a failure that halts critical processes, leaving the system offline until the services or server are manually restarted. As a result, access control readers cease to function, and potential failures may occur in third-party integrations. Since the exploit requires no privileges or user interaction and is trivial to automate, the impact on availability is high, and the effect extends to interconnected systems.",
  "id": "GHSA-4ccp-5qcj-7f48",
  "modified": "2026-05-29T15:30:33Z",
  "published": "2026-05-29T15:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9509"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-supremas-biostar"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-4CWX-7WF7-3272

Vulnerability from github – Published: 2026-08-03 19:19 – Updated: 2026-08-03 19:24
VLAI
Summary
undici vulnerable to cross-user information disclosure and parse-time crash via degenerate private cache directives
Details

Summary

Two issues in undici's cache interceptor, both fixed by the same patch on lib/util/cache.js:

  1. Shared-cache disclosure: Responses with malformed qualified Cache-Control: private directives such as private="" or private="," can be incorrectly stored in the default shared cache, then served to a later caller with the same cache key.
  2. Parse-time crash: Mixed unqualified-and-qualified private directives in the same header (such as public, max-age=60, private, private="hdr") cause an uncaught TypeError in the cache-control parser, terminating the request.

Impact

Shared-cache disclosure

Applications using interceptors.cache() in shared mode may cache a user-specific response and serve it to a later caller with the same cache key. This can disclose private response bodies and headers, including Set-Cookie.

Required conditions:

  • the cache interceptor is enabled in shared mode, including the default configuration;
  • an upstream returns a malformed directive such as Cache-Control: public, max-age=300, private="";
  • another request later matches the same cache key, without a separating Vary header.

Parse-time crash

Applications using interceptors.cache() against an upstream that returns a Cache-Control header combining unqualified private with qualified private="..." see an uncaught TypeError: output.private.concat is not a function during response handling. The request rejects; depending on the consumer's error handling, the process may exit.

Details

private="" is parsed as { private: [''] }. The shared-cache guard only rejects private === true, so the response can be stored. When served from cache, the previous user's body and headers may be returned to a different user.

For the crash variant, an unqualified private directive sets output.private = true, then a subsequent qualified private="hdr" directive attempts output.private.concat(['hdr']), which throws because boolean has no concat method.

The patch routes the qualified-directive path through a shared helper that normalizes empty-after-trim arrays to true and preserves existing true values, closing both vectors.

Patches

Upgrade to undici 7.29.0 or 8.9.0. Both releases fix the qualified private directive handling that caused the shared-cache storage and the parser crash.

Workarounds

Until patched, avoid shared interceptors.cache() for user-specific responses, use type: 'private', or disable caching for affected origins.

Credit

Disclosure variant reported by @h0rk1p via HackerOne report #3817497.

Severity
7.4 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "undici"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.29.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "undici"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-13697"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-248",
      "CWE-525"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-03T19:19:47Z",
    "nvd_published_at": "2026-07-29T17:16:50Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nTwo issues in undici\u0027s cache interceptor, both fixed by the same patch on `lib/util/cache.js`:\n\n1. **Shared-cache disclosure:** Responses with malformed qualified `Cache-Control: private` directives such as `private=\"\"` or `private=\",\"` can be incorrectly stored in the default shared cache, then served to a later caller with the same cache key.\n2. **Parse-time crash:** Mixed unqualified-and-qualified `private` directives in the same header (such as `public, max-age=60, private, private=\"hdr\"`) cause an uncaught `TypeError` in the cache-control parser, terminating the request.\n\n### Impact\n\n#### Shared-cache disclosure\n\nApplications using `interceptors.cache()` in shared mode may cache a user-specific response and serve it to a later caller with the same cache key. This can disclose private response bodies and headers, including `Set-Cookie`.\n\nRequired conditions:\n\n- the cache interceptor is enabled in shared mode, including the default configuration;\n- an upstream returns a malformed directive such as `Cache-Control: public, max-age=300, private=\"\"`;\n- another request later matches the same cache key, without a separating `Vary` header.\n\n#### Parse-time crash\n\nApplications using `interceptors.cache()` against an upstream that returns a `Cache-Control` header combining unqualified `private` with qualified `private=\"...\"` see an uncaught `TypeError: output.private.concat is not a function` during response handling. The request rejects; depending on the consumer\u0027s error handling, the process may exit.\n\n### Details\n\n`private=\"\"` is parsed as `{ private: [\u0027\u0027] }`. The shared-cache guard only rejects `private === true`, so the response can be stored. When served from cache, the previous user\u0027s body and headers may be returned to a different user.\n\nFor the crash variant, an unqualified `private` directive sets `output.private = true`, then a subsequent qualified `private=\"hdr\"` directive attempts `output.private.concat([\u0027hdr\u0027])`, which throws because boolean has no `concat` method.\n\nThe patch routes the qualified-directive path through a shared helper that normalizes empty-after-trim arrays to `true` and preserves existing `true` values, closing both vectors.\n\n### Patches\n\nUpgrade to `undici` 7.29.0 or 8.9.0. Both releases fix the qualified `private` directive handling that caused the shared-cache storage and the parser crash.\n\n### Workarounds\n\nUntil patched, avoid shared `interceptors.cache()` for user-specific responses, use `type: \u0027private\u0027`, or disable caching for affected origins.\n\n### Credit\n\nDisclosure variant reported by @h0rk1p via HackerOne report [#3817497](https://hackerone.com/reports/3817497).",
  "id": "GHSA-4cwx-7wf7-3272",
  "modified": "2026-08-03T19:24:25Z",
  "published": "2026-08-03T19:19:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/security/advisories/GHSA-4cwx-7wf7-3272"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13697"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/commit/4fe5bc5fefe5ac81a200fc8e1cf84b8bf8464451"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nodejs/undici"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/releases/tag/v7.29.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nodejs/undici/releases/tag/v8.9.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "undici vulnerable to cross-user information disclosure and parse-time crash via degenerate private cache directives"
}

GHSA-4H5X-W852-6G2X

Vulnerability from github – Published: 2026-09-22 00:30 – Updated: 2026-09-22 00:30
VLAI
Details

vLLM versions through 0.29.0 contain a denial of service vulnerability in the NIXL connector's metadata handling for prefill/decode disaggregated deployments. Attackers can send requests with incomplete kv_transfer_params dictionary entries to trigger an uncaught KeyError in EngineCore scheduling, causing the decode engine to terminate and making all routed requests fail until manual restart.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-94622"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-21T22:17:00Z",
    "severity": "HIGH"
  },
  "details": "vLLM versions through 0.29.0 contain a denial of service vulnerability in the NIXL connector\u0027s metadata handling for prefill/decode disaggregated deployments. Attackers can send requests with incomplete kv_transfer_params dictionary entries to trigger an uncaught KeyError in EngineCore scheduling, causing the decode engine to terminate and making all routed requests fail until manual restart.",
  "id": "GHSA-4h5x-w852-6g2x",
  "modified": "2026-09-22T00:30:55Z",
  "published": "2026-09-22T00:30:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94622"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/54807"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/blob/v0.29.0/vllm/distributed/kv_transfer/kv_connector/v1/nixl/metadata.py#L294-L312"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vllm-through-0.29.0-denial-of-service-via-incomplete-nixl-kv-transfer-metadata"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-4HGP-59H5-GVRJ

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

Summary

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

Details

Affected code

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

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

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

PoC

image

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

Impact

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

Remediation

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

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

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

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

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

GHSA-4MH8-R7RC-XPVC

Vulnerability from github – Published: 2026-09-30 23:53 – Updated: 2026-09-30 23:53
VLAI
Summary
fastify vulnerable to Denial of Service via unhandled exception on HTTP/2 trailer responses
Details

Impact

fastify crashes with an uncaught ERR_HTTP2_INVALID_CONNECTION_HEADERS exception when a route that registers a response trailer via reply.trailer() is served over HTTP/2. Fastify unconditionally adds the Transfer-Encoding: chunked header when a trailer is set, which is forbidden on HTTP/2, so Node.js throws while serializing the response headers. The exception is not caught and becomes an uncaughtException, terminating the Node.js process.

One unauthenticated HTTP/2 request to any route that uses trailers is enough to crash the server, dropping all in-flight requests, and the request can be repeated to keep the process down. Applications are affected only when HTTP/2 is enabled (http2: true) and at least one route registers a trailer. HTTP/1.x responses are not affected.

Patches

Upgrade to fastify 5.12.5 or later.

Workarounds

Avoid registering response trailers with reply.trailer() on routes served over HTTP/2 until upgrading.

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
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "fastify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.12.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-92081"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-248"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T23:53:44Z",
    "nvd_published_at": "2026-09-16T09:17:10Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n`fastify` crashes with an uncaught `ERR_HTTP2_INVALID_CONNECTION_HEADERS` exception when a route that registers a response trailer via `reply.trailer()` is served over HTTP/2. Fastify unconditionally adds the `Transfer-Encoding: chunked` header when a trailer is set, which is forbidden on HTTP/2, so Node.js throws while serializing the response headers. The exception is not caught and becomes an uncaughtException, terminating the Node.js process.\n\nOne unauthenticated HTTP/2 request to any route that uses trailers is enough to crash the server, dropping all in-flight requests, and the request can be repeated to keep the process down. Applications are affected only when HTTP/2 is enabled (`http2: true`) and at least one route registers a trailer. HTTP/1.x responses are not affected.\n\n### Patches\n\nUpgrade to `fastify` `5.12.5` or later.\n\n### Workarounds\n\nAvoid registering response trailers with `reply.trailer()` on routes served over HTTP/2 until upgrading.",
  "id": "GHSA-4mh8-r7rc-xpvc",
  "modified": "2026-09-30T23:53:44Z",
  "published": "2026-09-30T23:53:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify/security/advisories/GHSA-4mh8-r7rc-xpvc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92081"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify/issues/6574"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify/commit/ad06a4c3fe8a944a904f38068249b18b8f552e90"
    },
    {
      "type": "WEB",
      "url": "https://cna.openjsf.org/security-advisories.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fastify/fastify"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fastify/fastify/releases/tag/v5.12.5"
    }
  ],
  "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": "fastify vulnerable to Denial of Service via unhandled exception on HTTP/2 trailer responses"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list