Kafka の解凍爆弾 DoS は更新だけでは防げない：max.decompressed.message.bytes を設定する
Apache Kafka の CVE-2026-114349 は、約 90 バイトの圧縮レコードで最大約 2GiB のメモリー確保を起こせる DoS。4.2.2 / 4.3.2 / 4.4.0 への更新に加えて、展開後サイズの上限 max.decompressed.message.bytes をブローカーかトピック単位で設定しないと防げない。
どこが壊れるか
- 圧縮レコード内の申告サイズを検証せずにメモリーを確保する。悪用には、対象トピックへ書き込める認証済みの権限が必要。
- レコードを読むコンシューマーが DoS になる。圧縮方式を変えて再処理するブローカーも影響を受ける。
- ログクリーナーが細工レコードを読むと異常終了し、ログコンパクションが止まる。既定の 1 スレッド構成ではブローカー全体で止まり、レコードを除くまで再起動しても続く。
- 同時に公表された CVE-2026-111551 は
kafka-clientsとkafka-streamsの逆シリアル化の問題で、コンシューマーや Streams のスレッドが落ちる（ブローカーは影響外）。
対応手順
- 影響版を確認する。CVE-2026-114349 は 0.11.0.0〜4.1.2、4.2.0〜4.2.1、4.3.0〜4.3.1。CVE-2026-111551 は 0.10.0.0〜4.1.2 と同じく 4.2.x / 4.3.x の未修正版。
- ブローカーとクライアント（
kafka-clients、kafka-streamsを含むアプリ）を 4.2.2、4.3.2、4.4.0 以降に更新する。 - 更新後に
max.decompressed.message.bytesを設定する。既定値は事実上無制限で、従来のレコードサイズ上限（max.message.bytesなど）やクォータでは緩和できない。上限値は、実際に流れる最大メッセージの展開後サイズを測ってから決める。 - 設定前に書き込まれた細工レコードは、削除するか保存期間が過ぎるまで読み手側に危険が残る。異常終了したコンシューマーやログクリーナーのログから該当オフセットを特定する。
- トピックへの書き込み権限（ACL）を必要なプリンシパルに絞る。悪用の前提が「書き込めること」なので、ここが一番効く。
一般化できる教訓
- 圧縮データを扱う処理は「申告サイズを信じない」「展開後サイズに上限を設ける」が基本。更新で入った上限が既定で無効のこともあるので、修正版のリリースノートで新しい設定項目を確認する。