Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

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

6414 vulnerabilities reference this CWE, most recent first.

GHSA-2JVR-RX29-36X8

Vulnerability from github – Published: 2026-07-22 00:31 – Updated: 2026-07-22 00:31
VLAI
Details

Vulnerability in the MySQL Server, MySQL Cluster product of Oracle MySQL (component: Server: JSON). Supported versions that are affected are MySQL Server: 9.7.0-9.7.1; MySQL Cluster: 9.7.0-9.7.1. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server, MySQL Cluster. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server, MySQL Cluster. CVSS 3.1 Base Score 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-60718"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T22:18:12Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server, MySQL Cluster product of Oracle MySQL (component: Server: JSON).  Supported versions that are affected are MySQL Server: 9.7.0-9.7.1; MySQL Cluster: 9.7.0-9.7.1. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server, MySQL Cluster.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server, MySQL Cluster. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-2jvr-rx29-36x8",
  "modified": "2026-07-22T00:31:57Z",
  "published": "2026-07-22T00:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60718"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2026.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-2M3V-V2M8-Q956

Vulnerability from github – Published: 2025-12-11 22:36 – Updated: 2025-12-11 22:36
VLAI
Summary
Denial of Service Vulnerability in React Server Components
Details

Impact

There is a denial of service vulnerability in React Server Components.

React recommends updating immediately.

The vulnerability exists in versions 19.0.0, 19.0.1 19.1.0, 19.1.1, 19.1.2, 19.2.0 and 19.2.1 of:

These issues are present in the patches published last week.

Patches

Fixes were back ported to versions 19.0.2, 19.1.3, and 19.2.2.

If you are using any of the above packages please upgrade to any of the fixed versions immediately.

If your app’s React code does not use a server, your app is not affected by this vulnerability. If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by this vulnerability.

References

See the blog post for more information and upgrade instructions.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "react-server-dom-parcel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.0.0"
            },
            {
              "fixed": "19.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "react-server-dom-turbopack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.0.0"
            },
            {
              "fixed": "19.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "react-server-dom-webpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.0.0"
            },
            {
              "fixed": "19.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "react-server-dom-parcel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.1.0"
            },
            {
              "fixed": "19.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "react-server-dom-parcel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.2.0"
            },
            {
              "fixed": "19.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "react-server-dom-turbopack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.1.0"
            },
            {
              "fixed": "19.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "react-server-dom-turbopack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.2.0"
            },
            {
              "fixed": "19.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "react-server-dom-webpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.1.0"
            },
            {
              "fixed": "19.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "react-server-dom-webpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "19.2.0"
            },
            {
              "fixed": "19.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-55184"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-502"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-11T22:36:44Z",
    "nvd_published_at": "2025-12-11T20:16:00Z",
    "severity": "HIGH"
  },
  "details": "## Impact\n\nThere is a denial of service vulnerability in React Server Components.\n\nReact recommends updating immediately.\n\nThe vulnerability exists in versions 19.0.0, 19.0.1 19.1.0, 19.1.1, 19.1.2, 19.2.0 and 19.2.1 of:\n\n- [react-server-dom-webpack](https://www.npmjs.com/package/react-server-dom-webpack)\n- [react-server-dom-parcel](https://www.npmjs.com/package/react-server-dom-parcel)\n- [react-server-dom-turbopack](https://www.npmjs.com/package/react-server-dom-turbopack?activeTab=readme)\n\nThese issues are present in the patches published last week.\n\n## Patches\n\nFixes were back ported to versions 19.0.2, 19.1.3, and 19.2.2. \n\nIf you are using any of the above packages please upgrade to any of the fixed versions immediately.\n\nIf your app\u2019s React code does not use a server, your app is not affected by this vulnerability. If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by this vulnerability.\n\n## References\n\nSee the [blog post](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components) for more information and upgrade instructions.",
  "id": "GHSA-2m3v-v2m8-q956",
  "modified": "2025-12-11T22:36:45Z",
  "published": "2025-12-11T22:36:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/facebook/react/security/advisories/GHSA-2m3v-v2m8-q956"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55184"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/facebook/react"
    },
    {
      "type": "WEB",
      "url": "https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components"
    },
    {
      "type": "WEB",
      "url": "https://www.facebook.com/security/advisories/cve-2025-55184"
    }
  ],
  "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 Vulnerability in React Server Components"
}

GHSA-2M62-P72C-JPC9

Vulnerability from github – Published: 2026-09-08 03:31 – Updated: 2026-09-08 03:31
VLAI
Details

