Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the allocation and maintenance of a limited resource.

5567 vulnerabilities reference this CWE, most recent first.

GHSA-CPF9-PH2J-CCR9

Vulnerability from github – Published: 2026-04-16 21:09 – Updated: 2026-04-24 20:48
VLAI
Summary
zrok: Unauthenticated DoS via unbounded memory allocation in striped session cookie parsing
Details

Summary endpoints.GetSessionCookie parses an attacker-supplied cookie chunk count and calls make([]string, count) with no upper bound before any token validation occurs. The function is reached on every request to an OAuth-protected proxy share, allowing an unauthenticated remote attacker to trigger gigabyte-scale heap allocations per request, leading to process-level OOM termination or repeated goroutine panics. Both publicProxy and dynamicProxy are affected.

  • Attack Vector: Network — exploitable via a single HTTP request with a crafted Cookie header.
  • Attack Complexity: Low — no preconditions or chaining required; the attacker only needs to know the cookie name (publicly derivable from any OAuth redirect).
  • Privileges Required: None — reached before JWT validation or any authentication check.
  • User Interaction: None.
  • Scope: Unchanged — impact is confined to the affected proxy process.
  • Confidentiality Impact: None.
  • Integrity Impact: None.

Availability Impact: High — sustained or concurrent requests cause OOM process termination, taking down the proxy for all users of all shares it serves.

Affected Components - endpoints/oauthCookies.go — GetSessionCookie (line 81) - endpoints/publicProxy/authOAuth.go — handleOAuth (line 50) — call site, pre-auth - endpoints/dynamicProxy/cookies.go — getSessionCookie (line 29) — call site

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": "Go",
        "name": "github.com/openziti/zrok"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/openziti/zrok/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40303"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T21:09:08Z",
    "nvd_published_at": "2026-04-17T21:16:35Z",
    "severity": "HIGH"
  },
  "details": "**Summary**\nendpoints.GetSessionCookie parses an attacker-supplied cookie chunk count and calls make([]string, count) with no upper bound before any token validation occurs. The function is reached on every request to an OAuth-protected proxy share, allowing an unauthenticated remote attacker to trigger gigabyte-scale heap allocations per request, leading to process-level OOM termination or repeated goroutine panics. Both publicProxy and dynamicProxy are affected.\n\n- Attack Vector: Network \u2014 exploitable via a single HTTP request with a crafted Cookie header.\n- Attack Complexity: Low \u2014 no preconditions or chaining required; the attacker only needs to know the cookie name (publicly derivable from any OAuth redirect).\n- Privileges Required: None \u2014 reached before JWT validation or any authentication check.\n- User Interaction: None.\n- Scope: Unchanged \u2014 impact is confined to the affected proxy process.\n- Confidentiality Impact: None.\n- Integrity Impact: None.\n\nAvailability Impact: High \u2014 sustained or concurrent requests cause OOM process termination, taking down the proxy for all users of all shares it serves.\n\n**Affected Components**\n- endpoints/oauthCookies.go \u2014 GetSessionCookie (line 81)\n- endpoints/publicProxy/authOAuth.go \u2014 handleOAuth (line 50) \u2014 call site, pre-auth\n- endpoints/dynamicProxy/cookies.go \u2014 getSessionCookie (line 29) \u2014 call site",
  "id": "GHSA-cpf9-ph2j-ccr9",
  "modified": "2026-04-24T20:48:49Z",
  "published": "2026-04-16T21:09:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openziti/zrok/security/advisories/GHSA-cpf9-ph2j-ccr9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40303"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openziti/zrok"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openziti/zrok/releases/tag/v2.0.1"
    }
  ],
  "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": "zrok: Unauthenticated DoS via unbounded memory allocation in striped session cookie parsing"
}

GHSA-CPH5-3PGR-C82G

Vulnerability from github – Published: 2024-10-31 20:37 – Updated: 2024-11-04 13:48
VLAI
Summary
Gnark out-of-memory during deserialization with crafted inputs
Details

Thanks @pventuzelo for reporting.

From the correspondence:

Hi,

We (Fuzzinglabs & Lambdaclass) found that during deserialization of certain files representing a VerifyingKey, an excessive memory allocation is happening consuming a lot of resources and even triggering a crash with the error fatal error: runtime: out of memory.

Please find the details below:

Vulnerability Details

  • Severity: Critical -> DoS
  • Affected Component: Deserialization

