Releases

Cilium v1.19.5 is a bugfix-heavy patch release addressing policy enforcement bugs, Gateway API panics, and load-balancer correctness issues. No CVEs, but several fixes warrant attention before upgrading.

• breakingMigrate away from `l2podAnnouncements.interface` Helm value before upgrading

  The `l2podAnnouncements.interface` Helm key was removed because it wrote a configmap entry the agent no longer reads, causing crash-loops when L2 pod announcements are enabled. Before upgrading, check your Helm values for this key and replace it with `l2podAnnouncements.interfacePattern`. Clusters using the old key will fail to start after the upgrade.

• breakingCheck CiliumEgressGatewayPolicy if you use NamespaceSelector

  A bug caused the NamespaceSelector field in CiliumEgressGatewayPolicy to be silently corrupted, making those rules ineffective. After upgrading to 1.19.5, verify that egress policies with NamespaceSelector are actually being enforced — traffic that was previously leaking may now be blocked.

• enhancementVerify ipBlock network policies if you rely on selectorless rules

  A bypass was fixed where wildcard namespace selectors could skip ipBlock rules without a pod selector. If you have CiliumNetworkPolicies using ipBlock without explicit namespace selectors, review them post-upgrade to confirm enforcement behavior matches your intent — the fix may change observed traffic patterns.

Cilium 1.18.11 is a patch release focused on stability, fixing memory leaks, socket handling crashes, and Gateway API routing bugs. No breaking changes; safe to adopt for teams running 1.18.x in production.

• securityApply patch if you see agent crashes in socket handling

  Cilium 1.18.11 fixes a nil pointer dereference in filterAndDestroySockets that could crash the agent. If you have seen sudden agent pod restarts or panic logs mentioning socket filtering, upgrade promptly. This is a stability issue that affects 1.18.10 and earlier.

• breakingVerify MTU settings on non-Cilium interfaces after upgrade

  1.18.11 changes MTU handling to skip interfaces not managed by Cilium. If your infrastructure depends on Cilium adjusting MTU on external interfaces (e.g., host-managed veth pairs), test this upgrade in a staging environment first. Mark interfaces with altname to ensure they are recognized as Cilium-owned; otherwise, MTU will not be modified.

• enhancementAdopt if running Kubernetes Gateway API with TLS routes

  This patch fixes two distinct bugs in Gateway API support: weighted backend routing for TLSRoute passthrough and mixed listener handling. If you use Gateway API with TLS termination or passthrough, this upgrade eliminates silent routing failures. No configuration changes needed; test existing Gateway API resources in a staging cluster first.

Cilium v1.17.17 is a patch release fixing CiliumNode retry logic in multipool, improving troubleshoot command output, and updating dependencies. Primarily maintenance-focused with no breaking changes.

• enhancementTest multipool deployments after upgrade

  Cilium v1.17.17 fixes a retry mechanism for CiliumNode lookups that was causing intermittent failures in multipool setups. If you run multi-pool IP allocation (multiple resource pools per cluster), test pod scheduling and IP assignment post-upgrade to confirm the fix resolves any flapping you observed.

• enhancementUse enhanced troubleshoot output for cluster diagnosis

  The troubleshoot kvstore and clustermesh commands now report more diagnostic details. When investigating kvstore or clustermesh connectivity issues, re-run these commands after upgrading—the richer output will likely surface root causes faster than before.

• enhancementCheck Envoy proxy behavior after updating to v1.37.x

  The bundled Envoy proxy jumps to v1.37.x in this patch. Review Envoy release notes for v1.37.x for any behavioral changes in HTTP/2, load balancing, or observability that might affect your traffic patterns. No action required unless you rely on specific Envoy 1.36.x behavior.

Flatcar stable-4593.2.3 ships Linux 6.12.93 with eight kernel CVE patches and adds NVMe/TCP support for NVMe-oF storage backends.

• securityPatch eight kernel CVEs — update nodes now

  This release fixes eight Linux kernel CVEs. Details on severity are not yet in NVD for these 2026-prefixed IDs, but any kernel CVE batch warrants prompt node rotation. If you run Flatcar on bare metal or cloud VMs, schedule a node drain-and-replace cycle soon — do not wait for the next maintenance window if these IDs affect your kernel subsystems.

