リリース

CRI-O v1.36.1 is a small patch fixing a container status regression where ImageRef flipped to a raw image ID after restart, plus a debug log verbosity reduction.

• breakingUpgrade if you rely on ImageRef for image identity after restarts

  Before this fix, CRI-O restarts caused ImageRef in container status to switch from a repo@digest string to a raw image ID. Any tooling that parses ImageRef — admission controllers, audit pipelines, image policy enforcers — could silently receive the wrong format and fail validation or produce incorrect audit records. If you run workloads where CRI-O restarts are common (e.g., upgrades, node reboots), patch to v1.36.1 immediately and validate your tooling handles the repo@digest format consistently.

• enhancementExpect quieter debug logs under high-frequency List* RPC calls

  Clusters with aggressive monitoring or reconciliation loops generating frequent ListContainers/ListPodSandboxes calls were generating excessive debug log volume, which hurt CRI-O performance under high load. After this patch, debug logging is less chatty for these paths. If you previously reduced log levels specifically to work around this noise, you can now safely re-enable debug logging without the same overhead.

CRI-O v1.34.9 fixes two concurrency bugs: a panic from racing StopContainer calls and a spurious exit code 255 on fast-exiting containers. Pure bug-fix release, no dependency changes.

• breakingPanic risk on concurrent StopContainer — upgrade if you drain nodes or run rapid pod teardowns

  If your cluster drains nodes, runs batch workloads with rapid pod churn, or uses any automation that issues multiple StopContainer calls in parallel, the pre-fix versions could panic CRI-O, taking down the container runtime on that node. This is a hard crash, not a graceful error. Upgrade to v1.34.9 immediately on any node where concurrent stop operations are plausible.

• enhancementExit code 255 false positives are gone — review alerting and restart policies

  Exit code 255 is often treated as a runtime-level failure in monitoring stacks and can trigger unnecessary pod restarts or alerts. If you have OOMKill or fast-exit workloads (init containers, short-lived jobs) and have seen spurious 255 exit codes in your logs or metrics, those were false positives from this race. After upgrading, audit your alerting rules and CrashLoopBackOff history — you may find some pods were incorrectly flagged.

Single-fix patch release resolving a race condition that caused CRI-O to incorrectly report exit code 255 for fast-exiting containers.

• breakingFalse exit code 255 may have masked real container failures

  If your monitoring, alerting, or restart policies key off exit code 255, you may have been misclassifying fast-exiting containers as crashed. After upgrading, audit any runbooks or OOMKill/CrashLoopBackOff workflows that treat exit code 255 as a specific signal — the real exit codes from short-lived containers will now surface correctly.

• enhancementUpgrade straightforward for 1.33.x users — no config or dependency changes

  This is a clean drop-in replacement for v1.33.12. No dependency bumps, no config changes required. Plan a rolling node drain and replace the CRI-O binary. Prioritize nodes running batch jobs, init containers, or short-lived workloads where fast exits are common and exit code accuracy matters most.

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.35.2 is a focused bug-fix patch addressing image pull credential verification, metrics reporting gaps, and OCI artifact store contamination issues.

• breakingVerify credential provider workflows after upgrading

  The PullImage fix changes what gets returned during image pulls. If you use Kubernetes credential provider plugins or have automation that validates image pull behavior, test those flows before rolling this to production. The old behavior could silently bypass credential checks in edge cases.

• enhancementAudit your metrics pipelines — you may have been missing data

  The metrics bug means any cluster running v1.35.x before this patch was likely returning incomplete metrics when 'all' was set. After upgrading, expect metric cardinality to increase. Check dashboards and alerting thresholds — a spike in metrics volume is expected and correct, not a problem.

• enhancementUse additional_artifact_stores for air-gapped or mirrored artifact setups

  If you run air-gapped clusters or internal artifact mirrors, the new 'additional_artifact_stores' option lets you configure multiple read-only sources without hacking around existing config. Pair this with the pinned_images fix to ensure pinned artifacts are pulled from the right store consistently.

CRI-O v1.35.1 fixes critical systemd container issues with user namespaces and adds TLS configuration options for API servers.

• breakingTest systemd workloads with user namespaces

  A regression in v1.35.0 broke systemd containers when hostUsers: false is set. This patch fixes it, but if you're running v1.35.0, upgrade immediately and test any systemd workloads that use user namespace isolation to ensure they start properly.

• enhancementConfigure TLS settings for production security

  New TLS configuration options let you harden streaming and metrics server security. Add tls_min_version and tls_cipher_suites to your [crio.api] section to enforce TLS 1.3 and strong cipher suites in production environments.

• enhancementVerify runc v1.4.0 compatibility

  The update to runc v1.4.0 brings performance improvements and bug fixes. Test your container workloads, especially those using advanced features like cgroups v2 or checkpoint/restore, to ensure compatibility with the new runtime version.