リリース

v1.33.4 is a security-critical patch fixing a Lua code injection CVE in Contour's Cookie Rewriting feature — upgrade immediately, and note the hard Envoy 1.35.0 minimum requirement.

• securityPatch CVE-2026-41246 immediately — arbitrary code execution risk in shared Envoy

  Any tenant with RBAC permissions to create or modify HTTPProxy resources could inject arbitrary Lua code through a crafted pathRewrite value. In multi-tenant clusters where Envoy is shared infrastructure, this means a compromised or malicious tenant could steal xDS client credentials or deny service to other tenants. Upgrade Contour to v1.33.4 and ensure Envoy is at 1.35.0 or later before deploying. Audit your RBAC policies to limit HTTPProxy write access to trusted principals as a defense-in-depth measure.

• breakingEnvoy 1.35.0 minimum — verify your Envoy version before upgrading Contour

  This release will not function correctly with Envoy versions older than 1.35.0 due to the new filterContext-based Lua approach. If you manage your own Envoy image or pin versions, upgrade Envoy first. The bundled Envoy in the official manifests is already at v1.35.10, so if you use the standard deployment you're covered — but custom or air-gapped environments need explicit attention here.

• enhancementReview HTTPProxy RBAC regardless of upgrade timing

  Even after patching, the underlying attack surface is broad write access to HTTPProxy resources. Take this as a signal to tighten RBAC: restrict HTTPProxy creation/modification to platform operators rather than application developers where possible. In high-trust multi-tenant environments this kind of privilege separation is the right long-term control.

v1.32.5 is a security patch fixing a Lua code injection vulnerability (CVE-2026-41246) in Contour's Cookie Rewriting feature, plus an Envoy bump to v1.34.14. Upgrade immediately in multi-tenant environments.

• securityPatch CVE-2026-41246 immediately in multi-tenant clusters

  Any cluster where untrusted users or teams have RBAC permissions to create or modify HTTPProxy resources is directly exposed. An attacker crafts a pathRewrite.value that breaks out of the Lua string context, gaining code execution in Envoy — which runs as shared infrastructure. That means credential theft (xDS client certs) or denial of service for every tenant on the same Envoy instance. Upgrade to v1.32.5 now. While you prepare the upgrade, audit who has create/update rights on HTTPProxy and tighten RBAC to the minimum necessary.

• breakingReview existing cookieRewritePolicies after upgrade

  The fix adds escaping to pathRewrite.value inputs. Legitimate values with special characters (backslashes, quotes, etc.) will now be escaped before Lua interpolation, which changes runtime behavior. Test any HTTPProxy resources using cookieRewritePolicies[].pathRewrite.value in a staging environment post-upgrade to confirm cookie rewriting still behaves as expected.

• enhancementEnvoy v1.34.14 is bundled — no separate action needed

  The Envoy bump is included in the Contour image. If you run a managed Envoy deployment alongside Contour, verify your Envoy image is also updated to v1.34.14 to stay consistent with Contour's tested configuration.

Contour v1.31.6 patches a Lua code injection vulnerability (CVE-2026-41246) in Cookie Rewriting that could allow arbitrary code execution in shared Envoy infrastructure.

• securityPatch immediately if you allow untrusted users to create/modify HTTPProxy resources

  CVE-2026-41246 is a privilege escalation path in multi-tenant clusters. Any user with RBAC write access to HTTPProxy objects can inject arbitrary Lua into Envoy — and since Envoy is shared infrastructure, the blast radius extends to other tenants and exposes xDS credentials. Upgrade to v1.31.6 now. If you cannot upgrade immediately, audit existing HTTPProxy objects for suspicious pathRewrite values and tighten RBAC so only trusted principals can write HTTPProxy resources.

• enhancementReview RBAC around HTTPProxy write permissions regardless of upgrade status

  This CVE class — user-controlled values interpolated into code — is a design risk whenever untrusted users can write Kubernetes custom resources that drive proxy configuration. Use this as a prompt to apply least-privilege RBAC on HTTPProxy, HTTPRoute, and similar resources across your clusters. Namespace-scoped RBAC and admission webhooks that validate pathRewrite values are good mitigations to layer on top of the patch.

