リリース

Dapr 1.18 is a large release centered on workflow security and durability (tamper detection, access policies, history propagation, concurrency limits), with Jobs API and HotReload graduating to GA and several breaking changes requiring pre-upgrade review.

• securityEnable WorkflowAccessPolicy in shared or multi-tenant clusters

  Before 1.18, any caller in the same trust domain could schedule, terminate, or query any other app's workflows. The new WorkflowAccessPolicy CRD lets you lock this down per-operation with glob-pattern rules. The default is still open (no policy = all calls allowed), so existing deployments are unaffected — but teams running shared clusters should define policies now. Also: redis common components previously skipped TLS cert verification unconditionally; this is fixed in 1.18, so verify your Redis TLS config is correct before upgrading.

• breakingDo not roll back from 1.18 directly to 1.17.6 or earlier

  Sentry 1.18 writes an Ed25519-keyed CA into the dapr-trust-bundle secret. Any Sentry version before 1.17.7 cannot parse this and will crash-loop, blocking all new certificate issuance. Before upgrading, confirm your rollback target is 1.17.7+. If you need to go below 1.17.7, downgrade to 1.17.7 first, stabilize, then continue. Also audit any code that relied on silent workflow ID reuse — it now gets a hard conflict error.

• breakingHop-by-hop headers stripped on service invocation — check your apps

  Standard HTTP hop-by-hop headers (Connection, Keep-Alive, Transfer-Encoding, etc.) are now stripped during service invocation per RFC 7230. Any app relying on these headers passing through will silently break. Audit service invocation call sites and move to non-hop-by-hop equivalents before upgrading.

• enhancementEnable workflow history signing for audit-sensitive workloads

  Workflow history signing is opt-in and disabled by default. It requires mTLS to be active. Before turning it on cluster-wide, let any in-flight unsigned workflows complete or purge them — enabling signing on a workflow that started unsigned is a hard verification error with no catch-up path. Once enabled, a tampered workflow is terminated and flagged with DAPR_WORKFLOW_HISTORY_TAMPERED, leaving the original state intact for forensic review. Good candidate for compliance-sensitive or multi-tenant workflow deployments.

Chaos Mesh v2.8.3 is a security-focused patch: critical/high CVEs addressed via Go 1.25.11 and containerd 1.7.32 upgrades, plus a NetworkChaos recovery bug fix.

• securityUpgrade to v2.8.3 to patch critical/high CVEs

  The Go toolchain and containerd in the container images had critical/high CVEs. If you're running Chaos Mesh on release-2.8, upgrade to v2.8.3 now. No config changes needed — this is a drop-in image update.

• breakingVerify NetworkChaos experiments involving crash-looping pods

  NetworkChaos recovery previously failed when the target container was in CrashLoopBackOff. v2.8.3 fixes this by falling back to the pause container's PID. If your test environments include intentionally crash-looping workloads, re-run those experiments to confirm recovery behaves correctly after the upgrade.

OTel Collector v0.154.0 fixes a startup crash in exporterhelper and changes --skip-get-modules behavior. Two minor enhancements add TLS and CORS config options.

• securityinclude_insecure_cipher_suites is opt-in — keep it that way

  The new configtls option lets you re-enable weak cipher suites, but they stay disabled by default. Do not set include_insecure_cipher_suites: true in production unless you're forced to by a legacy peer — and if you are, treat it as a temporary workaround and track it.

• breakingCheck custom build pipelines using --skip-get-modules

  If your OCB-based build scripts pass --skip-get-modules expecting go.mod to be regenerated as a side effect, that no longer happens. Audit any CI pipelines that relied on this implicit behavior and add an explicit go mod tidy step if needed.

• enhancementUpgrade if you use sending_queue with sizer enabled

  The nil-pointer panic fix in exporterhelper is critical for anyone who sets sending_queue.sizer alongside batch.enabled: false. If your collector was crashing on startup in this config, v0.154.0 resolves it — upgrade directly.

KEDA 2.20.1 fixes a critical race condition that caused panics during concurrent scaling and restores missing startup events for ScaledJobs. Upgrade required if running 2.20.0.

• securityUpgrade to 2.20.1 if you saw panic crashes during concurrent scaling

  A concurrent map read/write race condition in the status update logic caused KEDA to panic when ScaledObjects or ScaledJobs scaled simultaneously (multiple triggers active at once). This is fixed in 2.20.1. If you experienced panics in 2.20.0 during periods of high scaling activity, upgrade immediately.

• breakingReview breaking changes in v2.20.0 before upgrading

  KEDA 2.20.0 introduced breaking changes. If you operate KEDA clusters on versions before 2.20.0, review the v2.20.0 release notes at the GitHub link provided in the warning before upgrading to 2.20.1. Do not skip directly from < 2.20.0 to 2.20.1 without reading those notes first.

• enhancementRestore ScaledJob scaler startup event visibility

  KEDA was failing to emit the KEDAScalersStarted event for ScaledJobs due to Kubernetes event aggregation key collision. Monitoring tools or dashboards relying on this event to track scaler initialization may have missed ScaledJob startup signals. Upgrade to 2.20.1 to restore proper event emission.

Security patch release upgrading Go to 1.26.4, fixing two stdlib vulnerabilities affecting OPA's HTTP handler and crypto builtins. No code changes from v1.17.0.

• securityUpgrade to v1.17.1 immediately if using OPA's HTTP server or crypto builtins

  Two Go stdlib vulnerabilities (GO-2026-5039, GO-2026-5037) hit the HTTP handler and crypto builtins directly. If you run OPA as a server or use crypto-related Rego builtins, you're exposed on v1.17.0 and earlier. Drop-in replace with v1.17.1 — no config or policy changes needed. If you build your own OPA binaries, bump your Go toolchain to 1.26.4 yourself; this release doesn't change anything else.

Patch release adding a v2 upgrade readiness scanner, a golang.org/x/net security fix, and a runtime bump. The new CLI command is the practical reason to upgrade now.

• securityUpdate immediately for golang.org/x/net fix

  golang.org/x/net was updated to v0.55.0 to address a security issue. The release notes tag this as a security dependency update, so treat it as mandatory. Upgrade to v1.20.9 before the next planned maintenance window, don't wait for a convenient moment.

• breakingTreat upgrade check findings as real blockers, not warnings

  The command reports usage of features that are removed or changed in v2 — native patch-and-transform Compositions, ControllerConfig, external secret stores, and unqualified package sources. These are not deprecation warnings; they are hard blockers. If your control plane has any findings, start migration work using the linked guides before attempting any v2 upgrade. Ignoring them and upgrading anyway will break running workloads.

