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.

5404 vulnerabilities reference this CWE, most recent first.

GHSA-FW38-PC54-JVX9

Vulnerability from github – Published: 2026-06-05 16:40 – Updated: 2026-06-05 16:40
VLAI
Summary
Klever-Go KVM: Throttler slot leak in trie account-data sync causes epoch bootstrap / state sync DoS
Details

Summary

The account-data trie syncers leak bounded throttler slots on error paths in syncDataTrie(). Each failed trie sync permanently consumes one slot from the NumGoRoutinesThrottler, and the slot is never returned unless the sync succeeds or the root hash was already present.

I confirmed this on the current default branch develop at commit 9640d63 (observed on May 20, 2026). I also confirmed the bug with a runtime PoC using the real timeout path in trieSyncer.StartSyncing(): two timed-out sync attempts are enough to exhaust a throttler with capacity 2.

This affects the epoch bootstrap path because syncUserAccountsState() and syncKappAccountsState() create bounded throttlers and abort bootstrap immediately if the syncer returns an error. Once enough trie-root sync attempts fail, the syncer cannot make forward progress and bootstrap fails.

## Affected Components

  • data/syncer/userAccountsSyncer.go
  • data/syncer/kappAccountsSyncer.go
  • data/trie/sync.go
  • core/throttler/numGoRoutinesThrottler.go
  • core/bootstrap/process.go

## Affected Version

Verified on: - develop HEAD 9640d63

Please check whether the same code is present in supported 1.7.x releases.

## Suggested Severity

High

## Vulnerability Details

### Root Cause

Both account-data syncers call StartProcessing() before creating / starting the trie syncer, but they only call EndProcessing() on the success path and on the duplicate-root early return.

userAccountsSyncer.syncDataTrie():