A vulnerability was found in java-json-tools jackson-coreutils 2.0. Affected by this vulnerability is the function BigDecimal.toPlainString of the file src/main/java/com/github/fge/jackson/JacksonUtils.java. Performing a manipulation results in resource consumption. The attack may be initiated remotely. The exploit has been made public and could be used. The project was informed of the problem early through an issue report but has not responded yet.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-86511"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T03:17:19Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in java-json-tools jackson-coreutils 2.0. Affected by this vulnerability is the function BigDecimal.toPlainString of the file src/main/java/com/github/fge/jackson/JacksonUtils.java. Performing a manipulation results in resource consumption. The attack may be initiated remotely. The exploit has been made public and could be used. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-2m62-p72c-jpc9",
  "modified": "2026-09-08T03:31:15Z",
  "published": "2026-09-08T03:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86511"
    },
    {
      "type": "WEB",
      "url": "https://github.com/java-json-tools/jackson-coreutils/issues/65"
    },
    {
      "type": "WEB",
      "url": "https://github.com/java-json-tools/jackson-coreutils"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-86511"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/908322"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/399664"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/399664/cti"
    }
  ],
  "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:P/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-2M7F-2C58-JFXC

Vulnerability from github – Published: 2025-10-21 21:33 – Updated: 2025-10-21 21:33
VLAI
Details

Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB). Supported versions that are affected are 8.0.0-8.0.43, 8.4.0-8.4.6 and 9.0.0-9.4.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 hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-53062"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-21T20:20:46Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.43, 8.4.0-8.4.6 and  9.0.0-9.4.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 hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-2m7f-2c58-jfxc",
  "modified": "2025-10-21T21:33:42Z",
  "published": "2025-10-21T21:33:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53062"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2025.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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2M8G-3CMR-WG3W

Vulnerability from github – Published: 2026-09-01 19:24 – Updated: 2026-09-01 19:24
VLAI
Summary
Django REST framework: Potential bypass of Django `DATA_UPLOAD_MAX_MEMORY_SIZE` when parsing oversized JSON and urlencoded request bodies via DRF `request.data`
Details

Summary

While investigating Django REST Framework's request parsing behavior, I identified that DRF's high-level request.data parsing appears to bypass Django's configured DATA_UPLOAD_MAX_MEMORY_SIZE protection for application/json and application/x-www-form-urlencoded request bodies.

In the tested configurations, Django correctly raises RequestDataTooBig when applications access request.body or Django's native request.POST, but DRF successfully parses the same oversized payloads through request.data.

This behavior appears to occur because DRF passes the underlying HttpRequest object directly to parsers, which consume the request stream through Django's lower-level streaming interface rather than the guarded request.body path.

I am reporting this privately because I am unsure whether this behavior is considered part of DRF's intended security boundary, but it appears to bypass a documented Django request-size protection for common DRF request parsing paths and may have availability implications.

What I Verified

I verified the behavior locally using the following combinations:

  • Django 6.0.7 + DRF 3.17.1 → Affected
  • Django 6.0.7 + DRF current upstream main → Affected

For both versions, the observed behavior was:

Django request.body
→ RequestDataTooBig

Django request.POST (application/x-www-form-urlencoded)
→ RequestDataTooBig

Django request.read()
→ Reads the entire oversized request body

DRF request.data
→ Successfully parses oversized JSON and urlencoded request bodies

I also confirmed that:

  • multipart/form-data remains protected because DRF delegates multipart parsing to Django's multipart parser.
  • The behavior reproduces on both direct WSGI and ASGI servers without a reverse proxy or external request-size middleware.

Technical Details

The relevant execution flow is:

APIView

↓

rest_framework.request.Request

↓

request.data

↓

Request._load_data_and_files()

↓

Request._parse()

↓

Request._load_stream()

↓

self._stream = self._request

↓

JSONParser.parse(...)
or
FormParser.parse(...)

↓

stream.read() / json.load(...)

The important implementation detail is that DRF assigns the original Django HttpRequest object as the parser stream.

Unlike request.body and Django's native form parsing, consuming the stream through HttpRequest.read() does not trigger Django's RequestDataTooBig protection.

As a result, DRF's built-in parsers successfully consume oversized request bodies that Django itself would reject through its higher-level request interfaces.

Reproduction Steps

Environment

Python 3.13

Django 6.0.7

Django REST Framework 3.17.1 (also reproduced on current upstream main)

Configure:

