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.

5435 vulnerabilities reference this CWE, most recent first.

GHSA-V829-X6HH-CQFQ

Vulnerability from github – Published: 2023-03-10 23:47 – Updated: 2023-03-10 23:47
VLAI
Summary
Crossplane-runtime contains Improper Input Validation via Compositions
Details

Summary

Fuzz testing, by Ada Logics and sponsored by the CNCF, identified a vulnerability in the fieldpath package from crossplane/crossplane-runtime that an already highly privileged Crossplane user able to create or update Compositions could leverage to cause an out of memory panic in Crossplane.

Details

Compositions allow users to specify patches inserting elements into arrays at an arbitrary index. When a Composition is selected for a Composite Resource, patches are evaluated and if a specified index is greater than the current size of the target slice, that slice's size will be increased to the specified index, which could lead to an excessive amount of memory usage and therefore the Pod being OOM-Killed. The index is already capped to the maximum value for a uint32 (4294967295) when parsed, but that is still an unnecessarily large value.

Workaround

Users can restrict write privileges on Compositions to only admin users as a workaround.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/crossplane/crossplane"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/crossplane/crossplane"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.10.0"
            },
            {
              "fixed": "1.10.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/crossplane/crossplane"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.11.0"
            },
            {
              "fixed": "1.11.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-27484"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-10T23:47:53Z",
    "nvd_published_at": "2023-03-09T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nFuzz testing, by Ada Logics and sponsored by the CNCF, identified a [vulnerability](https://github.com/crossplane/crossplane-runtime/security/advisories/GHSA-vfvj-3m3g-m532) in the `fieldpath` package from `crossplane/crossplane-runtime` that an already highly privileged Crossplane user able to create or update Compositions could leverage to cause an out of memory panic in Crossplane.\n\n### Details\n\nCompositions allow users to specify patches inserting elements into arrays at an arbitrary index. When a Composition is selected for a Composite Resource, patches are evaluated and if a specified index is greater than the current size of the target slice, that slice\u0027s size will be increased to the specified index, which could lead to an excessive amount of memory usage and therefore the Pod being OOM-Killed. The index is already capped to the maximum value for a uint32 (4294967295) when parsed, but that is still an unnecessarily large value.\n\n### Workaround\n\nUsers can restrict write privileges on Compositions to only admin users as a workaround.",
  "id": "GHSA-v829-x6hh-cqfq",
  "modified": "2023-03-10T23:47:53Z",
  "published": "2023-03-10T23:47:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/crossplane/crossplane/security/advisories/GHSA-v829-x6hh-cqfq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27484"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/crossplane/crossplane"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Crossplane-runtime contains Improper Input Validation via Compositions"
}

GHSA-V82G-2437-67M2

Vulnerability from github – Published: 2026-07-17 17:16 – Updated: 2026-07-17 17:16
VLAI
Summary
vLLM: Speech-to-text upload size limit is enforced after full UploadFile read
Details

Summary

Current-head vLLM documents VLLM_MAX_AUDIO_CLIP_FILESIZE_MB as the maximum audio file size accepted by the speech-to-text APIs. The default is 25 MB. vllm/envs.py also describes files larger than this value as rejected.

The /v1/audio/transcriptions and /v1/audio/translations routes call await request.file.read() before vLLM checks that limit. In FastAPI and Starlette, UploadFile.read() returns bytes from the uploaded file object; when called without a size argument, the route materializes the remaining file contents. vLLM then performs the compressed file-size check later in _preprocess_speech_to_text() against the already-created bytes object.

As a result, the documented compressed audio file-size limit does not bound the memory allocated by vLLM endpoint code before validation. An oversized multipart upload can cause vLLM to allocate memory proportional to the uploaded file size before rejecting the request as too large.

This is distinct from GHSA-6pr9-rp53-2pmc, which covered decoded PCM expansion after compressed input was accepted. This report covers compressed upload materialization before compressed-size validation.

Technical Details

The upload routes perform an unbounded read before vLLM checks the documented compressed audio file-size limit:

  • vllm/entrypoints/speech_to_text/transcription/api_router.py: audio_data = await request.file.read()
  • vllm/entrypoints/speech_to_text/translation/api_router.py: audio_data = await request.file.read()
  • vllm/entrypoints/speech_to_text/base/serving.py later checks: if len(audio_data) / 1024**2 > self.max_audio_filesize_mb