Environment

  • Compiler Version: go version go1.22.2 linux/amd64

  • Distro Version: Ubuntu 24.04.1 LTS

  • Additional Environment Details:

  • [github.com/consensys/gnark](http://github.com/consensys/gnark) v0.11.0
  • [github.com/consensys/gnark-crypto](http://github.com/consensys/gnark-crypto) v0.14.1-0.20240909142611-e6b99e74cec1

Steps to Reproduce

You can download the needed files here: https://drive.google.com/drive/folders/1KQ5I3vv4bUllvqbatGappwbAkIcR2NI_?usp=sharing

You have to run

shell go run gnark_poc.go

in a terminal.

Running the provided code will result in a memory crash or an extremely large memory allocation, which can be observed using the following command:

shell go tool pprof -web mem.pprof

Root Cause Analysis

The provided code loads a VerifyingKey from old.vk by calling the ReadFrom function. This function is implemented in backend/groth16/bn254/marshal.go within the gnark library.

The provided example uses the elliptic curve BN-254, so the code resides in the backend/groth16/bn254/ repertory. However, the same error exists in other repertories, such as backend/groth16/bls12-377/.

At line 207, a slice is allocated with a length of nbCommitments. This variable is directly extracted from the deserialized file, which, in our case, has a value of 2,327,186,600. This large value may be too big for some configurations, leading to memory allocations of approximately ±1 TB, as observed with pprof.

Detailed Behavior

shell go run gnark_poc.go

``` fatal error: runtime: out of memory

runtime stack: runtime.throw({0x5fe946?, 0x2052ae?}) /usr/lib/go-1.22/src/runtime/panic.go:1023 +0x5c fp=0x7ffd65b321a0 sp=0x7ffd65b32170 pc=0x438a9c runtime.sysMapOS(0xc000400000, 0x8ab6400000) /usr/lib/go-1.22/src/runtime/mem_linux.go:167 +0x11b fp=0x7ffd65b321e0 sp=0x7ffd65b321a0 pc=0x418bbb runtime.sysMap(0xc000400000, 0x8ab6400000, 0x7b19c8?) /usr/lib/go-1.22/src/runtime/mem.go:155 +0x34 fp=0x7ffd65b32200 sp=0x7ffd65b321e0 pc=0x418634 runtime.(mheap).grow(0x7a17c0, 0x455b066?) /usr/lib/go-1.22/src/runtime/mheap.go:1534 +0x236 fp=0x7ffd65b32270 sp=0x7ffd65b32200 pc=0x42b176 runtime.(mheap).allocSpan(0x7a17c0, 0x455b066, 0x0, 0x1) /usr/lib/go-1.22/src/runtime/mheap.go:1246 +0x1b0 fp=0x7ffd65b32310 sp=0x7ffd65b32270 pc=0x42a850 runtime.(*mheap).alloc.func1() /usr/lib/go-1.22/src/runtime/mheap.go:964 +0x5c fp=0x7ffd65b32358 sp=0x7ffd65b32310 pc=0x42a2fc runtime.systemstack(0x46d79f) /usr/lib/go-1.22/src/runtime/asm_amd64.s:509 +0x4a fp=0x7ffd65b32368 sp=0x7ffd65b32358 pc=0x46912a

goroutine 1 gp=0xc0000061c0 m=0 mp=0x798ca0 [running]: runtime.systemstack_switch() /usr/lib/go-1.22/src/runtime/asm_amd64.s:474 +0x8 fp=0xc000031b68 sp=0xc000031b58 pc=0x4690c8 runtime.(mheap).alloc(0x5bc040?, 0xc00012bb08?, 0xa0?) /usr/lib/go-1.22/src/runtime/mheap.go:958 +0x5b fp=0xc000031bb0 sp=0xc000031b68 pc=0x42a25b runtime.(mcache).allocLarge(0xc000126510?, 0x8ab60ca800, 0x1) /usr/lib/go-1.22/src/runtime/mcache.go:234 +0x87 fp=0xc000031c00 sp=0xc000031bb0 pc=0x4176e7 runtime.mallocgc(0x8ab60ca800, 0x5d92a0, 0x1) /usr/lib/go-1.22/src/runtime/malloc.go:1165 +0x597 fp=0xc000031c88 sp=0xc000031c00 pc=0x40ef97 runtime.makeslice(0xc00011c180?, 0x0?, 0x2?) /usr/lib/go-1.22/src/runtime/slice.go:107 +0x49 fp=0xc000031cb0 sp=0xc000031c88 pc=0x4500c9 github.com/consensys/gnark/backend/groth16/bn254.(*VerifyingKey).readFrom(0xc0001b7088 /home/raunan/go/pkg/mod/github.com/!ronan!thoraval/gnark@v0.0.0-20241007163125-4c0a7511c3d1/backend/groth16/bn254/marshal.go:214 +0x765 fp=0xc000031ea8 sp=0xc000031cb0 pc=0x59b205 github.com/consensys/gnark/backend/groth16/bn254.(*VerifyingKey).ReadFrom(0x100469020 /home/raunan/go/pkg/mod/github.com/!ronan!thoraval/gnark@v0.0.0-20241007163125-4c0a7511c3d1/backend/groth16/bn254/marshal.go:166 +0x1f fp=0xc000031ed8 sp=0xc000031ea8 pc=0x59aa5f main.main() /home/raunan/gnark_poc/gnark_poc/gnark_poc.go:19 +0xba fp=0xc000031f50 sp=0xc000031ed8 pc=0x5addda runtime.main() /usr/lib/go-1.22/src/runtime/proc.go:271 +0x29d fp=0xc000031fe0 sp=0xc000031f50 pc=0x43b55d runtime.goexit({}) /usr/lib/go-1.22/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc000031fe8 sp=0xc000031fe0 pc=0x46b0e1

goroutine 2 gp=0xc000006c40 m=nil [force gc (idle)]: runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) /usr/lib/go-1.22/src/runtime/proc.go:402 +0xce fp=0xc000074fa8 sp=0xc000074f88 pc=0x43b98e runtime.goparkunlock(...) /usr/lib/go-1.22/src/runtime/proc.go:408 runtime.forcegchelper() /usr/lib/go-1.22/src/runtime/proc.go:326 +0xb3 fp=0xc000074fe0 sp=0xc000074fa8 pc=0x43b813 runtime.goexit({}) /usr/lib/go-1.22/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc000074fe8 sp=0xc000074fe0 pc=0x46b0e1 created by runtime.init.6 in goroutine 1 /usr/lib/go-1.22/src/runtime/proc.go:314 +0x1a

goroutine 3 gp=0xc000007180 m=nil [GC sweep wait]: runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) /usr/lib/go-1.22/src/runtime/proc.go:402 +0xce fp=0xc000075780 sp=0xc000075760 pc=0x43b98e runtime.goparkunlock(...) /usr/lib/go-1.22/src/runtime/proc.go:408 runtime.bgsweep(0xc0000240e0) /usr/lib/go-1.22/src/runtime/mgcsweep.go:278 +0x94 fp=0xc0000757c8 sp=0xc000075780 pc=0x426cf4 runtime.gcenable.gowrap1() /usr/lib/go-1.22/src/runtime/mgc.go:203 +0x25 fp=0xc0000757e0 sp=0xc0000757c8 pc=0x41b845 runtime.goexit({}) /usr/lib/go-1.22/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc0000757e8 sp=0xc0000757e0 pc=0x46b0e1 created by runtime.gcenable in goroutine 1 /usr/lib/go-1.22/src/runtime/mgc.go:203 +0x66

goroutine 4 gp=0xc000007340 m=nil [GC scavenge wait]: runtime.gopark(0xc0000240e0?, 0x657100?, 0x1?, 0x0?, 0xc000007340?) /usr/lib/go-1.22/src/runtime/proc.go:402 +0xce fp=0xc000075f78 sp=0xc000075f58 pc=0x43b98e runtime.goparkunlock(...) /usr/lib/go-1.22/src/runtime/proc.go:408 runtime.(*scavengerState).park(0x797520) /usr/lib/go-1.22/src/runtime/mgcscavenge.go:425 +0x49 fp=0xc000075fa8 sp=0xc000075f78 pc=0x4246e9 runtime.bgscavenge(0xc0000240e0) /usr/lib/go-1.22/src/runtime/mgcscavenge.go:653 +0x3c fp=0xc000075fc8 sp=0xc000075fa8 pc=0x424c7c runtime.gcenable.gowrap2() /usr/lib/go-1.22/src/runtime/mgc.go:204 +0x25 fp=0xc000075fe0 sp=0xc000075fc8 pc=0x41b7e5 runtime.goexit({}) /usr/lib/go-1.22/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc000075fe8 sp=0xc000075fe0 pc=0x46b0e1 created by runtime.gcenable in goroutine 1 /usr/lib/go-1.22/src/runtime/mgc.go:204 +0xa5

goroutine 18 gp=0xc000102700 m=nil [finalizer wait]: runtime.gopark(0xc000074648?, 0x40f445?, 0xa8?, 0x1?, 0xc0000061c0?) /usr/lib/go-1.22/src/runtime/proc.go:402 +0xce fp=0xc000074620 sp=0xc000074600 pc=0x43b98e runtime.runfinq() /usr/lib/go-1.22/src/runtime/mfinal.go:194 +0x107 fp=0xc0000747e0 sp=0xc000074620 pc=0x41a887 runtime.goexit({}) /usr/lib/go-1.22/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc0000747e8 sp=0xc0000747e0 pc=0x46b0e1 created by runtime.createfing in goroutine 1 /usr/lib/go-1.22/src/runtime/mfinal.go:164 +0x3d exit status 2 ```

Appendices

This problem can also happen with ProvingKey.

Impact

Prover and verifier denial of service in case of maliciously crafted inputs (public key, verification key).

Patches

The issue is patched in https://github.com/Consensys/gnark/pull/1307. It was merged to gnark master at https://github.com/Consensys/gnark/commit/47ae846339add2bdf9983e499342bfdfe195191d. The fix will be incorporated in the next minor release of gnark (v0.11.1).

Workarounds

There are no convenient work-arounds currently. The best approach currently is to run key verification as a separate service which halts the verification pipeline in case of OOM when verification keys come from untrusted sources.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.11.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/consensys/gnark"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-50354"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-31T20:37:00Z",
    "nvd_published_at": "2024-10-31T16:15:05Z",
    "severity": "MODERATE"
  },
  "details": "Thanks @pventuzelo for reporting.\n\nFrom the correspondence:\n\n\u003e Hi,\n\u003e \n\u003e We (Fuzzinglabs \u0026 Lambdaclass) found that during deserialization of certain files representing a `VerifyingKey`, an excessive memory allocation is happening consuming a lot of resources and even triggering a crash with the error `fatal error: runtime: out of memory`.\n\u003e \n\u003e Please find the details below:\n\u003e \n\u003e ## Vulnerability Details\n\u003e \n\u003e - **Severity:** Critical -\u003e DoS\n\u003e - **Affected Component:** Deserialization\n\u003e \n\u003e ## Environment\n\u003e \n\u003e - **Compiler Version:** go version go1.22.2 linux/amd64\n\u003e - **Distro Version:** Ubuntu 24.04.1 LTS\n\u003e \n\u003e - **Additional Environment Details:**\n\u003e   - `[github.com/consensys/gnark](http://github.com/consensys/gnark) v0.11.0`\n\u003e   - `[github.com/consensys/gnark-crypto](http://github.com/consensys/gnark-crypto) v0.14.1-0.20240909142611-e6b99e74cec1`\n\u003e \n\u003e ## Steps to Reproduce\n\u003e \n\u003e You can download the needed files here: https://drive.google.com/drive/folders/1KQ5I3vv4bUllvqbatGappwbAkIcR2NI_?usp=sharing\n\u003e \n\u003e You have to run\n\u003e \n\u003e ```shell\n\u003e go run gnark_poc.go\n\u003e ```\n\u003e \n\u003e in a terminal.\n\u003e \n\u003e Running the provided code will result in a memory crash or an extremely large memory allocation, which can be observed using the following command:\n\u003e \n\u003e ```shell\n\u003e go tool pprof -web mem.pprof\n\u003e ```\n\u003e \n\u003e ## Root Cause Analysis\n\u003e \n\u003e The provided code loads a `VerifyingKey` from `old.vk` by calling the `ReadFrom` function. This function is implemented in [backend/groth16/bn254/marshal.go](https://github.com/Consensys/gnark/blob/ca8e1568f47ae6b717eda0a6734d87645edaecf7/backend/groth16/bn254/marshal.go#L174C2-L174C25) within the [gnark](https://github.com/Consensys/gnark) library.\n\u003e \n\u003e The provided example uses the elliptic curve BN-254, so the code resides in the [backend/groth16/bn254/](https://github.com/Consensys/gnark/blob/ca8e1568f47ae6b717eda0a6734d87645edaecf7/backend/groth16/bn254/) repertory. However, the same error exists in other repertories, such as [backend/groth16/bls12-377/](https://github.com/Consensys/gnark/blob/ca8e1568f47ae6b717eda0a6734d87645edaecf7/backend/groth16/bls12-377/).\n\u003e \n\u003e At [line 207](https://github.com/Consensys/gnark/blob/ca8e1568f47ae6b717eda0a6734d87645edaecf7/backend/groth16/bn254/marshal.go#L207), a slice is allocated with a length of `nbCommitments`. This variable is directly extracted from the deserialized file, which, in our case, has a value of `2,327,186,600`. This large value may be too big for some configurations, leading to memory allocations of approximately \u00b11\u202fTB, as observed with `pprof`.\n\u003e \n\u003e ## Detailed Behavior\n\u003e \n\u003e ```shell\n\u003e go run gnark_poc.go\n\u003e ```\n\u003e \n\u003e ```\n\u003e fatal error: runtime: out of memory\n\u003e \n\u003e runtime stack:\n\u003e runtime.throw({0x5fe946?, 0x2052ae?})\n\u003e /usr/lib/go-1.22/src/runtime/panic.go:1023 +0x5c fp=0x7ffd65b321a0 sp=0x7ffd65b32170 pc=0x438a9c\n\u003e runtime.sysMapOS(0xc000400000, 0x8ab6400000)\n\u003e /usr/lib/go-1.22/src/runtime/mem_linux.go:167 +0x11b fp=0x7ffd65b321e0 sp=0x7ffd65b321a0 pc=0x418bbb\n\u003e runtime.sysMap(0xc000400000, 0x8ab6400000, 0x7b19c8?)\n\u003e /usr/lib/go-1.22/src/runtime/mem.go:155 +0x34 fp=0x7ffd65b32200 sp=0x7ffd65b321e0 pc=0x418634\n\u003e runtime.(*mheap).grow(0x7a17c0, 0x455b066?)\n\u003e /usr/lib/go-1.22/src/runtime/mheap.go:1534 +0x236 fp=0x7ffd65b32270 sp=0x7ffd65b32200 pc=0x42b176\n\u003e runtime.(*mheap).allocSpan(0x7a17c0, 0x455b066, 0x0, 0x1)\n\u003e /usr/lib/go-1.22/src/runtime/mheap.go:1246 +0x1b0 fp=0x7ffd65b32310 sp=0x7ffd65b32270 pc=0x42a850\n\u003e runtime.(*mheap).alloc.func1()\n\u003e /usr/lib/go-1.22/src/runtime/mheap.go:964 +0x5c fp=0x7ffd65b32358 sp=0x7ffd65b32310 pc=0x42a2fc\n\u003e runtime.systemstack(0x46d79f)\n\u003e /usr/lib/go-1.22/src/runtime/asm_amd64.s:509 +0x4a fp=0x7ffd65b32368 sp=0x7ffd65b32358 pc=0x46912a\n\u003e \n\u003e goroutine 1 gp=0xc0000061c0 m=0 mp=0x798ca0 [running]:\n\u003e runtime.systemstack_switch()\n\u003e /usr/lib/go-1.22/src/runtime/asm_amd64.s:474 +0x8 fp=0xc000031b68 sp=0xc000031b58 pc=0x4690c8\n\u003e runtime.(*mheap).alloc(0x5bc040?, 0xc00012bb08?, 0xa0?)\n\u003e /usr/lib/go-1.22/src/runtime/mheap.go:958 +0x5b fp=0xc000031bb0 sp=0xc000031b68 pc=0x42a25b\n\u003e runtime.(*mcache).allocLarge(0xc000126510?, 0x8ab60ca800, 0x1)\n\u003e /usr/lib/go-1.22/src/runtime/mcache.go:234 +0x87 fp=0xc000031c00 sp=0xc000031bb0 pc=0x4176e7\n\u003e runtime.mallocgc(0x8ab60ca800, 0x5d92a0, 0x1)\n\u003e /usr/lib/go-1.22/src/runtime/malloc.go:1165 +0x597 fp=0xc000031c88 sp=0xc000031c00 pc=0x40ef97\n\u003e runtime.makeslice(0xc00011c180?, 0x0?, 0x2?)\n\u003e /usr/lib/go-1.22/src/runtime/slice.go:107 +0x49 fp=0xc000031cb0 sp=0xc000031c88 pc=0x4500c9\n\u003e [github.com/consensys/gnark/backend/groth16/bn254.(*VerifyingKey).readFrom(0xc0001b7088](http://github.com/consensys/gnark/backend/groth16/bn254.(*VerifyingKey).readFrom(0xc0001b7088), {0x6598a0, 0xc00011dc50}, 0x0)\n\u003e /home/raunan/go/pkg/mod/[github.com/!ronan!thoraval/gnark@v0.0.0-20241007163125-4c0a7511c3d1/backend/groth16/bn254/marshal.go:214](http://github.com/!ronan!thoraval/gnark@v0.0.0-20241007163125-4c0a7511c3d1/backend/groth16/bn254/marshal.go:214) +0x765 fp=0xc000031ea8 sp=0xc000031cb0 pc=0x59b205\n\u003e [github.com/consensys/gnark/backend/groth16/bn254.(*VerifyingKey).ReadFrom(0x100469020](http://github.com/consensys/gnark/backend/groth16/bn254.(*VerifyingKey).ReadFrom(0x100469020)?, {0x6598a0?, 0xc00011dc50?})\n\u003e /home/raunan/go/pkg/mod/[github.com/!ronan!thoraval/gnark@v0.0.0-20241007163125-4c0a7511c3d1/backend/groth16/bn254/marshal.go:166](http://github.com/!ronan!thoraval/gnark@v0.0.0-20241007163125-4c0a7511c3d1/backend/groth16/bn254/marshal.go:166) +0x1f fp=0xc000031ed8 sp=0xc000031ea8 pc=0x59aa5f\n\u003e main.main()\n\u003e /home/raunan/gnark_poc/gnark_poc/gnark_poc.go:19 +0xba fp=0xc000031f50 sp=0xc000031ed8 pc=0x5addda\n\u003e runtime.main()\n\u003e /usr/lib/go-1.22/src/runtime/proc.go:271 +0x29d fp=0xc000031fe0 sp=0xc000031f50 pc=0x43b55d\n\u003e runtime.goexit({})\n\u003e /usr/lib/go-1.22/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc000031fe8 sp=0xc000031fe0 pc=0x46b0e1\n\u003e \n\u003e goroutine 2 gp=0xc000006c40 m=nil [force gc (idle)]:\n\u003e runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)\n\u003e /usr/lib/go-1.22/src/runtime/proc.go:402 +0xce fp=0xc000074fa8 sp=0xc000074f88 pc=0x43b98e\n\u003e runtime.goparkunlock(...)\n\u003e /usr/lib/go-1.22/src/runtime/proc.go:408\n\u003e runtime.forcegchelper()\n\u003e /usr/lib/go-1.22/src/runtime/proc.go:326 +0xb3 fp=0xc000074fe0 sp=0xc000074fa8 pc=0x43b813\n\u003e runtime.goexit({})\n\u003e /usr/lib/go-1.22/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc000074fe8 sp=0xc000074fe0 pc=0x46b0e1\n\u003e created by runtime.init.6 in goroutine 1\n\u003e /usr/lib/go-1.22/src/runtime/proc.go:314 +0x1a\n\u003e \n\u003e goroutine 3 gp=0xc000007180 m=nil [GC sweep wait]:\n\u003e runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)\n\u003e /usr/lib/go-1.22/src/runtime/proc.go:402 +0xce fp=0xc000075780 sp=0xc000075760 pc=0x43b98e\n\u003e runtime.goparkunlock(...)\n\u003e /usr/lib/go-1.22/src/runtime/proc.go:408\n\u003e runtime.bgsweep(0xc0000240e0)\n\u003e /usr/lib/go-1.22/src/runtime/mgcsweep.go:278 +0x94 fp=0xc0000757c8 sp=0xc000075780 pc=0x426cf4\n\u003e runtime.gcenable.gowrap1()\n\u003e /usr/lib/go-1.22/src/runtime/mgc.go:203 +0x25 fp=0xc0000757e0 sp=0xc0000757c8 pc=0x41b845\n\u003e runtime.goexit({})\n\u003e /usr/lib/go-1.22/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc0000757e8 sp=0xc0000757e0 pc=0x46b0e1\n\u003e created by runtime.gcenable in goroutine 1\n\u003e /usr/lib/go-1.22/src/runtime/mgc.go:203 +0x66\n\u003e \n\u003e goroutine 4 gp=0xc000007340 m=nil [GC scavenge wait]:\n\u003e runtime.gopark(0xc0000240e0?, 0x657100?, 0x1?, 0x0?, 0xc000007340?)\n\u003e /usr/lib/go-1.22/src/runtime/proc.go:402 +0xce fp=0xc000075f78 sp=0xc000075f58 pc=0x43b98e\n\u003e runtime.goparkunlock(...)\n\u003e /usr/lib/go-1.22/src/runtime/proc.go:408\n\u003e runtime.(*scavengerState).park(0x797520)\n\u003e /usr/lib/go-1.22/src/runtime/mgcscavenge.go:425 +0x49 fp=0xc000075fa8 sp=0xc000075f78 pc=0x4246e9\n\u003e runtime.bgscavenge(0xc0000240e0)\n\u003e /usr/lib/go-1.22/src/runtime/mgcscavenge.go:653 +0x3c fp=0xc000075fc8 sp=0xc000075fa8 pc=0x424c7c\n\u003e runtime.gcenable.gowrap2()\n\u003e /usr/lib/go-1.22/src/runtime/mgc.go:204 +0x25 fp=0xc000075fe0 sp=0xc000075fc8 pc=0x41b7e5\n\u003e runtime.goexit({})\n\u003e /usr/lib/go-1.22/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc000075fe8 sp=0xc000075fe0 pc=0x46b0e1\n\u003e created by runtime.gcenable in goroutine 1\n\u003e /usr/lib/go-1.22/src/runtime/mgc.go:204 +0xa5\n\u003e \n\u003e goroutine 18 gp=0xc000102700 m=nil [finalizer wait]:\n\u003e runtime.gopark(0xc000074648?, 0x40f445?, 0xa8?, 0x1?, 0xc0000061c0?)\n\u003e /usr/lib/go-1.22/src/runtime/proc.go:402 +0xce fp=0xc000074620 sp=0xc000074600 pc=0x43b98e\n\u003e runtime.runfinq()\n\u003e /usr/lib/go-1.22/src/runtime/mfinal.go:194 +0x107 fp=0xc0000747e0 sp=0xc000074620 pc=0x41a887\n\u003e runtime.goexit({})\n\u003e /usr/lib/go-1.22/src/runtime/asm_amd64.s:1695 +0x1 fp=0xc0000747e8 sp=0xc0000747e0 pc=0x46b0e1\n\u003e created by runtime.createfing in goroutine 1\n\u003e /usr/lib/go-1.22/src/runtime/mfinal.go:164 +0x3d\n\u003e exit status 2\n\u003e ```\n\u003e \n\u003e ## Appendices\n\u003e \n\u003e This problem can also happen with `ProvingKey`.\n\n### Impact\n\nProver and verifier denial of service in case of maliciously crafted inputs (public key, verification key).\n\n### Patches\n\nThe issue is patched in https://github.com/Consensys/gnark/pull/1307. It was merged to gnark master at https://github.com/Consensys/gnark/commit/47ae846339add2bdf9983e499342bfdfe195191d. The fix will be incorporated in the next minor release of gnark (v0.11.1).\n\n### Workarounds\n\nThere are no convenient work-arounds currently. The best approach currently is to run key verification as a separate service which halts the verification pipeline in case of OOM when verification keys come from untrusted sources.",
  "id": "GHSA-cph5-3pgr-c82g",
  "modified": "2024-11-04T13:48:55Z",
  "published": "2024-10-31T20:37:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Consensys/gnark/security/advisories/GHSA-cph5-3pgr-c82g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50354"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Consensys/gnark/pull/1307"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Consensys/gnark/commit/47ae846339add2bdf9983e499342bfdfe195191d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Consensys/gnark"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-cph5-3pgr-c82g"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gnark out-of-memory during deserialization with crafted inputs"
}