• enhancementNVMe/TCP opens up NVMe-oF storage backends

  NVMe over Fabrics via TCP is now available in the kernel module set. If your storage team uses NVMe-oF targets (e.g., disaggregated storage arrays or SPDK-based backends), Flatcar nodes can now connect without a custom kernel build. Test in staging before relying on this in production — confirm the nvme-tcp module loads correctly on your target image.

Dapr v1.18.1 is a focused bug-fix release for the workflow engine, patching five issues including reminder leaks, permanent sidecar unavailability after config reload, and stuck workflows.

• breakingHelm users: workflow concurrency limits were silently ignored before this release

  If you set globalMaxConcurrentWorkflowInvocations, globalMaxConcurrentActivityInvocations, or the per-name limit fields on a Configuration resource and installed via Helm, those limits were never enforced. After upgrading to 1.18.1 the CRD schema is correct and limits will actually take effect. Review your configured values before upgrading in production — limits that were previously ignored will now be applied, which could throttle throughput if the values are too conservative.

• enhancementUpgrade if you run agentic or long-running loop workflows

  Three bugs in this release specifically affect workflows that loop via ContinueAsNew or repeatedly await the same external event name — patterns common in agentic workloads. The reminder leak accumulates garbage reminders over a workflow's lifetime; the ContinueAsNew deadlock causes indefinite hangs with no timeout or error. Both are fixed here. If you see workflows stuck in RUNNING or observe spurious wake-ups in loop workflows, upgrade to 1.18.1.

• enhancementConfig hot-reload now works reliably for workflow sidecars

  Before this fix, any SIGHUP-triggered config reload on a sidecar hosting workflow workers could permanently break the sidecar — port 50001 stops accepting connections and the only recovery was a pod restart. This is now fixed. If your team uses config hot-reload in any workflow-hosting deployment, 1.18.1 should be treated as a required upgrade.

Linkerd edge-26.6.2 patches policy and profile validation bugs, tightens namespace restrictions on external workloads, and upgrades to Envoy proxy v2.357.0 with unified failure accrual tuning.

• securityProfile validation now rejects nil configs

  The nil check in profile validation closes a path to crashes on malformed configs. No immediate action needed, but if your automation generates profiles programmatically, ensure they always have valid structure before applying them.

• breakingNamespace-restricted external workloads may affect routing

  External workloads and endpoints now honor namespace boundaries. If you cross namespaces with external workloads in your Linkerd setup, verify routing still works after upgrade. Update any policies that rely on previous (unrestricted) cross-namespace access.

• enhancementTune load balancing with unified failure accrual

  Unified failure accrual and response-penalty load biasing gives you finer control over how proxies handle slow or failing endpoints. Test this in a canary namespace first—adjust failure thresholds and penalty weights to match your SLOs. Check Linkerd docs for new policy knobs.

Dapr 1.17.10 fixes a bug where resiliency retry policies with `matching` rules on pubsub publish operations were silently ignored, causing terminal errors to be retried unnecessarily. Teams using pubsub with resiliency retry configuration should upgrade to enforce intended retry behavior.

• breakingRetry behavior change for pubsub publish errors

  If you have resiliency policies with `matching` rules targeting pubsub outbound retry, publish errors will now be classified correctly and non-retriable errors will stop retrying immediately instead of exhausting maxRetries. Verify your resiliency configuration expectations: terminal errors (e.g., 401 Unauthorized, 404 Not Found) will no longer consume retry attempts. If your application relied on the old behavior of always retrying publish, adjust your retry policy or remove the `matching` constraint.

• enhancementEnforce resiliency policy intent for pubsub

  Upgrade to 1.17.10 if you've configured resiliency policies with explicit `matching` codes for pubsub publish — your configuration will now work as intended. This brings pubsub publish in line with service invocation, output bindings, and other operations that already respect retry `matching`. No code changes needed; the fix is transparent.

Dapr 1.16.16 fixes two downgrade-specific bugs: Sentry certificate signing failures after a 1.18→1.16 rollback, and Helm StatefulSet storage conflicts when downgrading from 1.17/1.18.

• breakingFollow specific Helm flags when downgrading to 1.16.16

  Use --reset-values and explicitly pass the original install values. Do NOT use --reuse-values — it carries over 1.17/1.18 chart defaults that are invalid in 1.16, including placement disseminateTimeout=8s (1.16 only accepts 1s–3s), which will cause placement to fail at startup. If you skipped deleting the scheduler StatefulSet before downgrading, you may still need to pass --set dapr_scheduler.cluster.storageSize=<current size> or delete the StatefulSet with --cascade=orphan.

• breakingClusters downgraded from 1.18 to 1.16 need this patch to fix Sentry

  If you rolled back from Dapr 1.18 to any earlier 1.16.x release, Sentry is likely crashing on startup due to the Ed25519/ECDSA key type mismatch in the trust bundle. Upgrade to 1.16.16 to resolve it — no manual certificate rotation is required after upgrading.

KServe v0.19.0 is a large release focused heavily on LLMInferenceService (LLMISvc) maturity: better observability, autoscaling, routing, and a migration path for llm-d v0.6 upgrades. Two CVEs are patched.

• securityPatch two CVEs before upgrading or apply independently

  v0.19.0 patches a vLLM/Pillow CVE and pins azure-core>=1.38.0 for CVE-2026-21226. If you are running KServe with vLLM runtimes or azure-core dependencies, upgrade to v0.19.0 or manually apply the azure-core pin to your environment. Check your current Pillow version in custom server images as well.

• breakingRouter splitter off-by-one fix changes traffic split behavior

  The pickupRoute random range had an off-by-one error. After upgrading, traffic percentages in InferenceService splitter configurations will be computed correctly, which means observed traffic distribution will shift if your weights were tuned around the buggy behavior. Verify split configurations in staging before rolling to production.

• enhancementLLMISvc autoscaling and status visibility are now production-ready

  HPA/KEDA scaling conditions are now visible in LLMISvc status, and readiness transitions emit k8s events. If you are operating LLMInferenceService, add these conditions to your monitoring dashboards and alerting. The --scaling flag in kserve-install.sh simplifies enabling autoscaling during fresh installs.

Helm v4.2.1 fixes data races in concurrent operations, corrects output routing for command messages, and resolves version constraint parsing issues that caused false negatives.

• breakingVerify output parsing in automation after upgrade

  Helm command success messages now correctly write to stdout instead of stderr. If your CI/CD pipelines, monitoring, or shell scripts redirect or filter Helm output by stream, they may behave unexpectedly. Check any grep, tee, or output capture logic that assumes helm writes to stderr. Most scripts should work unchanged, but streaming-dependent logic needs review.

• enhancementUse version range constraints without workarounds

  Helm 4 previously rejected or warned about valid version range constraints like prerelease versions and missing spaces (e.g., 'v1.0.0||v1.1.0'). This is now fixed. If you've avoided version ranges or used pinned versions as a workaround, you can now adopt constraint-based version selection, which simplifies dependency management in large deployments.

• enhancementUpgrade to get concurrent operation stability

  Multiple race conditions in concurrent goroutines (upgrade + rollback, install + uninstall on the same client, and WaitForDelete timing) are now fixed. Teams running high-concurrency Helm operations (e.g., multi-chart deployments, parallel reconciliation loops, or large test suites) should upgrade to eliminate intermittent failures. This is particularly important if you see flaky test results in your CI pipeline.

Helm v3.21.1 fixes a nil pointer panic in template operations and updates dependencies. A straightforward patch for stability.

• securityUpgrade for Go security patch GO-2026-5026

  golang.org/x/net was bumped to v0.55.0 to fix GO-2026-5026. This is a supply-chain dependency, not directly exposed in Helm's API. Upgrade if your security scanning flags net vulnerabilities. No action needed if you're just using Helm normally—the fix is built in.

• breakingClientOnly template operations now error correctly instead of panicking

  Helm template commands executed without cluster access (ClientOnly mode) previously crashed with nil pointer panics. v3.21.1 returns proper template errors instead. If you have automation that catches panics, update error handling to expect typed template errors. Test your template workflows before production rollout.

• enhancementRegistry credentials now persist through HTTP fallback

  Registry operations now keep credentials when falling back from HTTPS to plain HTTP, thanks to oras-go v2.6.1. If you use private registries with HTTP-only endpoints, this improves reliability. No configuration change needed; the fix is automatic.

Kubernetes v1.36.2 is a patch release fixing critical bugs in Dynamic Resource Allocation (DRA) scheduler, CSI volume republishing, and endpoint controller, plus a Go 1.26.4 build update.

• securityBinary non-UTF8 Secret data in container env vars now handled correctly

  Kubernetes 1.34+ had a regression where containers could not properly read environment variables set from Secret API objects containing binary non-UTF8 data. This is fixed in 1.36.2. If your workloads use non-text Secret data in environment variables, upgrade to prevent decode errors or silent failures.