DATA_UPLOAD_MAX_MEMORY_SIZE = 10

Create a simple DRF API view:

from rest_framework.views import APIView
from rest_framework.response import Response

class DemoView(APIView):
    def post(self, request):
        return Response(request.data)

Start the application.

Send an oversized JSON request:

POST /demo
Content-Type: application/json
Content-Length: >10 bytes

Example:

{
  "value": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA..."
}

Observed:

HTTP 200

JSON successfully parsed

Now compare against:

request.body

Observed:

RequestDataTooBig

Likewise, compare against:

request.POST

using

application/x-www-form-urlencoded

Observed:

RequestDataTooBig

This demonstrates different enforcement depending on which request API is used.

Root Cause

Django documents HttpRequest.read() as a streaming interface.

DRF exposes request.data as the primary high-level request parsing API.

Currently, DRF forwards the raw Django request stream directly to parsers before any request-size validation equivalent to Django's request.body path occurs.

Consequently:

  • JSONParser
  • FormParser

fully consume oversized request bodies despite Django's configured request-size limit.

Security Impact

This does not appear to introduce:

  • Authentication bypass
  • Authorization bypass
  • Remote code execution
  • Information disclosure
  • Integrity compromise

However, it may reduce the effectiveness of deployments relying on Django's DATA_UPLOAD_MAX_MEMORY_SIZE to limit request-body resource consumption.

Potential consequences include:

  • Additional memory allocation during JSON parsing
  • Additional CPU usage while decoding large JSON payloads
  • Increased resource consumption when handling oversized request bodies
  • Reduced effectiveness of Django's configured request-size protection for DRF endpoints using request.data

The practical impact depends on deployment configuration, including:

  • upstream request-size limits
  • reverse proxy configuration
  • authentication
  • rate limiting
  • endpoint exposure

Memory Observations

During local testing I observed successful parsing of oversized request bodies despite the configured limit.

Representative measurements showed significantly increased memory allocation while parsing large JSON and urlencoded payloads.

I intentionally did not perform destructive concurrency testing or attempt to exhaust system resources.

Scope

Confirmed affected:

  • application/json
  • application/x-www-form-urlencoded

Confirmed not affected:

  • multipart/form-data

Suggested Fix Direction

One possible approach would be for DRF to enforce Django's configured DATA_UPLOAD_MAX_MEMORY_SIZE before handing the raw request stream to parsers that fully materialize request bodies in memory.

This would preserve Django's configured request-size protection for the common request.data API without requiring broader changes to Django's documented streaming interface.

Versions Tested

Affected:

  • Django 6.0.7 + DRF 3.17.1
  • Django 6.0.7 + DRF current upstream main

I did not perform a complete historical version bisect.

Disclosure

I have not publicly disclosed this behavior.

I am submitting it privately in accordance with the project's security policy because I am unsure whether maintainers consider this part of DRF's intended security boundary.

Note:

Thank you for taking the time to review this report.

If you determine that this behavior should be addressed, I would be happy to help investigate further, develop a fix, add regression tests, and submit a patch if you'd find that helpful.