• enhancementRun upgrade check before any v2 planning work

  If your team is on a v1.x control plane and Crossplane v2 is anywhere on the roadmap, run `crossplane beta upgrade check` against your environment now. It surfaces exactly which Compositions, ControllerConfigs, and package references will block an upgrade — saving hours of manual audit. Pipe it with `-o json` into your CI pipeline to enforce a clean bill of health before any v2 upgrade PR is merged. The non-zero exit code makes gating trivial.

v1.21.1 is a security-focused patch release addressing findings from a formal security audit, including XSS, gzip bomb, and memory amplification vulnerabilities — upgrade immediately.

• securityUpgrade immediately — multiple audit findings patched

  This release backports fixes from a formal security audit (V01–V07). The vulnerabilities include a stored XSS on status pages, a gzip bomb in the OTLP ingestion path, memory amplification via malformed native histogram payloads, and gossip port exposure to flood/OOM attacks. These are not theoretical — they are exploitable by any client that can reach your Cortex endpoints. Upgrade to v1.21.1 now. After upgrading, review your -distributor.otlp-max-recv-msg-size setting; the default may be too permissive depending on your ingest volume.

• securityAudit your /config endpoint exposure

  Prior to this release, Swift, etcd, Redis, and HTTP basic-auth credentials were exposed in plaintext on the /config endpoint. If that endpoint was accessible to internal users or scraping systems, treat those credentials as compromised and rotate them. Going forward, restrict /config access via network policy or auth middleware regardless of masking.

• enhancementHarden memberlist gossip with new bounding flags

  Three new flags (-memberlist.packet-read-timeout, -memberlist.max-packet-size, -memberlist.max-concurrent-connections) cap inbound gossip TCP behavior. The defaults are reasonable, but if your Cortex cluster is exposed to less-trusted network segments or you've seen gossip-related OOM events, tune these explicitly. Add them to your Helm values or config management before the next planned maintenance window.

v1.17.1 is a focused patch fixing two correctness bugs: stale cache reads and broken continuation tokens with pipe characters in type names.

• securityStale cache reads could return incorrect authorization decisions — patch now

  The iterator cache was using write time rather than query start time as the LastModified anchor, meaning cached entries could persist beyond the intended validity window and serve stale data. In an authorization system, a stale 'allow' decision is a real risk. This is fixed in v1.17.1; upgrade immediately if you run with caching enabled.

• breakingAudit type names with '|' if pagination was silently breaking

  If your FGA model uses type names containing the pipe character '|', continuation tokens were being deserialized incorrectly. This could cause ListObjects or similar paginated calls to return incomplete or wrong results without throwing obvious errors. Upgrade to v1.17.1 and re-test any pagination flows that touch those type names.

• enhancementv2Check throttling fallback removed — verify your error handling

  Previously, v2Check would fall back to v1 behavior under throttling or validation errors, masking the actual problem. Now it surfaces those errors directly. If your application swallows check errors silently or assumes fallback behavior, you may start seeing errors that were previously hidden. Test under load before rolling out to production.

Istio 1.29.4 patches a high-severity DoS CVE in Envoy plus six bug fixes, including a critical ambient mode traffic routing bug that could silently send traffic to unhealthy endpoints cluster-wide.

• securityPatch CVE-2026-47774 immediately — unauthenticated HTTP/2 DoS

  CVE-2026-47774 lets any unauthenticated attacker exhaust Envoy's memory via crafted HTTP/2 requests. Cookie header bytes aren't fully counted in header size validation, and HPACK limits apply only to encoded bytes — not decoded totals. If you're on 1.29.x, upgrade to 1.29.4 now. This is exploitable from outside the mesh wherever Envoy terminates HTTP/2, including ingress gateways.

• breakingAmbient mode users: audit Services using publishNotReadyAddresses + traffic distribution

  If any Service in your ambient mesh combines publishNotReadyAddresses:true with PreferSameZone or PreferSameNode traffic distribution, every other Service sharing that traffic-distribution preset was receiving healthPolicy:AllowAll — meaning traffic could route to not-ready endpoints across the entire cluster. After upgrading to 1.29.4, verify endpoint health policies are correct. Check ztunnel logs for unexpected AllowAll entries before and after the upgrade to confirm the fix took effect.

• enhancementCNI on older kernels: nftables fallback now automatic

  Hosts running an nft binary compiled without JSON support were causing the CNI agent to log errors and retry indefinitely on every pod removal — a silent drain on the agent's reliability. The new startup check detects this and switches to iptables automatically. No action needed for most users, but if you've been seeing 'JSON support not compiled-in' errors in CNI agent logs, this fix resolves the root cause.

Istio 1.28.8 patches a high-severity DoS CVE in Envoy's HTTP/2 memory handling, plus three bug fixes covering TLS delivery, route filter status reporting, and a nasty ambient mode health policy contamination bug.

• securityPatch CVE-2026-47774 immediately if you expose HTTP/2 endpoints

  An unauthenticated attacker can crash your Envoy sidecars by sending specially crafted HTTP/2 requests that bypass header size validation — cookie bytes aren't counted properly, and HPACK limits apply only to encoded size, not decoded. Any cluster accepting external or untrusted HTTP/2 traffic is at risk. Upgrade to 1.28.8 now. If you can't upgrade immediately, consider adding Envoy-level request header size limits or WAF rules to filter malformed HTTP/2 frames as a temporary measure.

• breakingAudit ambient mode clusters using publishNotReadyAddresses with zonal traffic distribution

  If you run ambient mode and any Service sets publishNotReadyAddresses:true alongside PreferSameZone or PreferSameNode, you've likely been routing traffic to not-ready endpoints across your entire cluster — not just for that Service, but for every Service sharing the same traffic-distribution preset. This is a silent data-plane correctness bug. After upgrading, verify endpoint health behavior across affected Services and check whether any downstream systems received traffic from unhealthy pods during the window this was active.

• enhancementFix for silent route filter drops enables reliable config debugging

  Previously, HTTPRoute or GRPCRoute filters with invalid header values would vanish from Envoy config without any status signal — making it nearly impossible to diagnose why traffic wasn't behaving as expected. Now Istio reports an invalid filter status, which surfaces in the Gateway API resource status. After upgrading, re-check any routes you may have debugged by guesswork; the explicit status message will clarify whether a header filter was rejected.

Istio 1.30.1 patches a high-severity DoS CVE in Envoy's HTTP/2 handling plus fixes 13 bugs including a CNI agent panic, a traffic distribution poison bug, and a consistent hash load balancing regression.

• securityPatch CVE-2026-47774 immediately — unauthenticated HTTP/2 DoS

  An attacker can exhaust Envoy's memory using crafted HTTP/2 requests that exploit gaps in Cookie header accounting and HPACK decoded-size limits. No authentication required. If you're running any Istio 1.30.x version, upgrade to 1.30.1 now. Check whether your ingress gateways are exposed to untrusted traffic — those are the highest-risk surfaces.

