Source Decompression Bomb Caps.Security

Sources that can decompress potentially untrusted input now cap compressed and decompressed payload sizes, preventing a small compressed payload (e.g. a gzip/zlib/zstd bomb) from allocating unbounded memory and OOM-killing the Vector process. The decompressed-output cap defaults to 100MiB and can be configured via --max-decompressed-size-bytes or VECTOR_MAX_DECOMPRESSED_SIZE_BYTES. Affected sources: http_server, heroku_logs, prometheus_pushgateway, prometheus_remote_write, datadog_agent, splunk_hec, aws_kinesis_firehose, fluent, logstash, vector, and opentelemetry (both its HTTP and gRPC modes). The datadog_agent, splunk_hec, and aws_kinesis_firehose sources additionally now cap the size of the raw (compressed) request body they buffer in memory before decompression, matching http_server and opentelemetry; oversized requests are rejected with 413 Payload Too Large instead of being read into memory unbounded. Relatedly, zstd decoders across all affected sources now also bound the decoder's internal window allocation, derived from the decompressed-size cap (and for HTTP-based sources, additionally clamped to the 8 MB ceiling suggested by RFC 9659), so a crafted frame can no longer declare a large Window_Size and drive a big allocation before the cap has a chance to trip.

authors: thomasqueirozb