Common Weakness Enumeration
CWE-772
AllowedMissing Release of Resource after Effective Lifetime
Abstraction: Base · Status: Draft
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
567 vulnerabilities reference this CWE, most recent first.
GHSA-FQX9-V8WW-56P9
Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2022-05-13 01:47
VLAI
Details
In ImageMagick 7.0.5-5, the ReadSFWImage function in sfw.c allows attackers to cause a denial of service (memory leak) via a crafted file.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2017-8349"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-30T17:59:00Z",
"severity": "MODERATE"
},
"details": "In ImageMagick 7.0.5-5, the ReadSFWImage function in sfw.c allows attackers to cause a denial of service (memory leak) via a crafted file.",
"id": "GHSA-fqx9-v8ww-56p9",
"modified": "2022-05-13T01:47:30Z",
"published": "2022-05-13T01:47:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8349"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/443"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3863"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/98370"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FR3C-69VX-774F
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50
VLAI
Details
ImageMagick 7.0.7-28 has a memory leak vulnerability in WriteSGIImage in coders/sgi.c.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2018-17965"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-03T18:29:00Z",
"severity": "MODERATE"
},
"details": "ImageMagick 7.0.7-28 has a memory leak vulnerability in WriteSGIImage in coders/sgi.c.",
"id": "GHSA-fr3c-69vx-774f",
"modified": "2022-05-13T01:50:36Z",
"published": "2022-05-13T01:50:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-17965"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/1052"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-17965"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4034-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FR4G-HMC7-W66H
Vulnerability from github – Published: 2022-04-05 00:00 – Updated: 2022-04-12 00:00
VLAI
Details
A potential DOS vulnerability was discovered in GitLab CE/EE affecting all versions from 13.1 prior to 14.7.7, 14.8.0 prior to 14.8.5, and 14.9.0 prior to 14.9.2. The api to update an asset as a link from a release had a regex check which caused exponential number of backtracks for certain user supplied values resulting in high CPU usage.
Severity
4.3 (Medium)
{
"affected": [],
"aliases": [
"CVE-2022-1100"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-04T20:15:00Z",
"severity": "MODERATE"
},
"details": "A potential DOS vulnerability was discovered in GitLab CE/EE affecting all versions from 13.1 prior to 14.7.7, 14.8.0 prior to 14.8.5, and 14.9.0 prior to 14.9.2. The api to update an asset as a link from a release had a regex check which caused exponential number of backtracks for certain user supplied values resulting in high CPU usage.",
"id": "GHSA-fr4g-hmc7-w66h",
"modified": "2022-04-12T00:00:53Z",
"published": "2022-04-05T00:00:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1100"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-1100.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/273771"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-FRPP-8PWQ-HJRX
Vulnerability from github – Published: 2026-01-26 21:30 – Updated: 2026-02-05 15:31
VLAI
Summary
Hibernate Reactive Vulnerable to DoS via Connection Pool Exhaustion
Details
A flaw was found in Hibernate Reactive. When an HTTP endpoint is exposed to perform database operations, a remote client can prematurely close the HTTP connection. This action may lead to leaking connections from the database connection pool, potentially causing a Denial of Service (DoS) by exhausting available database connections.
Severity
4.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.hibernate.reactive:hibernate-reactive-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-14969"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-27T21:05:43Z",
"nvd_published_at": "2026-01-26T20:16:08Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Hibernate Reactive. When an HTTP endpoint is exposed to perform database operations, a remote client can prematurely close the HTTP connection. This action may lead to leaking connections from the database connection pool, potentially causing a Denial of Service (DoS) by exhausting available database connections.",
"id": "GHSA-frpp-8pwq-hjrx",
"modified": "2026-02-05T15:31:09Z",
"published": "2026-01-26T21:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14969"
},
{
"type": "WEB",
"url": "https://github.com/hibernate/hibernate-reactive/commit/cd7f104e10de918004707ca0e26e3840976f780a"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:1965"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-14969"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2423822"
},
{
"type": "PACKAGE",
"url": "https://github.com/hibernate/hibernate-reactive"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Hibernate Reactive Vulnerable to DoS via Connection Pool Exhaustion"
}
GHSA-FVP5-3F6R-64FV
Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2022-05-13 01:47
VLAI
Details
In ImageMagick 7.0.5-5, the ReadPICTImage function in pict.c allows attackers to cause a denial of service (memory leak) via a crafted file.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2017-8353"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-30T17:59:00Z",
"severity": "MODERATE"
},
"details": "In ImageMagick 7.0.5-5, the ReadPICTImage function in pict.c allows attackers to cause a denial of service (memory leak) via a crafted file.",
"id": "GHSA-fvp5-3f6r-64fv",
"modified": "2022-05-13T01:47:30Z",
"published": "2022-05-13T01:47:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8353"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/454"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3863"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/98377"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/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: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.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
Severity
5.9 (Medium)
{
"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-FW79-73XX-C878
Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2022-05-13 01:47
VLAI
Details
In ImageMagick 7.0.5-5, the ReadEXRImage function in exr.c allows attackers to cause a denial of service (memory leak) via a crafted file.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2017-8347"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-30T17:59:00Z",
"severity": "MODERATE"
},
"details": "In ImageMagick 7.0.5-5, the ReadEXRImage function in exr.c allows attackers to cause a denial of service (memory leak) via a crafted file.",
"id": "GHSA-fw79-73xx-c878",
"modified": "2022-05-13T01:47:30Z",
"published": "2022-05-13T01:47:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8347"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/441"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2017/dsa-3863"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/98363"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FW8F-2256-8C8C
Vulnerability from github – Published: 2022-05-13 01:49 – Updated: 2022-05-13 01:49
VLAI
Details
In ImageMagick 7.0.7-20 Q16 x86_64, a memory leak vulnerability was found in the function GetImagePixelCache in MagickCore/cache.c, which allows attackers to cause a denial of service via a crafted CALS image file.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2018-11655"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-06-01T15:29:00Z",
"severity": "MODERATE"
},
"details": "In ImageMagick 7.0.7-20 Q16 x86_64, a memory leak vulnerability was found in the function GetImagePixelCache in MagickCore/cache.c, which allows attackers to cause a denial of service via a crafted CALS image file.",
"id": "GHSA-fw8f-2256-8c8c",
"modified": "2022-05-13T01:49:20Z",
"published": "2022-05-13T01:49:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11655"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/930"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/3681-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G3VC-C43J-GJJV
Vulnerability from github – Published: 2022-04-29 01:25 – Updated: 2025-04-03 03:53
VLAI
Details
A memory leak in Apache 2.0 through 2.0.44 allows remote attackers to cause a denial of service (memory consumption) via large chunks of linefeed characters, which causes Apache to allocate 80 bytes for each linefeed.
{
"affected": [],
"aliases": [
"CVE-2003-0132"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2003-04-11T04:00:00Z",
"severity": "MODERATE"
},
"details": "A memory leak in Apache 2.0 through 2.0.44 allows remote attackers to cause a denial of service (memory consumption) via large chunks of linefeed characters, which causes Apache to allocate 80 bytes for each linefeed.",
"id": "GHSA-g3vc-c43j-gjjv",
"modified": "2025-04-03T03:53:31Z",
"published": "2022-04-29T01:25:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2003-0132"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A156"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf6449464fd8b7437704c55f88361b66f12d5b5f90bcce66af4be4ba9%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re028d61fe612b0908595d658b9b39e74bca56f2a1ed3c5f06b5ab571@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re028d61fe612b0908595d658b9b39e74bca56f2a1ed3c5f06b5ab571%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd00b45b93fda4a5bd013b28587207d0e00f99f6e3308dbb6025f3b01@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd00b45b93fda4a5bd013b28587207d0e00f99f6e3308dbb6025f3b01%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9f93cf6dde308d42a9c807784e8102600d0397f5f834890708bf6920%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9e8622254184645bc963a1d47c5d47f6d5a36d6f080d8d2c43b2b142@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9e8622254184645bc963a1d47c5d47f6d5a36d6f080d8d2c43b2b142%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8828e649175df56f1f9e3919938ac7826128525426e2748f0ab62feb@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r8828e649175df56f1f9e3919938ac7826128525426e2748f0ab62feb%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7035b7c9091c4b665a3b7205364775410646f12125d48e74e395f2ce@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7035b7c9091c4b665a3b7205364775410646f12125d48e74e395f2ce%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5001ecf3d6b2bdd0b732e527654248abb264f08390045d30709a92f6@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5001ecf3d6b2bdd0b732e527654248abb264f08390045d30709a92f6%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2cb985de917e7da0848c440535f65a247754db8b2154a10089e4247b@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2cb985de917e7da0848c440535f65a247754db8b2154a10089e4247b%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0276683d8e1e07153fc8642618830ac0ade85b9ae0dc7b07f63bb8fc@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r0276683d8e1e07153fc8642618830ac0ade85b9ae0dc7b07f63bb8fc%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/5df9bfb86a3b054bb985a45ff9250b0332c9ecc181eec232489e7f79@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/5df9bfb86a3b054bb985a45ff9250b0332c9ecc181eec232489e7f79%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/54a42d4b01968df1117cea77fc53d6beb931c0e05936ad02af93e9ac@%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/54a42d4b01968df1117cea77fc53d6beb931c0e05936ad02af93e9ac%40%3Ccvs.httpd.apache.org%3E"
},
{
"type": "WEB",
"url": "http://lists.apple.com/mhonarc/security-announce/msg00028.html"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=104931360606484\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=104982175321731\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=104994239010517\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=104994309010974\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=105001663120995\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=105013378320711\u0026w=2"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/34920"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/8499"
},
{
"type": "WEB",
"url": "http://support.ca.com/irj/portal/anonymous/phpsupcontent?contentID=205147"
},
{
"type": "WEB",
"url": "http://www.idefense.com/advisory/04.08.03.txt"
},
{
"type": "WEB",
"url": "http://www.kb.cert.org/vuls/id/206537"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2003-139.html"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/1233"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-G43G-F8QW-G5RC
Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2022-05-13 01:43
VLAI
Details
In ImageMagick 7.0.7-1 Q16, a memory leak vulnerability was found in the function ReadMPCImage in coders/mpc.c, which allows attackers to cause a denial of service via a crafted file.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2017-14324"
],
"database_specific": {
"cwe_ids": [
"CWE-772"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-09-12T08:29:00Z",
"severity": "MODERATE"
},
"details": "In ImageMagick 7.0.7-1 Q16, a memory leak vulnerability was found in the function ReadMPCImage in coders/mpc.c, which allows attackers to cause a denial of service via a crafted file.",
"id": "GHSA-g43g-f8qw-g5rc",
"modified": "2022-05-13T01:43:22Z",
"published": "2022-05-13T01:43:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14324"
},
{
"type": "WEB",
"url": "https://github.com/ImageMagick/ImageMagick/issues/739"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100863"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-3
Requirements
Strategy: Language Selection
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
Mitigation
Implementation
It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.
Mitigation MIT-47
Operation
Architecture and Design
Strategy: Resource Limitation
- Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.
- When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.
- Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
CAPEC-469: HTTP DoS
An attacker performs flooding at the HTTP level to bring down only a particular web application rather than anything listening on a TCP/IP connection. This denial of service attack requires substantially fewer packets to be sent which makes DoS harder to detect. This is an equivalent of SYN flood in HTTP. The idea is to keep the HTTP session alive indefinitely and then repeat that hundreds of times. This attack targets resource depletion weaknesses in web server software. The web server will wait to attacker's responses on the initiated HTTP sessions while the connection threads are being exhausted.