Common Weakness Enumeration

CWE-405

Allowed-with-Review

Asymmetric Resource Consumption (Amplification)

Abstraction: Class · Status: Incomplete

The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."

115 vulnerabilities reference this CWE, most recent first.

GHSA-2GFX-528V-GRP3

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

ZcashFoundation Zebra before 6.1.0 contains a resource exhaustion vulnerability that allows unauthenticated peers to degrade block processing by pushing transactions with invalid Orchard proofs without being misbehavior-scored. Attackers can repeatedly push invalid proofs into the shared halo2 batch verifier, forcing honest block proofs onto the slow individual-verification path and slowing block processing roughly sevenfold.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-104425"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-02T12:17:12Z",
    "severity": "MODERATE"
  },
  "details": "ZcashFoundation Zebra before 6.1.0 contains a resource exhaustion vulnerability that allows unauthenticated peers to degrade block processing by pushing transactions with invalid Orchard proofs without being misbehavior-scored. Attackers can repeatedly push invalid proofs into the shared halo2 batch verifier, forcing honest block proofs onto the slow individual-verification path and slowing block processing roughly sevenfold.",
  "id": "GHSA-2gfx-528v-grp3",
  "modified": "2026-10-02T12:31:14Z",
  "published": "2026-10-02T12:31:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-g7c4-2w6c-cr3r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104425"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/zebra-before-6.1.0-batch-verification-poisoning-dos-via-unattributed-pushed-transactions"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/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"
    }
  ]
}

GHSA-36CP-MH65-X882

Vulnerability from github – Published: 2026-04-10 00:30 – Updated: 2026-04-10 20:18
Withdrawn 2026-04-10 VLAI
Summary
Duplicate Advisory: OpenClaw is vulnerable to unauthenticated resource exhaustion through its voice call webhook handling
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-rm59-992w-x2mv. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.3.22 contains an unauthenticated resource exhaustion vulnerability in voice call webhook handling that buffers request bodies before provider signature checks. Attackers can send large or malicious webhook requests to exhaust server resources without authentication by bypassing signature validation.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T20:18:58Z",
    "nvd_published_at": "2026-04-09T22:16:31Z",
    "severity": "MODERATE"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-rm59-992w-x2mv. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.22 contains an unauthenticated resource exhaustion vulnerability in voice call webhook handling that buffers request bodies before provider signature checks. Attackers can send large or malicious webhook requests to exhaust server resources without authentication by bypassing signature validation.",
  "id": "GHSA-36cp-mh65-x882",
  "modified": "2026-04-10T20:18:58Z",
  "published": "2026-04-10T00:30:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-rm59-992w-x2mv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35626"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/630f1479c44f78484dfa21bb407cbe6f171dac87"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/651dc7450b68a5396a009db78ef9382633707ead"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-unauthenticated-resource-exhaustion-via-voice-call-webhook"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/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"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw is vulnerable to unauthenticated resource exhaustion through its voice call webhook handling",
  "withdrawn": "2026-04-10T20:18:58Z"
}

GHSA-3G9Q-V48F-HH9W

Vulnerability from github – Published: 2026-09-10 22:44 – Updated: 2026-09-10 22:44
VLAI
Summary
Open WebUI: Unauthenticated requests can stall the server via uncached OIDC fetches in back-channel logout
Details

Summary

The OIDC back-channel logout endpoint is unauthenticated by design, because the identity provider calls it without a browser session. Before checking whether the submitted logout token was genuine, the handler fetched the provider's discovery document and its signing keys over the network, and repeated both fetches on every request because nothing was cached. The signing-key fetch also ran as a blocking call inside the async event loop. A small number of requests carrying a worthless token was therefore enough to make the whole instance stop answering.

