CVE-2026-55078: Coder ZIP Bomb Denial-of-Service Vulnerability – Patch Guidance

Technical summary

The `/api/v2/files` POST endpoint processes ZIP file uploads via the `CreateTarFromZip` function, which converts ZIP archives to tar format during decompression. The implementation enforces a per-entry size ceiling but allocates the entire decompressed output to an unbounded in-memory buffer, creating a zip-bomb vulnerability. An authenticated attacker can upload a highly compressed ZIP with carefully constructed entries that collectively exceed available heap memory, triggering out-of-memory conditions. The fix implements a two-stage defense: preflight metadata validation that sums projected entry sizes before decompression begins, and a streaming writer that enforces the aggregate limit during the actual decompression process, preventing memory exhaustion.

Business impact

Exploitation leads to service unavailability affecting all users reliant on the affected Coder deployment. For organizations using Coder as a critical development infrastructure component, an attacker with any valid user account can trigger repeated outages, disrupting developer productivity and CI/CD pipelines. Recovery requires manual service restart. The threat is elevated in multi-tenant environments where a malicious or compromised standard user account can impact other teams sharing the same Coder instance.

Affected systems

Coder versions 2.17.0 through 2.34.1 are vulnerable. Affected version ranges include 2.17.x, 2.18.x through 2.28.x, 2.29.0 through 2.29.6, 2.30.x through 2.31.x, 2.32.0 through 2.32.6, 2.33.0 through 2.33.7, and 2.34.0 through 2.34.1. Patched versions are 2.29.7, 2.32.7, 2.33.8, and 2.34.2. Verify your current version via `coder version` or your deployment configuration.

Exploitability

Exploitation requires two preconditions: the attacker must possess valid authentication credentials with file-upload permissions, and the Coder instance must accept the malicious ZIP upload without prior request-body size restrictions. The attack itself is trivial—constructing a zip bomb is well-understood—and no special tools or knowledge are required beyond the ability to craft a crafted ZIP. In internal or trusted environments where file-upload access is restricted to known developers, risk is lower. In organizations with broad user bases or federated authentication, the risk is substantially higher.

Remediation

Upgrade to patched versions immediately: 2.29.7 (for the 2.29 line), 2.32.7 (for the 2.32 line), 2.33.8 (for the 2.33 line), or 2.34.2 (for the 2.34 line and future releases). If an immediate upgrade is not feasible, implement compensating controls: (1) restrict file-upload API access via role-based permissions to only trusted users, or (2) deploy a reverse proxy (nginx, HAProxy, etc.) in front of `coderd` configured to reject requests with bodies exceeding a reasonable size threshold (e.g., 100 MB), ensuring the limit accounts for legitimate use cases in your environment.

Patch guidance

Apply the vendor-provided patch for your current Coder version line. If you are running an older version (e.g., 2.30.x or 2.31.x) for which no patch version is explicitly listed, upgrade to the next available patched version in a later release line after testing in a non-production environment. Verify the upgrade by confirming the new version number and reviewing Coder's changelog for any breaking changes or migration steps. Restart the `coderd` service cleanly to ensure all components are running the patched code.

Detection guidance

Monitor for POST requests to `/api/v2/files` with unusually large request-body sizes, especially from authenticated accounts that rarely upload files. Track memory consumption and out-of-memory errors in `coderd` logs correlating with file-upload activity. If you deploy a reverse proxy with request logging, capture and analyze the size distribution of uploads; a sudden spike or anomalous compressed-to-decompressed ratios may indicate attack attempts. Consider enabling detailed audit logging in Coder to track which accounts initiate file uploads and cross-reference with security events.

Why prioritize this

Although the CVSS 3.1 score is 6.5 (MEDIUM), prioritization depends on your deployment model. This issue warrants high-priority patching if: (1) your Coder instance is shared across a large user population, (2) users include contractors, third-party developers, or federated identities with minimal vetting, or (3) the development infrastructure it supports is critical to business operations. In smaller teams with strict access controls and lower criticality, it can be addressed in the next maintenance window. The absence of CVSS integrity or confidentiality impact means data is not at risk, but service availability is fully threatened.

Risk score, explained

CVSS 3.1 score of 6.5 reflects a MEDIUM severity: authentication is required (PR:L), no user interaction is needed (UI:N), the attack is network-accessible (AV:N) and has low complexity (AC:L), impact is limited to availability (A:H with C:N, I:N), and scope is unchanged (S:U). The score appropriately reflects that this is a denial-of-service flaw with a low barrier to entry for authenticated users but no data exfiltration or system compromise. Contextually, the true risk in your environment may be higher if file-upload permissions are widely distributed or if Coder availability is business-critical.

Frequently asked questions