GHSA-CPH5-M8F7-6C5X

Vulnerability from github – Published: 2021-09-01 18:23 – Updated: 2022-09-14 21:28
VLAI
Summary
axios Inefficient Regular Expression Complexity vulnerability
Details

axios before v0.21.2 is vulnerable to Inefficient Regular Expression Complexity.

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": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.21.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3749"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-09-01T18:14:02Z",
    "nvd_published_at": "2021-08-31T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "axios before v0.21.2 is vulnerable to Inefficient Regular Expression Complexity.",
  "id": "GHSA-cph5-m8f7-6c5x",
  "modified": "2022-09-14T21:28:32Z",
  "published": "2021-09-01T18:23:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3749"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/commit/5b457116e31db0e88fede6c428e969e87f290929"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/axios"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rfc5c478053ff808671aef170f3d9fc9d05cc1fab8fb64431edc66103@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rfa094029c959da0f7c8cd7dc9c4e59d21b03457bf0cedf6c93e1bb0a@%3Cdev.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rc263bfc5b53afcb7e849605478d73f5556eb0c00d1f912084e407289@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ra15d63c54dc6474b29f72ae4324bcb03038758545b3ab800845de7a1@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r74d0b359408fff31f87445261f0ee13bdfcac7d66f6b8e846face321@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r7324ecc35b8027a51cb6ed629490fcd3b2d7cf01c424746ed5744bf1@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r4bf1b32983f50be00f9752214c1b53738b621be1c2b0dbd68c7f2391@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3ae6d2654f92c5851bdb73b35e96b0e4e3da39f28ac7a1b15ae3aab8@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r216f0fd0a3833856d6a6a1fada488cadba45f447d87010024328ccf2@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r075d464dce95cd13c03ff9384658edcccd5ab2983b82bfc72b62bb10@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://huntr.dev/bounties/1e8f07fc-c384-4ff9-8498-0690de2e8c31"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/axios/axios"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-637483.pdf"
    }
  ],
  "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": "axios Inefficient Regular Expression Complexity vulnerability"
}

