Coder: Zip upload decompression lacks aggregate size limit, enabling denial of service
Summary
POST /api/v2/files converts zip uploads to tar in memory via CreateTarFromZip, which enforced a per-entry size limit but no aggregate limit on total decompressed output, writing to an unbounded in-memory buffer.
> Note: Exploitation requires authenticated file-upload access and the impact is limited to availability (denial of service).
Impact
An authenticated user could upload a zip within the 100 MiB upload limit but containing many highly compressible entries whose decompressed size exhausted memory, crashing coderd before any RBAC check. Repeated requests could keep the service unavailable. This is a denial of service; it does not allow data disclosure or code execution.
Patches
The fix adds a metadata preflight check that sums projected entry sizes and a streaming writer that enforces the aggregate limit during decompression.
The fix was backported to all supported release lines:
| Release line | Patched version | |---|---| | 2.34 | v2.34.2 | | 2.33 | v2.33.8 | | 2.32 | v2.32.7 | | 2.29 (ESR) | v2.29.17 |
Workarounds
Restrict file-upload permissions to trusted users or place a reverse proxy with request-body size limits in front of coderd.
Resources
- Fix: #25877
Credits
Coder would like to thank Anthropic's Security Team (ANT-2026-22438) for independently disclosing this issue!