GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
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.

6140 vulnerabilities reference this CWE, most recent first.

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).

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

{
  "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.

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": [
    {
      "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

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
5.3 (Medium)
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
Show details on source website
To clipboard 

{
  "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.

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-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.

Severity
6.0 (Medium)
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
Show details on source website
To clipboard 

{
  "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

Severity
6.2 (Medium)
CVSS:3.1/AV:L/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-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

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

{
  "affected": [],
  "aliases": [
    "CVE-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"
    }
  ]
}

GHSA-2MP6-9MJC-P6JG

Vulnerability from github – Published: 2022-11-09 12:00 – Updated: 2025-11-04 00:30
VLAI
Details

An issue was discovered in Python before 3.11.1. An unnecessary quadratic algorithm exists in one path when processing some inputs to the IDNA (RFC 3490) decoder, such that a crafted, unreasonably long name being presented to the decoder could lead to a CPU denial of service. Hostnames are often supplied by remote servers that could be controlled by a malicious actor; in such a scenario, they could trigger excessive CPU consumption on the client attempting to make use of an attacker-supplied supposed hostname. For example, the attack payload could be placed in the Location header of an HTTP response with status code 302. A fix is planned in 3.11.1, 3.10.9, 3.9.16, 3.8.16, and 3.7.16.

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-2022-45061"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-09T07:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Python before 3.11.1. An unnecessary quadratic algorithm exists in one path when processing some inputs to the IDNA (RFC 3490) decoder, such that a crafted, unreasonably long name being presented to the decoder could lead to a CPU denial of service. Hostnames are often supplied by remote servers that could be controlled by a malicious actor; in such a scenario, they could trigger excessive CPU consumption on the client attempting to make use of an attacker-supplied supposed hostname. For example, the attack payload could be placed in the Location header of an HTTP response with status code 302. A fix is planned in 3.11.1, 3.10.9, 3.9.16, 3.8.16, and 3.7.16.",
  "id": "GHSA-2mp6-9mjc-p6jg",
  "modified": "2025-11-04T00:30:34Z",
  "published": "2022-11-09T12:00:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45061"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python/cpython/issues/98433"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/O67LRHDTJWH544KXB6KY4HMHQLYDXFPK"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LKWAMPURWUV3DCCT4J7VHRF4NT2CFVBR"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/KNE4GMD45RGC2HWUAAIGTDHT5VJ2E4O4"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JTYVESWVBPD57ZJC35G5722Q6TS37WSB"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JCDJXNBHWXNYUTOEV4H2HCFSRKV3SYL3"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IN26PWZTYG6IF3APLRXQJBVACQHZUPT2"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GTPVDZDATRQFE6KAT6B4BQIQ4GRHIIIJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BWJREJHWVRBYDP43YB5WRL3QC7UBA7BR"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/B4MYQ3IV6NWA4CKSXEHW45CH2YNDHEPH"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/B3YI6JYARWU6GULWOHNUROSACT54XFFS"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7WQPHKGNXUJC3TC3BDW5RKGROWRJVSFR"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/63FS6VHY4DCS74HBTEINUDOECQ2X6ZCH"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4WBZJNSALFGMPYTINIF57HAAK46U72WQ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/35YDIWCUMWTMDBWFRAVENFH6BLB65D6S"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2AOUKI72ACV6CHY2QUFO6VK2DNMVJ2MB"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZB5YCMIRVX35RUB6XPOWKENCVCJEVDRK"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ORVCQGJCCAVLN4DJDTWGREFCUWXKQRML"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PLQ2BNZVBBAQPV3SPRU24ZD37UYJJS7W"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QCKD4AFBHXIMHS64ZER2U7QRT33HNE7L"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QLUGZSEAO3MBWGKCUSMKQIRYJZKJCIOB"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RDK3ZZBRYFO47ET3N4BNTKVXN47U6ICY"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RH57BNT4VQERGEJ5SXNXSVMDYP66YD4H"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RTN2OOLKYTG34DODUEJGT5MLC2PFGPBA"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/T3D5TX4TDJPXHXD2QICKTY3OCQC3JARP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UHVW73QZJMHA4MK7JBT7CXX7XSNYQEGF"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VCMDX6IFKLOA3NXUQEV524L5LHTPI2JI"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/X3EJ6J7PXVQOULBQZQGBXCXY6LFF6LZD"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XXZJL3CNAFS5PAIR7K4RL62S3Y7THR7O"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YPNWZKXPKTNHS5FVMN7UQZ2UPCSEFJUK"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZB5YCMIRVX35RUB6XPOWKENCVCJEVDRK"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202305-02"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20221209-0007"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JTYVESWVBPD57ZJC35G5722Q6TS37WSB"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JCDJXNBHWXNYUTOEV4H2HCFSRKV3SYL3"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IN26PWZTYG6IF3APLRXQJBVACQHZUPT2"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GTPVDZDATRQFE6KAT6B4BQIQ4GRHIIIJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/BWJREJHWVRBYDP43YB5WRL3QC7UBA7BR"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/B4MYQ3IV6NWA4CKSXEHW45CH2YNDHEPH"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/B3YI6JYARWU6GULWOHNUROSACT54XFFS"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7WQPHKGNXUJC3TC3BDW5RKGROWRJVSFR"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/63FS6VHY4DCS74HBTEINUDOECQ2X6ZCH"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/4WBZJNSALFGMPYTINIF57HAAK46U72WQ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/35YDIWCUMWTMDBWFRAVENFH6BLB65D6S"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2AOUKI72ACV6CHY2QUFO6VK2DNMVJ2MB"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/12/msg00000.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/11/msg00024.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/06/msg00039.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/05/msg00024.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/YPNWZKXPKTNHS5FVMN7UQZ2UPCSEFJUK"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XXZJL3CNAFS5PAIR7K4RL62S3Y7THR7O"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/X3EJ6J7PXVQOULBQZQGBXCXY6LFF6LZD"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VCMDX6IFKLOA3NXUQEV524L5LHTPI2JI"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UHVW73QZJMHA4MK7JBT7CXX7XSNYQEGF"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T3D5TX4TDJPXHXD2QICKTY3OCQC3JARP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RTN2OOLKYTG34DODUEJGT5MLC2PFGPBA"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RH57BNT4VQERGEJ5SXNXSVMDYP66YD4H"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RDK3ZZBRYFO47ET3N4BNTKVXN47U6ICY"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QLUGZSEAO3MBWGKCUSMKQIRYJZKJCIOB"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QCKD4AFBHXIMHS64ZER2U7QRT33HNE7L"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PLQ2BNZVBBAQPV3SPRU24ZD37UYJJS7W"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ORVCQGJCCAVLN4DJDTWGREFCUWXKQRML"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/O67LRHDTJWH544KXB6KY4HMHQLYDXFPK"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LKWAMPURWUV3DCCT4J7VHRF4NT2CFVBR"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KNE4GMD45RGC2HWUAAIGTDHT5VJ2E4O4"
    }
  ],
  "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-2MPQ-2V9J-3J3J

Vulnerability from github – Published: 2025-02-05 18:34 – Updated: 2025-02-05 18:34
VLAI
Details

When Client or Server SSL profiles are configured on a Virtual Server, or DNSSEC signing operations are in use, undisclosed traffic can cause an increase in memory and CPU resource utilization.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-21087"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-05T18:15:30Z",
    "severity": "HIGH"
  },
  "details": "When Client or Server SSL profiles are configured on a Virtual Server, or DNSSEC signing operations are in use, undisclosed traffic can cause an increase in memory and CPU resource utilization.\n\n \n\n\nNote: Software versions which have reached End of Technical Support (EoTS) are not evaluated",
  "id": "GHSA-2mpq-2v9j-3j3j",
  "modified": "2025-02-05T18:34:46Z",
  "published": "2025-02-05T18:34:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21087"
    },
    {
      "type": "WEB",
      "url": "https://my.f5.com/manage/s/article/K000134888"
    }
  ],
  "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:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/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-2MRG-GJXQ-2GVR

Vulnerability from github – Published: 2026-07-23 15:00 – Updated: 2026-07-23 15:00
VLAI
Summary
PHPSpreadsheet: Gnumeric reader unbounded gzip expansion causes memory exhaustion
Details

Summary

PhpSpreadsheet's Gnumeric reader reads attacker-supplied .gnumeric files into memory and, when the file starts with gzip magic bytes, calls gzdecode() on the full compressed contents without enforcing a decompressed-size limit. A very small compressed .gnumeric file can expand to data larger than the PHP memory limit and crash the process during Gnumeric::canRead() before the file is rejected or fully parsed.

This is reachable through normal file-type detection and Gnumeric loading paths, so applications that accept attacker-controlled spreadsheet uploads can suffer denial of service.

Vulnerability details

Gnumeric::canRead() invokes gzfileGetContents() before deciding whether the file is a valid Gnumeric spreadsheet:

  • src/PhpSpreadsheet/Reader/Gnumeric.php:80-90 calls $this->gzfileGetContents($filename) from canRead().
  • src/PhpSpreadsheet/Reader/Gnumeric.php:105-115 calls canRead() and then reads the expanded contents again for worksheet-name listing.
  • src/PhpSpreadsheet/Reader/Gnumeric.php:253-265 calls canRead() and then reads the expanded contents again for full loading.

The vulnerable expansion is in gzfileGetContents():

  • src/PhpSpreadsheet/Reader/Gnumeric.php:187-190 reads the entire input file into $contents with file_get_contents().
  • src/PhpSpreadsheet/Reader/Gnumeric.php:192-197 detects gzip magic bytes and calls gzdecode($contents) without a decompressed-size cap.
  • src/PhpSpreadsheet/Reader/Gnumeric.php:204-205 scans the expanded data only after decompression has already completed.

Because decompression occurs before XML scanning or structural validation, a tiny gzip payload can force large memory allocation even if the resulting XML is meaningless or invalid.

Impact

A small .gnumeric upload can crash a PHP worker during spreadsheet type detection or import. This can cause denial of service in web applications, queue workers, preview services, document converters, or any service that runs PhpSpreadsheet against untrusted spreadsheet files.

In the local reproduction below, a 97,811-byte file expands to about 96 MiB and crashes Gnumeric::canRead() under memory_limit=64M at Reader/Gnumeric.php:195.

Safe local proof of concept

This proof of concept uses only Docker with --network none; it creates the compressed payload inside the container and does not contact external infrastructure.

docker run --rm --network none -i \
  -v /home/sondt23/Github/CVE/ares/github-repo/PhpSpreadsheet:/app \
  -w /app ghcr.io/typo3/core-testing-php82:1.15 sh <<'SH'
set -eu
php -r '
$prefix = "<?xml version=\"1.0\"?><gnm:Workbook xmlns:gnm=\"http://www.gnumeric.org/v10.dtd\">";
$suffix = "</gnm:Workbook>";
$payload = $prefix . str_repeat("A", 96 * 1024 * 1024) . $suffix;
$gz = gzencode($payload, 9);
file_put_contents("/tmp/bomb.gnumeric", $gz);
printf("compressed_size=%d expanded_size=%d\n", filesize("/tmp/bomb.gnumeric"), strlen($payload));
'
php -d memory_limit=64M -d display_errors=1 -r '
require "/app/vendor/autoload.php";
$r = new PhpOffice\PhpSpreadsheet\Reader\Gnumeric();
var_dump($r->canRead("/tmp/bomb.gnumeric"));
' 2>&1 || true
SH

Observed output:

compressed_size=97811 expanded_size=100663390
PHP Fatal error:  Allowed memory size of 67108864 bytes exhausted (tried to allocate 50291378 bytes) in /app/src/PhpSpreadsheet/Reader/Gnumeric.php on line 195
PHP Stack trace:
PHP   1. {main}() Command line code:0
PHP   2. PhpOffice\PhpSpreadsheet\Reader\Gnumeric->canRead($filename = '/tmp/bomb.gnumeric') Command line code:4
PHP   3. PhpOffice\PhpSpreadsheet\Reader\Gnumeric->gzfileGetContents($filename = '/tmp/bomb.gnumeric') /app/src/PhpSpreadsheet/Reader/Gnumeric.php:84
PHP   4. gzdecode(...) /app/src/PhpSpreadsheet/Reader/Gnumeric.php:195