GHSA-CPJV-M49G-H8M9

Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38
VLAI
Details

Nextcloud Server before 9.0.55 and 10.0.2 suffers from a Denial of Service attack. Due to an error in the application logic an authenticated adversary may trigger an endless recursion in the application leading to a potential Denial of Service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-0886"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-674"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-04-05T20:59:00Z",
    "severity": "MODERATE"
  },
  "details": "Nextcloud Server before 9.0.55 and 10.0.2 suffers from a Denial of Service attack. Due to an error in the application logic an authenticated adversary may trigger an endless recursion in the application leading to a potential Denial of Service.",
  "id": "GHSA-cpjv-m49g-h8m9",
  "modified": "2022-05-13T01:38:26Z",
  "published": "2022-05-13T01:38:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0886"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/174524"
    },
    {
      "type": "WEB",
      "url": "https://nextcloud.com/security/advisory/?id=nc-sa-2017-004"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CPQF-F22C-R95X

Vulnerability from github – Published: 2025-12-12 16:41 – Updated: 2025-12-12 16:41
VLAI
Summary
Vite Plugin React has a Denial of Service Vulnerability in React Server Components
Details

Impact

@vitejs/plugin-rsc vendors react-server-dom-webpack, which contained a vulnerability in versions prior to 19.2.3. See details in React repository's advisory https://github.com/facebook/react/security/advisories/GHSA-7gmr-mq3h-m5h9

Patches

Upgrade immediately to @vitejs/plugin-rsc@0.5.7 or later.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.5.6"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@vitejs/plugin-rsc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395",
      "CWE-400",
      "CWE-502"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-12T16:41:08Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\n`@vitejs/plugin-rsc` vendors `react-server-dom-webpack`, which contained a vulnerability in versions prior to 19.2.3. See details in React repository\u0027s advisory https://github.com/facebook/react/security/advisories/GHSA-7gmr-mq3h-m5h9\n\n### Patches\n\nUpgrade immediately to `@vitejs/plugin-rsc@0.5.7` or later.",
  "id": "GHSA-cpqf-f22c-r95x",
  "modified": "2025-12-12T16:41:08Z",
  "published": "2025-12-12T16:41:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vitejs/vite-plugin-react/security/advisories/GHSA-cpqf-f22c-r95x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vitejs/vite-plugin-react"
    }
  ],
  "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": "Vite Plugin React has a Denial of Service Vulnerability in React Server Components"
}

GHSA-CPV9-4HM5-JJHJ

Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2022-05-24 17:33
VLAI
Details

Uncontrolled resource consumption vulnerability in Ethernet Port on MELSEC iQ-R, Q and L series CPU modules (R 00/01/02 CPU firmware versions '20' and earlier, R 04/08/16/32/120 (EN) CPU firmware versions '52' and earlier, R 08/16/32/120 SFCPU firmware versions '22' and earlier, R 08/16/32/120 PCPU all versions, R 08/16/32/120 PSFCPU all versions, R 16/32/64 MTCPU all versions, Q03 UDECPU, Q 04/06/10/13/20/26/50/100 UDEHCPU serial number '22081' and earlier , Q 03/04/06/13/26 UDVCPU serial number '22031' and earlier, Q 04/06/13/26 UDPVCPU serial number '22031' and earlier, Q 172/173 DCPU all versions, Q 172/173 DSCPU all versions, Q 170 MCPU all versions, Q 170 MSCPU all versions, L 02/06/26 CPU (-P) and L 26 CPU - (P) BT all versions) allows a remote unauthenticated attacker to stop the Ethernet communication functions of the products via a specially crafted packet, which may lead to a denial of service (DoS) condition .

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-5652"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-02T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Uncontrolled resource consumption vulnerability in Ethernet Port on MELSEC iQ-R, Q and L series CPU modules (R 00/01/02 CPU firmware versions \u002720\u0027 and earlier, R 04/08/16/32/120 (EN) CPU firmware versions \u002752\u0027 and earlier, R 08/16/32/120 SFCPU firmware versions \u002722\u0027 and earlier, R 08/16/32/120 PCPU all versions, R 08/16/32/120 PSFCPU all versions, R 16/32/64 MTCPU all versions, Q03 UDECPU, Q 04/06/10/13/20/26/50/100 UDEHCPU serial number \u002722081\u0027 and earlier , Q 03/04/06/13/26 UDVCPU serial number \u002722031\u0027 and earlier, Q 04/06/13/26 UDPVCPU serial number \u002722031\u0027 and earlier, Q 172/173 DCPU all versions, Q 172/173 DSCPU all versions, Q 170 MCPU all versions, Q 170 MSCPU all versions, L 02/06/26 CPU (-P) and L 26 CPU - (P) BT all versions) allows a remote unauthenticated attacker to stop the Ethernet communication functions of the products via a specially crafted packet, which may lead to a denial of service (DoS) condition .",
  "id": "GHSA-cpv9-4hm5-jjhj",
  "modified": "2022-05-24T17:33:04Z",
  "published": "2022-05-24T17:33:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5652"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/vu/JVNVU96558207/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.mitsubishielectric.co.jp/psirt/vulnerability/pdf/2020-013.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.mitsubishielectric.com/en/psirt/vulnerability/pdf/2020-013_en.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-CPW4-RFMM-H598