• breakingDRA device allocation bug affects multi-device workloads

  Kubernetes 1.36.0–1.36.1 has a scheduler bug that assigns mutually exclusive device partitions to multiple Pods when drivers use SharedCounters with multi-allocatable devices. This can cause workload failures, device conflicts, crashes, or data loss. If you use DRA with multi-allocatable devices (especially GPUs or custom accelerators with shared counters), upgrade to 1.36.2 immediately. Review recent Pod scheduling decisions for conflicts.

• enhancementCSI volume republish failures no longer corrupt mount state

  Kubelet was incorrectly deleting CSI mount directories when periodic NodePublishVolume calls (triggered by requiresRepublish=true) failed, leaving pods with stale volume content. This is fixed in 1.36.2. If you run CSI drivers with requiresRepublish=true, this patch eliminates a data consistency risk—upgrade to prevent potential data issues on transient network or storage errors.

Kubernetes v1.35.6 fixes critical issues in pod scheduling with multi-node claims, DRA device selection, CSI volume republishing, and endpoint handling; includes a Go runtime upgrade and performance improvements.

• securitySecret binary data in environment variables now handled correctly

  A 1.34+ regression broke environment variable injection from Secrets containing non-UTF8 binary data (e.g., certificates, keys in base64-encoded Secrets). If you inject Secrets as env vars and those Secrets contain binary data, upgrade to v1.35.6. Test this quickly if you run database credentials or keys via Secrets—the bug may have silently broken injection.

• breakingUpgrade Go runtime to 1.25.11 in your build pipeline

  Kubernetes v1.35.6 is built with Go 1.25.11. If you run custom controllers or operators on the same Go version, verify compatibility and rebuild. If your CI/CD locks Go versions, update your build configuration. This is standard but must be done; old Go versions may have security gaps you're inheriting.

• enhancementDRA scheduling and CSI republishing now reliable for dynamic resource allocation

  Three bugs are fixed: (1) scheduler no longer panics on DRA ResourceClaim with AllocationMode All and shared counters; (2) pods using multi-node and per-node claims no longer deadlock in Pending; (3) kubelet no longer deletes CSI mount directories on transient NodePublishVolume errors, preventing stale volume data. If you use DRA (dynamic resource allocation) or CSI with republish enabled, this release eliminates previously deadlocking scenarios. Upgrade to clear stuck pods and prevent future hangs.

Kubernetes v1.34.9 fixes volume handling in CSI mounts, binary secret data in containers, endpoint controller panics, and kubeadm certificate handling. Go 1.25.11 build improves runtime performance.

• breakingUpgrade kubelet if running CSI drivers with requiresRepublish enabled

  A 1.34+ regression caused kubelet to delete CSI mount directories on republish failures, stranding pods with stale volume data. If you run CSI drivers with spec.requiresRepublish=true, upgrade immediately. Check your CSI driver specs and watch for failed republish attempts in kubelet logs before upgrading to confirm you hit this bug.

• breakingTest binary Secret injection in container environment variables

  v1.34 broke environment variable parsing for containers referencing Secrets with binary (non-UTF8) data. If your workloads inject Secret data into environment variables, test them after upgrading. Check application startup logs for parsing errors; you may need to base64-encode binary Secret values instead.

• enhancementUpdate Go runtime for performance and security

  v1.34.9 uses Go 1.25.11, which includes runtime optimizations and security patches. Upgrade when you next rotate your control plane and worker nodes. No code changes needed on your side, but the Go update may improve latency and reduce memory usage in your cluster.

Kubernetes v1.33.13 was released, but the published notes are too brief to summarize. See the original release notes for details.

Dapr 1.16.15 fixes a sentry crash that blocks all mTLS identity issuance when the issuer key is Ed25519 or RSA — directly relevant to anyone who downgraded from 1.18 or rotated their issuer key type.

• breakingUpgrade to 1.16.15 if you downgraded from 1.18 or rotated your issuer key

  If your 1.16 control plane has an Ed25519 or RSA issuer key in the dapr-trust-bundle secret — which happens automatically after a 1.18 downgrade — dapr-sentry crash-loops and no new mTLS certificates are issued. Existing sidecars with unexpired certs keep working, but any pod restart or cert expiry will cause identity failures. Upgrade to 1.16.15 immediately. If you cannot upgrade right now, the only workaround is to replace the issuer key in dapr-trust-bundle with an ECDSA P-256 key.