Crossplane v2.2.1 patches two user-reported bugs — ImageConfig prefix rewrite dependency upgrades and ResourceSelector handling — plus a broad sweep of security dependency updates.

• securityUpgrade to v2.2.1 immediately for dependency security fixes

  This release pulls in security patches for at least 8 upstream libraries including cosign, go-git, go-jose, and cloudflare/circl. These are not cosmetic bumps — go-git had two separate security-tagged updates in this release alone (v5.17.1 and v5.18.0). If you're running v2.2.0, plan the upgrade now. The patch is a drop-in replacement with no breaking changes.

• breakingVerify your ImageConfig prefix rewrite setups after upgrading

  If you use ImageConfig prefix rewrites to redirect package pulls (e.g., to a private registry mirror), your packages may have been silently stuck on stale dependency versions before this fix. After upgrading to v2.2.1, expect Crossplane to reconcile and potentially upgrade dependent packages that were previously frozen. Review installed package versions post-upgrade to confirm the expected state.

• enhancementComposition functions can now use broad ResourceSelectors safely

  Composition functions that need to select all existing resources of a given kind no longer need workarounds. A ResourceSelector with only apiVersion and kind set is now valid. If you patched around this limitation with explicit matchLabels or matchName wildcards, you can simplify those selectors in your function logic.

v2.1.5 patches three behavioral bugs (ImageConfig upgrades, ResourceSelector matching, circuit breaker resets) and pulls in a broad sweep of security dependency updates including Go 1.25.9.

• securityUpgrade to v2.1.5 promptly — this release addresses multiple CVEs in core dependencies

  The dependency list here is long: grpc, go-git (patched twice), go-jose, cloudflare/circl, moby/spdystream, docker/cli, and the OTel OTLP trace exporter all received security updates, plus Go itself was bumped to 1.25.9. Any of these could carry CVEs relevant to your threat model. This isn't a routine chore bump — prioritize this upgrade over staying on v2.1.4.

• breakingCheck for silently stale packages if you use ImageConfig prefix rewrites

  If your environment uses ImageConfig to rewrite registry prefixes, dependent packages may have been silently pinned at outdated versions since the bug was introduced. After upgrading to v2.1.5, verify that your package dependency graph resolves to the expected versions — stale packages won't auto-upgrade retroactively, so you may need to trigger a reinstall or version bump manually.

• enhancementResourceSelector 'select all of a kind' unlocks cleaner composition function patterns

  If you've been working around the previous rejection of bare apiVersion/kind selectors — adding dummy matchLabels or splitting logic — you can now clean that up. A selector with no match fields is treated as 'give me all resources of this kind,' which is the intuitive behavior. Review your composition functions for any workarounds and simplify them after upgrading.

v2.0.8 fixes two user-reported bugs (ImageConfig prefix rewrite upgrades, ResourceSelector with no match field) and patches multiple security vulnerabilities in upstream dependencies.

• securityUpgrade to v2.0.8 immediately for dependency security patches

  Multiple upstream dependencies received security-tagged fixes in this release — go-git (two separate bumps to v5.17.1 then v5.18.0), go-jose, cloudflare/circl, and others. These aren't just routine bumps; they carry CVE-related fixes. If you're running any v2.0.x release prior to v2.0.8, upgrade now. There are no API changes, so the upgrade path is straightforward.

• breakingAudit packages installed via ImageConfig prefix rewrites for stale dependencies

  If your environment uses ImageConfig prefix rewrites to redirect package pulls (e.g., to a private registry), dependent packages may have been silently stuck on outdated versions since you adopted that configuration. After upgrading to v2.0.8, force a reconciliation and verify that all package dependencies are on their expected versions — don't assume the upgrade alone will catch everything already in a stuck state.

• enhancementUse bare ResourceSelector (apiVersion+kind only) for 'select all' semantics in composition functions

  Previously, omitting matchName and matchLabels from a ResourceSelector caused Crossplane to reject the request outright. That's now fixed — a bare selector correctly means 'all resources of this kind'. If you worked around this limitation by enumerating resources explicitly or adding dummy match conditions, clean up those workarounds after upgrading.

