Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#296 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@pintu544 ya está trabajando en esto.

Desde el 16/10/2026.

  • #297 de @pintu544 — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
8/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
express, javascript, nodejs
Área
backend, networking

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
JavaScript
Estrellas
2.8k
Forks
260
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de expressjs/compression

Todos los issues de expressjs/compression

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.