Releases

CRI-O v1.36.0 ships CNI health monitoring, configurable GOMAXPROCS injection, TLS hardening options, and a CVE fix — alongside a batch of race condition and cgroupv2 bug fixes.

• securityPatch CVE-2026-35469 by upgrading to v1.36.0

  The spdystream dependency carried CVE-2026-35469. If you're running v1.35.x, this is a direct reason to upgrade. After upgrading, verify the release bundle with cosign against the signed bundle artifacts — the SLSA provenance and OpenVEX report are both available for this release.

• breakingValidate CNI plugin behavior under new continuous health monitoring

  CRI-O now polls CNI plugins with STATUS after initial readiness. A plugin that was silently degraded will now actively set NetworkReady=false on the node, blocking pod scheduling. Before upgrading, confirm your CNI plugin properly implements the STATUS verb (Cilium, Calico, and Flannel do; older or custom plugins may not). Test in a non-production cluster first — this is a behavioral change that could surface latent CNI issues.

• enhancementSet TLS minimums for the CRI-O API — don't leave defaults in production

  New `tls_min_version` and `tls_cipher_suites` options under `[crio.api]` let you enforce TLS 1.2+ and restrict weak cipher suites on the streaming and metrics endpoints. The default is TLS 1.2, but you should explicitly set `tls_min_version = TLS13` in security-sensitive environments and review your cipher suite policy. Update your configuration management (Ansible, SaltStack, etc.) to codify this before the next node rollout.

v1.35.3 patches CVE-2026-35469, fixes a container stop panic and exit-code race, adds CNI health monitoring (then reverts it), and introduces GOMAXPROCS floor injection for containers.

• securityPatch CVE-2026-35469 by upgrading to v1.35.3

  The spdystream dependency had a vulnerability (CVE-2026-35469) fixed by bumping to moby/spdystream v0.5.1. If you're running v1.35.x, upgrade to v1.35.3 now. There's no workaround — the fix is only in the updated binary.

• breakingCNI health monitoring was added and then reverted in the same release

  CRI-O briefly added continuous CNI plugin health checks using the STATUS verb, which would have marked nodes NetworkReady=false on plugin failures. It was reverted before this release shipped because it caused bootstrapping regressions. Net result: no behavior change for CNI in v1.35.3. But if you saw this feature in changelogs and planned for it, don't — it's gone and will likely return in a future release with fixes.

• enhancementUse 'min_injected_gomaxprocs' to prevent CPU underutilization in containers with low CPU requests

  Containers with very low cpu.request values can end up with GOMAXPROCS=1, throttling Go-based workloads. The new 'min_injected_gomaxprocs' config field sets a floor so CRI-O injects max(floor, cpu.request) as GOMAXPROCS. This is particularly useful for Go-based sidecars or agents that are request-constrained but need threading headroom. Set this in your CRI-O config if you run Go workloads with conservative CPU requests.

CRI-O v1.34.8 patches CVE-2026-35469 in the spdystream dependency and adds two operator-facing features: a new runtime metric and configurable GOMAXPROCS injection.

• securityPatch CVE-2026-35469 — update to v1.34.8 now

  The spdystream library had a vulnerability fixed in this release. spdystream is used for streaming connections (exec, attach, port-forward), so exposure is real in any cluster. Upgrade CRI-O to v1.34.8 on all nodes. No config changes required — the fix is purely a dependency bump.

• enhancementUse the new runtime metric to audit node configurations

  The `container_runtime_crio_default_runtime` metric lets you confirm — via your existing Prometheus stack — that every node is actually running the runtime you expect (e.g., runc vs. kata-containers). This is particularly useful in mixed-runtime clusters or after node image upgrades where config drift can go undetected. Add an alert for unexpected runtime values once you've upgraded.

• enhancementEvaluate min_injected_gomaxprocs for CPU-constrained workloads

  If you run containers with very low cpu.request values (e.g., 0.1 cores), Go runtimes default to GOMAXPROCS=1, which can serialize work that should be parallel. Setting `min_injected_gomaxprocs` raises the floor so those containers get a more reasonable thread count. Be cautious on dense nodes: raising GOMAXPROCS across all containers increases goroutine scheduling overhead. Test with a non-Guaranteed workload first and watch CPU throttling metrics before rolling out cluster-wide.

v1.33.12 patches CVE-2026-35469 via a spdystream dependency bump and adds a new min_injected_gomaxprocs option for controlling GOMAXPROCS floor in containers.

• securityPatch CVE-2026-35469 — upgrade now

  The spdystream dependency update addresses CVE-2026-35469. Since spdystream handles HTTP/2 multiplexing in CRI-O's communication paths, any cluster running v1.33.x should move to v1.33.12 promptly. Check your vulnerability scanner results for this CVE and treat this as a routine security patch cycle rather than waiting for your next maintenance window.

• enhancementUse min_injected_gomaxprocs to prevent CPU underutilization in Go workloads

  Go runtimes default GOMAXPROCS to the number of logical CPUs on the node, which causes goroutine scheduling inefficiency when containers have small cpu.request values. This new option lets you set a floor (e.g., 2 or 4) so containers don't get starved of OS threads. It only applies to Burstable and BestEffort pods — Guaranteed QoS pods and partitioned workloads are unaffected. Start by auditing Go-based workloads in your cluster that run with low cpu.request; set min_injected_gomaxprocs conservatively and monitor goroutine behavior before widening the floor.

CRI-O v1.33.10 fixes a critical bug in high performance hook IRQ SMP affinity handling that could cause IRQ interference between containers during late deletion scenarios.

• securityUpdate immediately if using high performance hooks

  This bug could cause performance degradation or unexpected behavior in high-performance workloads by interfering with IRQ handling between containers. If you're running CRI-O with high performance hooks enabled (typically in HPC or latency-sensitive environments), upgrade immediately to prevent IRQ SMP affinity corruption that occurs during container cleanup.