Vulnerability from github – Published: 2026-02-12 00:31 – Updated: 2026-02-12 21:31
VLAI
Details

This issue was addressed through improved state management. This issue is fixed in iOS 26.3 and iPadOS 26.3, Safari 26.3, macOS Tahoe 26.3, visionOS 26.3. A website may be able to track users through Safari web extensions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-20676"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-11T23:16:09Z",
    "severity": "MODERATE"
  },
  "details": "This issue was addressed through improved state management. This issue is fixed in iOS 26.3 and iPadOS 26.3, Safari 26.3, macOS Tahoe 26.3, visionOS 26.3. A website may be able to track users through Safari web extensions.",
  "id": "GHSA-cpw4-rfmm-h598",
  "modified": "2026-02-12T21:31:26Z",
  "published": "2026-02-12T00:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20676"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126346"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126348"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126353"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/126354"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CPWV-6M75-7GFX

Vulnerability from github – Published: 2025-08-27 00:31 – Updated: 2025-08-27 15:33
VLAI
Details

In multiple locations, there is a possible crash loop due to resource exhaustion. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-49740"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-26T23:15:31Z",
    "severity": "MODERATE"
  },
  "details": "In multiple locations, there is a possible crash loop due to resource exhaustion. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-cpwv-6m75-7gfx",
  "modified": "2025-08-27T15:33:14Z",
  "published": "2025-08-27T00:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49740"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/frameworks/base/+/bcb1316835dc31f33f0c3b409ee847c389c09d2b"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/packages/services/Telephony/+/b1ab472f0f56146387d3822318394cb2525ad34c"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2025-03-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CQ2R-QJJF-XHVH

Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2024-04-04 02:38
VLAI
Details

