Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

1.8.2: intermittent HTTP response corruption on keep-alive connections (regression from the CVE-2026-87776 fix)

オープン
  • 何か問題がありますか？
#296 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

@pintu544 がすでに取り組んでいます。

2026年10月16日 から。

  • #297 @pintu544 による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
8/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
express, javascript, nodejs
領域
backend, networking

調査の方向性

The suspected cause is the close listener that 1.8.2 adds to destroy the zlib stream and fall back to the raw response, so start with the diff between 1.8.1 and 1.8.2 in the compression source. There is no minimal repro yet, so the first useful step is building one that combines streamed bodies, client aborts and a keep-alive agent. Done means that repro fails on 1.8.2 and passes on 1.8.1, with the race fixed and the framing verified.

索引モデルが issue の本文から書いたものです。

説明

Summary

After upgrading compression 1.8.1 → 1.8.2 (the fix for the client-abort zlib memory leak, CVE-2026-87776), our Express 4 API's integration test suite became reliably flaky: roughly 1 request per ~600 intermittently gets a corrupted or misframed response on keep-alive connections. Pinning back to 1.8.1 — with every other dependency unchanged — makes the suite stable again.

Symptoms observed (varies per occurrence)
  • Error: Parse Error: Expected HTTP/, RTSP/ or ICE/ raised by the Node HTTP client — the bytes on the socket do not start with a status line, i.e. the previous response's framing didn't end where its headers said it would;
  • responses seemingly answered to the wrong request on the socket (a route that must 401 returns 404 or 400, a GET that must 200 returns 404);
  • empty bodies ({} after JSON parsing) on responses that are otherwise 200;
  • socket hang up mid-body.

The failing requests are ordinary JSON endpoints; the suite also exercises streamed responses (image resizing piped through sharp) and requests aborted client-side, which run before/concurrently on the same keep-alive agent.

Evidence (A/B, single variable)

Same app, same Node, same test suite, ~600 HTTP requests per run:

compression runs failing runs
1.8.1 6+ 0
1.8.2 3 3 (1 corrupted response each)

Every other package was held constant during the comparison (we bisected it out of a larger dependency upgrade; morgan and body-parser bumps were cleared separately).

Suspected mechanism

1.8.2 adds a close listener that destroys the zlib stream when the response closes, and falls back to the raw response if the stream is already gone. If that teardown races a response that is still being written on a kept-alive socket (or runs on close of a completed response, since close also fires after normal end), part of the compressed body can be dropped or written raw, so the bytes on the wire no longer match the declared framing — and every subsequent response on that socket is misparsed.

Environment
  • compression 1.8.2 / express 4.22.1 / Node v24.19.0 (macOS, also reproduced with express 4.21.2's stack)
  • Client: node core http with keepAlive: true agents (mocha + chai-http/superagent)

I don't have a minimal standalone repro yet — a naive script (keep-alive agent + aborted compressed responses) didn't trigger it, so the race window seems to need the larger app's timing (streamed bodies + aborts + concurrent sockets). Happy to run instrumented builds or provide more detail from our suite if useful.

主要言語
JavaScript
スター
2.8k
フォーク
261
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

expressjs/compression のほかの issue

expressjs/compression の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。