There is no route-level check of request.file.size, Content-Length, a bounded read(max_bytes + 1), or a streaming copy that stops at the configured limit before the full file is materialized.

This does not appear to be intended behavior. vLLM's security guide treats request-controlled resource use as a security boundary: for example, requests that exceed VLLM_MAX_N_SEQUENCES are rejected before reaching the engine. The speech-to-text upload limit is documented in the same spirit as an API enforced limit, but the first vLLM check happens after the over-limit upload has already been copied into a bytes object.

Impact

Attack requirements:

  • the deployment exposes /v1/audio/transcriptions or /v1/audio/translations;
  • a speech-to-text capable model/task is configured; and
  • the caller can submit requests to the endpoint, including any API key the deployment requires.

An API caller who meets those requirements can send an oversized audio file. vLLM reads the full uploaded file into memory before applying the configured compressed audio file-size limit. This can create memory pressure or, depending on process/container limits and concurrency, terminate the process before the request is rejected.

Suggested severity: Moderate, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (6.5), CWE-770/CWE-400.

The impact is availability-only. This is not a claim of code execution, data access, cross-tenant data exposure, parser-level multipart memory exhaustion, or persistence after process restart. Deployment body-size limits at a reverse proxy or ASGI layer can mitigate the issue before vLLM sees the request, but vLLM's own documented file-size limit does not currently provide that memory boundary.

Suggested Fix

Enforce the compressed audio upload limit before the unbounded read:

  • Check reliable upload size metadata before reading when available.
  • Read at most max_bytes + 1 bytes in chunks as a defense-in-depth guard against missing or unreliable metadata.
  • Share the helper between transcription and translation routes.
  • Add regression tests that prove an over-limit UploadFile is rejected without calling an unbounded read().

The important property is that over-limit compressed uploads are rejected before vLLM allocates the full uploaded file as bytes.

Resources

  • vLLM security policy: https://github.com/vllm-project/vllm/security/policy
  • vLLM speech-to-text docs: https://docs.vllm.ai/en/latest/serving/online_serving/speech_to_text/
  • vLLM security guide, request parameter resource limits: https://docs.vllm.ai/en/latest/usage/security/
  • vLLM vulnerability management docs: https://docs.vllm.ai/en/latest/contributing/vulnerability_management/
  • FastAPI file uploads: https://fastapi.tiangolo.com/reference/uploadfile/
  • Starlette uploaded files: https://www.starlette.io/requests/
  • Adjacent published audio advisory: https://github.com/vllm-project/vllm/security/advisories/GHSA-6pr9-rp53-2pmc
  • Request-parameter resource DoS precedent: https://github.com/vllm-project/vllm/security/advisories/GHSA-3mwp-wvh9-7528

Appendix: Affected Version

Validated against current head:

  • commit: 1033ffac2eccf986fdd880f4dee64ca3b22c63c9
  • described version: v0.22.1rc0-491-g1033ffac2e

Known affected range: current head. It has not been determined the introducing commit or release range.

Appendix: Proof Of Vulnerability

The attached proof is a non-destructive static probe. It does not upload a large file or contact a running vLLM server:

python3 attached-evidence/poc/audio_upload_size_precheck_probe.py

Observed result:

{
  "pov": "this report",
  "validated": true,
  "default_limit_mb": 25,
  "documented_api_limit": true,
  "routes": {
    "transcription_route": {
      "unbounded_upload_read": true,
      "early_size_guard_before_read": false,
      "chunked_bounded_read": false
    },
    "translation_route": {
      "unbounded_upload_read": true,
      "early_size_guard_before_read": false,
      "chunked_bounded_read": false
    }
  },
  "late_size_check": {
    "present": true
  }
}

Expected behavior: vLLM rejects over-limit audio files before materializing the entire upload into memory in vLLM endpoint code.