Falco 0.44.1 adds BPF iterator control and fixes multiple BPF-related issues via a libs bump. Minimal release focused on stability for deployments using kernel-level tracing.

• breakingUpdate libs and kernel driver together

  This release bumps libs to 0.25.4 and driver to 10.2.0+driver. If you pin kernel driver versions separately from Falco, ensure you update both in the same maintenance window. Mismatched versions can cause syscall capture failures or silent data loss.

• enhancementControl BPF iterator behavior if you hit performance or compatibility issues

  Falco 0.44.1 introduces a config option to disable BPF iterators. If you run Falco on kernels with problematic BPF iterator implementations or see high CPU usage tied to iterator overhead, test disabling them. Check your Falco logs and metrics after upgrading to confirm the fix resolves any BPF-related instability you were seeing in 0.44.0.

Envoy v1.38.2 is a small patch release: one RTDS runtime bug fix and two opt-in HTTP/2 cookie observability features. No security fixes.

• breakingRTDS runtime guard fix changes delete behavior — verify your override logic

  If your config management deletes RTDS runtime guard overrides expecting them to revert to default, prior behavior was broken and left stale values. After upgrading to v1.38.2, deletes will now correctly restore defaults. Test any automation that removes runtime overrides to confirm it behaves as intended.

• enhancementUse new HTTP/2 cookie size limit to guard against oversized headers

  The new envoy.reloadable_features.http2_max_cookies_size_in_kb flag lets you cap the reassembled cookie header size in HTTP/2. If your deployment handles untrusted upstream or downstream traffic with large cookie headers, set an explicit limit to reduce memory pressure. The default is unlimited, so this is opt-in.

Envoy v1.37.4 is a small patch with one RTDS bug fix and two opt-in HTTP/2 cookie-related observability/safety features. No security CVEs.

• breakingRTDS override deletion behavior changed — verify runtime guard state

  If your deployments rely on RTDS to manage runtime guard overrides, the old behavior left stale override values after deletion. The fix now restores the process-wide default. Check that your expected default values are actually what you want after an override is removed, especially if you were working around the old broken behavior.

• enhancementUse the new cookie size limit to protect against oversized cookie headers

  HTTP/2 reassembled cookie headers had no size cap before this release. If you proxy untrusted HTTP/2 clients, set envoy.reloadable_features.http2_max_cookies_size_in_kb to a reasonable limit (e.g., 32–64 KB) to prevent unexpectedly large cookie payloads from reaching upstreams. The default remains unlimited, so this requires an explicit opt-in.

• enhancementEnable HTTP/2 header histograms in staging to baseline your traffic

  The new envoy.reloadable_features.http2_record_histograms flag adds histograms for header count, map byte size, and cookie metrics. These are useful for understanding HTTP/2 header pressure in your fleet. Enable in a non-production environment first — note these metrics will be removed in a future Envoy release, so don't build long-term dashboards around them.

Envoy v1.36.8 is a minor patch with one bug fix and two opt-in HTTP/2 observability features. No breaking changes or CVEs.

• breakingHTTP/2 header histograms are temporary — don't build dashboards on them

  The new http2_record_histograms feature and its runtime guard are explicitly scheduled for removal in a future Envoy release. If you enable them for debugging HTTP/2 header issues, treat the resulting metrics as short-lived. Don't wire them into permanent dashboards or alerts that would break on upgrade.

• enhancementEnable HTTP/2 header histograms if you're debugging large header or cookie payloads

  If you're seeing unexpectedly large HTTP/2 requests or cookie-related issues, flip envoy.reloadable_features.http2_record_histograms to get histograms on header entry count, byte size, and cookie metrics. Pair this with envoy.reloadable_features.http2_max_cookies_size_in_kb to enforce a hard cap on reassembled cookie header size — useful if you need to protect upstream services from oversized cookie headers.

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.

Envoy v1.35.12 is a minor patch with one runtime bug fix and two opt-in HTTP/2 cookie/header observability features. No breaking changes or CVEs.

• breakingRTDS override deletion behavior changed — verify runtime guard defaults

  If you rely on RTDS to manage runtime guard overrides, test this fix in staging. Previously, deleting an override left the old value active; now it resets to the process default. Any automation that deleted overrides expecting them to persist will behave differently.

• enhancementUse the new HTTP/2 cookie size limit to guard against oversized cookie headers

  The new envoy.reloadable_features.http2_max_cookies_size_in_kb flag is off by default. If your deployments accept untrusted HTTP/2 traffic, consider setting a reasonable limit to bound memory usage from reassembled cookie headers. Pair it with the new histograms to first measure your actual cookie sizes before choosing a cap.

Backstage v1.51.2 was released, but the published notes are too brief to summarize. See the original release notes for details.

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.

Crossplane v2.3.2 was released, but the published notes are too brief to summarize. See the original release notes for details.

NATS v2.12.11 is a single-fix patch release targeting a JetStream regression in v2.12.7 that caused stale subject state tracking and 'Message Not Found' errors on streams with per-subject message limits.

• breakingUpgrade if you use max-messages-per-subject on any stream

  If you run NATS 2.12.7–2.12.10 and have streams configured with MaxMsgsPerSubject (max_msgs_per_subject), you are exposed to silent stale-state bugs that surface as 'Message Not Found' errors. These errors can cause consumers to miss messages or behave unpredictably. Upgrade to 2.12.11 immediately. If you are already on 2.14.x, you are not affected and no action is needed.

CoreDNS v1.14.4 delivers a broad set of targeted fixes and new capabilities: DNSSEC signing correctness fix, cache behavior improvements, forward plugin now resolves hostnames, and several transport security hardening items.

• breakingDNSSEC signing behavior changed — review delegated zone setups

  The fix to sign each RRset with its owning zone rather than the query zone is technically correct, but if you have multi-zone DNSSEC setups with delegations, validate your signed responses after upgrading. Zones that were relying on the previous (incorrect) signing behavior may produce different signatures. Run dnssec-verify on a sample of records before cutting over in production.

• enhancementUse hostname-based forward targets instead of hard-coded IPs

  The forward plugin now resolves hostnames for TO endpoints at runtime. If your CoreDNS configs currently pin upstream resolver IPs, you can switch to FQDNs and let CoreDNS handle resolution. This simplifies config management in environments where upstream IPs change (e.g., cloud-managed resolvers). Test in staging first — resolution failures at startup could affect forwarding.

• enhancementRemove the 3600s cache TTL ceiling if longer TTLs are appropriate

  Cache TTLs were previously capped at 3600s regardless of the DNS record's actual TTL. That cap is gone. For stable records (root hints, internal authoritative zones) you can now set higher max_ttl values to reduce upstream query load. Audit your cache plugin config and raise max_ttl where it makes sense.

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.

gRPC v1.81.1 is a patch release fixing memory safety bugs on Windows and ARM, plus Python/Ruby housekeeping. No API-breaking changes.

• breakingPython 3.9 and Ruby 3.1 are no longer supported

  If your services run gRPC Python on 3.9 or Ruby on 3.1, upgrading to v1.81.1 will break your build. Check your runtime versions before upgrading. Python 3.10+ and Ruby 3.2+ are the minimum now.

• enhancementUpgrade Windows/ARM deployments to get memory safety fixes

  Two Windows EventEngine races and an ARM completion queue shutdown race are fixed. If you run gRPC servers on Windows or ARM-based hosts (e.g., Graviton), this patch is worth applying — use-after-free and assertion crashes are hard to reproduce but can cause random service failures.

• enhancementprotobuf 7.x now allowed for gRPC Python

  The grpc-status package previously capped protobuf at <6.x. With the upper bound relaxed to 7.x, you can now unpin protobuf in Python services that use grpc-status alongside other libraries requiring newer protobuf versions.

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.

Mostly a dependency maintenance release with two proxy bumps (v2.355.0, v2.356.0) and a fix for ReadAllLimit byte boundary handling.

• enhancementTwo proxy versions in one release — check proxy changelogs separately

  This edge release packages proxy v2.355.0 and v2.356.0 together, meaning two rounds of proxy changes landed at once. If you track proxy behavior closely (traffic policy, retries, protocol detection), pull the proxy-specific changelogs before rolling this out to staging. The combined nature makes it harder to bisect if you hit regressions.

• enhancementReadAllLimit fix may affect request body handling edge cases

  The ReadAllLimit fix allows inputs that hit the exact byte boundary to pass through correctly. If you have services where request bodies are crafted to exactly match a configured limit — common in API gateways or body-size validation scenarios — this corrects previously incorrect rejection behavior. No config changes needed, but worth validating if you saw unexpected 413-style rejections.

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.