stratisX through 2.0.0.5 (a chain-based proof-of-stake cryptocurrency) allows a remote denial of service, exploitable by an attacker who acquires even a small amount of stake/coins in the system. The attacker sends invalid headers/blocks, which are stored on the victim's disk.

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": [],
  "aliases": [
    "CVE-2018-19163"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-05T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "stratisX through 2.0.0.5 (a chain-based proof-of-stake cryptocurrency) allows a remote denial of service, exploitable by an attacker who acquires even a small amount of stake/coins in the system. The attacker sends invalid headers/blocks, which are stored on the victim\u0027s disk.",
  "id": "GHSA-cq2r-qjjf-xhvh",
  "modified": "2024-04-04T02:38:15Z",
  "published": "2022-05-24T17:00:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19163"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/%40dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrencies-b8b05723f806"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrencies-b8b05723f806"
    },
    {
      "type": "WEB",
      "url": "http://fc19.ifca.ai/preproceedings/180-preproceedings.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CQ85-VQ4V-C3F4

Vulnerability from github – Published: 2026-02-10 18:30 – Updated: 2026-02-10 21:31
VLAI
Details

An issue in mquickjs before commit 74b7e (2026-01-15) allows a local attacker to cause a denial of service via a crafted file to the get_mblock_size function at mquickjs.c.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-70347"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-10T16:16:09Z",
    "severity": "MODERATE"
  },
  "details": "An issue in mquickjs before commit 74b7e (2026-01-15) allows a local attacker to cause a denial of service via a crafted file to the get_mblock_size function at mquickjs.c.",
  "id": "GHSA-cq85-vq4v-c3f4",
  "modified": "2026-02-10T21:31:29Z",
  "published": "2026-02-10T18:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-70347"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bellard/mquickjs/issues/56"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Mitigation
Architecture and Design
  • Mitigation of resource exhaustion attacks requires that the target system either:
  • The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
  • The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • recognizes the attack and denies that user further access for a given amount of time, or
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation
Implementation

Ensure that all failures in resource allocation place the system into a safe posture.

CAPEC-147: XML Ping of the Death

An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.

CAPEC-227: Sustained Client Engagement

An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.

CAPEC-492: Regular Expression Exponential Blowup

An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.

← Back to the CWE list