v1.20.6 is a security-focused patch release fixing multiple dependency CVEs and hardening CI workflows against script injection attacks.

• securityUpgrade to v1.20.6 immediately — multiple dependency CVEs patched

  Five separate security dependency updates landed in this release, covering cryptography (circl), git operations (go-git), HTTP/2 streaming (spdystream), and telemetry export (otelhttp). Any Crossplane v1.20.x deployment is exposed until upgraded. This isn't a theoretical risk — go-git had two separate security fixes within this single patch release, which signals active exploitation concern. Run your upgrade now.

• securityCI/CD supply chain hardening — audit your own pipelines

  The Crossplane team mitigated script injection in their release promotion workflow and tightened GitHub Actions job permissions. If you're running Crossplane forks, mirrors, or custom automation that builds on top of Crossplane's CI patterns, audit your own workflows for similar issues: untrusted input in run steps and overly broad GITHUB_TOKEN permissions are the two patterns to check.

• enhancementTrivy scanning dropped from CI — don't let it drop from yours

  Crossplane dropped Trivy from their CI pipeline in this release. This is an internal CI decision, but if your team was relying on Crossplane's upstream scan results as a proxy for your own security posture, that signal is now gone. Make sure you have independent vulnerability scanning on your Crossplane images and provider images in your own pipelines.

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

Kubescape v4.0.5 is a routine maintenance release: Go toolchain update plus dependency bumps. No new features or bug fixes.

• securityUpgrade to pick up Go runtime and dependency CVE fixes

  Go version bumps often patch stdlib vulnerabilities (e.g., net/http, crypto) that affect compiled binaries. If you're running Kubescape as a cluster component or in CI pipelines, pull this update. Check your current version with 'kubescape version' and replace the binary or update your container image tag. Low effort, low risk.

• enhancementPin to this patch version in your automation

  If you're using Kubescape in CI/CD security scanning pipelines, update your pinned version to v4.0.5 to stay current with the dependency graph. This is especially relevant if your org has SCA tooling that flags transitive dependency staleness in scan tooling itself — a common audit finding.

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

v4.0.4 is a dependency maintenance release with security-relevant library bumps across gRPC, go-git, cloudflare/circl, go-jose, and hashicorp/go-getter, plus minor CLI bug fixes.

• securityUpgrade immediately due to security-sensitive dependency updates

  Several updated libraries — hashicorp/go-getter, cloudflare/circl, go-jose, and go-git — have histories of CVEs covering path traversal, cryptographic weaknesses, and JWT attacks. While Kubescape's release notes don't call out specific CVEs, the jump from go-getter 1.7.9 to 1.8.6 and go-git 5.16.5 to 5.17.1 are both large version gaps. If you run Kubescape in CI pipelines or as part of automated scanning, update to v4.0.4 now rather than waiting for a scheduled maintenance window.

• enhancementHelm 3.20.2 and gRPC 1.79.3 bring compatibility improvements

  The Helm SDK bump to 3.20.2 means Kubescape's chart scanning logic stays aligned with current Helm releases. If your clusters use recent Helm chart features, earlier Kubescape versions may have produced incomplete or inaccurate scan results. Rerun chart-level scans after upgrading to confirm coverage.

• enhancementFix for duplicate flags in `scan image` — check any wrapper scripts

  If you have shell scripts or CI configs that pass flags explicitly to `kubescape scan image`, the duplicate-flag bug could have caused unexpected behavior or silent flag ignoring. After upgrading, verify your pipeline invocations still produce expected output.

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

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

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

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

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

Critical security patch fixing ACL bypass via path traversal in service invocation — any deployment using access control policies must upgrade immediately.

• securityUpgrade immediately if you use service invocation ACLs

  This is a real ACL bypass, not a theoretical one. If your Dapr deployment uses access control policies for service invocation and the Dapr API is reachable by untrusted callers — even internal ones — you are vulnerable. The gRPC vector is especially dangerous since it passes method strings raw with no sanitization. Upgrade to v1.15.14 now. There is no workaround short of disabling service invocation or isolating the Dapr API entirely.