I have experience as a Python/Django software engineer, security researcher, and open-source contributor, and I'd be glad to contribute if you think that would be useful.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "djangorestframework"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.17.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73228"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-01T19:24:51Z",
    "nvd_published_at": "2026-08-11T19:18:52Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nWhile investigating Django REST Framework\u0027s request parsing behavior, I identified that DRF\u0027s high-level `request.data` parsing appears to bypass Django\u0027s configured `DATA_UPLOAD_MAX_MEMORY_SIZE` protection for `application/json` and `application/x-www-form-urlencoded` request bodies.\n\nIn the tested configurations, Django correctly raises `RequestDataTooBig` when applications access `request.body` or Django\u0027s native `request.POST`, but DRF successfully parses the same oversized payloads through `request.data`.\n\nThis behavior appears to occur because DRF passes the underlying `HttpRequest` object directly to parsers, which consume the request stream through Django\u0027s lower-level streaming interface rather than the guarded `request.body` path.\n\nI am reporting this privately because I am unsure whether this behavior is considered part of DRF\u0027s intended security boundary, but it appears to bypass a documented Django request-size protection for common DRF request parsing paths and may have availability implications.\n\n\n# What I Verified\n\nI verified the behavior locally using the following combinations:\n\n* Django **6.0.7** + DRF **3.17.1** \u2192 **Affected**\n* Django **6.0.7** + DRF **current upstream main** \u2192 **Affected**\n\nFor both versions, the observed behavior was:\n\n```\nDjango request.body\n\u2192 RequestDataTooBig\n\nDjango request.POST (application/x-www-form-urlencoded)\n\u2192 RequestDataTooBig\n\nDjango request.read()\n\u2192 Reads the entire oversized request body\n\nDRF request.data\n\u2192 Successfully parses oversized JSON and urlencoded request bodies\n```\n\nI also confirmed that:\n\n* `multipart/form-data` remains protected because DRF delegates multipart parsing to Django\u0027s multipart parser.\n* The behavior reproduces on both direct WSGI and ASGI servers without a reverse proxy or external request-size middleware.\n\n\n# Technical Details\n\nThe relevant execution flow is:\n\n```\nAPIView\n\n\u2193\n\nrest_framework.request.Request\n\n\u2193\n\nrequest.data\n\n\u2193\n\nRequest._load_data_and_files()\n\n\u2193\n\nRequest._parse()\n\n\u2193\n\nRequest._load_stream()\n\n\u2193\n\nself._stream = self._request\n\n\u2193\n\nJSONParser.parse(...)\nor\nFormParser.parse(...)\n\n\u2193\n\nstream.read() / json.load(...)\n```\n\nThe important implementation detail is that DRF assigns the original Django `HttpRequest` object as the parser stream.\n\nUnlike `request.body` and Django\u0027s native form parsing, consuming the stream through `HttpRequest.read()` does not trigger Django\u0027s `RequestDataTooBig` protection.\n\nAs a result, DRF\u0027s built-in parsers successfully consume oversized request bodies that Django itself would reject through its higher-level request interfaces.\n\n\n# Reproduction Steps\n\n## Environment\n\nPython 3.13\n\nDjango 6.0.7\n\nDjango REST Framework 3.17.1 (also reproduced on current upstream main)\n\nConfigure:\n\n```python\nDATA_UPLOAD_MAX_MEMORY_SIZE = 10\n```\n\nCreate a simple DRF API view:\n\n```python\nfrom rest_framework.views import APIView\nfrom rest_framework.response import Response\n\nclass DemoView(APIView):\n    def post(self, request):\n        return Response(request.data)\n```\n\nStart the application.\n\nSend an oversized JSON request:\n\n```\nPOST /demo\nContent-Type: application/json\nContent-Length: \u003e10 bytes\n```\n\nExample:\n\n```json\n{\n  \"value\": \"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...\"\n}\n```\n\nObserved:\n\n```\nHTTP 200\n\nJSON successfully parsed\n```\n\nNow compare against:\n\n```python\nrequest.body\n```\n\nObserved:\n\n```\nRequestDataTooBig\n```\n\nLikewise, compare against:\n\n```python\nrequest.POST\n```\n\nusing\n\n```\napplication/x-www-form-urlencoded\n```\n\nObserved:\n\n```\nRequestDataTooBig\n```\n\nThis demonstrates different enforcement depending on which request API is used.\n\n\n# Root Cause\n\nDjango documents `HttpRequest.read()` as a streaming interface.\n\nDRF exposes `request.data` as the primary high-level request parsing API.\n\nCurrently, DRF forwards the raw Django request stream directly to parsers before any request-size validation equivalent to Django\u0027s `request.body` path occurs.\n\nConsequently:\n\n* JSONParser\n* FormParser\n\nfully consume oversized request bodies despite Django\u0027s configured request-size limit.\n\n\n# Security Impact\n\nThis does **not** appear to introduce:\n\n* Authentication bypass\n* Authorization bypass\n* Remote code execution\n* Information disclosure\n* Integrity compromise\n\nHowever, it may reduce the effectiveness of deployments relying on Django\u0027s `DATA_UPLOAD_MAX_MEMORY_SIZE` to limit request-body resource consumption.\n\nPotential consequences include:\n\n* Additional memory allocation during JSON parsing\n* Additional CPU usage while decoding large JSON payloads\n* Increased resource consumption when handling oversized request bodies\n* Reduced effectiveness of Django\u0027s configured request-size protection for DRF endpoints using `request.data`\n\nThe practical impact depends on deployment configuration, including:\n\n* upstream request-size limits\n* reverse proxy configuration\n* authentication\n* rate limiting\n* endpoint exposure\n\n\n# Memory Observations\n\nDuring local testing I observed successful parsing of oversized request bodies despite the configured limit.\n\nRepresentative measurements showed significantly increased memory allocation while parsing large JSON and urlencoded payloads.\n\nI intentionally did **not** perform destructive concurrency testing or attempt to exhaust system resources.\n\n\n# Scope\n\nConfirmed affected:\n\n* application/json\n* application/x-www-form-urlencoded\n\nConfirmed not affected:\n\n* multipart/form-data\n\n\n# Suggested Fix Direction\n\nOne possible approach would be for DRF to enforce Django\u0027s configured `DATA_UPLOAD_MAX_MEMORY_SIZE` before handing the raw request stream to parsers that fully materialize request bodies in memory.\n\nThis would preserve Django\u0027s configured request-size protection for the common `request.data` API without requiring broader changes to Django\u0027s documented streaming interface.\n\n\n# Versions Tested\n\nAffected:\n\n* Django 6.0.7 + DRF 3.17.1\n* Django 6.0.7 + DRF current upstream main\n\nI did not perform a complete historical version bisect.\n\n\n# Disclosure\n\nI have not publicly disclosed this behavior.\n\nI am submitting it privately in accordance with the project\u0027s security policy because I am unsure whether maintainers consider this part of DRF\u0027s intended security boundary.\n\n# Note:\n\n**Thank you for taking the time to review this report.**\n\nIf you determine that this behavior should be addressed, I would be happy to help investigate further, develop a fix, add regression tests, and submit a patch if you\u0027d find that helpful.\n\nI have experience as a **Python/Django software engineer, security researcher, and open-source contributor**, and I\u0027d be glad to contribute if you think that would be useful.",
  "id": "GHSA-2m8g-3cmr-wg3w",
  "modified": "2026-09-01T19:24:51Z",
  "published": "2026-09-01T19:24:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/encode/django-rest-framework/security/advisories/GHSA-2m8g-3cmr-wg3w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73228"
    },
    {
      "type": "WEB",
      "url": "https://github.com/encode/django-rest-framework/pull/10013"
    },
    {
      "type": "WEB",
      "url": "https://github.com/encode/django-rest-framework/commit/2912dc98042f78e27636551fc22eeaf10f725fdd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/encode/django-rest-framework/commit/82ef7b7e4e0a73ba5c489b465fae7e76d948da4e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/encode/django-rest-framework"
    },
    {
      "type": "WEB",
      "url": "https://github.com/encode/django-rest-framework/releases/tag/3.17.2"
    }
  ],
  "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": "Django REST framework: Potential bypass of Django `DATA_UPLOAD_MAX_MEMORY_SIZE` when parsing oversized JSON and urlencoded request bodies via DRF `request.data`"
}

