🤖 fix: Daytona client buffers whole API responses without a size limit
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 79/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- node.js, typescript
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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.
- 主要言語
- TypeScript
- スター
- 2.1k
- フォーク
- 139
- 平均マージ
- 3時間 45分
- マージ済み PR（30日）
- 953
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
coder/xum のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
components-web-app/docs#307 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
localstack/localstack-mcp-server#112 ·
メンテナーはふだん 1 日以内に返信
-
area:frontend kind:bug priority:p1 ready
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
メンテナーはふだん 1 日以内に返信
-
bug ready-for-agent
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
PhyberApex/kuroshiro#1687 ·
メンテナーはふだん 1 日以内に返信
-
Performance (Web Vitals) collector: LCP/FCP from background tabs are not discarded, inflating p75オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
umami-software/umami#4720 ·
メンテナーはふだん 3 日以内に返信