```go func (u *userAccountsSyncer) syncDataTrie(rootHash []byte, ssh data.SyncStatisticsHandler, ctx context.Context) error { u.throttler.StartProcessing()

  u.syncerMutex.Lock()
  if _, ok := u.dataTries[string(rootHash)]; ok {
      u.syncerMutex.Unlock()
      u.throttler.EndProcessing()
      return nil
  }

  dataTrie, err := trie.NewTrie(...)
  if err != nil {
      u.syncerMutex.Unlock()
      return err
  }

  trieSyncer, err := trie.NewTrieSyncer(arg)
  if err != nil {
      u.syncerMutex.Unlock()
      return err
  }

  u.syncerMutex.Unlock()

  err = trieSyncer.StartSyncing(rootHash, ctx)
  if err != nil {
      return err
  }

  u.throttler.EndProcessing()
  return nil

}

The same bug exists in kappAccountsSyncer.syncDataTrie().

  ### Missing slot release paths

  After StartProcessing(), the following error paths return without EndProcessing():

  1. trie.NewTrie(...) returns an error
  2. trie.NewTrieSyncer(...) returns an error
  3. trieSyncer.StartSyncing(...) returns an error

  ### Why this matters

  NumGoRoutinesThrottler is a strict bounded counter:

func (ngrt *NumGoRoutinesThrottler) CanProcess() bool { valCounter := atomic.LoadInt32(&ngrt.counter) return valCounter < ngrt.max }

func (ngrt *NumGoRoutinesThrottler) StartProcessing() { atomic.AddInt32(&ngrt.counter, 1) }

func (ngrt *NumGoRoutinesThrottler) EndProcessing() { atomic.AddInt32(&ngrt.counter, -1) }

Once leaked, a slot remains consumed for the lifetime of that throttler instance.

The parent loops in both syncers wait for capacity before starting the next account-data trie sync:

for !u.throttler.CanProcess() { select { case <-time.After(timeBetweenRetries): continue case <-ctx.Done(): return common.ErrTimeIsOut } }

  So after enough failures, further roots stop progressing and the sync operation eventually returns time is out.

  ### Bootstrap impact

  Epoch bootstrap uses these syncers directly and aborts on any error:

err = e.syncUserAccountsState(e.epochStartMeta.Header.TrieRoot) if err != nil { return nil, nil, err }

err = e.syncKappAccountsState(e.epochStartMeta.Header.KAppsTrieRoot) if err != nil { return nil, nil, err }

  The throttlers for these paths are real bounded throttlers created from numConcurrentTrieSyncers.

  ## Proof of Concept

  I verified the bug with the real timeout path, not only with a canceled context.

  The PoC below uses:

  - a real NumGoRoutinesThrottler with capacity 2
  - a real trieSyncer.StartSyncing()
  - an empty trie-node cache and a request handler that never supplies nodes
  - a short sync timeout (1s) so StartSyncing() returns trie.ErrTimeIsOut

  After the first failed sync, one slot remains leaked.
  After the second failed sync, the throttler is exhausted.

  ### PoC test

package syncer

import ( "context" "testing" "time"

    commonmock "github.com/klever-io/klever-go/common/mock"
    corethrottler "github.com/klever-io/klever-go/core/throttler"
    "github.com/klever-io/klever-go/data"
    "github.com/klever-io/klever-go/data/trie"
    triestats "github.com/klever-io/klever-go/data/trie/statistics"
    "github.com/stretchr/testify/require"

)

func newBaseSyncerForTimeoutPOC(t testing.T) baseAccountsSyncer { t.Helper()

    storageManager, err := trie.NewTrieStorageManagerWithoutPruning(commonmock.NewMemDbMock())
    require.NoError(t, err)

    return &baseAccountsSyncer{
            hasher:                    commonmock.HasherMock{},
            marshalizer:               &commonmock.MarshalizerMock{},
            trieSyncers:               make(map[string]data.TrieSyncer),
            dataTries:                 make(map[string]data.Trie),
            trieStorageManager:        storageManager,
            requestHandler:            &commonmock.RequestHandlerStub{},
            timeout:                   time.Second,
            cacher:                    commonmock.NewCacherStub(),
            maxTrieLevelInMemory:      5,
            name:                      "timeout-poc",
            maxHardCapForMissingNodes: 1,
    }

}

func TestPOC_UserAccountsSyncer_LeaksThrottlerSlotOnTrieTimeout(t *testing.T) { thr, err := corethrottler.NewNumGoRoutinesThrottler(2) require.NoError(t, err)

    s := &userAccountsSyncer{
            baseAccountsSyncer: newBaseSyncerForTimeoutPOC(t),
            throttler:          thr,
    }

    err = s.syncDataTrie([]byte("missing-root-1"), triestats.NewTrieSyncStatistics(), context.Background())
    require.ErrorIs(t, err, trie.ErrTimeIsOut)
    require.True(t, thr.CanProcess())

    err = s.syncDataTrie([]byte("missing-root-2"), triestats.NewTrieSyncStatistics(), context.Background())
    require.ErrorIs(t, err, trie.ErrTimeIsOut)
    require.False(t, thr.CanProcess())

}

func TestPOC_KappAccountsSyncer_LeaksThrottlerSlotOnTrieTimeout(t *testing.T) { thr, err := corethrottler.NewNumGoRoutinesThrottler(2) require.NoError(t, err)

    s := &kappAccountsSyncer{
            baseAccountsSyncer: newBaseSyncerForTimeoutPOC(t),
            throttler:          thr,
    }

    err = s.syncDataTrie([]byte("missing-root-1"), triestats.NewTrieSyncStatistics(), context.Background())
    require.ErrorIs(t, err, trie.ErrTimeIsOut)
    require.True(t, thr.CanProcess())

    err = s.syncDataTrie([]byte("missing-root-2"), triestats.NewTrieSyncStatistics(), context.Background())
    require.ErrorIs(t, err, trie.ErrTimeIsOut)
    require.False(t, thr.CanProcess())

}

  ### Command used

go test ./data/syncer -run 'TestPOC_(User|Kapp)AccountsSyncer_LeaksThrottlerSlotOnTrieTimeout' -count=1

  ### Result

ok github.com/klever-io/klever-go/data/syncer 4.005s

  This confirms the leak with the real timeout path from trieSyncer.StartSyncing().

  ## Impact

  An attacker who can repeatedly cause trie-node sync failures or timeouts during bootstrap can consume the bounded sync throttler until no capacity
  remains.

  Once enough slots are leaked:

  - additional account-data trie sync attempts stop making progress
  - the parent loop waits until context timeout
  - SyncAccounts() fails
  - epoch bootstrap fails

  This is a core node availability issue. It affects fresh/restarting nodes and validators that need to bootstrap or resync state.

  This is not a theoretical issue:

  - StartSyncing() performs network-dependent trie-node retrieval
  - it already has explicit timeout / failure paths
  - the leaked throttler slots are confirmed by runtime PoC

  ## Recommended Fix

  Release the slot with defer immediately after StartProcessing() and cancel the defer only if ownership is intentionally transferred, which is not the
  case here.

  Example fix pattern:

func (u *userAccountsSyncer) syncDataTrie(rootHash []byte, ssh data.SyncStatisticsHandler, ctx context.Context) error { u.throttler.StartProcessing() defer u.throttler.EndProcessing()

  u.syncerMutex.Lock()
  defer u.syncerMutex.Unlock()

  if _, ok := u.dataTries[string(rootHash)]; ok {
      return nil
  }

  dataTrie, err := trie.NewTrie(...)
  if err != nil {
      return err
  }

  trieSyncer, err := trie.NewTrieSyncer(arg)
  if err != nil {
      return err
  }

  u.trieSyncers[string(rootHash)] = trieSyncer
  return trieSyncer.StartSyncing(rootHash, ctx)

} ``` The same pattern should be applied to:

  • data/syncer/userAccountsSyncer.go
  • data/syncer/kappAccountsSyncer.go