• securityAudit who can reach your Dapr API endpoints

  This vulnerability required API access, so the blast radius depends entirely on your network posture. After upgrading, take the opportunity to review which workloads and network paths can reach the Dapr HTTP and gRPC APIs. Sidecar-only access (localhost) is the safest posture — if you're exposing Dapr APIs more broadly, tighten that regardless of this fix.

• breakingVerify your service invocation method paths still route correctly after normalization

  The fix applies path.Clean normalization to all method paths and rejects any containing #, ?, null bytes, or control characters. If any of your services legitimately use encoded slashes (%2F) as path separators in method names — particularly over gRPC where these were previously passed through raw — those calls will now behave differently. Test your service-to-service invocation patterns before rolling this to production.

Argo CD v3.3.7 is a patch release fixing controller performance regressions, OIDC config handling, and several UI/security header issues.

• securitySwagger UI endpoints now have clickjacking protection — upgrade if exposed

  X-Frame-Options and Content-Security-Policy headers were missing from Swagger UI endpoints. If your Argo CD API server is reachable from browsers (even internally), those endpoints were frameable. Upgrade to 3.3.7 to close this. No config change needed post-upgrade.

• breakingOIDC auth may behave differently after upgrade if config was stale

  The fix ensures OIDC config reloads on server restart rather than using a cached/stale version. In practice this is a correctness fix, but if you've been working around stale OIDC behavior with manual pod restarts, verify SSO flows after upgrading to confirm expected behavior.

• enhancementUpgrade if you're seeing excessive reconciliation or controller CPU spikes

  Two separate fixes address controller overhead: the parentUIDToChildren data structure change reduces memory churn on large clusters, and the informer resync fix stops unnecessary app refreshes that inflate API server load. If your controller is burning CPU or you're seeing constant reconcile loops, this patch is worth prioritizing.

v1.17.5 is a security-only patch fixing a path traversal vulnerability that allowed attackers to bypass service invocation ACL policies via encoded URL characters.

• securityUpgrade immediately if you use service invocation ACLs

  Any deployment with access control policies for service invocation is vulnerable. An attacker with Dapr API access (HTTP or gRPC) could reach denied endpoints by encoding the path. gRPC is especially risky since method strings were passed raw. Upgrade to v1.17.5 now — there is no workaround short of removing Dapr API exposure entirely. After upgrading, audit your ACL policies to confirm expected paths are actually being enforced.

• breakingMethod paths with #, ?, null bytes, or control characters are now rejected

  The fix adds strict validation: method paths containing #, ?, null bytes, or control characters are now rejected at the invocation edge. If any of your services use these characters in method paths (uncommon but possible with gRPC), those calls will fail after upgrade. Test your service invocation paths in a staging environment before rolling this to production.

Critical security fix: path traversal and encoded characters in service invocation method paths could bypass ACL policies entirely. Upgrade immediately if you use access control policies.

• securityUpgrade immediately if you use Dapr ACL policies

  Any deployment with service invocation access control policies is vulnerable. An attacker with access to the Dapr HTTP or gRPC API can craft method paths that the ACL permits but route to denied endpoints. The gRPC vector is especially dangerous since no client-side sanitization occurs. Upgrade to v1.16.14 now — there is no viable workaround short of removing Dapr API access entirely. After upgrading, audit your ACL policy rules to confirm they match the normalized path forms (resolved ../ and no encoded separators).

