🤖 fix: Daytona client buffers whole API responses without a size limit

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
79/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
node.js, typescript
Área
backend, security, testing

Línea de trabajo

Start in src/node/services/daytona/daytonaClient.ts, around the fetchWithTimeout path near line 379, and trace how response bodies are read and transport errors are reported. Add a hard byte cap to streamed responses, abort when it is exceeded, and report the endpoint in the error. Add the described unit test with a fake fetch that streams beyond the cap; done when that test confirms the oversized response is rejected.

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

Descripción

Follow-up from the Codex security review of #7100 (thread: https://github.com/coder/xum/pull/7100#discussion_r4353457236).

Problem

DaytonaClient (src/node/services/daytona/daytonaClient.ts, the fetchWithTimeout path around line 379) reads every Daytona API response with response.text() before it validates it, with no byte limit. The per-request timeout (15 s) bounds time, not size. The reconciler lists sandboxes every 60 s, so a malicious or compromised Daytona control plane (or a proxy in front of it) could return one very large /sandbox response and exhaust the memory of the desktop app or xum server.

Precondition: Daytona credentials are configured and the control plane or its HTTPS proxy is hostile.

Proposed fix

Read the body as a stream with a hard cap (a few MiB is far above any real list or config response), abort the request when the cap is exceeded, and report it as a transport error that names the endpoint. Add a unit test with a fake fetch that streams more than the cap.

Why it is deferred

#7100 runs its review loop under a P0/P1-only rule; P2 findings get a tracked follow-up.

Lenguaje dominante
TypeScript
Estrellas
2.1k
Forks
139
Merge medio
3 h 34 min
PR fusionados (30 d)
953

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

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 coder/xum

Todos los issues de coder/xum

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.