Actual behavior: the route materializes the upload into memory first, and only then does vLLM reject the request as exceeding VLLM_MAX_AUDIO_CLIP_FILESIZE_MB.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.22.0"
            },
            {
              "fixed": "0.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55646"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-17T17:16:17Z",
    "nvd_published_at": "2026-07-06T20:16:37Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nCurrent-head vLLM documents `VLLM_MAX_AUDIO_CLIP_FILESIZE_MB` as the maximum audio file size accepted by the speech-to-text APIs. The default is 25 MB. `vllm/envs.py` also describes files larger than this value as rejected.\n\nThe `/v1/audio/transcriptions` and `/v1/audio/translations` routes call `await request.file.read()` before vLLM checks that limit. In FastAPI and Starlette, `UploadFile.read()` returns bytes from the uploaded file object; when called without a size argument, the route materializes the remaining file contents. vLLM then performs the compressed file-size check later in `_preprocess_speech_to_text()` against the already-created `bytes` object.\n\nAs a result, the documented compressed audio file-size limit does not bound the memory allocated by vLLM endpoint code before validation. An oversized multipart upload can cause vLLM to allocate memory proportional to the uploaded file size before rejecting the request as too large.\n\nThis is distinct from `GHSA-6pr9-rp53-2pmc`, which covered decoded PCM expansion after compressed input was accepted. This report covers compressed upload materialization before compressed-size validation.\n\n## Technical Details\n\nThe upload routes perform an unbounded read before vLLM checks the documented compressed audio file-size limit:\n\n- `vllm/entrypoints/speech_to_text/transcription/api_router.py`: `audio_data = await request.file.read()`\n- `vllm/entrypoints/speech_to_text/translation/api_router.py`: `audio_data = await request.file.read()`\n- `vllm/entrypoints/speech_to_text/base/serving.py` later checks: `if len(audio_data) / 1024**2 \u003e self.max_audio_filesize_mb`\n\nThere is no route-level check of `request.file.size`, `Content-Length`, a bounded `read(max_bytes + 1)`, or a streaming copy that stops at the configured limit before the full file is materialized.\n\nThis does not appear to be intended behavior. vLLM\u0027s security guide treats request-controlled resource use as a security boundary: for example, requests that exceed `VLLM_MAX_N_SEQUENCES` are rejected before reaching the engine. The speech-to-text upload limit is documented in the same spirit as an API enforced limit, but the first vLLM check happens after the over-limit upload has already been copied into a `bytes` object.\n\n## Impact\n\nAttack requirements:\n\n- the deployment exposes `/v1/audio/transcriptions` or `/v1/audio/translations`;\n- a speech-to-text capable model/task is configured; and\n- the caller can submit requests to the endpoint, including any API key the deployment requires.\n\nAn API caller who meets those requirements can send an oversized audio file. vLLM reads the full uploaded file into memory before applying the configured compressed audio file-size limit. This can create memory pressure or, depending on process/container limits and concurrency, terminate the process before the request is rejected.\n\nSuggested severity: Moderate, `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H` (`6.5`), CWE-770/CWE-400.\n\nThe impact is availability-only. This is not a claim of code execution, data access, cross-tenant data exposure, parser-level multipart memory exhaustion, or persistence after process restart. Deployment body-size limits at a reverse proxy or ASGI layer can mitigate the issue before vLLM sees the request, but vLLM\u0027s own documented file-size limit does not currently provide that memory boundary.\n\n## Suggested Fix\n\nEnforce the compressed audio upload limit before the unbounded read:\n\n- Check reliable upload size metadata before reading when available.\n- Read at most `max_bytes + 1` bytes in chunks as a defense-in-depth guard against missing or unreliable metadata.\n- Share the helper between transcription and translation routes.\n- Add regression tests that prove an over-limit `UploadFile` is rejected without calling an unbounded `read()`.\n\nThe important property is that over-limit compressed uploads are rejected before vLLM allocates the full uploaded file as `bytes`.\n\n## Resources\n\n- vLLM security policy: `https://github.com/vllm-project/vllm/security/policy`\n- vLLM speech-to-text docs: `https://docs.vllm.ai/en/latest/serving/online_serving/speech_to_text/`\n- vLLM security guide, request parameter resource limits: `https://docs.vllm.ai/en/latest/usage/security/`\n- vLLM vulnerability management docs: `https://docs.vllm.ai/en/latest/contributing/vulnerability_management/`\n- FastAPI file uploads: `https://fastapi.tiangolo.com/reference/uploadfile/`\n- Starlette uploaded files: `https://www.starlette.io/requests/`\n- Adjacent published audio advisory: `https://github.com/vllm-project/vllm/security/advisories/GHSA-6pr9-rp53-2pmc`\n- Request-parameter resource DoS precedent: `https://github.com/vllm-project/vllm/security/advisories/GHSA-3mwp-wvh9-7528`\n\n## Appendix: Affected Version\n\nValidated against current head:\n\n- commit: `1033ffac2eccf986fdd880f4dee64ca3b22c63c9`\n- described version: `v0.22.1rc0-491-g1033ffac2e`\n\nKnown affected range: current head. It has not been determined the introducing commit or release range.\n\n## Appendix: Proof Of Vulnerability\n\nThe attached proof is a non-destructive static probe. It does not upload a large file or contact a running vLLM server:\n\n```bash\npython3 attached-evidence/poc/audio_upload_size_precheck_probe.py\n```\n\nObserved result:\n\n```json\n{\n  \"pov\": \"this report\",\n  \"validated\": true,\n  \"default_limit_mb\": 25,\n  \"documented_api_limit\": true,\n  \"routes\": {\n    \"transcription_route\": {\n      \"unbounded_upload_read\": true,\n      \"early_size_guard_before_read\": false,\n      \"chunked_bounded_read\": false\n    },\n    \"translation_route\": {\n      \"unbounded_upload_read\": true,\n      \"early_size_guard_before_read\": false,\n      \"chunked_bounded_read\": false\n    }\n  },\n  \"late_size_check\": {\n    \"present\": true\n  }\n}\n```\n\nExpected behavior: vLLM rejects over-limit audio files before materializing the entire upload into memory in vLLM endpoint code.\n\nActual behavior: the route materializes the upload into memory first, and only then does vLLM reject the request as exceeding `VLLM_MAX_AUDIO_CLIP_FILESIZE_MB`.",
  "id": "GHSA-v82g-2437-67m2",
  "modified": "2026-07-17T17:16:17Z",
  "published": "2026-07-17T17:16:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-v82g-2437-67m2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55646"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/45510"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/b997071ec493765abbed990c65843ed05e4708a8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2026-2305.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vLLM: Speech-to-text upload size limit is enforced after full UploadFile read"
}

GHSA-V889-JQHM-9WFF

Vulnerability from github – Published: 2023-03-14 06:30 – Updated: 2023-03-21 18:30
VLAI
Details

SAP NetWeaver Application Server for ABAP and ABAP Platform - versions 700, 701, 702, 731, 740, 750, 751, 752, 753, 754, 755, 756, 757, 791, has multiple vulnerabilities in a class for test purposes in which an attacker authenticated as a non-administrative user can craft a request with certain parameters, which will consume the server's resources sufficiently to make it unavailable. There is no ability to view or modify any information.

Severity
6.5 (Medium)
CVSS:3.1/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-2023-27270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-14T05:15:00Z",
    "severity": "MODERATE"
  },
  "details": "SAP NetWeaver Application Server for ABAP and ABAP Platform - versions 700, 701, 702, 731, 740, 750, 751, 752, 753, 754, 755, 756, 757, 791, has multiple vulnerabilities in a class for test purposes in which an attacker authenticated as a non-administrative user can craft a request with certain parameters, which will consume the server\u0027s resources sufficiently to make it unavailable. There is no ability to view or modify any information.",
  "id": "GHSA-v889-jqhm-9wff",
  "modified": "2023-03-21T18:30:20Z",
  "published": "2023-03-14T06:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27270"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3296328"
    },
    {
      "type": "WEB",
      "url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V88G-Q782-JGP2

Vulnerability from github – Published: 2022-10-11 19:00 – Updated: 2022-10-14 12:00
VLAI
Details

XAPI open file limit DoS It is possible for an unauthenticated client on the network to cause XAPI to hit its file-descriptor limit. This causes XAPI to be unable to accept new requests for other (trusted) clients, and blocks XAPI from carrying out any tasks that require the opening of file descriptors.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-33749"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-11T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "XAPI open file limit DoS It is possible for an unauthenticated client on the network to cause XAPI to hit its file-descriptor limit. This causes XAPI to be unable to accept new requests for other (trusted) clients, and blocks XAPI from carrying out any tasks that require the opening of file descriptors.",
  "id": "GHSA-v88g-q782-jgp2",
  "modified": "2022-10-14T12:00:17Z",
  "published": "2022-10-11T19:00:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33749"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202402-07"
    },
    {
      "type": "WEB",
      "url": "https://xenbits.xenproject.org/xsa/advisory-413.txt"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2022/10/11/4"
    },
    {
      "type": "WEB",
      "url": "http://xenbits.xen.org/xsa/advisory-413.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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V8C7-M4FP-FC53

Vulnerability from github – Published: 2025-07-15 21:31 – Updated: 2025-07-15 21:31
VLAI
Details

Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and 9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 2.7 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L).

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-50098"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-15T20:15:46Z",
    "severity": "LOW"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 2.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L).",
  "id": "GHSA-v8c7-m4fp-fc53",
  "modified": "2025-07-15T21:31:42Z",
  "published": "2025-07-15T21:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50098"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2025.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V8PV-8XHP-96RH

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

