CVE-2026-61801: Moby sys/user Package DoS Vulnerability

CVE-2026-61801 Overview

CVE-2026-61801 is a resource exhaustion vulnerability in the github.com/moby/sys/user Go package, which provides utilities for parsing Unix-style user and group database files. Versions before 0.4.1 fail to limit the amount of data read when parsing /etc/passwd- or /etc/group-style files. An attacker who can supply a specially crafted file can trigger excessive memory consumption, potentially terminating the affected process through an out-of-memory (OOM) condition. The flaw is categorized under CWE-400 (Uncontrolled Resource Consumption). The package maintainers released a patch in version 0.4.1.

Critical Impact
A local attacker able to influence user or group database file paths can cause denial of service by exhausting process memory, impacting container runtimes and orchestration tools that depend on the moby/sys/user library.

Affected Products

github.com/moby/sys/user versions prior to 0.4.1
Go applications and container tooling that import the moby/sys/user package
Downstream projects within the Moby ecosystem that parse user/group database files

Discovery Timeline

2026-10-08 - CVE CVE-2026-61801 published to NVD
2026-10-08 - Last updated in NVD database

Technical Details for CVE-2026-61801

Vulnerability Analysis

The moby/sys/user package exposes functions such as ParsePasswdFile, ParseGroupFile, and their filter variants. These functions open a file path and stream the contents line by line into Go slices representing user or group records. Prior to version 0.4.1, the package applied no upper bound on the file size or the number of entries parsed.

When the parser receives an oversized or maliciously constructed input, it continues allocating memory for each parsed entry. The Go runtime eventually triggers an OOM condition, terminating the process. In container runtimes and orchestration systems, this can disrupt workload scheduling, break identity resolution, and halt services that depend on user namespace mapping.

Root Cause

The root cause is missing input validation on the size of user and group database files. The parser used os.Open directly and read without any byte or entry cap. User database files are expected to be small, but the code trusted untrusted inputs to adhere to that convention.

Attack Vector

Exploitation requires local access with low privileges and the ability to supply a crafted file to a process that calls the vulnerable parsing functions. Common scenarios include mounting an attacker-controlled filesystem into a container, substituting /etc/passwd within an unprivileged user namespace, or passing an arbitrary path to a tool that invokes ParsePasswdFileFilter. No user interaction is required.

// Patch excerpt - user/user.go
 func ParseGroupFileFilter(path string, filter func(Group) bool) ([]Group, error) {
-	group, err := os.Open(path)
+	group, err := openUserFile(path)
 	if err != nil {
 		return nil, err
 	}

// Patch excerpt - user/user_utils.go (new file)
package user

import (
	"errors"
	"fmt"
	"io"
	"os"
)

// maxUserFileBytes caps how much data is read from any user-database file.
// User database files are expected to be relatively small. 10 MiB provides
// generous headroom while bounding memory usage.
const maxUserFileBytes = 10 << 20

// openUserFile attempts to open a user-database file with a limitedFile
// capped at maxUserFileBytes. It produces an error if the given path is
// a non-regular file.
func openUserFile(path string) (*limitedFile, error) {
	f, err := os.Open(path)
	if err != nil {
		return nil, err
	}

	info, err := f.Stat()
	if err != nil {
		_ = f.Close()
		return nil, err
	}
	if !info.Mode().IsRegular() {
		_ = f.Close()

Source: GitHub Commit 85a71bbe

Detection Methods for CVE-2026-61801

Indicators of Compromise

Unexpected OOM-killer events targeting container runtime binaries, Docker daemons, or Go processes that consume user/group files
Unusually large /etc/passwd or /etc/group files (above a few megabytes) in container images, bind mounts, or user-controlled directories
Repeated process crashes in services performing UID/GID resolution shortly after a tenant action

Detection Strategies

Inventory Go binaries using Software Composition Analysis (SCA) to find imports of github.com/moby/sys/user at versions below 0.4.1
Correlate kernel OOM log entries (dmesg, /var/log/messages) with recent file writes to user/group database paths
Monitor container filesystems for /etc/passwd and /etc/group files that exceed a reasonable size threshold

Monitoring Recommendations

Alert on process termination events for container runtimes with high resident memory immediately before exit
Track dependency manifests (go.mod, go.sum) in CI pipelines for the vulnerable package version
Enable auditd or eBPF-based file access monitoring on user/group database paths within sensitive hosts

How to Mitigate CVE-2026-61801

Immediate Actions Required

Upgrade all Go modules depending on github.com/moby/sys/user to version 0.4.1 or later and rebuild affected binaries
Identify downstream container tools and runtimes that vendor the package and apply vendor-supplied updates when available
Restrict the ability of untrusted users to supply file paths or filesystem content consumed by parsing routines

Patch Information

The fix was merged via GitHub Pull Request #221 and committed in GitHub Commit 85a71bbe. The patch introduces an openUserFile helper backed by a limitedFile wrapper that caps reads at 10 MiB (maxUserFileBytes = 10 << 20) and rejects non-regular files. Full advisory details are in GitHub Security Advisory GHSA-mjcv-p78q-w5fw.

Workarounds

Avoid parsing attacker-controlled user or group database files from untrusted sources such as tenant-supplied volumes
Validate file size and reject non-regular files before invoking the vulnerable parsing functions
Impose process-level memory limits using cgroups or systemd MemoryMax to bound the blast radius of OOM conditions

bash

# Update the vulnerable Go module to the patched version
go get github.com/moby/sys/user@v0.4.1
go mod tidy

# Verify the resolved version
go list -m github.com/moby/sys/user

# Apply a cgroup memory ceiling to a systemd service as defense-in-depth
sudo systemctl set-property my-service.service MemoryMax=512M