Uh oh!
There was an error while loading. Please reload this page.
fix(logstash): [OBE-10712] bound zlib frame inflation, reject nested compressed frames - #142
Merged
ajayshekar-s1 merged 2 commits intoAug 12, 2026
Conversation
…d frames The Beats `C` frame was inflated with read_to_end and no upper bound, so a zip bomb from any peer could exhaust the heap. A `C` frame nested inside a `C` frame also recursed with no depth limit. max_decompressed_bytes defaults to 256 MiB. One `C` frame carries an entire window rather than a single event -- Filebeat's bulk_max_size defaults to 2048 and go-lumber's maxWindowSize allows 10000 -- so legitimate inflated batches reach tens of MiB and the bound must sit well above that. It applies per frame, so peak memory is this value times the concurrent connection count; set a finite connection_limit if that product matters. The reader is capped at max + 1 rather than max so that "exactly at the limit" stays distinguishable from "truncated at the limit"; capping at max alone rejected a payload of exactly max_decompressed_bytes. Nested frames are rejected with can_continue() == false, since a peer sending them is not recoverable. The two decompression-bomb tests were behind the logstash-integration-tests feature and never ran in normal CI; they are now unit tests, with added boundary, buffer-drain and stream-continuation coverage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ajayshekar-s1
approved these changes
Aug 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
max_decompressed_bytes(default 256 MiB) caps how far a BeatsCframe may inflate. Previouslyread_to_endwith no bound, so a zip bomb from any peer could exhaust the heap.Cframes are rejected outright; previously they recursed with no depth limit.Why 256 MiB
One
Cframe carries an entire window, not a single event — Filebeat'sbulk_max_sizedefaults to 2048 and go-lumber'smaxWindowSizeallows 10000 — so legitimate inflated batches reach tens of MiB and the bound must sit well above that.It applies per frame, so peak memory is this value × the concurrent connection count. Set a finite
connection_limitif that product matters for your deployment.The reader is capped at
max + 1rather thanmaxso "exactly at the limit" stays distinguishable from "truncated at the limit" — capping atmaxalone rejected a payload of exactlymax_decompressed_bytes.Testing
The two decompression-bomb tests were behind the
logstash-integration-testsfeature and never ran in normal CI. They are now unit tests, plus added boundary, buffer-drain and stream-continuation coverage. 17 passing.Jira: OBE-10712