CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5401 vulnerabilities reference this CWE, most recent first.
GHSA-FVH4-7PMW-84HM
Vulnerability from github – Published: 2025-07-21 12:30 – Updated: 2025-11-03 21:34A high privileged remote attacker can exhaust critical system resources by sending specifically crafted POST requests to the send-mail action in fast succession.
{
"affected": [],
"aliases": [
"CVE-2025-41677"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-21T10:15:24Z",
"severity": "MODERATE"
},
"details": "A high privileged remote attacker can exhaust critical system resources by sending specifically crafted POST requests to the send-mail action in fast succession.",
"id": "GHSA-fvh4-7pmw-84hm",
"modified": "2025-11-03T21:34:09Z",
"published": "2025-07-21T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41677"
},
{
"type": "WEB",
"url": "https://certvde.com/de/advisories/VDE-2025-058"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Jul/38"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FVMW-88R5-VRP4
Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34A vulnerability in the Bulk Administration Tool (BAT) for Cisco Unity Connection could allow an authenticated, remote attacker to cause high disk utilization, resulting in a denial of service (DoS) condition. The vulnerability exists because the affected software does not restrict the maximum size of certain files that can be written to disk. An attacker who has valid administrator credentials for an affected system could exploit this vulnerability by sending a crafted, remote connection request to an affected system. A successful exploit could allow the attacker to write a file that consumes most of the available disk space on the system, causing application functions to operate abnormally and leading to a DoS condition.
{
"affected": [],
"aliases": [
"CVE-2018-15396"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-05T14:29:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the Bulk Administration Tool (BAT) for Cisco Unity Connection could allow an authenticated, remote attacker to cause high disk utilization, resulting in a denial of service (DoS) condition. The vulnerability exists because the affected software does not restrict the maximum size of certain files that can be written to disk. An attacker who has valid administrator credentials for an affected system could exploit this vulnerability by sending a crafted, remote connection request to an affected system. A successful exploit could allow the attacker to write a file that consumes most of the available disk space on the system, causing application functions to operate abnormally and leading to a DoS condition.",
"id": "GHSA-fvmw-88r5-vrp4",
"modified": "2022-05-13T01:34:21Z",
"published": "2022-05-13T01:34:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15396"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181003-unity-dos"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1041782"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FVMX-5P62-PXM8
Vulnerability from github – Published: 2024-09-17 00:31 – Updated: 2025-11-04 18:31An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in macOS Ventura 13.7, iOS 17.7 and iPadOS 17.7, visionOS 2, watchOS 11, macOS Sequoia 15, iOS 18 and iPadOS 18, macOS Sonoma 14.7, tvOS 18. Processing an image may lead to a denial-of-service.
{
"affected": [],
"aliases": [
"CVE-2024-44176"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-17T00:15:51Z",
"severity": "MODERATE"
},
"details": "An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in macOS Ventura 13.7, iOS 17.7 and iPadOS 17.7, visionOS 2, watchOS 11, macOS Sequoia 15, iOS 18 and iPadOS 18, macOS Sonoma 14.7, tvOS 18. Processing an image may lead to a denial-of-service.",
"id": "GHSA-fvmx-5p62-pxm8",
"modified": "2025-11-04T18:31:24Z",
"published": "2024-09-17T00:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44176"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121234"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121238"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121240"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121246"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121247"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121248"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121249"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121250"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Sep/32"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Sep/33"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Sep/36"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Sep/40"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Sep/41"
}
],
"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-FVQJ-2F9F-F8H7
Vulnerability from github – Published: 2026-02-19 00:30 – Updated: 2026-02-19 00:30Bematech (formerly Logic Controls, now Elgin) MP-4200 TH printer contains a denial of service vulnerability in the admin configuration page. Remote attackers can send crafted POST requests with malformed 'admin' and 'person' parameters to crash the printer's web service, causing a denial of service condition.
{
"affected": [],
"aliases": [
"CVE-2019-25401"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-18T22:16:23Z",
"severity": "HIGH"
},
"details": "Bematech (formerly Logic Controls, now Elgin) MP-4200 TH printer contains a denial of service vulnerability in the admin configuration page. Remote attackers can send crafted POST requests with malformed \u0027admin\u0027 and \u0027person\u0027 parameters to crash the printer\u0027s web service, causing a denial of service condition.",
"id": "GHSA-fvqj-2f9f-f8h7",
"modified": "2026-02-19T00:30:29Z",
"published": "2026-02-19T00:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-25401"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20180814065516/https://www.bematech.com.br"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/47648"
},
{
"type": "WEB",
"url": "https://www.legacyglobal.com/products/bematech-formerly-logic-controls-mp-4200-thermal-receipt-printer/?srsltid=AfmBOor3LXakwJp10bE_8n8YIBKrFPFGFc5DKrxdMGChGQ-Y24i8MVQa"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/bematech-printer-mp-th-denial-of-service"
}
],
"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"
}
]
}
GHSA-FVR3-V8H9-3CWW
Vulnerability from github – Published: 2025-11-10 21:30 – Updated: 2025-11-12 21:31In Open5GS 2.7.6, AMF crashes when receiving an abnormal NGSetupRequest message, resulting in denial of service.
{
"affected": [],
"aliases": [
"CVE-2025-63288"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-10T19:15:57Z",
"severity": "HIGH"
},
"details": "In Open5GS 2.7.6, AMF crashes when receiving an abnormal NGSetupRequest message, resulting in denial of service.",
"id": "GHSA-fvr3-v8h9-3cww",
"modified": "2025-11-12T21:31:06Z",
"published": "2025-11-10T21:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63288"
},
{
"type": "WEB",
"url": "https://github.com/open5gs/open5gs/issues/4087"
},
{
"type": "WEB",
"url": "https://github.com/open5gs/open5gs/commit/be765fe2b03e350836272eee5afb3931bdfb86d5"
}
],
"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-FVWR-H9XH-M6WC
Vulnerability from github – Published: 2020-09-03 20:33 – Updated: 2020-08-31 18:49Versions of @commercial/subtext prior to 5.1.1 are vulnerable to Denial of Service (DoS). The package fails to enforce the maxBytes configuration for payloads with chunked encoding that are written to the file system. This allows attackers to send requests with arbitrary payload sizes, which may exhaust system resources leading to Denial of Service.
Recommendation
Upgrade to version 5.1.1 or later.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@commercial/subtext"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2020-08-31T18:49:40Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Versions of `@commercial/subtext` prior to 5.1.1 are vulnerable to Denial of Service (DoS). The package fails to enforce the `maxBytes` configuration for payloads with chunked encoding that are written to the file system. This allows attackers to send requests with arbitrary payload sizes, which may exhaust system resources leading to Denial of Service.\n\n\n## Recommendation\n\nUpgrade to version 5.1.1 or later.",
"id": "GHSA-fvwr-h9xh-m6wc",
"modified": "2020-08-31T18:49:40Z",
"published": "2020-09-03T20:33:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hapijs/subtext/issues/72"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/1166"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Denial of Service in @commercial/subtext"
}
GHSA-FVXV-8C37-QRC6
Vulnerability from github – Published: 2026-06-29 21:32 – Updated: 2026-06-30 00:31JavaScript::Minifier::XS versions before 0.16 for Perl leak memory on every call to minify(), allowing unbounded memory growth.
In JsMinify (XS.xs) the cleanup frees only the NodeSet structures and never the per-token contents buffers allocated in JsSetNodeContents; JsDiscardNode unlinks nodes without freeing their contents. Each token's contents buffer is therefore leaked on every call, and the two early returns taken when the node list is empty leak the whole NodeSet.
A long-lived process that minifies repeatedly, such as an asset pipeline or a server-side minifier endpoint, grows in memory without bound until it exhausts available memory and is killed, causing denial of service.
{
"affected": [],
"aliases": [
"CVE-2026-56018"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-29T20:17:39Z",
"severity": "HIGH"
},
"details": "JavaScript::Minifier::XS versions before 0.16 for Perl leak memory on every call to minify(), allowing unbounded memory growth.\n\nIn JsMinify (XS.xs) the cleanup frees only the NodeSet structures and never the per-token contents buffers allocated in JsSetNodeContents; JsDiscardNode unlinks nodes without freeing their contents. Each token\u0027s contents buffer is therefore leaked on every call, and the two early returns taken when the node list is empty leak the whole NodeSet.\n\nA long-lived process that minifies repeatedly, such as an asset pipeline or a server-side minifier endpoint, grows in memory without bound until it exhausts available memory and is killed, causing denial of service.",
"id": "GHSA-fvxv-8c37-qrc6",
"modified": "2026-06-30T00:31:30Z",
"published": "2026-06-29T21:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56018"
},
{
"type": "WEB",
"url": "https://github.com/bleargh45/JavaScript-Minifier-XS/issues/10"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/GTERMARS/JavaScript-Minifier-XS-0.16/changes"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/06/29/17"
}
],
"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-FW34-GJFF-GR9G
Vulnerability from github – Published: 2023-04-18 21:30 – Updated: 2024-04-04 03:33Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: Core). Supported versions that are affected are 12.2.1.3.0, 12.2.1.4.0 and 14.1.1.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via T3 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).
{
"affected": [],
"aliases": [
"CVE-2023-21964"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-18T20:15:16Z",
"severity": "HIGH"
},
"details": "Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: Core). Supported versions that are affected are 12.2.1.3.0, 12.2.1.4.0 and 14.1.1.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via T3 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-fw34-gjff-gr9g",
"modified": "2024-04-04T03:33:32Z",
"published": "2023-04-18T21:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21964"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2023.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-FW38-PC54-JVX9
Vulnerability from github – Published: 2026-06-05 16:40 – Updated: 2026-06-05 16:40Summary
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.godata/syncer/kappAccountsSyncer.godata/trie/sync.gocore/throttler/numGoRoutinesThrottler.gocore/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
{
"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:31A 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.
{
"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"
}
]
}
Mitigation
Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Mitigation
- Mitigation of resource exhaustion attacks requires that the target system either:
- The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
- The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- recognizes the attack and denies that user further access for a given amount of time, or
- uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Ensure that protocols have specific limits of scale placed on them.
Mitigation
Ensure that all failures in resource allocation place the system into a safe posture.
CAPEC-147: XML Ping of the Death
An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.
CAPEC-227: Sustained Client Engagement
An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.
CAPEC-492: Regular Expression Exponential Blowup
An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.