## References

  • data/syncer/userAccountsSyncer.go
  • data/syncer/kappAccountsSyncer.go
  • data/trie/sync.go
  • core/throttler/numGoRoutinesThrottler.go
  • core/bootstrap/process.go
  • SECURITY.md
Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/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.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49343"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-772"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-05T16:40:40Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n  The account-data trie syncers leak bounded throttler slots on error paths in `syncDataTrie()`. Each failed trie sync permanently consumes one slot from\n  the `NumGoRoutinesThrottler`, and the slot is never returned unless the sync succeeds or the root hash was already present.\n\n  I confirmed this on the current default branch `develop` at commit `9640d63` (observed on May 20, 2026). I also confirmed the bug with a runtime PoC\n  using the real timeout path in `trieSyncer.StartSyncing()`: two timed-out sync attempts are enough to exhaust a throttler with capacity `2`.\n\n  This affects the epoch bootstrap path because `syncUserAccountsState()` and `syncKappAccountsState()` create bounded throttlers and abort bootstrap\n  immediately if the syncer returns an error. Once enough trie-root sync attempts fail, the syncer cannot make forward progress and bootstrap fails.\n\n  ## Affected Components\n\n  - `data/syncer/userAccountsSyncer.go`\n  - `data/syncer/kappAccountsSyncer.go`\n  - `data/trie/sync.go`\n  - `core/throttler/numGoRoutinesThrottler.go`\n  - `core/bootstrap/process.go`\n\n  ## Affected Version\n\n  Verified on:\n  - `develop` HEAD `9640d63`\n\n  Please check whether the same code is present in supported `1.7.x` releases.\n\n  ## Suggested Severity\n\n  High\n\n  ## Vulnerability Details\n\n  ### Root Cause\n\n  Both account-data syncers call `StartProcessing()` before creating / starting the trie syncer, but they only call `EndProcessing()` on the success path\n  and on the duplicate-root early return.\n\n  `userAccountsSyncer.syncDataTrie()`:\n\n  ```go\n  func (u *userAccountsSyncer) syncDataTrie(rootHash []byte, ssh data.SyncStatisticsHandler, ctx context.Context) error {\n      u.throttler.StartProcessing()\n\n      u.syncerMutex.Lock()\n      if _, ok := u.dataTries[string(rootHash)]; ok {\n          u.syncerMutex.Unlock()\n          u.throttler.EndProcessing()\n          return nil\n      }\n\n      dataTrie, err := trie.NewTrie(...)\n      if err != nil {\n          u.syncerMutex.Unlock()\n          return err\n      }\n\n      trieSyncer, err := trie.NewTrieSyncer(arg)\n      if err != nil {\n          u.syncerMutex.Unlock()\n          return err\n      }\n\n      u.syncerMutex.Unlock()\n\n      err = trieSyncer.StartSyncing(rootHash, ctx)\n      if err != nil {\n          return err\n      }\n\n      u.throttler.EndProcessing()\n      return nil\n  }\n\n  The same bug exists in kappAccountsSyncer.syncDataTrie().\n```\n  ### Missing slot release paths\n\n  After StartProcessing(), the following error paths return without EndProcessing():\n\n  1. trie.NewTrie(...) returns an error\n  2. trie.NewTrieSyncer(...) returns an error\n  3. trieSyncer.StartSyncing(...) returns an error\n\n  ### Why this matters\n\n  NumGoRoutinesThrottler is a strict bounded counter:\n```\n  func (ngrt *NumGoRoutinesThrottler) CanProcess() bool {\n      valCounter := atomic.LoadInt32(\u0026ngrt.counter)\n      return valCounter \u003c ngrt.max\n  }\n\n  func (ngrt *NumGoRoutinesThrottler) StartProcessing() {\n      atomic.AddInt32(\u0026ngrt.counter, 1)\n  }\n\n  func (ngrt *NumGoRoutinesThrottler) EndProcessing() {\n      atomic.AddInt32(\u0026ngrt.counter, -1)\n  }\n\n  Once leaked, a slot remains consumed for the lifetime of that throttler instance.\n\n  The parent loops in both syncers wait for capacity before starting the next account-data trie sync:\n\n  for !u.throttler.CanProcess() {\n      select {\n      case \u003c-time.After(timeBetweenRetries):\n          continue\n      case \u003c-ctx.Done():\n          return common.ErrTimeIsOut\n      }\n  }\n```\n  So after enough failures, further roots stop progressing and the sync operation eventually returns time is out.\n\n  ### Bootstrap impact\n\n  Epoch bootstrap uses these syncers directly and aborts on any error:\n```\n  err = e.syncUserAccountsState(e.epochStartMeta.Header.TrieRoot)\n  if err != nil {\n      return nil, nil, err\n  }\n\n  err = e.syncKappAccountsState(e.epochStartMeta.Header.KAppsTrieRoot)\n  if err != nil {\n      return nil, nil, err\n  }\n```\n  The throttlers for these paths are real bounded throttlers created from numConcurrentTrieSyncers.\n\n  ## Proof of Concept\n\n  I verified the bug with the real timeout path, not only with a canceled context.\n\n  The PoC below uses:\n\n  - a real NumGoRoutinesThrottler with capacity 2\n  - a real trieSyncer.StartSyncing()\n  - an empty trie-node cache and a request handler that never supplies nodes\n  - a short sync timeout (1s) so StartSyncing() returns trie.ErrTimeIsOut\n\n  After the first failed sync, one slot remains leaked.\n  After the second failed sync, the throttler is exhausted.\n\n  ### PoC test\n```\n  package syncer\n\n  import (\n        \"context\"\n        \"testing\"\n        \"time\"\n\n        commonmock \"github.com/klever-io/klever-go/common/mock\"\n        corethrottler \"github.com/klever-io/klever-go/core/throttler\"\n        \"github.com/klever-io/klever-go/data\"\n        \"github.com/klever-io/klever-go/data/trie\"\n        triestats \"github.com/klever-io/klever-go/data/trie/statistics\"\n        \"github.com/stretchr/testify/require\"\n  )\n\n  func newBaseSyncerForTimeoutPOC(t *testing.T) *baseAccountsSyncer {\n        t.Helper()\n\n        storageManager, err := trie.NewTrieStorageManagerWithoutPruning(commonmock.NewMemDbMock())\n        require.NoError(t, err)\n\n        return \u0026baseAccountsSyncer{\n                hasher:                    commonmock.HasherMock{},\n                marshalizer:               \u0026commonmock.MarshalizerMock{},\n                trieSyncers:               make(map[string]data.TrieSyncer),\n                dataTries:                 make(map[string]data.Trie),\n                trieStorageManager:        storageManager,\n                requestHandler:            \u0026commonmock.RequestHandlerStub{},\n                timeout:                   time.Second,\n                cacher:                    commonmock.NewCacherStub(),\n                maxTrieLevelInMemory:      5,\n                name:                      \"timeout-poc\",\n                maxHardCapForMissingNodes: 1,\n        }\n  }\n\n  func TestPOC_UserAccountsSyncer_LeaksThrottlerSlotOnTrieTimeout(t *testing.T) {\n        thr, err := corethrottler.NewNumGoRoutinesThrottler(2)\n        require.NoError(t, err)\n\n        s := \u0026userAccountsSyncer{\n                baseAccountsSyncer: newBaseSyncerForTimeoutPOC(t),\n                throttler:          thr,\n        }\n\n        err = s.syncDataTrie([]byte(\"missing-root-1\"), triestats.NewTrieSyncStatistics(), context.Background())\n        require.ErrorIs(t, err, trie.ErrTimeIsOut)\n        require.True(t, thr.CanProcess())\n\n        err = s.syncDataTrie([]byte(\"missing-root-2\"), triestats.NewTrieSyncStatistics(), context.Background())\n        require.ErrorIs(t, err, trie.ErrTimeIsOut)\n        require.False(t, thr.CanProcess())\n  }\n\n  func TestPOC_KappAccountsSyncer_LeaksThrottlerSlotOnTrieTimeout(t *testing.T) {\n        thr, err := corethrottler.NewNumGoRoutinesThrottler(2)\n        require.NoError(t, err)\n\n        s := \u0026kappAccountsSyncer{\n                baseAccountsSyncer: newBaseSyncerForTimeoutPOC(t),\n                throttler:          thr,\n        }\n\n        err = s.syncDataTrie([]byte(\"missing-root-1\"), triestats.NewTrieSyncStatistics(), context.Background())\n        require.ErrorIs(t, err, trie.ErrTimeIsOut)\n        require.True(t, thr.CanProcess())\n\n        err = s.syncDataTrie([]byte(\"missing-root-2\"), triestats.NewTrieSyncStatistics(), context.Background())\n        require.ErrorIs(t, err, trie.ErrTimeIsOut)\n        require.False(t, thr.CanProcess())\n  }\n```\n  ### Command used\n```\n  go test ./data/syncer -run \u0027TestPOC_(User|Kapp)AccountsSyncer_LeaksThrottlerSlotOnTrieTimeout\u0027 -count=1\n```\n  ### Result\n```\n  ok    github.com/klever-io/klever-go/data/syncer      4.005s\n```\n  This confirms the leak with the real timeout path from trieSyncer.StartSyncing().\n\n  ## Impact\n\n  An attacker who can repeatedly cause trie-node sync failures or timeouts during bootstrap can consume the bounded sync throttler until no capacity\n  remains.\n\n  Once enough slots are leaked:\n\n  - additional account-data trie sync attempts stop making progress\n  - the parent loop waits until context timeout\n  - SyncAccounts() fails\n  - epoch bootstrap fails\n\n  This is a core node availability issue. It affects fresh/restarting nodes and validators that need to bootstrap or resync state.\n\n  This is not a theoretical issue:\n\n  - StartSyncing() performs network-dependent trie-node retrieval\n  - it already has explicit timeout / failure paths\n  - the leaked throttler slots are confirmed by runtime PoC\n\n  ## Recommended Fix\n\n  Release the slot with defer immediately after StartProcessing() and cancel the defer only if ownership is intentionally transferred, which is not the\n  case here.\n\n  Example fix pattern:\n```\n  func (u *userAccountsSyncer) syncDataTrie(rootHash []byte, ssh data.SyncStatisticsHandler, ctx context.Context) error {\n      u.throttler.StartProcessing()\n      defer u.throttler.EndProcessing()\n\n      u.syncerMutex.Lock()\n      defer u.syncerMutex.Unlock()\n\n      if _, ok := u.dataTries[string(rootHash)]; ok {\n          return nil\n      }\n\n      dataTrie, err := trie.NewTrie(...)\n      if err != nil {\n          return err\n      }\n\n      trieSyncer, err := trie.NewTrieSyncer(arg)\n      if err != nil {\n          return err\n      }\n\n      u.trieSyncers[string(rootHash)] = trieSyncer\n      return trieSyncer.StartSyncing(rootHash, ctx)\n  }\n```\n  The same pattern should be applied to:\n\n  - data/syncer/userAccountsSyncer.go\n  - data/syncer/kappAccountsSyncer.go\n\n  ## References\n\n  - data/syncer/userAccountsSyncer.go\n  - data/syncer/kappAccountsSyncer.go\n  - data/trie/sync.go\n  - core/throttler/numGoRoutinesThrottler.go\n  - core/bootstrap/process.go\n  - SECURITY.md",
  "id": "GHSA-fw38-pc54-jvx9",
  "modified": "2026-06-05T16:40:40Z",
  "published": "2026-06-05T16:40:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/security/advisories/GHSA-fw38-pc54-jvx9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/klever-io/klever-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klever-io/klever-go/releases/tag/v1.7.18"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Klever-Go KVM: Throttler slot leak in trie account-data sync causes epoch bootstrap / state sync DoS"
}

GHSA-FW53-Q2VG-JR6G

Vulnerability from github – Published: 2026-07-06 09:30 – Updated: 2026-07-08 09:31
VLAI
Details

A flaw was found in Red Hat Advanced Cluster Security for Kubernetes (RHACS). Central does not limit the depth of GraphQL queries served on the authenticated GraphQL API. An authenticated user with a valid API token can send deeply nested queries that cause excessive resource consumption in Central, resulting in a denial of service for the management plane.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-9165"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-06T09:16:39Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in Red Hat Advanced Cluster Security for Kubernetes (RHACS). Central does not limit the depth of GraphQL queries served on the authenticated GraphQL API. An authenticated user with a valid API token can send deeply nested queries that cause excessive resource consumption in Central, resulting in a denial of service for the management plane.",
  "id": "GHSA-fw53-q2vg-jr6g",
  "modified": "2026-07-08T09:31:47Z",
  "published": "2026-07-06T09:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9165"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36207"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36319"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:36625"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-9165"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2480505"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FW6M-W9WG-Q6CJ

Vulnerability from github – Published: 2022-05-14 01:50 – Updated: 2022-05-14 01:50
VLAI
Details

In BIG-IP 14.0.0-14.0.0.2 or 13.0.0-13.1.1.1, iControl and TMSH usage by authenticated users may leak a small amount of memory when executing commands

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-15325"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-31T14:29:00Z",
    "severity": "MODERATE"
  },
  "details": "In BIG-IP 14.0.0-14.0.0.2 or 13.0.0-13.1.1.1, iControl and TMSH usage by authenticated users may leak a small amount of memory when executing commands",
  "id": "GHSA-fw6m-w9wg-q6cj",
  "modified": "2022-05-14T01:50:11Z",
  "published": "2022-05-14T01:50:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15325"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K77313277"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FW8M-P8G9-XXPF

Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2022-05-24 16:53
VLAI
Details