• breakingAmbient users with traffic distribution policies: audit Services immediately

  If you use ambient mode with any Service that sets publishNotReadyAddresses: true alongside PreferSameZone or PreferSameNode traffic distribution, the bug caused ztunnel to apply healthPolicy: AllowAll to OTHER unrelated Services sharing that preset. This means traffic has potentially been routed to not-ready endpoints across your cluster. After upgrading to 1.30.1, verify endpoint health state and check whether any unexpected traffic reached unready pods.

• enhancementRun 'istioctl analyze' after upgrading to catch stale Gateway API CRDs

  Upgrading Istio without updating Gateway API CRDs was silently breaking TLS passthrough in 1.30.0 — istiod would filter resources without any visible error. The new IST0176 check surfaces this. After upgrading, run istioctl analyze and resolve any IST0176 findings before they cause silent routing failures in production.

v1.38.1 is a security-focused patch addressing two HTTP/2 CVEs and two oauth2 vulnerabilities — upgrade immediately if running HTTP/2 or oauth2 filter.

• securityPatch HTTP/2 and oauth2 CVEs now — don't wait for your next maintenance window

  Two HTTP/2 CVEs (cookie-bomb memory exhaustion via HPACK and nghttp2 CVE-2026-27135) plus two oauth2 bugs (timing oracle and a crash-as-auth-bypass) make this a must-apply patch. If you're running the oauth2 filter, the HMAC timing side-channel is particularly nasty — attackers could probe HMAC secret validity over time. Upgrade to v1.38.1 immediately. The new HTTP/2 header limit behavior is enabled by default; only revert with `envoy.reloadable_features.http2_include_cookies_in_limits` if you have a specific, documented reason.

• breakingUpstream failure reason stripped from HTTP response bodies — check your client error handling

  Any downstream client or API consumer that parses or displays the upstream transport failure reason from the HTTP response body will now get nothing. The information is still in access logs. Audit your clients and dashboards before upgrading — if something depends on that response body content, you have a short window to either update the client or re-enable the old behavior with `envoy.reloadable_features.hide_transport_failure_reason_in_response_body`.

• breakingEDS batch LB rebuild coalescing is now opt-in — test under high-churn service discovery

  Load balancer rebuild coalescing during EDS batch host updates is disabled by default. Environments with large EDS clusters and frequent host churn (e.g., Kubernetes rolling deployments with many pods) may see increased CPU from more frequent LB rebuilds. Benchmark your control-plane interaction patterns after upgrading. Re-enable the old behavior with `envoy.reloadable_features.coalesce_lb_rebuilds_on_batch_update` if you observe performance regression.

Keycloak 26.6.3 is a critical security release fixing 16 CVEs spanning OIDC, SAML, LDAP, WebAuthn, and authorization services. Upgrade immediately.

• securityUpgrade to 26.6.3 now — 16 CVEs, several high-severity

  This release patches a dense cluster of vulnerabilities. The most dangerous include: CVE-2026-9704 (privilege escalation via silent subject_token removal in token exchange), CVE-2026-4874 (SSRF via OIDC token endpoint), CVE-2026-9802 (rotated refresh token reuse after server restart with revokeRefreshToken=true), and CVE-2026-8830 (missing WebAuthn server-side validation). If you're running any 26.x version, treat this as an emergency patch. Review the migration guide before upgrading, but don't delay the upgrade waiting for a maintenance window — schedule one immediately.