This issue was addressed by removing the vulnerable code. This issue is fixed in macOS Ventura 13.6.7, macOS Monterey 12.7.5, iOS 16.7.8 and iPadOS 16.7.8, tvOS 17.5, visionOS 1.2, iOS 17.5 and iPadOS 17.5, watchOS 10.5, macOS Sonoma 14.5. Processing a maliciously crafted message may lead to a denial-of-service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-27800"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-10T21:15:49Z",
    "severity": "MODERATE"
  },
  "details": "This issue was addressed by removing the vulnerable code. This issue is fixed in macOS Ventura 13.6.7, macOS Monterey 12.7.5, iOS 16.7.8 and iPadOS 16.7.8, tvOS 17.5, visionOS 1.2, iOS 17.5 and iPadOS 17.5, watchOS 10.5, macOS Sonoma 14.5. Processing a maliciously crafted message may lead to a denial-of-service.",
  "id": "GHSA-v8pv-8xhp-96rh",
  "modified": "2026-04-02T21:31:44Z",
  "published": "2024-06-10T21:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27800"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120898"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120899"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120900"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120901"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120902"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120903"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120905"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120906"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214100"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214101"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214102"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214104"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214105"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214106"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214107"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214108"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214100"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214101"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214102"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214104"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214105"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214106"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214107"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214108"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jun/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V8X6-59G4-5G3W

Vulnerability from github – Published: 2022-06-03 22:18 – Updated: 2022-06-14 20:00
VLAI
Summary
Denial of service binding form from JSON in Play Framework
Details

Impact

A denial-of-service vulnerability has been discovered in Play's forms library, in both the Scala and Java APIs. This can occur when using either the Form#bindFromRequest method on a JSON request body or the Form#bind method directly on a JSON value. If the JSON data being bound to the form contains a deeply-nested JSON object or array, the form binding implementation may consume all available heap space and cause an OutOfMemoryError. If executing on the default dispatcher and akka.jvm-exit-on-fatal-error is enabled—as it is by default—then this can crash the application process.

Form.bindFromRequest is vulnerable when using any body parser that produces a type of AnyContent or JsValue in Scala, or one that can produce a JsonNode in Java. This includes Play's default body parser.

Patches

This vulnerability been patched in version 2.8.16. There is now a global limit on the depth of a JSON object that can be parsed, which can be configured by the user if necessary.

Workarounds

Applications that do not need to parse a request body of type application/json can switch from the default body parser to another body parser that supports only the specific type of body they expect; for example, the formUrlEncoded body parser can be used if the Play action only needs to accept application/x-www-form-urlencoded.

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": "Maven",
        "name": "com.typesafe.play:play_2.13"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.3"
            },
            {
              "fixed": "2.8.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.typesafe.play:play_2.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.3"
            },
            {
              "fixed": "2.8.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31018"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-03T22:18:58Z",
    "nvd_published_at": "2022-06-02T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nA denial-of-service vulnerability has been discovered in Play\u0027s forms library, in both the Scala and Java APIs. This can occur when using either the `Form#bindFromRequest` method on a JSON request body or the `Form#bind` method directly on a JSON value. If the JSON data being bound to the form contains a deeply-nested JSON object or array, the form binding implementation may consume all available heap space and cause an `OutOfMemoryError`. If executing on the default dispatcher and `akka.jvm-exit-on-fatal-error` is enabled\u2014as it is by default\u2014then this can crash the application process.\n\n`Form.bindFromRequest` is vulnerable when using any body parser that produces a type of `AnyContent` or `JsValue` in Scala, or one that can produce a `JsonNode` in Java. This includes Play\u0027s default body parser.\n\n### Patches\n\nThis vulnerability been patched in version 2.8.16. There is now a global limit on the depth of a JSON object that can be parsed, which can be configured by the user if necessary.\n\n### Workarounds\n\nApplications that do not need to parse a request body of type `application/json` can switch from the default body parser to another body parser that supports only the specific type of body they expect; for example, the `formUrlEncoded` body parser can be used if the Play action only needs to accept `application/x-www-form-urlencoded`.\n\n",
  "id": "GHSA-v8x6-59g4-5g3w",
  "modified": "2022-06-14T20:00:10Z",
  "published": "2022-06-03T22:18:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/playframework/playframework/security/advisories/GHSA-v8x6-59g4-5g3w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31018"
    },
    {
      "type": "WEB",
      "url": "https://github.com/playframework/playframework/pull/11301"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/playframework/playframework"
    },
    {
      "type": "WEB",
      "url": "https://github.com/playframework/playframework/releases/tag/2.8.16"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Denial of service binding form from JSON in Play Framework"
}