• breakingMethod paths with #, ?, null bytes, or control characters are now rejected

  The fix actively rejects method paths containing fragment (#), query (?), null bytes, or control characters rather than silently normalizing them. If any of your services invoke methods with these characters (unlikely but possible via programmatic gRPC calls), those calls will fail after upgrading. Review your service invocation call sites — especially any that construct method paths dynamically — before rolling this out to production.

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

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

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

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

Argo CD v3.1.14 is a small patch fixing unnecessary app refreshes and a CI lockfile issue, plus a dependency bump for fast-xml-parser.

• securityfast-xml-parser bump closes potential parsing vulnerabilities

  The fast-xml-parser library was bumped three minor versions. These kinds of XML parser updates often address denial-of-service or entity expansion issues. While Argo CD's exposure surface for this library is limited to the UI, staying current here is straightforward — just upgrade and verify UI functionality in your staging environment.

• enhancementUpgrade if informer resync is flooding your refresh queue

  The fix for automatic refreshes triggered by informer resync and status updates is the real reason to pick up this patch. If you've been seeing excessive app refresh activity or high controller CPU load during resync windows, this addresses the root cause. Deploy this patch during your next maintenance window — it's low risk.

Argo CD v3.2.9 is a patch release fixing excessive refresh triggers, a UI rendering bug for OCI revisions, and a CI lockfile issue, plus a dependency bump for fast-xml-parser.

• securityfast-xml-parser bump addresses potential XML parsing issues in the UI

  fast-xml-parser was bumped from 4.5.3 to 4.5.6. While no specific CVE is called out in the release notes, staying current on XML parsing libraries in web UIs is prudent given their attack surface. If your Argo CD UI is exposed to untrusted users or external traffic, this upgrade is worth prioritizing.

• enhancementUpgrade if informer resync noise is causing excessive reconciliation

  The fix for unintended automatic refreshes from informer resync and status updates (#25290) is the most operationally impactful change here. If you've seen high reconciliation rates or unexplained sync activity in busy clusters, this patch directly addresses that. Upgrade to 3.2.9 and monitor your refresh/sync rate metrics post-upgrade.

• enhancementOCI users: revision metadata now renders correctly

  If your team uses OCI-based Helm charts or manifests and noticed the revision metadata panel was always blank, that was a guard clause bug — not a config problem. This release fixes it. No action needed beyond upgrading; the UI should display OCI revision info correctly afterward.

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

v1.33.11 is a targeted patch fixing two networking bugs — apiserver startup failures with MultiCIDRServiceAllocator and kube-proxy nftables breakage on nft 1.1.3 — plus a Go 1.25.9 compiler bump.

• breakingUpgrade now if using MultiCIDRServiceAllocator with large clusters

  If you have MultiCIDRServiceAllocator enabled and a large namespace count, apiserver can fail to start during an upgrade — it was hitting Forbidden errors from admission plugins that weren't ready yet and not retrying. This patch makes that retry happen. If you've been deferring upgrades to 1.33 because of this, you're now unblocked. Check your apiserver logs for 'Forbidden' errors from the IP repair controller as a diagnostic signal.

• breakingkube-proxy nftables mode is broken on nft 1.1.3 — patch immediately

  Systems running nft 1.1.3 (which ships in some recent distro releases) will have silently broken kube-proxy nftables mode. Traffic may appear to work at first but rule updates won't apply correctly. If your nodes run nft 1.1.3, either pin to an older nft version as a workaround or — better — upgrade to this patch release. Run 'nft --version' on your nodes to check.

• enhancementOTel dependency jump to v1.41.0 — validate your observability pipeline

  The OpenTelemetry Go SDK went from v1.33.0 to v1.41.0 in this patch, which is a substantial version range. If you're consuming Kubernetes telemetry data or running sidecars that interact with the OTel SDK, verify compatibility with your collectors and backends after upgrading. No functional changes are documented for Kubernetes itself, but the jump is large enough to warrant a smoke test of your tracing and metrics pipelines in a non-prod environment first.

v1.34.7 is a focused patch release fixing two regressions — audit log latency annotations and nftables kube-proxy compatibility — plus a Go 1.25.9 rebuild.

• breakingAudit log latency data was silently missing — patch if you rely on it

  Any 1.34.x cluster prior to this patch has been dropping the request latency annotation from audit logs whenever a request exceeded 500ms. If your security or compliance tooling parses these annotations for SLO tracking or anomaly detection, your data has gaps. Upgrade to v1.34.7 and consider whether historical audit logs need to be flagged as incomplete for that window.

• breakingnftables kube-proxy is broken on nft 1.1.3 — don't skip this patch

  Clusters running kube-proxy in nftables mode on nodes with nft 1.1.3 (common in newer distros like Fedora 42 or Ubuntu 25.04) have non-functional networking. This isn't a performance issue — it's a hard failure. Either pin nft to an older version as a workaround or upgrade to v1.34.7 immediately. The fix is in the knftables library bump (v0.0.17 → v0.0.21).

• enhancementOTel dependency jump to v1.41.0 — verify your tracing integrations

  The OpenTelemetry Go packages moved from v1.35.0 to v1.41.0, which is a substantial jump. If you have custom instrumentation or sidecars that interact with Kubernetes' OTel spans, test in staging first. The change is backward-compatible in the API but internal behavior around span propagation and metric collection has evolved.

v1.35.4 is a focused patch fixing five real-world bugs: sidecar container restart failure, StatefulSet parallel scaling regression, kube-proxy nftables breakage, and audit log latency annotation errors.

• breakingCheck StatefulSet workloads if you rely on MaxUnavailable rolling behavior

  The MaxUnavailableStatefulSet feature gate is now disabled by default in 1.35.4, reversing behavior introduced earlier in 1.35. If you upgraded to 1.35.x expecting parallel pod management with maxUnavailable, that behavior is gone until the feature stabilizes. Audit your StatefulSet specs: if you set maxUnavailable, it will be silently ignored. Plan accordingly before upgrading, and watch for the gate to re-enable in a future minor.

• breakingSidecar + startupProbe combination was silently broken — upgrade promptly

  Any pod using an initContainer with restartPolicy: Always alongside a startupProbe would silently fail to restart crashed containers after a kubelet restart, showing RestartCount: 0 forever. This affects production workloads relying on sidecars (e.g., service mesh proxies, log shippers). If you've seen pods stuck in this state, upgrading to 1.35.4 and then manually deleting/recreating affected pods is the remediation path.

• enhancementUpgrade kube-proxy if running nft 1.1.3 on nodes

  Systems with nft (nftables) version 1.1.3 were broken in kube-proxy's nftables mode. This is a quiet but hard failure — networking simply doesn't work. If you're on newer distros shipping nft 1.1.3 (some recent Debian/Ubuntu variants), prioritize this patch upgrade for your node components.

Cilium v1.19.3 is a dense bugfix release targeting memory leaks, panics, and networking correctness issues — particularly in DSR mode, WireGuard dual-stack, and IPAM edge cases.

• securityUpdate go-jose dependency (CVE exposure)

  go-jose/go-jose was bumped to v4.1.4 as a security update. While Cilium's direct exposure depends on usage paths, this library is involved in JWT/token handling. If you're running automated audits or supply chain checks, note this dependency version change in your SBOM.

• breakingIPAM corruption risk on dual-stack clusters — upgrade urgently

  A bug in dual-stack cluster-pool IPAM could cause IPv4 PodCIDRs to be freed and reassigned after an operator restart if duplicate IPv6 PodCIDRs existed. This is a data-plane correctness issue that causes silent IP conflicts between nodes. If you run dual-stack with cluster-pool IPAM, upgrade to v1.19.3 before your next operator restart. After upgrading, inspect node CIDRs for any anomalies.

• enhancementMemory leak fixes matter more than they look — plan your upgrade

  Two distinct memory leaks are patched here. One is triggered by incremental policy updates (common in dynamic environments), the other by policy create/delete cycles. In clusters with frequent NetworkPolicy churn — CI namespaces, multi-tenant platforms, or GitOps-driven policy — these leaks can accumulate over hours or days. If your Cilium agents show gradual memory growth, this release likely explains it. Rolling restart after upgrade is sufficient; no config changes needed.

Cilium v1.18.9 is a patch release focused on memory leak fixes, panic prevention, and load balancer correctness — several bugs here could cause real production incidents.

• securitygo-jose dependency patched — update if using Cilium's auth features

  go-jose/go-jose/v4 was updated to v4.1.4 as a security fix. If your Cilium deployment uses mutual auth or any JWT/JOSE-based features, this patch addresses a known vulnerability in that library. Treat this upgrade as a priority if those code paths are active.

• breakingIPAM reassignment risk: upgrade dual-stack clusters promptly

  If you run dual-stack with cluster-pool IPAM, a bug could reassign a node's IPv4 PodCIDR to another node after an operator restart — with an existing duplicate IPv6 PodCIDR in play. This causes IP conflicts and broken pod networking. Upgrade to 1.18.9 before your next operator restart or planned maintenance window.

• enhancementMemory leaks under policy churn are fixed — relevant for dynamic environments

  Two separate memory leak paths were closed: one from incremental policy updates, one from policies being frequently created and deleted. Clusters with high policy churn (CI environments, multi-tenant setups, frequent namespace deployments) were slowly leaking memory. After upgrading, monitor Cilium agent memory baselines — you should see stabilization over hours to days.

v1.17.15 is a bug-fix patch tackling memory leaks, endpoint regeneration hangs, IPAM data corruption, and policy update deadlocks — all of which can cause silent production degradation.

• breakingIPAM corruption risk: upgrade before operator restarts in dual-stack clusters

  If you run dual-stack with cluster-pool IPAM and have any duplicate IPv6 PodCIDR conditions, an operator restart can cause IPv4 PodCIDR reassignment across nodes — effectively giving two nodes the same subnet. This is silent data-plane corruption. Upgrade to v1.17.15 before performing any operator restarts or node scaling operations in affected clusters.

• enhancementAddress memory leak accumulation in policy-heavy environments

  Two separate memory leaks were patched: one from incremental policy updates (slow, hard to detect) and another from policy churn (create/delete cycles). If you use GitOps-driven policy workflows or frequently rotate NetworkPolicies, your agents may be leaking memory right now. After upgrading, watch agent memory trends over 24-48 hours — you should see stabilization compared to a pre-upgrade baseline.

• enhancementEndpoints stuck in waiting-to-regenerate? This release fixes it

  A race condition caused endpoints to get permanently stuck in the 'waiting-to-regenerate' state, meaning policy changes stopped being applied to affected pods without obvious errors. If you've seen endpoints failing to pick up policy updates without a pod restart, upgrade and validate that endpoint regeneration completes cleanly after policy changes using 'cilium endpoint list'.

OpenFeature core/v0.15.4 was released, but the published notes are too brief to summarize. See the original release notes for details.

OpenFeature flagd/v0.15.4 was released, but the published notes are too brief to summarize. See the original release notes for details.

edge-26.4.3 adds per-pod proxy env var injection via annotation, bumps proxy to v2.349.0, and validates Kubernetes 1.35 compatibility across policy tests.

• securityrustls-webpki patch — verify if you vendor Rust dependencies

  rustls-webpki was bumped to 0.103.11. This library is part of Linkerd's mTLS stack. No CVE is listed, but if your organization audits or vendors Rust dependencies, update your lockfiles and re-run your SBOM scans to stay current.

• enhancementUse proxy-additional-env to inject custom env vars without custom images

  The new `proxy-additional-env` annotation lets you set environment variables on injected proxies at the pod or namespace scope. This is useful for tuning proxy behavior (e.g., log levels, feature flags) in specific workloads without modifying global Helm values or building custom proxy images. Start using it on non-critical workloads first to validate behavior before rolling out broadly.

• enhancementPlan for Kubernetes 1.35 if you're on the upgrade path

  Linkerd's test suite now covers k8s 1.35, including policy tests. If your team is evaluating or scheduling a cluster upgrade to 1.35, this edge release gives you reasonable confidence that core Linkerd functionality and policy enforcement will hold. Run your own smoke tests against a 1.35 staging cluster before committing to a production upgrade.

26.6.1 is a security patch release fixing two CVEs — blind SSRF and user enumeration — plus a critical migration bug that broke authentication flows when upgrading from older versions.

• securityPatch immediately for SSRF and user enumeration CVEs

  Two CVEs in 26.6.0 (and earlier) need your attention. CVE-2026-4366 allows blind SSRF through HTTP redirect handling — a real risk if Keycloak can reach internal services. CVE-2026-4633 leaks user existence through identity-first login, which aids credential stuffing. Upgrade to 26.6.1 now. If you can't upgrade immediately, consider disabling identity-first login as a short-term mitigation for CVE-2026-4633.

• breakingIf you upgraded to 26.6.0, check your custom authentication flows immediately

  The MigrateTo26_6_0 migration script had a bug that modified custom browser flows, potentially breaking realm authentication silently. If you upgraded to 26.6.0 and noticed login failures or unexpected flow behavior, this is why. Upgrading to 26.6.1 fixes the migration, but you may need to manually review and repair any already-affected custom flows in your realms. Audit them before upgrading in production.

• breaking26.6.0 JS/Java admin clients were broken — use 26.6.1 packages

  Both @keycloak/keycloak-admin-client (JS) and the Java admin client had packaging issues in 26.6.0 that prevented installation or sync. If your pipelines or applications depend on these libraries and you pinned to 26.6.0, they are likely broken. Update your dependency references to 26.6.1 immediately.

Dapr v1.16.13 fixes a critical scheduler reliability bug affecting multi-replica deployments, patches a silent Pulsar misconfiguration that could cause OOM crashes, and rebuilds with Go 1.25.9 for security fixes.

• securityUpgrade immediately for Go 1.25.9 security patches

  This build patches vulnerabilities in Go's crypto/x509, crypto/tls, archive/tar, and html/template packages. Any Dapr deployment still on 1.16.12 or earlier is exposed. Upgrade to 1.16.13 now — there's no workaround short of rebuilding from source with Go 1.25.9 yourself.

• breakingPulsar users: processMode will now actually take effect — verify your config

  If you have processMode set in your Pulsar component YAML, it was silently ignored before this release. After upgrading, that config will be enforced. If you set processMode: sync expecting ordered processing but were actually running async, behavior changes on upgrade. Review your Pulsar component metadata and subscription behavior before rolling this out to production. Also check maxConcurrentHandlers: if it was set to 0, it previously caused a deadlock; now it falls back to 100.

• breakingMulti-replica scheduler deployments: patch this immediately

  The scheduler bug is severe in practice. A routine pod restart — due to a rolling update, OOM kill, or node eviction — would silently stop all job triggers across your deployment until some unrelated cluster event re-established connections. There's no alerting or visible failure; jobs just stop firing. If you run multiple scheduler replicas (standard HA setup), this fix is critical. Upgrade and verify your scheduled jobs are firing after any scheduler pod restart.

Litmus 3.28.0 is a focused maintenance release fixing a probe config leak, a subscriber crash on workflow events, and a Python vulnerability in the frontend base image.

• securityUpgrade frontend to resolve Python CVE in base image

  The frontend container was running on a ubi8 base image with a Python vulnerability. The fix upgrades it to ubi9. If you run Litmus in environments with strict image scanning policies (e.g., Trivy in CI, ACS, or Prisma), this upgrade will clear those alerts. Pull the 3.28.0 frontend image and redeploy — no config changes needed.

• breakingProbe config leak fix may change behavior for shared-type probe setups

  If you run multiple probes of the same type in a single experiment, previous releases silently shared stale config between them. The fix now isolates config per probe. Audit any experiments where multiple probes of the same type are defined — if you were unknowingly relying on config bleed-over, results may differ after upgrading.

• enhancementSubscriber crash fix improves reliability for GitOps and event-driven workflows

  Teams using Litmus in GitOps mode or triggering experiments via Argo Workflow ADD events with ChaosEngine nodes were hitting silent subscriber crashes. After upgrading to 3.28.0, those workflows should resume without manual subscriber restarts. No action required beyond the upgrade, but verify subscriber pod stability post-deploy if you've been seeing unexplained restarts.

Rook v1.19.4 is a focused patch release fixing CephObjectStoreUser capabilities, adding multi-cluster RBAC fixes, and improving OSD disk handling with forceful zap support.

• breakingMulti-cluster deployments: apply the RBAC fix immediately

  The missing ceph-mgr RBAC role in secondary clusters could cause silent permission failures that are hard to diagnose. If you're running Rook in a multi-cluster setup, upgrade to v1.19.4 and verify ceph-mgr is operating correctly post-upgrade. Don't wait on this one.

• enhancementForceful OSD replacement is now cleaner with disk zap

  The new disk zap behavior during forceful OSD installation removes the manual cleanup step that previously caused headaches when replacing failed OSDs. If you've been scripting around this limitation, review your runbooks — the operator now handles it directly.

• enhancementAdd labels to RGW services for better traffic routing

  CephObjectStore RGW services now accept custom labels, which opens up more precise service mesh, load balancer, and network policy targeting. Worth adopting if you're running multiple object stores or need finer-grained traffic control.