CVE-2026-55079: Coder Provisioner Daemon Memory Exhaustion Vulnerability (DoS)

Technical summary

The vulnerability resides in `NewDataBuilder` within `provisionersdk/proto/dataupload.go`. When processing a `DataUpload` message, the code reads a `FileSize` field supplied by the client and immediately allocates a byte slice of that size without validation. Although the DRPC protocol layer enforces a 4 MiB wire-message limit, this constraint only applies to the message itself, not to the `FileSize` integer value. An attacker can specify a `FileSize` of, for example, 10 GB, causing the daemon to allocate that much memory in a single operation. The fix introduces a `MaxFileSize` constant of 100 MiB and validates the client-supplied value against this bound before memory allocation, preventing unbounded allocation requests.

Business impact

This denial-of-service vulnerability can crash provisioner daemons, disrupting the ability to provision or manage remote development environments. Organizations relying on Coder for developer infrastructure may experience service unavailability if attackers or compromised accounts trigger memory exhaustion. The impact is limited by the requirement for authentication (high privilege level per CVSS), but in environments where provisioner service account credentials are shared or exposed, the risk escalates. Repeated exploitation could necessitate manual service recovery and delay development workflows.

Affected systems

Coder versions 2.24.0 through 2.34.1 are affected. Patched versions are 2.29.7 (for the 2.29.x branch), 2.32.7 (for the 2.32.x branch), 2.33.8 (for the 2.33.x branch), and 2.34.2 (for the 2.34.x branch). Organizations should verify their running version via `coder version` or deployment logs. Users on 2.24.x through 2.28.x may not have a patched release available in their branch; such deployments should either upgrade to a newer branch or implement access controls.

Exploitability

Exploitation requires network access to the provisioner daemon endpoint and authenticated credentials with provisioner daemon service account privileges. The CVSS score of 4.9 reflects this constraint: no user interaction is required, network access is straightforward, and the attack is repeatable, but the attacker must possess valid credentials. In poorly segmented environments or where service account credentials are shared across teams, the barrier to exploitation is lower. Notably, this is not a critical remote code execution or privilege escalation; it is a targeted denial-of-service affecting infrastructure availability.

Remediation

Apply the patched version corresponding to your release branch immediately: 2.34.2 for the latest line, 2.33.8, 2.32.7, or 2.29.7 for earlier branches. If immediate patching is not feasible, restrict network and authentication access to the provisioner daemon serve endpoint to only trusted provisioner daemon service accounts. Implement network policies (e.g., firewall rules, Kubernetes NetworkPolicies) to limit inbound connections to the daemon endpoint, and audit service account credentials to ensure they are not overshared or exposed in logs or repositories.

Patch guidance

Verify your current Coder version before patching. Patched versions are 2.29.7, 2.32.7, 2.33.8, and 2.34.2; ensure your upgrade path lands on one of these releases or later. Review release notes for each branch to confirm no breaking changes affect your deployment. Test the upgrade in a non-production environment first, particularly if your Coder instance manages critical development infrastructure. After upgrading, confirm the daemon process starts cleanly and connectivity to existing workspaces is unaffected. No database migrations or configuration changes are required for this fix.

Detection guidance

Monitor provisioner daemon logs for `NewDataBuilder` allocation errors or out-of-memory (OOM) kills. Look for HTTP 500 or connection reset errors when clients attempt to upload files, which may indicate memory exhaustion. If available, enable Coder's audit logging to track `DataUpload` message origins and the `FileSize` values claimed in failed requests. Track daemon restart frequencies and memory pressure metrics; repeated restarts or sustained high memory usage followed by crashes may indicate exploitation attempts. Network-based detection is difficult without deep packet inspection, so host-level monitoring and log analysis are essential.

Why prioritize this

Although the CVSS score is moderate (4.9), this vulnerability should be prioritized because it directly impacts infrastructure availability for development teams and requires only authentication (not complex exploitation steps). Organizations with shared or loosely-managed provisioner service account credentials face elevated risk. The presence of multiple patched versions suggests Coder's maintenance across multiple branches, making remediation straightforward for most deployments. Prioritize instances with exposed or shared service account credentials and those in multi-tenant or high-volatility environments where attacker motivation is higher.

Risk score, explained

The CVSS 3.1 score of 4.9 (MEDIUM severity) reflects a network-accessible vulnerability with low attack complexity but requiring high privileges (authenticated provisioner service account access). The impact is availability only (denial of service via memory exhaustion), with no confidentiality or integrity risk. The score appropriately captures that this is a bounded DoS affecting a specific service component, not a system-wide compromise. Organizations should not underestimate risk based on the moderate score alone; situational factors such as credential exposure or shared accounts can elevate practical risk substantially.

Frequently asked questions