Suggested remediation

  • Do not decompress gzip data with unbounded gzdecode() for untrusted .gnumeric files.
  • Stream decompression with a strict maximum output-size limit before allocating the full expanded XML.
  • Enforce a configurable maximum compressed size and maximum decompressed size for Gnumeric files.
  • Ensure canRead(), listWorksheetNames(), listWorksheetInfo(), and load() share bounded decompression logic and avoid decompressing the same file repeatedly.
  • Fail closed with a recoverable Reader\Exception when limits are exceeded, rather than allowing a PHP fatal memory error.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.8.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "5.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.10.6"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.3.0"
            },
            {
              "fixed": "3.10.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.4.6"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.4.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.17"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.1.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.30.5"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpoffice/phpspreadsheet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.30.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59932"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-23T15:00:17Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nPhpSpreadsheet\u0027s Gnumeric reader reads attacker-supplied `.gnumeric` files into memory and, when the file starts with gzip magic bytes, calls `gzdecode()` on the full compressed contents without enforcing a decompressed-size limit. A very small compressed `.gnumeric` file can expand to data larger than the PHP memory limit and crash the process during `Gnumeric::canRead()` before the file is rejected or fully parsed.\n\nThis is reachable through normal file-type detection and Gnumeric loading paths, so applications that accept attacker-controlled spreadsheet uploads can suffer denial of service.\n\n## Vulnerability details\n\n`Gnumeric::canRead()` invokes `gzfileGetContents()` before deciding whether the file is a valid Gnumeric spreadsheet:\n\n- `src/PhpSpreadsheet/Reader/Gnumeric.php:80-90` calls `$this-\u003egzfileGetContents($filename)` from `canRead()`.\n- `src/PhpSpreadsheet/Reader/Gnumeric.php:105-115` calls `canRead()` and then reads the expanded contents again for worksheet-name listing.\n- `src/PhpSpreadsheet/Reader/Gnumeric.php:253-265` calls `canRead()` and then reads the expanded contents again for full loading.\n\nThe vulnerable expansion is in `gzfileGetContents()`:\n\n- `src/PhpSpreadsheet/Reader/Gnumeric.php:187-190` reads the entire input file into `$contents` with `file_get_contents()`.\n- `src/PhpSpreadsheet/Reader/Gnumeric.php:192-197` detects gzip magic bytes and calls `gzdecode($contents)` without a decompressed-size cap.\n- `src/PhpSpreadsheet/Reader/Gnumeric.php:204-205` scans the expanded data only after decompression has already completed.\n\nBecause decompression occurs before XML scanning or structural validation, a tiny gzip payload can force large memory allocation even if the resulting XML is meaningless or invalid.\n\n## Impact\n\nA small `.gnumeric` upload can crash a PHP worker during spreadsheet type detection or import. This can cause denial of service in web applications, queue workers, preview services, document converters, or any service that runs PhpSpreadsheet against untrusted spreadsheet files.\n\nIn the local reproduction below, a 97,811-byte file expands to about 96 MiB and crashes `Gnumeric::canRead()` under `memory_limit=64M` at `Reader/Gnumeric.php:195`.\n\n## Safe local proof of concept\n\nThis proof of concept uses only Docker with `--network none`; it creates the compressed payload inside the container and does not contact external infrastructure.\n\n```bash\ndocker run --rm --network none -i \\\n  -v /home/sondt23/Github/CVE/ares/github-repo/PhpSpreadsheet:/app \\\n  -w /app ghcr.io/typo3/core-testing-php82:1.15 sh \u003c\u003c\u0027SH\u0027\nset -eu\nphp -r \u0027\n$prefix = \"\u003c?xml version=\\\"1.0\\\"?\u003e\u003cgnm:Workbook xmlns:gnm=\\\"http://www.gnumeric.org/v10.dtd\\\"\u003e\";\n$suffix = \"\u003c/gnm:Workbook\u003e\";\n$payload = $prefix . str_repeat(\"A\", 96 * 1024 * 1024) . $suffix;\n$gz = gzencode($payload, 9);\nfile_put_contents(\"/tmp/bomb.gnumeric\", $gz);\nprintf(\"compressed_size=%d expanded_size=%d\\n\", filesize(\"/tmp/bomb.gnumeric\"), strlen($payload));\n\u0027\nphp -d memory_limit=64M -d display_errors=1 -r \u0027\nrequire \"/app/vendor/autoload.php\";\n$r = new PhpOffice\\PhpSpreadsheet\\Reader\\Gnumeric();\nvar_dump($r-\u003ecanRead(\"/tmp/bomb.gnumeric\"));\n\u0027 2\u003e\u00261 || true\nSH\n```\n\nObserved output:\n\n```text\ncompressed_size=97811 expanded_size=100663390\nPHP Fatal error:  Allowed memory size of 67108864 bytes exhausted (tried to allocate 50291378 bytes) in /app/src/PhpSpreadsheet/Reader/Gnumeric.php on line 195\nPHP Stack trace:\nPHP   1. {main}() Command line code:0\nPHP   2. PhpOffice\\PhpSpreadsheet\\Reader\\Gnumeric-\u003ecanRead($filename = \u0027/tmp/bomb.gnumeric\u0027) Command line code:4\nPHP   3. PhpOffice\\PhpSpreadsheet\\Reader\\Gnumeric-\u003egzfileGetContents($filename = \u0027/tmp/bomb.gnumeric\u0027) /app/src/PhpSpreadsheet/Reader/Gnumeric.php:84\nPHP   4. gzdecode(...) /app/src/PhpSpreadsheet/Reader/Gnumeric.php:195\n```\n\n## Suggested remediation\n\n- Do not decompress gzip data with unbounded `gzdecode()` for untrusted `.gnumeric` files.\n- Stream decompression with a strict maximum output-size limit before allocating the full expanded XML.\n- Enforce a configurable maximum compressed size and maximum decompressed size for Gnumeric files.\n- Ensure `canRead()`, `listWorksheetNames()`, `listWorksheetInfo()`, and `load()` share bounded decompression logic and avoid decompressing the same file repeatedly.\n- Fail closed with a recoverable `Reader\\Exception` when limits are exceeded, rather than allowing a PHP fatal memory error.",
  "id": "GHSA-2mrg-gjxq-2gvr",
  "modified": "2026-07-23T15:00:17Z",
  "published": "2026-07-23T15:00:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-2mrg-gjxq-2gvr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/commit/85f2556b0bf5269061bf45932ecda8a128d81750"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/1.30.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/2.1.18"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/2.4.7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/3.10.7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/PHPOffice/PhpSpreadsheet/releases/tag/5.8.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": "PHPSpreadsheet: Gnumeric reader unbounded gzip expansion causes memory exhaustion"
}
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