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

CVE-2022-1708 — cri-o

HIGHFix: cri-o/cri-o@f032cf6

CVE-2022-1708 is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption vulnerability in github.com/cri-o/cri-o. 1 public exploit or proof-of-concept reference is indexed, so weaponization risk is real. A fix is available for github.com/cri-o/cri-o — see the affected versions and patch details below.

Node DOS by way of memory exhaustion through ExecSync request in CRI-O

Also known asGHSA-fcm2-6c3h-pg6jGO-2022-0480
Published
Updated
Affected
3 pkgs
Patched
3 / 3
Exploits
1 known
Exploitation data as of Nov 5, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
3.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs88th percentile — riskier than 88% of all scored CVEsHighest risk
0.00%1.34%2.67%4.01%0.5%3.2%May 26Sep 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

3 pkgs affected
🐹github.com/cri-o/cri-o🐹github.com/cri-o/cri-o🐹github.com/cri-o/cri-o

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

Description

An ExecSync request runs a command in a container and returns the output to the Kubelet. It is used for readiness and liveness probes within a pod. The way CRI-O runs ExecSync commands is through conmon. CRI-O asks conmon to start the process, and conmon writes the output to disk. CRI-O then reads the output and returns it to the Kubelet.

If the output of the command is large enough, it is possible to exhaust the memory (or disk usage) of the node. The following deployment is an example yaml file that will output around 8GB of ‘A’ characters, which would be written to disk by conmon and read by CRI-O.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment100
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        lifecycle:
          postStart:
            exec:
              command: ["/bin/sh", "-c", "seq 1 50000000`; do echo -n 'aaaaaaaaaaaaaaaa'; done"]

Impact

It is possible for the node to be exhausted of memory or disk space, depending on the node the command is being run on. What is further problematic is that the memory and disk usage aren't attributed to the container, as this file and its processing are implementation details of CRI-O. The consequence of the exhaustion is that other services on the node, e.g. other containers, will be unable to allocate memory and thus causing a denial of service.

Patches

This vulnerability will be fixed in 1.24.1, 1.23.3, 1.22.5, v1.21.8, v1.20.8, v1.19.7

Workarounds

At the time of writing, no workaround exists other than ensuring only trusted images are used.

References

https://github.com/containerd/containerd/security/advisories/GHSA-5ffw-gxpp-mxpf

For more information

If you have any questions or comments about this advisory:

Credits

Disclosed by Ada Logics in a security audit sponsored by CNCF and facilitated by OSTIF.

Affected Packages

3 total 3 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/cri-o/cri-o≥ 1.24.0&&< 1.24.11.24.1go get github.com/cri-o/cri-o@v1.24.1
🐹Gogithub.com/cri-o/cri-o≥ 1.23.0&&< 1.23.31.23.3go get github.com/cri-o/cri-o@v1.23.3
🐹Gogithub.com/cri-o/cri-oall versions1.22.5go get github.com/cri-o/cri-o@v1.22.5

Affected Products

4 products · 14 configurations
OS
fedorafedoraproject
1 version
36
Application
cri-okubernetes
≥ 1.23.0 && < 1.23.3
1 version
1.24.0
OS
enterprise linuxredhat
3 versions
7.08.09.0
Application
openshift container platformredhat
4 versions
3.114.04.94.10
Exploits & PoCs
1

Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.

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/cri-o/cri-o, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/cri-o/cri-o to 1.24.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2022-1708 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.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate

The vulnerability exists in reading of the output file from the ExecSync command, by the CRI-O in the Kubernetes,if the file were to be too large, then this would lead to resource exhaustion,the attack is purely theoretical in nature and would only lead to a denial of service,moreover the attacker would require code…

ProductFixed inAdvisory
Red Hat Enterprise Linux 8container-tools:rhel8-8070020220929222448.39077419RHSA-2022:7457
Red Hat Enterprise Linux 8container-tools:4.0-8070020220830101436.39077419RHSA-2022:7469
Red Hat Enterprise Linux 8container-tools:3.0-8070020220802115906.39077419RHSA-2022:7529
Red Hat OpenShift Container Platform 3.11cri-o-0:1.11.16-0.17.rhaos3.11.git4c0a8ad.el7RHSA-2022:4999
Red Hat OpenShift Container Platform 4.10conmon-2:2.0.29-3.rhaos4.10.el8RHSA-2022:4943
Red Hat OpenShift Container Platform 4.6conmon-2:2.0.21-3.rhaos4.6.el7RHSA-2022:4947
Red Hat OpenShift Container Platform 4.7conmon-2:2.0.29-3.rhaos4.7.el7RHSA-2022:4965
Red Hat OpenShift Container Platform 4.8conmon-2:2.0.29-3.rhaos4.8.el7RHSA-2022:4951

Frequently Asked Questions

### Description An ExecSync request runs a command in a container and returns the output to the Kubelet. It is used for readiness and liveness probes within a pod. The way CRI-O runs ExecSync commands is through conmon. CRI-O asks conmon to start the process, and conmon writes the output to disk. CRI-O then reads the output and returns it to the Kubelet. If the output of the command is large enough, it is possible to exhaust the memory (or disk usage) of the node. The following deployment is an example yaml file that will output around 8GB of ‘A’ characters, which would be written to disk by
O3 Security · Impact-Aware SCA

Is CVE-2022-1708 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2022-1708: cri-o DoS — Fixed in 1.24.1