Preconditions

  • ENABLE_OAUTH_BACKCHANNEL_LOGOUT=true. The default is False, so a stock deployment is not affected. This setting is recommended in the Open WebUI hardening documentation, which is why the issue is treated as in scope.
  • At least one OIDC provider configured (OAUTH_CLIENT_ID, OAUTH_CLIENT_SECRET, OPENID_PROVIDER_URL).
  • No account, credential, session or secret identifier is required. The attacker needs network access to the instance and the configured issuer string, which is published in the provider's own discovery document.

Impact

Against 0.11.0, with the identity provider answering in 150 ms, 60 concurrent requests carrying a token whose signature was four characters long stalled the async event loop for 8.3 seconds, measured against an idle baseline of 10.8 ms. For the length of that stall the process answers nothing: no chat requests, no API calls, no health check. Open WebUI runs a single worker by default, so the effect is instance-wide rather than per-connection, and no rate limit sits in front of the endpoint.

The same traffic is also amplified outward: 20 sequential requests produced 20 discovery fetches and 40 key-set fetches at the identity provider, so an attacker can drive load onto the provider through the instance.

No data is read, modified or exposed, and the forged token is still rejected. The cost is paid before the rejection.

Fix

Fixed in 0.11.1. The handler now resolves both the discovery document and the signing keys through the already-configured OAuth client, so each is fetched once per provider and reused afterwards, and both fetches are asynchronous rather than blocking the event loop. A token carrying no kid header is rejected before any key lookup happens. Upgrading is sufficient, and no configuration change is required.

Root cause

Affected component: the OIDC back-channel logout handler in backend/open_webui/utils/oauth.py, reached through POST /oauth/backchannel-logout. Affected setups: releases 0.9.0 through 0.11.0 with back-channel logout enabled and an OIDC provider configured.

The handler treated its network work as cheap preparation rather than as work worth protecting. For every request it opened a new HTTP session per configured provider to re-read the discovery document, then constructed a fresh JWKS client, whose own cache consequently started empty each time, and asked that client for the signing key through a synchronous call issued directly on the event loop. All of this ran before the token signature was verified, so an attacker unable to produce a valid token still cost the server two network round trips and a blocked loop per request. Both fetches used the library default timeout of five minutes.

Proof of concept

Reproduced by running the unmodified handler from the 0.11.0 and 0.11.1 backends against a loopback identity provider that counted every inbound request and could answer with a configured delay. The submitted token carried a valid issuer and audience, a kid naming a key the provider does not hold, and AAAA as its signature.

20 sequential requests, provider answering immediately:

Version Discovery fetches Key-set fetches Response
0.11.0 20 40 400
0.11.1 1 1 400

60 concurrent requests, provider answering in 150 ms:

Version Wall time Discovery fetches Key-set fetches Worst event-loop stall
0.11.0 18.6 s 60 120 8255 ms
0.11.1 under 0.01 s 0 0 none measurable

Idle event-loop stall was 10.8 ms in both cases. On 0.11.1 the first request an instance receives warms both caches, and every request after that reaches the signature check without any outbound network call.

Credits

@galanko, for reporting the issue and identifying both the missing caching and the blocking call.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.11.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0"
            },
            {
              "fixed": "0.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-87011"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-10T22:44:42Z",
    "nvd_published_at": "2026-09-09T21:17:05Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe OIDC back-channel logout endpoint is unauthenticated by design, because the identity provider calls it without a browser session. Before checking whether the submitted logout token was genuine, the handler fetched the provider\u0027s discovery document and its signing keys over the network, and repeated both fetches on every request because nothing was cached. The signing-key fetch also ran as a blocking call inside the async event loop. A small number of requests carrying a worthless token was therefore enough to make the whole instance stop answering.\n\n## Preconditions\n\n- `ENABLE_OAUTH_BACKCHANNEL_LOGOUT=true`. The default is `False`, so a stock deployment is not affected. This setting is recommended in the Open WebUI hardening documentation, which is why the issue is treated as in scope.\n- At least one OIDC provider configured (`OAUTH_CLIENT_ID`, `OAUTH_CLIENT_SECRET`, `OPENID_PROVIDER_URL`).\n- No account, credential, session or secret identifier is required. The attacker needs network access to the instance and the configured issuer string, which is published in the provider\u0027s own discovery document.\n\n## Impact\n\nAgainst 0.11.0, with the identity provider answering in 150 ms, 60 concurrent requests carrying a token whose signature was four characters long stalled the async event loop for 8.3 seconds, measured against an idle baseline of 10.8 ms. For the length of that stall the process answers nothing: no chat requests, no API calls, no health check. Open WebUI runs a single worker by default, so the effect is instance-wide rather than per-connection, and no rate limit sits in front of the endpoint.\n\nThe same traffic is also amplified outward: 20 sequential requests produced 20 discovery fetches and 40 key-set fetches at the identity provider, so an attacker can drive load onto the provider through the instance.\n\nNo data is read, modified or exposed, and the forged token is still rejected. The cost is paid before the rejection.\n\n## Fix\n\nFixed in 0.11.1. The handler now resolves both the discovery document and the signing keys through the already-configured OAuth client, so each is fetched once per provider and reused afterwards, and both fetches are asynchronous rather than blocking the event loop. A token carrying no `kid` header is rejected before any key lookup happens. Upgrading is sufficient, and no configuration change is required.\n\n## Root cause\n\nAffected component: the OIDC back-channel logout handler in `backend/open_webui/utils/oauth.py`, reached through `POST /oauth/backchannel-logout`. Affected setups: releases 0.9.0 through 0.11.0 with back-channel logout enabled and an OIDC provider configured.\n\nThe handler treated its network work as cheap preparation rather than as work worth protecting. For every request it opened a new HTTP session per configured provider to re-read the discovery document, then constructed a fresh JWKS client, whose own cache consequently started empty each time, and asked that client for the signing key through a synchronous call issued directly on the event loop. All of this ran before the token signature was verified, so an attacker unable to produce a valid token still cost the server two network round trips and a blocked loop per request. Both fetches used the library default timeout of five minutes.\n\n## Proof of concept\n\nReproduced by running the unmodified handler from the 0.11.0 and 0.11.1 backends against a loopback identity provider that counted every inbound request and could answer with a configured delay. The submitted token carried a valid issuer and audience, a `kid` naming a key the provider does not hold, and `AAAA` as its signature.\n\n20 sequential requests, provider answering immediately:\n\n| Version | Discovery fetches | Key-set fetches | Response |\n| --- | --- | --- | --- |\n| 0.11.0 | 20 | 40 | 400 |\n| 0.11.1 | 1 | 1 | 400 |\n\n60 concurrent requests, provider answering in 150 ms:\n\n| Version | Wall time | Discovery fetches | Key-set fetches | Worst event-loop stall |\n| --- | --- | --- | --- | --- |\n| 0.11.0 | 18.6 s | 60 | 120 | 8255 ms |\n| 0.11.1 | under 0.01 s | 0 | 0 | none measurable |\n\nIdle event-loop stall was 10.8 ms in both cases. On 0.11.1 the first request an instance receives warms both caches, and every request after that reaches the signature check without any outbound network call.\n\n## Credits\n\n@galanko, for reporting the issue and identifying both the missing caching and the blocking call.",
  "id": "GHSA-3g9q-v48f-hh9w",
  "modified": "2026-09-10T22:44:42Z",
  "published": "2026-09-10T22:44:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-3g9q-v48f-hh9w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87011"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/aeda6ff13a25d3b3ba1b303609f35382db22142c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.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": "Open WebUI: Unauthenticated requests can stall the server via uncached OIDC fetches in back-channel logout"
}

GHSA-3JGV-277J-G3M7

Vulnerability from github – Published: 2025-09-19 21:31 – Updated: 2025-09-19 21:31
VLAI
Details

StorageGRID (formerly StorageGRID Webscale) versions prior to 11.8.0.15 and 11.9.0.8 are susceptible to a Denial of Service vulnerability. Successful exploit could allow an unauthenticated attacker to cause a Denial of Service on the Admin node.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-26516"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-19T19:15:38Z",
    "severity": "MODERATE"
  },
  "details": "StorageGRID (formerly \nStorageGRID Webscale) versions prior to 11.8.0.15 and 11.9.0.8 are \nsusceptible to a Denial of Service vulnerability. Successful exploit \ncould allow an unauthenticated attacker to cause a Denial of Service on \nthe Admin node.",
  "id": "GHSA-3jgv-277j-g3m7",
  "modified": "2025-09-19T21:31:17Z",
  "published": "2025-09-19T21:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26516"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/NTAP-20250910-0003"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3V8X-282W-FMJ2

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-09 18:30
VLAI
Details

SAP NetWeaver remote service for Xcelsius allows an attacker with network access and high privileges to execute arbitrary code on the affected system due to insufficient input validation and improper handling of remote method calls. Exploitation does not require user interaction and could lead to service disruption or unauthorized system control. This has high impact on integrity and availability, with no impact on confidentiality.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-42874"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T16:17:51Z",
    "severity": "HIGH"
  },
  "details": "SAP NetWeaver remote service for Xcelsius allows an attacker with network access and high privileges to execute arbitrary code on the affected system due to insufficient input validation and improper handling of remote method calls. Exploitation does not require user interaction and could lead to service disruption or unauthorized system control. This has high impact on integrity and availability, with no impact on confidentiality.",
  "id": "GHSA-3v8x-282w-fmj2",
  "modified": "2025-12-09T18:30:37Z",
  "published": "2025-12-09T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-42874"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3640185"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-428G-F7CQ-PGP5

Vulnerability from github – Published: 2025-12-22 20:20 – Updated: 2025-12-23 16:01
VLAI
Summary
Marshmallow has DoS in Schema.load(many)
Details

Impact

Schema.load(data, many=True) is vulnerable to denial of service attacks. A moderately sized request can consume a disproportionate amount of CPU time.

Patches

4.1.2, 3.26.2

Workarounds

# Fail fast
def load_many(schema, data, **kwargs):
    if not isinstance(data, list):
        raise ValidationError(['Invalid input type.'])
    return [schema.load(item, **kwargs) for item in data]
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "marshmallow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0rc1"
            },
            {
              "fixed": "3.26.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "marshmallow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68480"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-22T20:20:07Z",
    "nvd_published_at": "2025-12-22T22:16:09Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n`Schema.load(data, many=True)` is vulnerable to denial of service attacks. A moderately sized request can consume a disproportionate amount of CPU time.\n\n### Patches\n\n4.1.2, 3.26.2\n\n### Workarounds\n\n```py\n# Fail fast\ndef load_many(schema, data, **kwargs):\n    if not isinstance(data, list):\n        raise ValidationError([\u0027Invalid input type.\u0027])\n    return [schema.load(item, **kwargs) for item in data]\n```",
  "id": "GHSA-428g-f7cq-pgp5",
  "modified": "2025-12-23T16:01:21Z",
  "published": "2025-12-22T20:20:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/marshmallow-code/marshmallow/security/advisories/GHSA-428g-f7cq-pgp5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68480"
    },
    {
      "type": "WEB",
      "url": "https://github.com/marshmallow-code/marshmallow/commit/d24a0c9df061c4daa92f71cf85aca25b83eee508"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/marshmallow-code/marshmallow"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Marshmallow has DoS in Schema.load(many)"
}

GHSA-4P9G-QGX9-397P

Vulnerability from github – Published: 2021-03-23 01:54 – Updated: 2024-02-07 18:50
VLAI
Summary
Denial of Service in Page Error Handling
Details

Meta

  • CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C (5.5)
  • CWE-405, CWE-674
  • Status: DRAFT

Problem

Requesting invalid or non-existing resources via HTTP triggers the page error handler which again could retrieve content to be shown as error message from another page. This leads to a scenario in which the application is calling itself recursively - amplifying the impact of the initial attack until the limits of the web server are exceeded.

Solution

Update to TYPO3 versions 9.5.25, 10.4.14, 11.1.1 that fix the problem described.

Credits

Thanks to Paul Keller, Mathias Bolt Lesniak and Kay Strobach who reported this issue and to TYPO3 framework merger Frank Nägler and to TYPO3 security team member Torben Hansen who fixed the issue.

References

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.4.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.5.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.4.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.5.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21359"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405",
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-03-23T01:42:10Z",
    "nvd_published_at": "2021-03-23T02:15:00Z",
    "severity": "MODERATE"
  },
  "details": "\u003e ### Meta\n\u003e * CVSS:  `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C` (5.5)\n\u003e * CWE-405, CWE-674\n\u003e * Status: **DRAFT**\n\n### Problem\nRequesting invalid or non-existing resources via HTTP triggers the page error handler which again could retrieve content  to be shown as error message from another page. This leads to a scenario in which the application is calling itself recursively - amplifying the impact of the initial attack until the limits of the web server are exceeded.\n\n### Solution\nUpdate to TYPO3 versions 9.5.25, 10.4.14, 11.1.1 that fix the problem described.\n\n### Credits\nThanks to Paul Keller, Mathias Bolt Lesniak and Kay Strobach who reported this issue and to TYPO3 framework merger Frank N\u00e4gler and to TYPO3 security team member Torben Hansen who fixed the issue.\n\n### References\n* [TYPO3-CORE-SA-2021-005](https://typo3.org/security/advisory/typo3-core-sa-2021-005)",
  "id": "GHSA-4p9g-qgx9-397p",
  "modified": "2024-02-07T18:50:34Z",
  "published": "2021-03-23T01:54:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/TYPO3.CMS/security/advisories/GHSA-4p9g-qgx9-397p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21359"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms-core/CVE-2021-21359.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms/CVE-2021-21359.yaml"
    },
    {
      "type": "WEB",
      "url": "https://packagist.org/packages/typo3/cms-core"
    },
    {
      "type": "WEB",
      "url": "https://typo3.org/security/advisory/typo3-core-sa-2021-005"
    }
  ],
  "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/E:F/RL:O/RC:C",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Denial of Service in Page Error Handling"
}

GHSA-4QG8-FJ49-PXJH

Vulnerability from github – Published: 2025-12-05 18:19 – Updated: 2025-12-05 18:19
VLAI
Summary
Sigstore Timestamp Authority allocates excessive memory during request parsing
Details

Impact

Excessive memory allocation

Function api.ParseJSONRequest currently splits (via a call to strings.Split) an optionally-provided OID (which is untrusted data) on periods. Similarly, function api.getContentType splits the Content-Type header (which is also untrusted data) on an application string.

As a result, in the face of a malicious request with either an excessively long OID in the payload containing many period characters or a malformed Content-Type header, a call to api.ParseJSONRequest or api.getContentType incurs allocations of O(n) bytes (where n stands for the length of the function's argument). Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)

Patches

Upgrade to v2.0.3.

Workarounds

There are no workarounds with the service itself. If the service is behind a load balancer, configure the load balancer to reject excessively large requests.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/timestamp-authority"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66564"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-05T18:19:00Z",
    "nvd_published_at": "2025-12-04T23:15:47Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\n**Excessive memory allocation**\n\nFunction [api.ParseJSONRequest](https://github.com/sigstore/timestamp-authority/blob/26d7d426d3000abdbdf2df34de56bb92246c0365/pkg/api/timestamp.go#L63) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) an optionally-provided OID (which is untrusted data) on periods. Similarly, function [api.getContentType](https://github.com/sigstore/timestamp-authority/blob/26d7d426d3000abdbdf2df34de56bb92246c0365/pkg/api/timestamp.go#L114) splits the `Content-Type` header (which is also untrusted data) on an `application` string.\n\nAs a result, in the face of a malicious request with either an excessively long OID in the payload containing many period characters or a malformed `Content-Type` header, a call to `api.ParseJSONRequest` or `api.getContentType` incurs allocations of O(n) bytes (where n stands for the length of the function\u0027s argument). Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](https://cwe.mitre.org/data/definitions/405.html)\n\n### Patches\n\nUpgrade to v2.0.3.\n\n### Workarounds\n\nThere are no workarounds with the service itself. If the service is behind a load balancer, configure the load balancer to reject excessively large requests.",
  "id": "GHSA-4qg8-fj49-pxjh",
  "modified": "2025-12-05T18:19:00Z",
  "published": "2025-12-05T18:19:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/timestamp-authority/security/advisories/GHSA-4qg8-fj49-pxjh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66564"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/timestamp-authority/commit/0cae34e197d685a14904e0bad135b89d13b69421"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/timestamp-authority"
    }
  ],
  "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": "Sigstore Timestamp Authority allocates excessive memory during request parsing"
}

GHSA-4X5W-56X5-CMFR

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

Zebra (zebrad) before 6.2.1 contains an asymmetric resource consumption vulnerability that allows unauthenticated peers to stall block verification by pushing V6 mempool transactions with invalid Halo2 proofs. Attackers can flood the shared unprioritized Halo2 verification queue with zero-fee transactions carrying zero-filled Orchard and Ironwood proofs, causing nodes to fall behind the chain tip.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-104423"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-02T12:17:12Z",
    "severity": "HIGH"
  },
  "details": "Zebra (zebrad) before 6.2.1 contains an asymmetric resource consumption vulnerability that allows unauthenticated peers to stall block verification by pushing V6 mempool transactions with invalid Halo2 proofs. Attackers can flood the shared unprioritized Halo2 verification queue with zero-fee transactions carrying zero-filled Orchard and Ironwood proofs, causing nodes to fall behind the chain tip.",
  "id": "GHSA-4x5w-56x5-cmfr",
  "modified": "2026-10-02T12:31:14Z",
  "published": "2026-10-02T12:31:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-2p4c-3q4q-p463"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104423"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/zebra-before-6.2.1-denial-of-service-via-uncapped-v6-shielded-proof-verification"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-524P-RWPG-QG57

Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-09 18:30
VLAI
Details

Due to a Missing Authorization Check vulnerability in SAP S/4 HANA Private Cloud (Financials General Ledger), an authenticated attacker with authorization limited to a single company code could read sensitive data and post or modify documents across all company codes. Successful exploitation could result in a high impact to confidentiality and a low impact to integrity, while availability remains unaffected.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-42876"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-09T16:17:51Z",
    "severity": "HIGH"
  },
  "details": "Due to a Missing Authorization Check vulnerability in SAP S/4 HANA Private Cloud (Financials General Ledger), an authenticated attacker with authorization limited to a single company code could read sensitive data and post or modify documents across all company codes. Successful exploitation could result in a high impact to confidentiality and a low impact to integrity, while availability remains unaffected.",
  "id": "GHSA-524p-rwpg-qg57",
  "modified": "2025-12-09T18:30:37Z",
  "published": "2025-12-09T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-42876"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3672151"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

An application must make resources available to a client commensurate with the client's access level.

Mitigation
Architecture and Design

An application must, at all times, keep track of allocated resources and meter their usage appropriately.

Mitigation
System Configuration

Consider disabling resource-intensive algorithms on the server side, such as Diffie-Hellman key exchange.

No CAPEC attack patterns related to this CWE.