NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

containerd CRI stream server vulnerable to host memory exhaustion via terminalGHSA-2qjp-425j-52j9

MEDIUMFix: containerd/containerd@241563b

GHSA-2qjp-425j-52j9 is a medium-severity (CVSS 5.7) Uncontrolled Resource Consumption vulnerability in github.com/containerd/containerd. A fix is available for github.com/containerd/containerd — see the affected versions and patch details below.

Also known asCVE-2022-23471GO-2022-1147
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-2qjp-425j-52j9.

EPSS Exploitation Probability

via FIRST.org ↗
1.1%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs66th percentile — riskier than 66% of all scored CVEsHighest risk
0.00%0.54%1.07%1.61%0.2%1.1%May 26Aug 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

2 pkgs affected
🐹github.com/containerd/containerd🐹github.com/containerd/containerd

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Impact

A bug was found in containerd's CRI implementation where a user can exhaust memory on the host. In the CRI stream server, a goroutine is launched to handle terminal resize events if a TTY is requested. If the user's process fails to launch due to, for example, a faulty command, the goroutine will be stuck waiting to send without a receiver, resulting in a memory leak. Kubernetes and crictl can both be configured to use containerd's CRI implementation and the stream server is used for handling container IO.

Patches

This bug has been fixed in containerd 1.6.12 and 1.5.16. Users should update to these versions to resolve the issue.

Workarounds

Ensure that only trusted images and commands are used and that only trusted users have permissions to execute commands in running containers.

For more information

If you have any questions or comments about this advisory:

To report a security issue in containerd:

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/containerd/containerdall versions1.5.16go get github.com/containerd/containerd@v1.5.16
🐹Gogithub.com/containerd/containerd≥ 1.6.0&&< 1.6.121.6.12go get github.com/containerd/containerd@v1.6.12

Affected Products

1 product · 2 configurations
Application
containerdlinuxfoundation
≥ 1.6.0 && < 1.6.12
range

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/containerd/containerd, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/containerd/containerd to 1.5.16 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2qjp-425j-52j9 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

### Impact A bug was found in containerd's CRI implementation where a user can exhaust memory on the host. In the CRI stream server, a goroutine is launched to handle terminal resize events if a TTY is requested. If the user's process fails to launch due to, for example, a faulty command, the goroutine will be stuck waiting to send without a receiver, resulting in a memory leak. Kubernetes and crictl can both be configured to use containerd's CRI implementation and the stream server is used for handling container IO. ### Patches This bug has been fixed in containerd 1.6.12 and 1.5.16. User
O3 Security · Impact-Aware SCA

Is GHSA-2qjp-425j-52j9 in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works
containerd CRI stream server vulnerable to host memory…