• securityAudit redirect URI configs after wildcard matching fix

  CVE fix for wildcard redirect URI matching (issue #48430) changes enforcement behavior — '*' placed directly after a hostname no longer matches arbitrary subdomains or paths. After upgrading, verify that legitimate client redirect URIs still work correctly in your environments. Any client relying on overly broad wildcard patterns should be tightened anyway; this is a good forcing function.

• securityReview LDAP federation and token exchange configurations

  Two targeted vectors: CVE-2026-9801 allows DoS via malformed PasswordPolicyControl in LDAP federation — if you expose LDAP federation to partially-trusted inputs or have external-facing auth flows backed by LDAP, this is high priority. CVE-2026-9704 affects any realm using token exchange with subject_token; the fix prevents silent removal of subject_token from escalating privileges. Confirm your token exchange policies are scoped correctly post-upgrade.

v1.37.3 is a security-focused patch fixing two HTTP/2 CVEs and oauth2 vulnerabilities — upgrade immediately if you use HTTP/2 or oauth2 filter.

• securityPatch HTTP/2 deployments now for CVE-2026-47774 and CVE-2026-27135

  Two HTTP/2 CVEs are fixed in this release. CVE-2026-47774 enables a cookie-bomb attack that causes excessive memory usage by sending large numbers of cookies that bypass header size limits before this fix. CVE-2026-27135 is an nghttp2-level vulnerability. If you terminate HTTP/2 traffic, upgrade to v1.37.3 immediately. The new cookie-counting behavior is enabled by default; if it causes regressions, you can temporarily disable it with the feature flag `envoy.reloadable_features.http2_include_cookies_in_limits`, but treat that as a short-term workaround only.

• securityRotate oauth2 HMAC secrets after upgrading

  The timing side-channel in HMAC verification means a patient attacker could have probed whether a given secret was valid. After upgrading, rotate your oauth2 HMAC secrets as a precaution — especially in internet-facing deployments. The AES-CBC crash fix is also relevant: the previous 1/256 spurious decryption success could cause unpredictable auth behavior, not just crashes.

• breakingCookie-heavy workloads may see HTTP/2 stream resets

  The CVE-2026-47774 fix changes how cookies are counted against `mutable_max_request_headers_kb` and `max_headers_count`. Clients sending many cookies that were previously accepted may now hit limits and receive stream resets. Test your high-cookie traffic patterns in staging before rolling this to production, and review your header size limits to ensure they are set appropriately for your workloads.

v1.36.7 is a security-focused patch addressing two CVEs in HTTP/2 and an HPACK cookie-bomb attack vector in the oauth2 filter, plus a crash fix. Upgrade immediately.

• securityPatch HTTP/2 CVEs now — two CVEs affect any HTTP/2-exposed Envoy

  CVE-2026-47774 enables a cookie-bomb attack where crafted HPACK-compressed cookies inflate to exhaust Envoy memory. After patching, cookies count toward `mutable_max_request_headers_kb` and `max_headers_count`. If you see legitimate requests being reset post-upgrade, the escape hatch is the `envoy.reloadable_features.http2_include_cookies_in_limits` flag — but audit your header size limits first rather than disabling the protection. CVE-2026-27135 is an nghttp2-layer fix with no workaround; you must upgrade.

• securityAudit oauth2 filter deployments for timing and decryption exposure

  Two oauth2 bugs fixed here are subtle but serious. The timing side-channel in HMAC verification could allow an attacker to probe secret validity over many requests. The AES-CBC crash (1/256 chance on bad tokens) is a reliability issue that could be triggered deliberately. If you use the oauth2 filter with token cookies, treat this as a high-priority upgrade — there's no configuration workaround for either issue.

• breakingReview header size limits before deploying — cookie counting is a behavior change

  Cookies previously excluded from header size accounting now count toward limits. In practice, applications with many or large cookies may hit `max_headers_count` or `mutable_max_request_headers_kb` and get HTTP/2 stream resets where they didn't before. Before rolling out, check your current limit configurations against real traffic cookie sizes. If you need time, the reloadable feature flag lets you defer the behavior change, but don't leave it disabled long-term.

v1.35.11 is a security-focused patch fixing two HTTP/2 CVEs and two oauth2 vulnerabilities — upgrade immediately if you're running HTTP/2 or oauth2 filter.

• securityPatch HTTP/2 HPACK cookie-bomb vulnerability now

  CVE-2026-47774 allows an attacker to craft requests with large numbers of HPACK-compressed cookies that decompress into massive header payloads, causing excessive memory usage. The fix resets offending streams and counts cookies toward existing header size limits. Roll out this patch to any Envoy instance terminating HTTP/2 traffic. If you hit legitimate regressions with cookie-heavy workloads, the flag `envoy.reloadable_features.http2_include_cookies_in_limits` can temporarily revert the behavior — but treat that as a short-term workaround, not a solution.

• securityUpgrade if you use the oauth2 filter — two separate fixes here

  There are two distinct oauth2 issues fixed: a timing side-channel in HMAC verification (exploitable via repeated probing to determine secret validity) and a crash from incorrect AES-CBC decryption behavior on secret mismatch. The crash was probabilistic (~1/256 per request) but real. If your deployment uses Envoy's built-in oauth2 filter for token validation, this patch directly reduces both crash risk and secret exposure surface.

• enhancementEvaluate stats eviction for high-cardinality metric environments

  The new `stats_eviction_interval` config allows Envoy to periodically purge unused metrics from memory. If you're running workloads with dynamic or high-cardinality labels (e.g., per-request or per-user stats), this can meaningfully reduce memory footprint over time. Test in staging first — eviction behavior depends on whether extensions implement the evictable metrics interface, so not all metrics will be affected.

KubeVirt v1.8.3 is a patch release with 75 fixes targeting security, authorization, live migration stability, and GPU/DRA device handling — all worth deploying promptly.

• securityPatch CVE and symlink traversal — upgrade now

  Two security issues demand attention: a gRPC CVE (GHSA-p77j-4mvh-x3m3) and a symlink traversal in the VMExport dir handler. Both are fixed in this release. If you use VMExport or expose VM data externally, treat this upgrade as urgent. Verify no malicious symlinks exist in existing VMExport directories before and after upgrading.

• breakingRecording rule renames — update dashboards and alerts before upgrading

  kubevirt_vm_created_total and kubevirt_vm_created_by_pod_total are deprecated outright, and multiple other recording rules are being renamed for naming convention compliance. If your Grafana dashboards, alerting rules, or SLO queries reference these metrics, they will silently stop matching after upgrade. Audit your observability stack now and migrate to the new names before rolling this out to production.

• enhancementLive migration is more reliable — especially on IPv6 and cross-namespace setups

  Several live migration bugs are resolved here: cross-namespace migration on IPv6 clusters now works, duplicate kubevirt_vmi_info series no longer break VirtualMachineStuckOnNode and VMCannotBeEvicted alerts, and GuestAgentPing probes no longer cause spurious pod restarts during migration. If you've been avoiding live migration in IPv6 or multi-namespace environments due to instability, this release clears those blockers.

KubeVirt v1.7.4 is a patch release fixing a CVE in gRPC, authorization bugs, live migration on IPv6, and probe-triggered pod restarts during VM lifecycle events.

• securityPatch CVE-2026-33186 by upgrading to v1.7.4 now

  The gRPC dependency was vulnerable to CVE-2026-33186. This is a direct dependency bump to 1.79.3, so upgrading your KubeVirt installation to v1.7.4 is the only required action — no configuration changes needed. Prioritize this if your cluster runs workloads exposed to untrusted input over gRPC.

• breakingAudit authorization if you use VNC, SEV, or evacuate subresources

  The SubjectAccessReview truncation bug meant RBAC checks were being evaluated against incorrect subresource names — which could have allowed access that should have been denied, or denied access that should have been allowed. After upgrading, verify that your RBAC policies for vnc/screenshot, sev/*, and evacuate/cancel subresources behave as intended. This is not just a security fix; it's a correctness fix for authorization logic.

• enhancementVMs using GuestAgentPing probes during migrations or pauses should no longer bounce

  If you've been seeing unexpected virt-launcher pod restarts during live migrations or VM pause operations, this was a known probe behavior issue. The fix suppresses false-positive probe failures during pre-copy target, post-copy source, user pause, snapshot, save, and dump states. No action required — just upgrade. If you had workarounds in place (e.g., disabling GuestAgentPing during migrations), you can now remove them.

KubeVirt v1.6.6 is a patch release fixing 9 notable bugs including a CVE remediation, authorization bypass in virt-api, and broken cross-namespace live migration on IPv6 clusters.

• securityPatch CVE-2026-33186 by upgrading to v1.6.6

  The grpc dependency was bumped to remediate CVE-2026-33186. If your KubeVirt deployment exposes gRPC endpoints or you're running in a multi-tenant cluster, this is the main reason to push this upgrade now. Check your current version and plan the rollout — this is a patch release so the upgrade path should be straightforward.

• securityFix incorrect SubjectAccessReview checks in virt-api — audit your RBAC

  virt-api was constructing SubjectAccessReviews with truncated subresource names for deep paths like vnc/screenshot and sev/*. This means authorization checks were running against wrong resource names, potentially allowing or denying access incorrectly. After upgrading, audit any RBAC policies that restrict access to VNC, SEV, or evacuation subresources to confirm they behave as intended.

• breakingIPv6 clusters: cross-namespace live migration was silently broken — verify after upgrade

  If you're running KubeVirt on an IPv6 cluster and rely on cross-namespace live migrations, those migrations were failing. This fix restores the expected behavior. After upgrading, run a test migration across namespaces in your IPv6 environment to confirm the fix holds before relying on it in production workflows.

• enhancementPCI hostdev users on mixed machine types: restart reliability improved

  VMs using PCI passthrough hostdevices were failing to restart after hotplugging a block volume. The root cause was PCI topology being gated only on architecture, not machine type. If you manage VMs with PCI hostdevices and have seen unexplained restart failures post-hotplug, this patch resolves it — no config change needed, just the upgrade.

v2.3.0 ships workload env/config/secrets management in wash, wasmtime 45 upgrade with security patches, and improved OTel tracing across workloads and HTTP spans.

• securityApply wasmtime 45 upgrade and dependency security patches immediately

  This release includes two wasmtime bumps: 44.0.2 was a targeted security patch, and 45 followed shortly after. On top of that, additional dependency security advisories were patched separately. If you're running wasmCloud in production, upgrade to v2.3.0 now rather than waiting — the cumulative security surface covered here is non-trivial.

• enhancementScope Kubernetes RBAC to namespaces instead of cluster-wide

  The runtime.wasmcloud.dev apiGroup RBAC can now be namespaced rather than cluster-scoped. If you're running the wasmCloud operator in multi-tenant Kubernetes clusters, revisit your RBAC configuration and tighten it to namespace scope where possible. This is a meaningful security posture improvement for shared clusters.

• enhancementStart using wash workload env/config/secrets for structured configuration

  Configuration and secrets management is now surfaced directly in the wash CLI. This is the workflow shift wasmCloud has been building toward — rather than managing config out-of-band, you can now handle env vars, config, and secrets as first-class workload concerns. Check the new otel-config example in the repo to see the intended pattern before adopting it in production.

Security patch release fixing CVE-2026-46680 plus runtime bugs in sandbox service, AppArmor compatibility, and OCI USER spec handling.

• securityPatch CVE-2026-46680 immediately

  CVE-2026-46680 is the primary driver for this release. Review the GHSA advisory to understand the attack surface and severity. If you run containerd 2.1.x in any environment, upgrading to 2.1.8 should be your next deployment task. There are no dependency changes, so the upgrade path is straightforward.

• breakingOCI USER out-of-range values now fail explicitly — check your container specs

  Previously, out-of-range USER values in OCI specs could silently fall through to username/group lookups, masking misconfigurations. Now containerd returns an explicit error. If any of your containers or image builds set numeric USER values outside valid UID/GID ranges, they will start failing visibly after this upgrade. Audit your specs before rolling out to production.

• enhancementUpgrade if you run AppArmor < 3.0 or use sandbox-based runtimes

  The conditional AppArmor abi fix is a real blocker for anyone on older AppArmor (e.g., Ubuntu 20.04 ships 2.x). The sandbox service bug also affects event-driven workflows and correct sandbox creation — silent misconfiguration is worse than a visible error. If you use Kata Containers or any sandbox-based runtime, this fix directly affects you.

v1.17.0 hardens cache key generation against hash-flooding attacks and adds configurable OpenTelemetry trace sampling, including parent-based propagation.

• securityUpgrade to get hash-flooding protection in cache keys

  The old string-concatenation cache key approach was vulnerable to hash-flooding attacks and key collisions. The new TLV encoding with per-process hash seeding closes both issues. There are no config changes required — just upgrade. If you run OpenFGA in a multi-tenant or public-facing setup, this is a meaningful security improvement that warrants prioritizing the upgrade.

• enhancementConfigure parent-based trace sampling if OpenFGA runs behind an API gateway or service mesh

  Previously, OpenFGA couldn't honor upstream sampling decisions, meaning traces could be captured inconsistently across your stack. Set `OPENFGA_TRACE_SAMPLER=parentbased_always_on` (or `parentbased_traceidratio`) so OpenFGA respects the sampling decision made by the calling service. This is especially useful when OpenFGA is a downstream dependency in a larger traced system — it reduces trace noise and aligns sampling with your existing observability strategy.

NATS v2.14.2 is a focused stability release fixing multiple JetStream data integrity issues, lock release bugs, and protocol corruption risks — upgrade if you run JetStream at any meaningful scale.

• securityProtocol corruption vectors closed — critical for WebSocket and JetStream users

  Two protocol corruption bugs were fixed: one in $JS.ACK subject rewriting and one in compressed WebSocket client buffer handling. Either could produce malformed frames that corrupt stream state or client sessions. If you expose NATS WebSocket endpoints or rely heavily on JetStream ACKs, treat this as a security-adjacent stability issue and prioritize the upgrade.

• breakingTwo separate lock-release bugs can cause silent hangs — patch now

  Both the filestore and consumer code paths had cases where locks were never released after specific error conditions (write errors and start sequence errors). In production this means stuck consumers or hung filestore operations that don't recover without a restart. If you've seen unexplained JetStream stalls, this is likely why. Upgrade to v2.14.2 immediately.

• enhancementHigh subject-count streams no longer risk CPU spikes — no config change needed

  The filestore block skip check was triggering runaway CPU on streams with very high subject counts. The fix is automatic after upgrade — no configuration changes required. If you've been working around this with stream design compromises (e.g., artificially limiting subjects per stream), you can revisit those decisions after upgrading.

v2.12.10 is a focused bug-fix release addressing protocol corruption risks, JetStream Raft/quorum issues, and a CPU runaway bug in high-cardinality streams.

• securityUpdate x/crypto and nkeys immediately

  This release bumps golang.org/x/crypto to v0.52.0 and nkeys to v0.4.16. These libraries handle cryptographic operations in NATS auth flows. Don't wait for scheduled maintenance — patch now, especially if your clusters are internet-exposed or use decentralized auth.

• breakingProtocol corruption fixes require prompt upgrade for WebSocket and JetStream users

  Two separate protocol-level corruption bugs are fixed here: one in compressed WebSocket clients, one in $JS.ACK subject rewriting. Either can silently corrupt message framing. If you run WebSocket clients or any JetStream workload with acknowledgements, staying on 2.12.9 or earlier is a real risk. Upgrade servers first, then clients.

• enhancementHigh-cardinality JetStream streams get a CPU safety fix — verify your config

  The block skip check on streams with very high subject counts could cause runaway CPU. That check is now disabled for those cases. If you've been seeing unexpected CPU spikes on JetStream nodes with streams containing millions of subjects, this is likely the culprit. After upgrading, also review Counter stream and message schedule configs — new constraints are enforced that may reject previously accepted but incorrect configurations.

Knative Serving v1.22.1 is a focused patch fixing an idle connection leak in the network prober, a memory leak in webhook matchers, and adding a 3MiB webhook request body size limit.

• securityApply the 3MiB webhook body limit immediately

  The new hard cap on webhook request body size closes a potential vector for memory exhaustion via oversized payloads. If you run Knative Serving in a multi-tenant or externally-exposed environment, upgrade to v1.22.1 now — don't wait for your next maintenance window.

• breakingWebhook requests larger than 3MiB will now be rejected

  If any of your workloads submit unusually large objects to Knative's admission webhooks (e.g., Services or Configurations with very large env var blocks or annotations), those requests will start failing after this upgrade. Audit object sizes before rolling out, and trim any oversized metadata or spec fields.

• enhancementUpgrade to stop slow memory and connection accumulation

  The prober connection leak and the expired-matcher memory leak are both cumulative — they degrade pod health gradually over time rather than causing immediate crashes. Clusters that have been running v1.22.0 for a while may already be affected. After upgrading, watch activator and webhook pod memory trends to confirm they stabilize.

Knative Serving v1.21.3 is a patch release fixing memory leaks, a connection leak in the network prober, and adding a 3MiB webhook request body size limit.

• security3MiB webhook body limit now enforced — test before upgrading

  The webhook request body is now hard-limited to 3MiB. If your workloads send large Knative resource specs (e.g., Services with extensive annotations, large env var blocks, or embedded configs), they could start getting rejected after this upgrade. Audit your largest Knative Service manifests before rolling this out to production. Anything approaching or exceeding 3MiB in a single admission request will fail.

• enhancementPatch memory and connection leaks — upgrade promptly

  Two resource leaks are fixed here: a memory leak in expired matchers and an idle connection leak in the network prober. In long-running clusters with frequent reconciliation or active health-checking, these leaks accumulate. If you've noticed gradual memory growth in the Knative controller or networking components, this patch is the likely fix. No config changes needed — just upgrade.

KEDA v2.20 ships four breaking removals, an RBAC migration for Kubernetes events, two new scalers, and a wave of bug fixes including credential-leak and connection-leak patches across several scalers.

• securityPatch credential-leak and connection-leak issues in Pulsar, RabbitMQ, and AWS scalers

  The Pulsar scaler was leaking bearer/basic auth credentials on cross-host redirects or HTTPS-to-HTTP downgrades. RabbitMQ had an AMQP connection leak. AWS scalers (SQS, Kinesis, DynamoDB, CloudWatch) leaked TCP connections on scaler close. If you run any of these scalers, upgrading to v2.20 closes real attack surface and resource exhaustion vectors. No config changes needed, but consider rotating credentials used by Pulsar scalers as a precaution.

• breakingUpdate RBAC before upgrading — events.k8s.io migration is not optional

  If you use custom or restricted RBAC for KEDA, add create/patch on events.k8s.io/events to the operator role before you upgrade. The official Helm chart and manifests already handle this, but any out-of-tree RBAC will silently break event recording. Also audit your ScaledObjects for the four removed settings (GCP PubSub subscriptionSize, Huawei minMetricValue, IBM MQ tls, InfluxDB authToken in triggerMetadata) — resources using these will fail validation after upgrade.

• enhancementAWS cross-account scaling now works natively via External ID support

  The new External ID field in TriggerAuthentication podIdentity covers all AWS scalers. If you've been using workarounds for cross-account IAM assume-role scenarios, you can now use the native field. Update your TriggerAuthentication manifests to set the externalId field — no more custom IAM boundary hacks required.

Volcano v1.15.0 ships gang-aware preemption/reclamation, DRA queue quota, autoscaler-friendly scheduling gates, and a batch of critical scheduler stability fixes addressing double-counting, race conditions, and rollback correctness.

• securityApply CVE-2026-44247 webhook DoS fix and Prometheus XSS patch

  v1.15.0 includes a mitigation for CVE-2026-44247, which allowed oversized webhook request bodies to exhaust webhook server memory. The Prometheus dependency is also updated for a stored XSS advisory (GHSA-vffh-x6r8-xx99). Upgrade to v1.15.0 if you expose Volcano admission webhooks — there's no workaround short of upgrading.

• breakingDon't mix gangPreempt/gangReclaim with legacy preempt/reclaim

  The new gangPreempt and gangReclaim actions are mutually exclusive with the legacy preempt and reclaim actions in a scheduler action list. If you upgrade and add gang-aware actions without removing the old ones, you'll get undefined behavior. Audit your scheduler ConfigMap before upgrading — pick one set or the other. Also note that DRA scheduling is now on by default; if your cluster doesn't have DRA-capable drivers, explicitly set predicate.DynamicResourceAllocationEnable: false.

• enhancementEnable Scheduling Gates to stop autoscaler over-scaling on queue limits

  If you run Cluster Autoscaler or Karpenter alongside Volcano, queue-blocked pods previously triggered unnecessary node scale-ups. The new scheduling gate feature fixes this cleanly. It's opt-in per pod via the scheduling.volcano.sh/queue-allocation-gate: 'true' annotation. Enable the feature gate on both the scheduler and webhook-manager, then annotate workloads that should respect queue admission before autoscaler signals fire. Good candidate workloads: batch jobs with strict queue quotas where you want to avoid wasted node provisioning.

v1.18.0 adds overflow cluster affinities for hybrid cloud burst scheduling and a scheduling overcommit protection mechanism. Mandatory step: upgrade to v1.17.3+ before applying this release.

• securityAlpine base image updated to 3.23.4

  The base Alpine image moved from 3.23.3 to 3.23.4. No action needed beyond the normal upgrade, but if you pin image digests in your deployment, update them accordingly.

• breakingUpgrade to v1.17.3+ before moving to v1.18.x

  Before upgrading to v1.18.x, you must first be on v1.17.3+. Skipping this step will break the operator upgrade. Check your current version with `karmadactl version` and upgrade to v1.17.3+ first if you are behind.

• breakingDeprecated gRPC fields in scheduler-estimator require plugin updates

  Several deprecated gRPC fields in karmada-scheduler-estimator are now replaced: `resourceRequest` → `resourceRequestBytes`, `nodeAffinity` → `nodeAffinityBytes`, `tolerations` → `tolerationsBytes`. If you have custom estimator plugins or tooling that reads these fields directly, update them before upgrading. The old fields still exist in v1.18 but are deprecated and will be removed in a future release.

• breakingRemoved flags and metric labels will break existing configs

  Two flags removed from karmada-controller-manager: `--cluster-lease-duration` and `--cluster-lease-renew-interval-fraction`. Also, `Etcd.Local.InitImage` is gone from Karmada Init Configuration. If your deployment scripts or Helm values reference these, remove them before upgrading or the components will fail to start. Also check your Prometheus dashboards: the `cluster` and `cluster_name` metric labels are gone, replaced by `member_cluster`.

• enhancementCritical scheduler and eviction bug fixes

  Two significant scheduler bugs are fixed in this release. First, bindings with insufficient cluster replicas were retrying via exponential backoff (1–10s) instead of the correct 5-minute timer queue — workloads may have appeared stuck. Second, a race condition could silently drop graceful eviction tasks when multiple controllers modified the same ResourceBinding concurrently, meaning workloads might not have been evacuated from failing clusters. If you have observed unexplained scheduling delays or failed evictions, upgrade to v1.18.0 and re-examine affected workloads.

• enhancementEnable SchedulingOvercommitProtection in high-throughput clusters

  SchedulingOvercommitProtection (disabled by default via feature gate) closes the window where back-to-back scheduling decisions could over-commit a cluster's capacity before Pods are actually bound to nodes. Enable it in high-throughput environments where you see workloads going Pending due to resource exhaustion shortly after scheduling. Set `--feature-gates=SchedulingOvercommitProtection=true` on karmada-scheduler and karmada-scheduler-estimator once you've validated in staging.

• enhancementOverflow Cluster Affinities for hybrid cloud burst scheduling

  The new `overflowAffinities` field in PropagationPolicy/ClusterPropagationPolicy lets you define fallback cluster groups. The scheduler fills the primary group first, then spills to supplementary groups in order. On scale-down, replicas are reclaimed from supplementary groups first. Useful for IDC-primary / public-cloud-overflow patterns. This is a new API field — existing policies are unaffected unless you add it.

v1.120.3 patches two Go CVEs and ships a wide range of bug fixes across AWS, Azure, Oracle, and DigitalOcean providers, plus OVH support and cosign image signing.

• securityPatch vulnerable Go dependencies — upgrade immediately

  A Go dependency update patches GHSA-xmrv-pmrh-hhx2 and CVE-2026-34986. If you're running any v1.120.x release prior to v1.120.3, upgrade now — these are dependency-level vulnerabilities, not just code changes.

• breakingMCP server is now opt-in — check your config before upgrading

  The MCP server now defaults to disabled (MCP_SERVER_ENABLED=false). If you were relying on it being on by default, set the env var explicitly after upgrading. Check your deployment manifests before rolling out.

• enhancementEnable cosign image verification in your admission pipeline

  Container images are now signed with cosign keyless signing and include SLSA provenance attestations. If your admission policy requires image signature verification, you can now enforce it against OpenCost images. Update your policy tooling (e.g., Kyverno, Cosign verify) to validate these attestations in CI or at deploy time.

Kubescape v4.0.9 is a large maintenance release fixing scan accuracy bugs (partial resource collection, coverage reporting, Prometheus output), hardening data exposure in scan reports, and changing the patch command's default push behavior.

• securityReview secret exposure fixes and new anonymization flag

  Multiple fixes landed for secret/data leakage in scan output: EnvFrom and Env[].ValueFrom are now cleared in removeContainersData (commits acc3280, 0c68cca), an IDOR in /v1/results was hardened (commit 0fe6a0f), and a new --hide/anonymization pipeline was added to scrub resource names, namespaces, labels, annotations, and container metadata from scan reports. If you share or export Kubescape reports outside your team, review the new --hide flag and confirm your CI artifacts aren't exposing secret references from container env vars.

• breakingPatch command no longer pushes images by default

  Kubescape's `kubescape fix` command now defaults to not pushing patched images (commit b10cbb1). If your CI pipelines relied on the old default push behavior, add an explicit `--push` flag or equivalent opt-in, or your patch pipeline will silently stop pushing images after upgrading.

• enhancementAdopt new coverage-gate and diff commands in CI

  New flags let you gate CI pipelines on scan coverage and control results: --fail-coverage-below sets a minimum coverage threshold (commit 4ae7b87), and scan coverage gaps/not-evaluated controls are now reported explicitly (commit 5876d2b). A new `kubescape diff` command compares two scan reports (commit 00682ee). Add --fail-coverage-below to CI gates where partial resource collection could previously pass silently, and use `kubescape diff` to track posture drift between scans.

v1.17.8 fixes two issues: workflows getting permanently stuck when reusing completed instance IDs, and a Sentry OIDC security flaw (CWE-346) that allows discovery document poisoning via X-Forwarded-Host.

• securityFix OIDC discovery document poisoning via X-Forwarded-Host

  Sentry OIDC deployments running without `--jwt-issuer` or `--oidc-allowed-hosts` are vulnerable to CWE-346: an attacker who can send requests with a forged `X-Forwarded-Host` header can poison the discovery document, and HTTP caches may serve the poisoned response for up to an hour. If you can't upgrade immediately, set `--jwt-issuer` (pins the issuer statically, simplest fix) or `--oidc-allowed-hosts`. If you use a reverse proxy that needs to advertise its public hostname via `X-Forwarded-Host`, set `--oidc-allowed-hosts` to your expected hostname — this is now required for that header to take effect.

• breakingUpgrade to fix stuck workflows with reused instance IDs

  Any workflow using deterministic/stable instance IDs is affected. After upgrading sidecars to 1.17.8, stuck workflows recover automatically on the next retention reminder fire — no manual scheduler cleanup needed. Check your `dapr_runtime_workflow_operation_count{operation=purge_workflow,status=failed}` metric; if it's incrementing at ~1/sec per workflow, you're hitting this bug.

v1.14.7 patches a critical azure_imds node attestor vulnerability that allowed forged VM identity during node attestation. Mandatory upgrade for any Azure IMDS users.

• securityUpgrade immediately if using azure_imds node attestor

  The azure_imds node attestor had a certificate validation bug: it anchored the PKCS7 certificate bag's first cert to Azure roots, but verified the signature against a separate signer cert from SignerInfo. An attacker could slip a real Azure cert into the bag alongside content signed by an unrelated cert, getting a forged node attestation accepted. If you use Azure IMDS node attestation, treat this as a mandatory upgrade — an attacker with network access could impersonate arbitrary Azure VMs during node attestation.

• enhancementDependency updates bundled in this release

  golang.org/x/net, golang.org/x/crypto, and go-jose/v4 are all updated alongside Go 1.26.3 toolchain. These dependency updates are routine but include security fixes in the upstream packages. No action needed beyond upgrading SPIRE.

Prometheus 3.12.0 ships two security patches (Remote Write DoS, STACKIT SD secret leak), fixes a WAL race in Agent mode, and cuts TSDB range query CPU with a quadratic-to-constant head chunk lookup fix.

• securityPatch two security fixes now — especially if using STACKIT SD

  Two CVEs patched in this release. First: Remote Write now rejects snappy-compressed payloads where the declared decoded size exceeds 32 MB — this closes a DoS vector against your remote-write receiver endpoint. Second: STACKIT SD was leaking secrets in plaintext via the `/-/config` endpoint (GHSA-39j6-789q-qxvh). If you use STACKIT SD, rotate any credentials that may have been exposed before upgrading.

• breakingAgent mode WAL race and remote_write panic bug fixed — upgrade Agent deployments

  A race condition in the agent appender could produce duplicate in-memory series and duplicate WAL records when concurrent appends target the same label set. If you run Prometheus in Agent mode under high write concurrency, this bug could silently corrupt your WAL. Upgrade to 3.12.0 to fix it. Also, `remote_write` queue_config fields are now validated at load time — misconfigurations that previously caused silent runtime panics will now fail at startup, which is the right behavior but means you should test configs before rolling out.

• enhancementTSDB range query CPU cut and auto-reload-config is now stable

  TSDB head chunk lookup in range queries drops from quadratic to constant time, and mmap operations now skip series that don't need work. At production scale with large head chunks, this can meaningfully cut CPU. No config changes needed — just upgrade. Separately, `auto-reload-config` is now stable (no longer experimental), so you can drop any caveats around it in runbooks.

Argo CD v3.3.11 is a routine patch release on the 3.3 branch, bundling six bug fixes and one dependency security update (CVE-2026-41240).

• securityPatch dompurify CVE in Argo CD UI

  This patch bumps redoc/dompurify to v3.4.0 in the UI to fix CVE-2026-41240. If you run the Argo CD UI, upgrade to v3.3.11 to close this XSS-related dependency vulnerability.

• enhancementFixes for controller startup race and nil pointer crash

  A race condition could raise an InvalidSpecError during application controller startup, and a nil pointer dereference existed in removeWebookMutation() from gitops-engine. Both are fixed here; upgrade if you've seen spurious spec errors or controller crashes on startup.

Argo CD 3.4.3 is a patch release fixing a UI XSS CVE (CVE-2026-41240 via dompurify), a controller startup race, a webhook nil-pointer crash, and several CLI/UI bugs.

• securityPatch CVE-2026-41240 in the UI (dompurify bump)

  dompurify was bumped to v3.4.0 to fix CVE-2026-41240. If you're running Argo CD 3.4.x with the web UI exposed — especially to less-trusted users — upgrade to 3.4.3 promptly. Check whether your current version is behind 3.4.3 and roll it out during your next maintenance window or sooner if the UI is internet-facing.

• enhancementFix startup race condition and nil-pointer crash in webhook mutation

  A race condition in application controller startup could trigger InvalidSpecError incorrectly, and a nil pointer dereference in removeWebhookMutation() could cause crashes. Both are fixed here. If you've seen spurious errors at controller startup or webhook-related panics, 3.4.3 addresses them directly.

• enhancement'app wait' no longer hangs when app is already synced

  'app wait' now returns immediately when the app is already in the desired state, instead of blocking. If you use 'app wait' in CI/CD pipelines or scripts as a sync gate, this means faster pipeline runs when apps are already healthy — no code changes needed, just upgrade.

Rook v1.19.6 is a targeted patch release addressing OSD device class handling, Prometheus metric labeling, and a network-layer dependency vulnerability. Mainly operational refinements for Ceph clusters already in production.

• securityPatch golang.org/x/net vulnerability

  Rook v1.19.6 bumps golang.org/x/net twice (to fix govulncheck CI failures and address GO-2026-5026). If you run Rook in high-traffic environments or handle untrusted network input, review the golang.org/x/net advisory for the specific vulnerability. Upgrade to 1.19.6 to inherit the patched dependency, but do not delay if your Rook instance exposes networking logic to untrusted sources.

• enhancementOSD device class detection fixed in raw-mode

  OSD device class handling now works correctly in raw-mode prepare and reconcile operations (#17407). If you use device classes to segregate fast (NVMe) from slow (HDD) storage, verify after upgrading that your OSD topology reflects the correct device classes. Check `ceph osd crush tree` and OSD weight distribution to ensure placement rules work as intended.

• enhancementCluster label added to Prometheus metrics

  Prometheus scrape metrics now include a `cluster` label from upstream Ceph rules (#17544). If you aggregate Rook metrics across multiple Ceph clusters, this label addition improves metric cardinality and avoids collisions. Update any Prometheus rules, dashboards, or alerts that rely on the old label set; test in non-production first to catch any PromQL query breaks.

A pure security patch release: 50+ Linux kernel CVEs patched via a jump to kernel 6.12.91, plus updated CA certificates. No feature changes.

• securitySchedule node reboots promptly — 50+ kernel CVEs patched

  This release patches a large batch of kernel CVEs, including several from 2025 and some tagged 2026 (likely pre-publication assignments). The sheer volume suggests broad attack surface coverage across networking and driver subsystems. Flatcar uses automatic updates by default, but if you've disabled auto-reboot or use a maintenance window controller like FLUO or Kured, verify that nodes are cycling through the update. Clusters where nodes haven't rebooted recently are carrying all of these exposures.

• securityCA certificate bundle updated to NSS 3.124 — verify custom PKI setups

  The ca-certificates update to NSS 3.124 may add or distrust specific root CAs. If your workloads pin to system trust stores or you've layered custom CA bundles on top of the system bundle, test after the node update to confirm TLS handshakes still succeed. This is low-risk for standard setups but can quietly break internal services that rely on specific intermediates.

• enhancementConfirm your update group is tracking stable, not pinned to a fixed version

  With patch-only releases like this, the fastest path to safety is having nodes enrolled in the stable channel with automatic updates enabled. If you pinned a specific image version for consistency, this is a good moment to re-evaluate — security-only patch releases are exactly the scenario the auto-update mechanism is designed for. Check your Container Linux Config or Butane spec to ensure the update strategy isn't set to 'off'.

Flatcar LTS 4081.3.8 is a security-focused update that bundles 12 kernel releases (6.6.128-6.6.141) worth of CVE fixes plus a ca-certificates refresh. No feature or config changes — just patch and move on.

• securityUpgrade from 4081.3.7 without delay

  This release rolls up 12 kernel point releases (6.6.128 through 6.6.141) covering several hundred CVEs, mostly memory-safety and use-after-free fixes across drivers, filesystems, and networking subsystems. If you're running LTS 4081.3.7 or earlier, treat this as a mandatory upgrade rather than routine maintenance given the sheer volume of kernel-level fixes since the last release.

• enhancementCheck TLS trust store assumptions after ca-certificates bump

  ca-certificates moved to NSS 3.124 (including 3.123.1). If you pin certificate bundle versions or vendor your own trust store on top of Flatcar, verify your TLS validation still works as expected after the update, since NSS releases occasionally drop or distrust certain root CAs.

Falco 0.44.0 drops three long-deprecated features (gRPC output, gVisor engine, legacy BPF probe) and adds expressive rule engine improvements. Deployments using any of these must migrate before upgrading.

• securityfalco-webui restricted to local access — check external tooling

  The falco-webui Docker service now restricts access to localhost only. If you had it exposed on a broader interface, that changes on upgrade. This is a net positive for most deployments, but verify any tooling or dashboards that reached the webui over the network still work after the upgrade.

• breakingThree features dropped — check your config before upgrading

  Three major removals land in this release: gRPC output/server, gVisor engine, and the legacy BPF probe. If you rely on gRPC-based output consumers, you need an alternative output path (e.g., JSON over HTTP, or a sidecar) before upgrading. gVisor users must switch to a supported engine. Legacy BPF users should move to the modern eBPF probe. Audit your current config for any of these before touching 0.44.0 in production.

• enhancementRicher rule syntax — review custom rules for validation errors

  The rule engine now supports oneof/allof/anyof string comparator modifiers, and rules can use list transformer exceptions. These let you write tighter, more expressive detection rules without duplicating conditions. If you maintain custom rules, review whether these can replace existing workarounds. Also, Falco now validates unknown keys in rules — so rule files with typos or unsupported fields will produce warnings or errors instead of silently being ignored.