GHSA-V938-7WCM-8MHR

Vulnerability from github – Published: 2023-09-18 09:30 – Updated: 2024-04-04 07:43
VLAI
Details

Certain WithSecure products allow a remote crash of a scanning engine via processing of an import struct in a PE file. This affects WithSecure Client Security 15, WithSecure Server Security 15, WithSecure Email and Server Security 15, WithSecure Elements Endpoint Protection 17 and later, WithSecure Client Security for Mac 15, WithSecure Elements Endpoint Protection for Mac 17 and later, Linux Security 64 12.0 , Linux Protection 12.0, and WithSecure Atlant (formerly F-Secure Atlant) 1.0.35-1.

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-2023-42522"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-18T07:15:37Z",
    "severity": "HIGH"
  },
  "details": "Certain WithSecure products allow a remote crash of a scanning engine via processing of an import struct in a PE file. This affects WithSecure Client Security 15, WithSecure Server Security 15, WithSecure Email and Server Security 15, WithSecure Elements Endpoint Protection 17 and later, WithSecure Client Security for Mac 15, WithSecure Elements Endpoint Protection for Mac 17 and later, Linux Security 64 12.0 , Linux Protection 12.0, and WithSecure Atlant (formerly F-Secure Atlant) 1.0.35-1.",
  "id": "GHSA-v938-7wcm-8mhr",
  "modified": "2024-04-04T07:43:00Z",
  "published": "2023-09-18T09:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42522"
    },
    {
      "type": "WEB",
      "url": "https://www.withsecure.com/en/support/security-advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V95G-89M8-9P9R

Vulnerability from github – Published: 2026-06-01 06:30 – Updated: 2026-06-01 06:30
VLAI
Details

An uncontrolled allocation of resources without limits or throttling in the e-mail handling in OTRS allows excessive allocation which may lead to the abortion of the webserver.This issue affects OTRS:

  • 8.0.X
  • 2023.X
  • 2024.X
  • 2025.X
  • 2026.X before 2026.4.X

Please note that ((OTRS)) Community Edition 6.x, OTRS 7.x and products based on the ((OTRS)) Community Edition also very likely to be affected

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-48187"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-01T04:16:22Z",
    "severity": "MODERATE"
  },
  "details": "An uncontrolled allocation of resources without limits or throttling in the e-mail handling in OTRS allows excessive allocation which may lead to the abortion of the webserver.This issue affects OTRS:\n\n  *  8.0.X\n  *  2023.X\n  *  2024.X\n  *  2025.X\n  *  2026.X before 2026.4.X\n\nPlease note that ((OTRS)) Community Edition 6.x, OTRS 7.x and products based on the ((OTRS)) Community Edition also very likely to be affected",
  "id": "GHSA-v95g-89m8-9p9r",
  "modified": "2026-06-01T06:30:26Z",
  "published": "2026-06-01T06:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48187"
    },
    {
      "type": "WEB",
      "url": "https://otrs.com/release-notes/otrs-security-advisory-2026-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V968-C7V4-J7J9

Vulnerability from github – Published: 2023-05-23 03:30 – Updated: 2024-04-04 04:17
VLAI
Details

Denial-of-service (DoS) vulnerability in Message of Cybozu Garoon 4.10.0 to 5.9.2 allows a remote authenticated attacker to cause a denial of service condition.

Severity
6.5 (Medium)
CVSS:3.1/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-2023-26595"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-23T02:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Denial-of-service (DoS) vulnerability in Message of Cybozu Garoon 4.10.0 to 5.9.2 allows a remote authenticated attacker to cause a denial of service condition.",
  "id": "GHSA-v968-c7v4-j7j9",
  "modified": "2024-04-04T04:17:52Z",
  "published": "2023-05-23T03:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26595"
    },
    {
      "type": "WEB",
      "url": "https://cs.cybozu.co.jp/2023/007698.html"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN41694426"
    }
  ],
  "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: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