A vulnerability has been identified in SCALANCE X-200 (All versions), SCALANCE X-200IRT (All versions), SCALANCE X-200RNA (All versions). The device contains a vulnerability that could allow an attacker to trigger a denial-of-service condition by sending large message packages repeatedly to the telnet service. The security vulnerability could be exploited by an attacker with network access to the affected systems. Successful exploitation requires no system privileges and no user interaction. An attacker could use the vulnerability to compromise availability of the device. At the time of advisory publication no public exploitation of this security vulnerability was known.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-10942"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-13T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SCALANCE X-200 (All versions), SCALANCE X-200IRT (All versions), SCALANCE X-200RNA (All versions). The device contains a vulnerability that could allow an attacker to trigger a denial-of-service condition by sending large message packages repeatedly to the telnet service. The security vulnerability could be exploited by an attacker with network access to the affected systems. Successful exploitation requires no system privileges and no user interaction. An attacker could use the vulnerability to compromise availability of the device. At the time of advisory publication no public exploitation of this security vulnerability was known.",
  "id": "GHSA-fw8m-p8g9-xxpf",
  "modified": "2022-05-24T16:53:15Z",
  "published": "2022-05-24T16:53:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10942"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-100232.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-FWCC-9735-QJCM

Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46
VLAI
Details

There's a flaw in OpenEXR's scanline input file functionality in versions before 3.0.0-beta. An attacker able to submit a crafted file to be processed by OpenEXR could consume excessive system memory. The greatest impact of this flaw is to system availability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-3478"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-31T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "There\u0027s a flaw in OpenEXR\u0027s scanline input file functionality in versions before 3.0.0-beta. An attacker able to submit a crafted file to be processed by OpenEXR could consume excessive system memory. The greatest impact of this flaw is to system availability.",
  "id": "GHSA-fwcc-9735-qjcm",
  "modified": "2022-05-24T17:46:00Z",
  "published": "2022-05-24T17:46:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3478"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=27409"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1939160"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/07/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00022.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202107-27"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FWFV-76HG-43MF

Vulnerability from github – Published: 2022-09-03 00:00 – Updated: 2022-09-09 00:00
VLAI
Details

An issue was discovered in net/netfilter/nf_tables_api.c in the Linux kernel before 5.19.6. A denial of service can occur upon binding to an already bound chain.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-39190"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-02T05:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in net/netfilter/nf_tables_api.c in the Linux kernel before 5.19.6. A denial of service can occur upon binding to an already bound chain.",
  "id": "GHSA-fwfv-76hg-43mf",
  "modified": "2022-09-09T00:00:55Z",
  "published": "2022-09-03T00:00:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39190"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torvalds/linux/commit/e02f0d3970404bfea385b6edb86f2d936db0ea2b"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.6"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html"
    },
    {
      "type": "WEB",
      "url": "https://lore.kernel.org/all/20220824220330.64283-12-pablo@netfilter.org"
    },
    {
      "type": "WEB",
      "url": "https://twitter.com/pr0Ln"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FWP5-77RJ-82G4

Vulnerability from github – Published: 2022-05-17 00:21 – Updated: 2022-05-17 00:21
VLAI
Details

An issue was discovered in certain Apple products. macOS before 10.13.1 is affected. The issue involves the "CoreText" component. It allows remote attackers to execute arbitrary code or cause a denial of service (memory consumption) via a crafted font file.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-13825"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-13T03:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in certain Apple products. macOS before 10.13.1 is affected. The issue involves the \"CoreText\" component. It allows remote attackers to execute arbitrary code or cause a denial of service (memory consumption) via a crafted font file.",
  "id": "GHSA-fwp5-77rj-82g4",
  "modified": "2022-05-17T00:21:15Z",
  "published": "2022-05-17T00:21:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-13825"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT208221"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1039710"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FWP9-Q76V-G574

Vulnerability from github – Published: 2026-03-16 15:30 – Updated: 2026-03-16 15:30
VLAI
Details

A vulnerability has been found in Radare2 5.9.9. This issue affects the function walk_exports_trie of the file libr/bin/format/mach0/mach0.c of the component Mach-O File Parser. Such manipulation leads to resource consumption. The attack can only be performed from a local environment. The exploit has been disclosed to the public and may be used. The existence of this vulnerability is still disputed at present. Upgrading to version 6.1.2 is capable of addressing this issue. The name of the patch is 4371ae84c99c46b48cb21badbbef06b30757aba0. You should upgrade the affected component. The code maintainer states that, "[he] wont consider this bug a DoS".

Severity
3.3 (Low)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
1.9 (Low)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-4174"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-16T14:19:57Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been found in Radare2 5.9.9. This issue affects the function walk_exports_trie of the file libr/bin/format/mach0/mach0.c of the component Mach-O File Parser. Such manipulation leads to resource consumption. The attack can only be performed from a local environment. The exploit has been disclosed to the public and may be used. The existence of this vulnerability is still disputed at present. Upgrading to version 6.1.2 is capable of addressing this issue. The name of the patch is 4371ae84c99c46b48cb21badbbef06b30757aba0. You should upgrade the affected component. The code maintainer states that, \"[he] wont consider this bug a DoS\".",
  "id": "GHSA-fwp9-q76v-g574",
  "modified": "2026-03-16T15:30:44Z",
  "published": "2026-03-16T15:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4174"
    },
    {
      "type": "WEB",
      "url": "https://github.com/radareorg/radare2/issues/25482"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ToddAWalter/radare2/commit/4371ae84c99c46b48cb21badbbef06b30757aba0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/radareorg/radare2/milestone/94"
    },
    {
      "type": "WEB",
      "url": "https://github.com/user-attachments/files/25620145/gen_macho_poc.py"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.351081"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.351081"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.769799"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-FWRG-4QC6-4Q9C

Vulnerability from github – Published: 2022-10-15 12:01 – Updated: 2022-10-18 19:00
VLAI
Details

In sensor driver, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service in kernel.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-39125"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-14T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In sensor driver, there is a possible out of bounds write due to a missing bounds check. This could lead to local denial of service in kernel.",
  "id": "GHSA-fwrg-4qc6-4q9c",
  "modified": "2022-10-18T19:00:30Z",
  "published": "2022-10-15T12:01:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39125"
    },
    {
      "type": "WEB",
      "url": "https://www.unisoc.com/en_us/secy/announcementDetail/1575654905820020738"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FX2X-5JPH-MXXH

Vulnerability from github – Published: 2026-04-03 00:31 – Updated: 2026-04-04 00:31
VLAI
Details

Hirschmann EagleSDV version 05.4.01 prior to 05.4.02 contains a denial-of-service vulnerability that causes the device to crash during session establishment when using TLS 1.0 or TLS 1.1. Attackers can trigger a crash by initiating TLS connections with these protocol versions to disrupt service availability.

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": [],
  "aliases": [
    "CVE-2022-4986"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-02T22:16:23Z",
    "severity": "HIGH"
  },
  "details": "Hirschmann EagleSDV version 05.4.01 prior to 05.4.02 contains a denial-of-service vulnerability that causes the device to crash during session establishment when using TLS 1.0 or TLS 1.1. Attackers can trigger a crash by initiating TLS connections with these protocol versions to disrupt service availability.",
  "id": "GHSA-fx2x-5jph-mxxh",
  "modified": "2026-04-04T00:31:26Z",
  "published": "2026-04-03T00:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4986"
    },
    {
      "type": "WEB",
      "url": "https://assets.belden.com/m/1c8fe5d916567af6/original/Belden_Security_Bulletin_BSECV-2022-08.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.belden.com/security"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/hirschmann-eaglesdv-denial-of-service-via-tls"
    }
  ],
  "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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}
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