リリース

CRI-O v1.35.5は2件のバグ修正のみを含むパッチリリースです。再起動をまたいでImageRefが変化する問題と、gomaxprocs hookのCPU算出ロジックの問題が解消されました。破壊的変更・セキュリティ修正・API変更はありません。

CRI-O v1.36.2は、gomaxprocsフックのCPU割り当て計算を修正する通常のパッチリリースです。Goスケジューラがスロットリングされる問題を軽減します。セキュリティ修正や破壊的変更はありません。

CRI-O v1.34.10はバグ修正のみのパッチで、gomaxprocsのCPU注入ロジックの修正と、再起動後のコンテナステータスにおけるImageRef形式のリグレッション修正の2件が含まれます。セキュリティ、API、設定の変更はありません。

CRI-O v1.35.4 is a patch release with no code changes or dependency updates from v1.35.3 — essentially a rebuild or re-tag of the previous patch.

• enhancementSkip this upgrade unless you need a clean rebuild

  There are zero changelog entries and zero dependency changes. This release is likely a rebuild triggered by a CI/pipeline issue or a signing/artifact correction. If you're already on v1.35.3 and it's working, there's no functional reason to upgrade. Check the CRI-O GitHub issue tracker or release PR for context on why this tag was cut before deciding to roll it out.

• enhancementVerify artifact integrity with cosign and SBOM before deploying

  Even for a no-change release, practice your supply chain verification workflow: use cosign to verify the signature on the tarball and the bom tool to validate the SPDX SBOM. This is good hygiene to establish before you need it on a critical release.

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.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.

v1.33.11 is a maintenance patch with no code changes or dependency updates — purely a rebuild/re-release against the v1.33.10 baseline.

• enhancementSkip this upgrade if you're already on v1.33.10

  There are zero functional or security changes here. If your nodes are running v1.33.10 without issues, there's no practical reason to roll this out. Watch for v1.33.12 or a patch with actual fixes before scheduling maintenance windows.

• enhancementUse SBOM and cosign artifacts for supply chain verification

  Every build ships SPDX SBOMs and cosign bundle files. If your org has supply chain security requirements, integrate cosign verification into your upgrade pipeline now — this is a low-risk release to test that workflow against before a more impactful update arrives.

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.34.7 is a patch release with no code changes or dependency updates from v1.34.6 — essentially a rebuild or release process artifact.

• enhancementSafe to skip unless you need the rebuild

  This release carries zero functional or security changes. If you're already on v1.34.6, there's no operational reason to upgrade immediately. That said, if your pipeline requires the latest patch tag for compliance or artifact provenance reasons, the SPDX SBOM and cosign bundles are all present and accounted for.

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.

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.

CRI-O v1.34.6 is a maintenance release with no functional changes, dependencies, or fixes - purely a version bump from v1.34.5.

• enhancementSkip this release unless forced by policy

  This release contains zero functional changes. Stay on v1.34.5 unless your organization requires running the latest patch version for compliance reasons. Save the upgrade effort for a release that brings actual improvements.