GHSA-2M96-52R3-2F3G

Vulnerability from github – Published: 2024-08-19 17:29 – Updated: 2024-08-21 14:55
VLAI
Summary
fugit parse and parse_nat stall on lengthy input
Details

Impact

The fugit "natural" parser, that turns "every wednesday at 5pm" into "0 17 * * 3", accepted any length of input and went on attempting to parse it, not returning promptly, as expected. The parse call could hold the thread with no end in sight.

Fugit dependents that do not check (user) input length for plausability are impacted.

Patches

Problem was reported in #104 and the fix was released in fugit 1.11.1

Workarounds

By making sure that Fugit.parse(s), Fugit.do_parse(s), Fugit.parse_nat(s), Fugit.do_parse_nat(s), Fugit::Nat.parse(s), and Fugit::Nat.do_parse(s) are not fed strings too long. 1000 chars feels ok, while 10_000 chars makes it stall.

In fewer words, making sure those fugit methods are not fed unvetted input strings.

References

gh-104

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "fugit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-43380"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-19T17:29:36Z",
    "nvd_published_at": "2024-08-19T15:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe fugit \"natural\" parser, that turns \"every wednesday at 5pm\" into \"0 17 * * 3\", accepted any length of input and went on attempting to parse it, not returning promptly, as expected. The parse call could hold the thread with no end in sight.\n\nFugit dependents that do not check (user) input length for plausability are impacted.\n\n### Patches\n\nProblem was reported in #104 and the fix was released in [fugit 1.11.1](https://rubygems.org/gems/fugit/versions/1.11.1)\n\n### Workarounds\n\nBy making sure that `Fugit.parse(s)`, `Fugit.do_parse(s)`, `Fugit.parse_nat(s)`, `Fugit.do_parse_nat(s)`, `Fugit::Nat.parse(s)`, and `Fugit::Nat.do_parse(s)` are not fed strings too long. 1000 chars feels ok, while 10_000 chars makes it stall.\n\nIn fewer words, making sure those fugit methods are not fed unvetted input strings.\n\n### References\n\ngh-104\n",
  "id": "GHSA-2m96-52r3-2f3g",
  "modified": "2024-08-21T14:55:22Z",
  "published": "2024-08-19T17:29:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/floraison/fugit/security/advisories/GHSA-2m96-52r3-2f3g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43380"
    },
    {
      "type": "WEB",
      "url": "https://github.com/floraison/fugit/issues/104"
    },
    {
      "type": "WEB",
      "url": "https://github.com/floraison/fugit/commit/ad2c1c9c737213d585fff0b51c927d178b2c05a5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/floraison/fugit"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/fugit/CVE-2024-43380.yml"
    }
  ],
  "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:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "fugit parse and parse_nat stall on lengthy input"
}

GHSA-2MF6-25GQ-26V8

Vulnerability from github – Published: 2026-03-24 15:30 – Updated: 2026-03-24 21:31
VLAI
Details

Denial-of-service in the WebRTC: Signaling component. This vulnerability affects Firefox < 149 and Firefox ESR < 140.9.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-4704"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-24T13:16:06Z",
    "severity": "HIGH"
  },
  "details": "Denial-of-service in the WebRTC: Signaling component. This vulnerability affects Firefox \u003c 149 and Firefox ESR \u003c 140.9.",
  "id": "GHSA-2mf6-25gq-26v8",
  "modified": "2026-03-24T21:31:22Z",
  "published": "2026-03-24T15:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4704"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2014868"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-20"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-22"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-23"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2026-24"
    }
  ],
  "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-2MGW-7Q6P-8GRG

Vulnerability from github – Published: 2026-05-19 19:56 – Updated: 2026-06-12 19:27
VLAI
Summary
FPDI: Memory Exhaustion and Endless Loop in FPDI leads to Denial of Service
Details

Impact

This is a significant Denial of Service (DoS) vulnerability. Any application that uses FPDI to process user-supplied PDF files is at risk. An attacker can upload a small, malicious PDF file that will cause the server-side script to crash due to memory exhaustion or a script time-out. Repeated attacks can lead to sustained service unavailability.

Patches

Fixed as of version 2.6.7

Workarounds

No.

References

No.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "setasign/fpdi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45802"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T19:56:17Z",
    "nvd_published_at": "2026-06-11T20:16:23Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThis is a significant Denial of Service (DoS) vulnerability. Any application that uses FPDI to process user-supplied PDF files is at risk. An attacker can upload a small, malicious PDF file that will cause the server-side script to crash due to memory exhaustion or a script time-out. Repeated attacks can lead to sustained service unavailability.\n\n### Patches\nFixed as of version 2.6.7\n\n### Workarounds\nNo.\n\n### References\nNo.",
  "id": "GHSA-2mgw-7q6p-8grg",
  "modified": "2026-06-12T19:27:03Z",
  "published": "2026-05-19T19:56:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Setasign/FPDI/security/advisories/GHSA-2mgw-7q6p-8grg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45802"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Setasign/FPDI/commit/1695cfcc7e01fe844a7296b3de90855a3fa65be6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Setasign/FPDI"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Setasign/FPDI/releases/tag/v2.6.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FPDI: Memory Exhaustion and Endless Loop in FPDI leads to Denial of Service"
}

GHSA-2MJ4-5V84-3P3J

Vulnerability from github – Published: 2023-11-14 18:30 – Updated: 2023-11-14 18:30
VLAI
Details

Visual Studio Denial of Service Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-36042"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-14T18:15:34Z",
    "severity": "MODERATE"
  },
  "details": "Visual Studio Denial of Service Vulnerability",
  "id": "GHSA-2mj4-5v84-3p3j",
  "modified": "2023-11-14T18:30:28Z",
  "published": "2023-11-14T18:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36042"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36042"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2MMQ-F6MJ-FWFX

Vulnerability from github – Published: 2023-01-26 21:30 – Updated: 2023-02-01 18:30
VLAI
Details

In several functions of SettingsState.java, there is a possible system 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.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-239415861

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-20908"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-26T21:18:00Z",
    "severity": "MODERATE"
  },
  "details": "In several functions of SettingsState.java, there is a possible system 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.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-239415861",
  "id": "GHSA-2mmq-f6mj-fwfx",
  "modified": "2023-02-01T18:30:31Z",
  "published": "2023-01-26T21:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20908"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2023-01-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"
    }
  ]
}

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.