Skip to content

GHSA-fqw6-gf59-qr4w CVE-2026-46680 GO-2026-5378

containerd user ID handling bypass allows runAsNonRoot evasion

High Go
Severity
0.0 / 10
High · CVSS 4.0
Exploit chance (EPSS)
0.16%
Chance of exploitation in the next 30 days. Higher than 5.46% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-269 Improper Privilege Management
CWE-843 Access of Resource Using Incompatible Type ('Type Confusion')
Fix
Available
2 packages have a fixed version

Description

Impact

A bug was found in containerd where containers launched with a numeric User directive that cannot be parsed as a 32-bit integer are incorrectly treated as a username. If a crafted image provides an /etc/passwd file mapping this large numeric string to root, the container ultimately runs as root (UID 0). This allows the Kubernetes runAsNonRoot restriction to be bypassed, causing unexpected behavior for environments that require containers to run as a non-root user.

Patches

This bug has been fixed in the following containerd versions:

  • 2.3.1
  • 2.2.4
  • 2.0.9
  • 1.7.32

Note: The containerd 2.1 release has reached its end of life and a fixed version is not provided.

Users should update to these versions to resolve the issue.

Workarounds

Ensure that only trusted images are used and that only trusted users have permissions to import images. Alternatively, enforcing a specific numeric runAsUser in the Kubernetes Pod securityContext overrides the USER directive in the image and prevents the bypass. Newer versions of Kubernetes, starting with 1.34, also appear to enforce runAsNonRoot properly regardless of this bug.

Credits

The containerd project would like to thank Lei Wang (@ssst0n3) for responsibly disclosing this issue in accordance with the containerd security policy.

Resources

For more information

If there are any questions or comments about this advisory:

To report a security issue in containerd:

Affected versions

Go

PackageVulnerableFixed in
github.com/containerd/containerd
>= 1.7.27, < 1.7.32
1.7.32
github.com/containerd/containerd/v2
>= 2.0.4, < 2.0.9
2.0.9
github.com/containerd/containerd/v2
>= 2.1.0-beta.0, < 2.2.4
2.2.4
github.com/containerd/containerd/v2
>= 2.3.0-beta.0, < 2.3.1
2.3.1
github.com/containerd/containerd/v2
>= 2.0.4, < 2.0.9
>= 2.1.0-beta.0, < 2.2.4
>= 2.3.0-beta.0, < 2.3.1
2.0.9
2.2.4
2.3.1

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/containerd/containerd Go → 1.7.32

go
go get github.com/containerd/containerd@v1.7.32 && go mod tidy

github.com/containerd/containerd/v2 Go → 2.0.9

go
go get github.com/containerd/containerd/v2@v2.0.9 && go mod tidy

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Attack vector
Local
Attack complexity
Low
Attack requirements
Present
Privileges required
None
User interaction
Passive
Confidentiality (vulnerable system)
High
Integrity (vulnerable system)
High
Availability (vulnerable system)
High
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

CVSS 3.1 7.8

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Attack vector
Local
Attack complexity
Low
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Weakness

CWE-269: Improper Privilege Management

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

How to prevent it
  • Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  • Architecture and Design: Follow the principle of least privilege when assigning access rights to entities in a software system.
  • Architecture and Design: Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')

The product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-rp3h-jf77-q9p4
containerd: Unpack DoS via repeated opaque whiteouts
Medium Also affects github.com/containerd/containerd
GO-2026-6791
containerd CRI plugin: Checkpoint restore bypasses destination security context
High Also affects github.com/containerd/containerd
GHSA-pg57-6jwg-q645
Containerd has image-pull DoS via crafted OCI index graph amplification
Medium Also affects github.com/containerd/containerd
GHSA-7jxh-36q5-gcqv
containerd: CRI ExecSync Goroutine Leak Leads to Node-Level Denial of Service
Medium Also affects github.com/containerd/containerd
GO-2026-5064
containerd CRI checkpoint restore CDI annotation smuggling
Critical Also affects github.com/containerd/containerd
GO-2026-5622
Arbitrary host CRI log file read via symlink following in CRI checkpoint restore
Medium Also affects github.com/containerd/containerd
GHSA-xhf5-7wjv-pqxp
containerd CRI — image-config `LABEL` flows to restart-monitor `binary://` logger: host-root command execution from an image pull
High Also affects github.com/containerd/containerd
GO-2026-5338
containerd: CRI checkpoint import allows local image tag poisoning
Critical Also affects github.com/containerd/containerd
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor