1.8.2: intermittent HTTP response corruption on keep-alive connections (regression from the CVE-2026-87776 fix)
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 8/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- express, javascript, nodejs
- Lĩnh vực
- backend, networking
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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 upmid-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
httpwithkeepAlive: trueagents (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.
- Ngôn ngữ chính
- JavaScript
- Star
- 2.8k
- Fork
- 261
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của expressjs/compression
-
Compression middleware changes behavior of undefined statusText in writeHeadCó thể đã có người làm @dyk1454683243-sudo đã nhận 32 ngày trước. Đang mởbug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 62/100
expressjs/compression#254 · 2 bình luận ·
-
Compression v2Có thể làm lại được @UlisesGascon đã nhận 525 ngày trước và không có pull request nào đang mở. Đang mở
expressjs/compression#234 · 1 reaction · 2 người được giao ·
-
awaiting more info bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
expressjs/compression#220 · 11 bình luận · 2 reaction ·
-
Support zstdCó thể đã có người làm @polys đã nhận 436 ngày trước. Đang mởenhancement future
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
expressjs/compression#217 · 4 bình luận · 12 reaction ·
-
Express returns a non-compliant HTTP/206 response when gzip is enabledCó thể đã có người làm @vibhor-aggr đã nhận 133 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
expressjs/compression#185 · 9 bình luận · 1 reaction ·
Tất cả issue của expressjs/compression
Issue tương tự
-
ew
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Maintainer thường phản hồi trong vòng 1 ngày
-
priority: medium status: needs-decision work-class: scoped
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
melodic-software/claude-code-plugins#9339 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug-report bug-report-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Codeinwp/templates-patterns-collection#539 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
建议增加URL参数构建的工具Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
-
[Bug] dsh 0.2.1 返回 session/not-found 时 sessionExists 不重建会话,消息恒失败并被误报为 INTERNAL_UNKNOWNCó thể đã có người làm @ANIIAN91 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
xmanrui/dsh-im#444 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày