リリース

v1.51.0 lands six breaking changes alongside major catalog performance wins, a new AiResource entity kind, and MCP/OIDC hardening. Plan migration time before upgrading.

• breakingRun catalog DB migration SQL before deploying to large installs

  The new catalog migration adds covering indices and a UNIQUE constraint on the search table, which can be slow on large datasets. The release notes explicitly recommend running the provided SQL commands manually before deploying v1.51.0. Skipping this turns a controlled maintenance window into an uncontrolled deployment stall. Check the changelog for the exact SQL before you upgrade.

• breakingAudit six breaking changes before upgrading — OIDC and MsgGraph need immediate config review

  The OIDC CIMD/DCR patterns changed from wildcard '*' to specific MCP client defaults — any custom MCP clients will silently stop working unless you explicitly add their patterns to the allow list. Separately, Microsoft Graph now excludes disabled user accounts; if your org tracks disabled users in Backstage, add an explicit filter before upgrading. Also migrate NavItemBlueprint usages to PageBlueprint title/icon params, and update PolicyQueryUser code to use credentials instead of the removed token/expiresInSeconds fields.

• enhancementAdopt incremental Microsoft Graph ingestion for large orgs

  The new msgraph-incremental module processes users and groups one page at a time and persists cursor state, meaning a pod restart no longer forces a full re-ingest. For orgs with tens of thousands of users, this is a practical operational improvement worth switching to. Install the new module and migrate your provider config — the old MicrosoftGraphOrgEntityProvider remains available but holds the full dataset in memory.

v0.152.1 is a bug-fix-heavy release with one useful new metric. The most operationally impactful changes are snappy decompression security fixes and a Prometheus metric naming regression fix.

• securityconfighttp snappy fixes limit memory exposure from compressed payloads

  Three snappy decompression fixes land in `pkg/confighttp`: body is now closed after reading, panics in decompression libraries return HTTP 400 instead of crashing with 500, and `max_request_body_size` is enforced before the decoded buffer is allocated. The size-check fix in particular prevents a potential memory spike from a maliciously crafted compressed payload. If you accept compressed OTLP over HTTP from untrusted sources, upgrade.

• breakingPrometheus metric name format may change if you customized telemetry host

  If you explicitly set the `host` field in the telemetry metrics section of your collector config, check whether your Prometheus metric names changed after upgrading to recent versions. The bug caused `WithoutScopeInfo`, `WithoutUnits`, and `WithoutTypeSuffix` to default to false instead of true in that code path, which means your metrics may have had unexpected suffixes or scope labels. This release restores the correct defaults — metric names may shift again on upgrade, so update dashboards and alerts accordingly.

• enhancementAdd in-flight exporter metric to your dashboards

  The new `otelcol_exporter_in_flight_requests` UpDownCounter metric is available in `pkg/exporterhelper`. Add it to your dashboards to see when exporters are queuing up requests or saturating worker pools — it's a direct signal of export backpressure that was previously hard to observe without custom instrumentation.

SPIRE v1.15.0 adds HashiCorp Vault key management, rootless Podman support, and PROXY protocol rate limiting, while promoting sigstore attestation out of experimental. One CLI JSON output change requires attention before upgrading.

• breakingAudit CLI JSON consumers before upgrading

  The CLI no longer wraps objects in slices when printing JSON output. Any scripts, pipelines, or tools that parse SPIRE CLI JSON output will likely break — they expected arrays and will now get single objects. Audit all automation that calls spire-server or spire-agent CLI with JSON output flags before rolling this out. Test in a non-production environment first.

• breakingUpdate metric dashboards for 'bootstrapped' label rename

  The metric label 'bootstraped' (one 'p') was corrected to 'bootstrapped'. Any Prometheus queries, Grafana dashboards, or alerting rules referencing the old misspelled label will silently stop matching after upgrade. Find and update all references before deploying v1.15.0.

• enhancementMigrate to HashiCorp Vault Key Manager if your org already runs Vault

  If your team already operates HashiCorp Vault, the new Vault Key Manager plugin lets you consolidate key storage there instead of managing a separate AWS KMS or Azure Key Vault setup. This is particularly useful for on-prem or multi-cloud deployments where cloud-native KMS options are awkward. Review the plugin configuration docs and plan a key migration window — existing keys in other backends won't auto-migrate.

• enhancementPromote sigstore attestation to production workloads

  Sigstore-based attestation in both the k8s and docker attestors is now stable. If you've been holding off due to the experimental flag, this is the release to enable it for production. Verify your signing workflows are compatible and enable the feature in staging first to confirm selector behavior matches expectations.

Keycloak 26.6.2 is a security-heavy patch release addressing 16 CVEs spanning session fixation, XSS, access control bypass, redirect URI validation, and cryptographic weaknesses. Upgrade immediately.

• securityUpgrade immediately — multiple account takeover and data leakage CVEs

  This release patches session fixation (CVE-2026-7507) enabling account takeover, redirect URI bypass (CVE-2026-7504), access token disclosure (CVE-2026-7571), stored XSS in org templates (CVE-2026-37980), and PII enumeration via account resource lookup (CVE-2026-37981). These are not theoretical — they affect standard OIDC flows and admin APIs. Any Keycloak 26.x deployment should be upgraded to 26.6.2 without delay. Check your change management process, but treat this as an emergency patch.

• securityFreeMarker RCE risk — audit custom login themes before upgrading

  CVE tracked under #47915 allowed FreeMarker templates to instantiate arbitrary Java objects and execute OS commands. If you have custom login themes that accept any user-influenced input in FTL files, audit them now. The fix adds proper expression escaping in JS blocks within FTL pages. After upgrading, test your custom themes to ensure the new escaping doesn't break existing behavior — especially in frontchannel-logout.ftl.

• securityWebAuthn AAGUID policy bypass — re-verify authenticator enrollment policies

  CVE-2026-6856 allowed packed self-attestation to bypass AAGUID allowlist policies during WebAuthn registration. If you rely on AAGUID restrictions to enforce specific authenticator hardware (e.g., FIDO2 security keys in regulated environments), credentials may have been enrolled that violate your policy. After upgrading, review recently enrolled WebAuthn credentials and consider requiring re-enrollment if strict hardware attestation is a compliance requirement.

v2.9.0 adds HAMi-DRA for NVIDIA (now production-ready), Ascend HAMi-core mode, VastAI support, and patches a scheduler DoS vulnerability. Prometheus metric renames require dashboard updates before upgrading.

• securityPatch scheduler DoS vector and Go security upgrades

  Two scheduler-level security fixes land in this release: an io.LimitReader guard on scheduler HTTP routes to prevent DoS (issue #554), and a Go runtime upgrade to 1.26.2 for upstream security fixes. If you run HAMi scheduler exposed to any untrusted network path, upgrade promptly.

• breakingPrometheus metric names changed — update dashboards before upgrading

  Prometheus metric and label names have been realigned to follow best practices (renamed fields). If you have dashboards or alerts built against HAMi vGPU metrics, audit your metric names after upgrading. The existing dashboard.md has been updated — cross-reference it. The new ServiceMonitor Helm chart options also make scrape config cleaner if you're on the Prometheus Operator stack.

• enhancementHAMi-DRA for NVIDIA is production-ready — start evaluating

  HAMi-DRA (Dynamic Resource Allocation) for NVIDIA is now marked ready for use. If you're on Kubernetes 1.26+ and want finer-grained GPU resource management without relying solely on device plugins, this is the release to start evaluating DRA. Test in a non-prod cluster first — DRA changes how the scheduler sees GPU resources.

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

v1.120.2 is a substantial release with security fixes, memory leak patches, AWS CUR 2.0 support, OVH cloud provider, and supply chain security improvements via cosign image signing.

• securityUpgrade immediately for CVE-2026-34986 fix

  This release patches GHSA-xmrv-pmrh-hhx2 and CVE-2026-34986 in Go dependencies. If you're running any prior v1.120.x or v1.119.x version, upgrade to v1.120.2 now. Check your vulnerability scanner output to confirm the affected packages are resolved post-upgrade.

• enhancementVerify cosign image signatures in your admission pipeline

  OpenCost images are now signed with cosign keyless signing and include SLSA provenance attestations. If your cluster uses an admission controller (e.g., Kyverno, Connaisseur), add a policy to enforce signature verification on opencost images. This closes a real supply-chain gap for teams running OpenCost in regulated environments.

• enhancementEnable AWS CUR 2.0 and tune spot data feed behavior

  If your AWS billing is already on CUR 2.0, you can now configure OpenCost to use it directly. Additionally, if you don't use the AWS spot data feed, set the new toggle to disable it — this suppresses noisy warnings and avoids unnecessary config polling. Teams with spot-heavy workloads should also benefit from the new spot price API caching layer reducing API call volume.

Istio 1.30 ships experimental AI-focused agentgateway, ambient mode CIDR support, a new TrafficExtension API, and tightened debug endpoint auth that breaks existing setups.

• breakingDebug endpoint auth is on by default — audit your tooling now

  Port 15010 XDS debug endpoints now enforce authentication with ENABLE_DEBUG_ENDPOINT_AUTH=true as the default. Any internal tooling, dashboards, or scripts hitting syncz or config_dump without credentials will start failing after upgrade. Before upgrading, inventory everything that talks to port 15010 and either add auth or explicitly allowlist namespaces via DEBUG_ENDPOINT_AUTH_ALLOWED_NAMESPACES.

• breakingStart migrating off WasmPlugin to TrafficExtension API

  TrafficExtension is now the primary extensibility API, replacing WasmPlugin. WasmPlugin isn't being removed immediately, but new features will land in TrafficExtension first. If you run Wasm extensions in production, plan a migration window and test TrafficExtension parity before 1.31 hardens the deprecation.

• enhancementUse CIDR ServiceEntry in ambient mode to simplify external IP routing

  Previously, ambient mode required enumerating individual IP endpoints in ServiceEntry. CIDR support means you can now cover entire subnets — useful for external databases, on-prem services, or shared infrastructure with dynamic IPs. If you've been maintaining large lists of individual endpoints, consolidate them now and reduce operational overhead.

Istio 1.29.3 patches two security vulnerabilities — an AuthorizationPolicy bypass and a cross-namespace XDS config leak — alongside a multicluster deadlock fix and AWS EKS ambient mesh probe fix.

• securityAudit AuthorizationPolicy rules using suffix-match principals or namespace selectors — patch immediately

  Regex metacharacters (., [, etc.) in source.principals and source.namespaces were embedded into Envoy SafeRegex unescaped. This means a policy allowing 'spiffe://cluster.local/ns/foo/sa/bar.admin' could inadvertently also match 'spiffe://cluster.local/ns/foo/sa/barXadmin'. Any service with suffix-based wildcard principal matching is potentially affected. Upgrade to 1.29.3 and review policies where principals or namespace values contain dots, brackets, or other regex metacharacters.

• securityRotate access controls on XDS debug endpoints — any authenticated workload could read cross-namespace configs

  The /debug/syncz and /debug/config_dump endpoints served by StatusGen had no namespace boundary enforcement. An authenticated workload in namespace A could enumerate and read Envoy configs of workloads in namespace B. If you run multi-tenant clusters or expose istiod debug endpoints, assume cross-namespace config data may have been accessible. Upgrade immediately and audit who has accessed these endpoints via your API server audit logs.

• breakingMulti-cluster operators: the secret controller deadlock fix may change behavior during cluster updates

  The deadlock in the multicluster secret controller was triggered during remote cluster updates. If your control plane has been experiencing hangs or stalls in multi-cluster scenarios, this fix resolves the root cause — but test your cluster join/leave workflows after upgrading to confirm expected behavior is restored.

Istio 1.28.7 was released, but the published notes are too brief to summarize. See the original release notes for details.

Litmus 3.29.0 patches a gRPC CVE, fixes duplicate chaos triggers under concurrent reconciles, and adds Prometheus metrics support for experiment observability.

• securityPatch CVE-2026-33186 by upgrading to 3.29.0 now

  The gRPC library was upgraded to v1.79.3 to fix CVE-2026-33186. If you're running any Litmus version prior to 3.29.0, your control plane is exposed. Upgrade immediately — this isn't a 'schedule it next sprint' situation.

• breakingVerify event-tracker behavior after the duplicate-trigger fix

  The fix for duplicate chaos experiment triggers under concurrent reconciles changes how the event-tracker handles race conditions. If you rely on the event-tracker for automated chaos injection, test your pipelines post-upgrade to confirm expected trigger counts. Duplicate runs may have been masking gaps in your experiment coverage.

• enhancementWire up Prometheus metrics to your existing dashboards

  Prometheus metrics are now natively exposed by ChaosCenter. The release includes a getting-started guide and unit tests, so integration is straightforward. Add Litmus as a scrape target and start tracking experiment pass/fail rates, run durations, and infra connectivity — this fills a long-standing observability gap for chaos workflows.

Kyverno v1.18.1 is a targeted patch fixing two regressions in generate and mutate-existing policies introduced in v1.18.0.

• breakingUpgrade immediately if you use generate policies on cluster-scoped resources

  If you upgraded to v1.18.0 and have GeneratingPolicy rules targeting cluster-scoped resources (ClusterRoles, Namespaces, CRDs, etc.), generation was silently broken. v1.18.1 restores correct behavior. Validate that expected resources were actually generated after upgrading — anything that should have been generated during the v1.18.0 window may need manual remediation or a policy re-trigger.

• breakingMutate-existing policies on v1.18.0 may have produced incorrect results

  The AdmissionRequest context was not being forwarded to UpdateRequests in mutate-existing policies. This means any rule relying on request context (user info, object, oldObject) for conditional logic or patches would have behaved incorrectly. Audit mutations applied while running v1.18.0 and verify affected resources are in the expected state after upgrading to v1.18.1.

• enhancementTreat v1.18.0 as effectively broken for generate and mutate-existing users

  Both fixes were cherry-picked from main, meaning v1.18.0 should be skipped entirely if you rely on either feature. Skip straight to v1.18.1. If you are still on v1.17.x and evaluating the v1.18 line, start your testing against v1.18.1 instead.

v7.0.0 fixes a Windows-specific security vulnerability in delegation path matching and tightens the ngclient API with one breaking constructor change.

• securityPatch Windows deployments immediately for GHSA-qp9x-wp8f-qgjj

  Delegation path matching was broken on Windows, meaning a malicious or misconfigured repository could match targets it shouldn't. If any of your TUF clients run on Windows, upgrade to v7.0.0 now. Linux/macOS deployments are unaffected, but upgrading is still the right move before paths diverge further.

• breakingUpdate all Updater() call sites to use the named bootstrap argument

  The Updater() constructor signature changed: 'bootstrap' is now a required keyword argument. Any code calling Updater() without explicitly passing 'bootstrap' will break. Audit your code for Updater instantiations — if you weren't passing a bootstrap value before, add bootstrap=None to restore the previous behavior. This is a one-line fix per call site, but it will cause an immediate TypeError if missed.

• enhancementWatch for securesystemslib.hash removal in upcoming releases

  This release starts phasing out the securesystemslib.hash dependency. If your codebase or any custom TUF extensions directly import or rely on securesystemslib.hash, start planning a migration now rather than scrambling when a future release drops it entirely.

pack v0.40.6 is a small patch fixing a trust detection bug in 'builder inspect' and adding Heroku's builder:26 to the trusted builders list.

• breakingAudit pipelines that worked around the trust detection bug

  If your CI scripts or automation added extra flags or workarounds because 'builder inspect' was misreporting trusted builders as untrusted, remove those workarounds now. Running with unnecessary trust overrides is a security smell worth cleaning up.

• enhancementUse heroku/builder:26 without manual trust configuration

  Teams targeting Heroku's stack 26 no longer need to manually mark the builder as trusted via '--trust-builder' or config file entries. Upgrade to v0.40.6 and clean up any explicit trust overrides you've added for this builder.

Dapr v1.17.7 is a dense bug-fix release targeting workflow reliability, messaging correctness, and control-plane resilience. Fourteen production-grade fixes land here — upgrade if you run workflows, Kafka, or RabbitMQ.

• securityUpgrade sentry immediately if you downgraded from 1.18 or use Ed25519/RSA issuer keys

  A type-switch bug in dapr/kit caused sentry to crash on startup with 'unsupported key type' for Ed25519 and RSA issuer keys. Sentry enters a crash-loop, stops issuing mTLS identities, and halts cert rotation. Sidecars with unexpired certs keep running, but any pod restart or cert expiry silently breaks identity. If your trust bundle was generated by 1.18 or you manually rotated to Ed25519/RSA keys, this is a crash-loop waiting to happen. Upgrading to 1.17.7 is the only fix — no trust bundle migration needed.

• breakingScheduler etcd compaction mode change requires PVC capacity review

  The embedded etcd compaction mode switches from periodic (10 min) to revision-based (1,000,000 revisions), and the default storage size jumps from 1Gi to 16Gi. Kubernetes StatefulSet volumeClaimTemplates are immutable, so existing 1Gi PVCs are NOT automatically resized. If you're running the scheduler at any real workflow throughput, check your current PVC utilization now. If you're close to capacity, expand the PVC on the cluster before upgrading. The helm chart uses a lookup helper to avoid overwriting existing PVC sizes, but it cannot expand them for you.

• enhancementAdd workflow payload size ratio dashboards before upgrading

  Two new histograms — dapr_runtime_workflow_payload_size_ratio and dapr_runtime_workflow_activity_payload_size_ratio — report payload size as a fraction of --max-body-size. Before upgrading, set up a Prometheus alert on histogram_quantile(0.99, ...) > 0.9 so you catch workflows trending toward the 0.95 stall threshold before they freeze. This is especially useful for workflows with large activity payloads or long histories. Note: metrics are only recorded when --max-body-size is explicitly configured.

Native sidecars promoted to GA and enabled by default, plus a security fix restricting Server resources from affecting workloads outside their namespace. Heavy dependency refresh across Rust and Go stacks.

• securityServer namespace isolation fix — review cross-namespace Server resources immediately

  A fix was applied so that Server resources can no longer affect workloads in namespaces other than their own. If you have intentionally or accidentally created Server policies that were influencing workloads cross-namespace, those policies will silently stop applying after this upgrade. Audit your Server resources across all namespaces and verify that authorization policies still behave as expected post-upgrade. The risk of misconfigured over-broad policies is reduced, but any reliance on the previous behavior will break.

• breakingNative sidecars are now on by default — audit your cluster before upgrading

  Native sidecar support (using Kubernetes init containers with restartPolicy: Always) is now GA and enabled by default. If your cluster runs Kubernetes < 1.29, native sidecars are unsupported and this will break injection. Even on supported versions, verify that any tooling, admission webhooks, or pod lifecycle assumptions in your workloads are compatible. Test in a staging environment before rolling out to production. If you need the old behavior, explicitly disable the feature flag during install/upgrade.

• enhancementConfigure honorTimestamps on the linkerd-proxy PodMonitor

  If you're using the Prometheus Operator and have timestamp alignment issues in your Linkerd proxy metrics (e.g., stale or out-of-order samples), you can now set honorTimestamps in the Helm chart for the linkerd-proxy PodMonitor. This is a quality-of-life win for teams with strict metric ingestion pipelines. Set it explicitly during your next Helm upgrade rather than leaving it at the default.

Buildpacks v0.40.5 was released, but the published notes are too brief to summarize. See the original release notes for details.

Helm v3.21.0 bumps Kubernetes client libs to v1.36, patches OpenTelemetry CVEs, fixes OCI index chart pulling, and corrects nil value preservation in chart merging. Helm v3 EOL is approaching.

• securityUpgrade immediately to patch OpenTelemetry CVEs

  OpenTelemetry packages were patched specifically to address CVEs. If you're running Helm in CI/CD pipelines or as part of automation tooling, upgrade to v3.21.0 now. Don't wait for the next patch release.

• breakingPlan your Helm v4 migration — v3 EOL is real

  The release explicitly warns that Helm v3 is approaching end-of-life. This is not a distant concern — v3.22.0 targets Kubernetes v1.37 and v3.21.1 is just a bug fix release. Start evaluating Helm v4 changes now, especially if you maintain custom plugins or automation built around Helm's CLI or Go SDK.

• enhancementTest OCI index-based chart pulls if you use multi-arch registries

  The fix for pulling charts from OCI indices means setups using image index manifests (common in multi-arch environments) should now work reliably. If you previously worked around this with direct digest references or manifest-specific tags, revisit those workarounds — they may no longer be necessary.

Helm v4.2.0 ships Kubernetes 1.36 client support, a new mustToToml template function, fixes for dry-run server mode with generateName, and several post-renderer YAML parsing correctness fixes.

• breakingRemove --hide-notes and --render-subchart-notes from your CI scripts

  Both flags are now deprecated and will likely be removed in a future release. Audit your helm install/upgrade/template invocations in CI pipelines and scripts. Dropping them now avoids a forced migration later when they're removed entirely.

• enhancementAdopt mustToToml for safer TOML templating

  The new mustToToml function behaves like mustToJson — it returns an error instead of silently failing when TOML serialization goes wrong. If you're using toToml anywhere in your chart templates, swap it for mustToToml so template rendering failures are surfaced as actual errors rather than empty or malformed output.

• enhancementValidate --dry-run=server against generateName resources

  Previously, --dry-run=server skipped resources that used generateName instead of name, which gave false confidence that those resources were being validated. That's fixed now. Re-run your server-side dry-run checks against any charts that use generateName — you may catch validation errors that were previously being silently ignored.

Cilium v1.19.4 is a stability-focused patch release with 20+ bug fixes covering crash prevention, IPsec reliability, and Cluster Mesh correctness — upgrade if you run any of those features.

• securityUpdate moby/spdystream dependency (security fix included)

  This release bumps github.com/moby/spdystream to v0.5.1 as a security fix. The dependency is used in Kubernetes API communication paths. No CVE number is listed in the release notes, but treat this as a prompt to upgrade — staying on v1.19.3 leaves the exposure open.

• breakingHand-managed EndpointSlices need service-proxy-name label added

  If you set --k8s-service-proxy-name and manage EndpointSlices manually, those slices will now be filtered OUT at the watch level unless they carry the matching service.kubernetes.io/service-proxy-name label. After upgrading, any untagged hand-managed slice becomes invisible to Cilium, causing traffic drops. Audit your EndpointSlices before upgrading and stamp the label on any that are missing it.

• enhancementPrioritize upgrade if you run IPsec, WireGuard, or Cluster Mesh

  Three distinct data-plane reliability fixes land here: IPsec packet drops during rolling key rotation, WireGuard silent packet loss under constrained MTU with IPv6, and Cluster Mesh missing backends for multi-port services. Any of these can cause hard-to-diagnose intermittent connectivity issues. If your environment uses any of these features, this patch should move to the front of your upgrade queue.

v1.17.16 patches a cross-namespace traffic hijacking vulnerability in CiliumLocalRedirectPolicy, fixes an IPsec panic on malformed input, and resolves a static pod identity resolution bug.

• securityAudit LRP addressMatcher configs before upgrading

  The LRP addressMatcher change fixes a real attack vector: a policy in one namespace could previously override a Service frontend and redirect traffic cross-namespace. After upgrading, any LRP that was relying on this override behavior will stop working silently — traffic won't redirect as expected. Before upgrading, audit your CiliumLocalRedirectPolicy objects for addressMatcher entries that overlap with existing Service frontends. If you legitimately need the old behavior, set --enable-lrp-address-matcher-override=true, but treat that as a temporary measure and redesign the policy.

• securityUpgrade if running IPsec — agent crash risk on malformed input

  The parseSPI panic means a malformed IPsec packet could crash the Cilium agent, taking down networking on that node. This is a low-complexity denial-of-service risk for any cluster using Cilium's IPsec transparent encryption. Upgrade to v1.17.16 promptly if IPsec is enabled in your environment.

• breakingLRP addressMatcher behavior change is not fully backward-compatible

  This is a behavior change, not just a bug fix. If you have CiliumLocalRedirectPolicies using addressMatcher that overlap with Service ClusterIPs or external IPs, those policies will now be rejected or ignored where they previously worked. Test your LRP configurations in a non-production environment before rolling this upgrade out. The opt-in flag --enable-lrp-address-matcher-override=true exists, but using it means you are accepting the previously-vulnerable behavior.

Cilium v1.18.10 is a stability-focused patch release fixing agent crashes, IPsec panics, Cluster Mesh backend gaps, and a data race in IPAM — all backported from upstream.

• securitymoby/spdystream and x/net security updates are included

  This release pulls in a security fix for github.com/moby/spdystream and bumps x/net to v0.53. Both are network-layer dependencies. If your policy or threat model tracks transitive dependency CVEs, this patch justifies the upgrade on its own.

• breakingUpgrade encrypted clusters to fix IPsec panic risk

  A panic in parseSPI on malformed IPsec input could crash the agent on nodes running encrypted traffic. If you use IPsec encryption, treat this as a priority upgrade — a malformed packet or misconfigured peer can take down the agent process entirely.

• enhancementCluster Mesh users with shared target ports should upgrade

  The missing global service backends bug silently dropped backends from services where multiple ports mapped to the same target port. Traffic would route correctly within a single cluster but fail cross-cluster. Upgrade and verify affected services post-rollout using hubble observe or service endpoint inspection.

Jaeger v2.18.0 brings two breaking changes (OTEL metrics overhaul and removed min-step API), useful header-forwarding for ES/OpenSearch, and a massive UI refactor migrating state management from Redux to Zustand.

• breakingAudit your metrics dashboards before upgrading

  The OTEL collector package upgrade changed metric names and shapes. Before upgrading, compare your current Jaeger metrics against the new ones by running both versions in parallel or checking the PR diff. Any Grafana dashboards, Prometheus alerts, or monitoring rules built on Jaeger's internal metrics need to be reviewed and updated. The min_step removal is a smaller blast radius — only affects custom tooling that calls the metricstore API directly — but still requires a code or config change before upgrading.

• enhancementUse header forwarding if you authenticate ES/OpenSearch with custom headers

  If your Elasticsearch or OpenSearch cluster requires auth headers beyond basic username/password (e.g., custom JWT, IAM proxy headers), configure the new header-forwarding feature. This also helps in multi-tenant setups where storage routing depends on request headers. Configure via the storage backend settings in jaeger-query or the gRPC storage plugin config.

• enhancementEvaluate ClickHouse as a storage backend if you want SPM without Prometheus

  ClickHouse SPM support is experimental but now covers the full metrics trifecta: call rates, error rates, and latencies. TTL support is also added. If you're running ClickHouse already or want a single-store solution for both traces and metrics, this is the release to start testing against. Don't use it in production yet, but set up a staging environment to track maturity.

v3.2.12 is a minor patch fixing a lint nesting issue, URL validation export, and a log line overflow bug in the UI. Low risk, safe to apply.

• enhancementApply patch if UI log wrapping is causing visual issues

  If your team uses Argo CD's log viewer with line-wrapping enabled, lines were overflowing their container — a fairly annoying UX bug. This patch resolves it cleanly. No config changes needed; just upgrade.

• enhancementRoutine patch — schedule upgrade at your next maintenance window

  No breaking changes, no CVEs. The spdystream dependency bump is a minor upstream fix. This is a straightforward patch release; there's no urgency, but keeping current on 3.2.x is good hygiene before any future minor version jump.

Argo CD v3.3.10 is a patch release fixing a nil-pointer panic in permission validation, a log line UI overflow bug, and bumping Go to 1.25.9 to address CVEs.

• securityUpgrade immediately — Go 1.25.9 fixes CVEs in the runtime

  The Go runtime was bumped from a prior version to 1.25.9 specifically to resolve CVEs. The release notes don't enumerate the CVE IDs, but any patch that upgrades the runtime for security reasons on a stable branch deserves prompt action. If you're running 3.3.x, upgrade to 3.3.10 now rather than waiting for your next maintenance window.

• breakingServer-side diff now correctly hides secrets — verify diff outputs if you rely on them

  The fix to apply HideSecretData to server-side diff results means that previously exposed secret values in diff views will now be redacted. If any automation, alerting, or audit tooling parses diff output expecting raw secret values, it will break. Review your diff-dependent workflows before upgrading.

• enhancementNil APIResource panic fix prevents unexpected controller crashes

  The permission validator could panic when an APIResource was nil — a condition that can occur with certain custom or non-standard API groups. If you've seen intermittent ArgoCD controller restarts without clear cause, this is a likely culprit. Upgrade to 3.3.10 to stabilize those environments.

Argo CD v3.4.2 is a patch release fixing a panic in the permission validator, reverting a problematic revision update optimization, and patching secret data exposure in server-side diffs.

• securitySecret values could appear in diff output — patch now

  Server-side diff results for Secret resources were not having HideSecretData applied, meaning secret values could be exposed in diff views through the UI or API. If you use server-side apply or server-side diff previews, upgrade to 3.4.2 immediately. Audit your ArgoCD API access logs if you suspect exposure.

• breakingUpdateRevisionForPaths revert may re-introduce previous behavior

  The optimization that avoided unnecessary UpdateRevisionForPaths calls (merged in 3.4.x) caused regressions and has been reverted. If you were relying on that behavior for performance or correctness, expect the pre-fix behavior to return. Monitor sync operations after upgrading, especially for path-filtered applications.

• enhancementPermission validator panic fix improves stability

  A nil APIResource in the permission validator could crash the ArgoCD server process. This is now guarded. If you've seen unexpected pod restarts on the ArgoCD server, especially in environments with non-standard CRDs or API aggregation, this patch likely addresses it.

Kubernetes v1.36.1 is a focused patch release fixing 8 bugs across networking, node, and cluster lifecycle — most impacting Windows environments, ZFS nodes, and kubeadm-managed clusters.

• breakingZFS nodes: upgrade immediately if running v1.36.0

  kubelet fails to start on ZFS-backed nodes in v1.36.0 due to a missing cadvisor plugin. If you deployed v1.36.0 on ZFS storage, those nodes are likely not running. Patch to v1.36.1 before any further ZFS node rollouts.

• breakingWindows L2Bridge users: DNS timeouts are fixed but require upgrade

  Stale HNS endpoints caused traffic to route to wrong nodes when pod IPs were reused, producing silent DNS failures. This is hard to diagnose and easy to misattribute to DNS config. If you run Windows nodes with L2Bridge networking, treat this as a high-priority patch.

• enhancementkubeadm bootstrap is more resilient against slow load balancers

  Previously, kubeadm init could fail or behave unexpectedly when the control plane load balancer wasn't ready yet. The fix makes bootstrap use the local API endpoint first, then defer to the LB endpoint — a meaningful improvement for cloud environments where the LB provisions asynchronously. Worth upgrading before your next cluster init or upgrade cycle.

Kubernetes v1.35.5 is a focused patch release fixing scheduler state corruption, Windows networking, kube-proxy large-cluster behavior, and several kubeadm initialization issues.

• breakingKubeadm users: review kubeconfig generation behavior after upgrade

  The kubeadm init change to use localAPIEndpoint for admin.conf and super-admin.conf is a behavioral fix, but clusters with custom controlPlaneEndpoint setups should validate that kubeconfigs are generated correctly after upgrading. If you rely on the controlPlaneEndpoint in generated configs for post-init tooling, test in staging first.

• enhancementLarge clusters: upgrade kube-proxy to stop unnecessary full-syncs

  If you're running 1000+ endpoints, kube-proxy was previously triggering full-sync operations it shouldn't. This patch stops that. The fix directly reduces CPU and network overhead on busy clusters — upgrade kube-proxy as part of your next maintenance window.

• enhancementScheduler memory leak fix — prioritize this patch if you see scheduling instability

  The scheduler bug with in-flight state tracking could cause unbounded growth in memory usage when pods with reused names fail scheduling repeatedly. If you've observed scheduling delays or growing scheduler memory consumption, this patch addresses the root cause directly.

v1.34.8 is a focused bug-fix patch addressing IPv6 CIDR allocation errors, a scheduler memory leak, Windows DNS routing failures, and several kubeadm cluster lifecycle issues.

• securitykubeadm now uses a dedicated ClusterRole for kube-apiserver kubelet access

  The kube-apiserver's kubelet client is now bound to 'system:kubelet-api-admin' instead of a shared role. For kubeadm-managed clusters, re-running 'kubeadm init phase bootstrap-token' or upgrading via kubeadm will apply this change. Existing clusters upgraded in-place will get this tighter RBAC scoping automatically — verify with 'kubectl get clusterrolebinding' post-upgrade.

• breakingIPv6 clusters: audit ServiceCIDR allocations before upgrading

  The 64-bit IPv6 ServiceCIDR bug means some clusters may have services with IPs that technically fall outside the configured subnet. After upgrading to v1.34.8, check whether any existing service IPs are out-of-range and consider recreating affected services. This primarily impacts clusters using /64 IPv6 service CIDRs.

• enhancementLarge clusters: kube-proxy full-sync elimination reduces control plane pressure

  If you're running clusters with 1000+ endpoints, kube-proxy was performing expensive full-sync operations unnecessarily in large-cluster mode. This patch stops that. The benefit is lower CPU and latency spikes during endpoint churn. No config changes needed — upgrade and monitor kube-proxy CPU usage to confirm the improvement.

v1.33.12 is a focused patch release with four kubeadm bug fixes targeting cluster init reliability, etcd health checks, and RBAC hardening for kubelet API access.

• securityRBAC isolation for kube-apiserver's kubelet client is now enforced

  The kube-apiserver now uses a dedicated ClusterRole 'system:kubelet-api-admin' for its kubelet client credentials. This tightens RBAC boundaries and reduces blast radius if credentials are ever misused. No immediate action required for existing clusters, but verify your RBAC audits reflect this role after upgrading kubeadm.

• enhancementUpgrade kubeadm if you use external load balancers during cluster init

  Previously, kubeadm init would write kubeconfigs pointing at the load balancer endpoint, which fails when the LB isn't provisioned until after the first apiserver starts — a chicken-and-egg problem common with cloud providers. The fix makes init use the local API endpoint instead. If you've been working around this with retry scripts or manual kubeconfig edits, this patch removes the need for those hacks.

• enhancementEtcd quorum-based health check prevents false failures in partially degraded clusters

  The old all-members health check would fail kubeadm operations if any etcd member was unhealthy, even when quorum was maintained. Now it only blocks when quorum is actually lost. If you run 3- or 5-node etcd clusters and have hit spurious kubeadm upgrade or join failures due to a single unhealthy member, this patch resolves that.

Flux v2.8.7 patches a CVE in go-git and fixes a destructive reconciliation bug where non-namespaced resources with ssa:IfNotPresent were being deleted and recreated every cycle.

• securityPatch CVE-2026-45022 by upgrading now

  go-git v5.19.0 fixes CVE-2026-45022, which affects source-controller and image-automation-controller — two components that actively clone and interact with Git repos. If your Flux installation pulls from any external or semi-trusted Git source, treat this as a priority upgrade. Run 'flux install' or update your Helm release to v2.8.7 immediately.

• breakingCheck non-namespaced resources using ssa:IfNotPresent for unintended churn

  If you're managing ClusterRoles, CRDs, or other cluster-scoped resources with the kustomize.toolkit.fluxcd.io/ssa: IfNotPresent annotation, those resources were being silently deleted and recreated on every reconciliation loop before this fix. Audit your Kustomization objects and verify resource state after upgrading to confirm the churn has stopped. Any dependent workloads may have experienced disruptions you weren't aware of.

• enhancementFollow the v2.7+ upgrade procedure if coming from v2.6

  The Flux team has a specific upgrade discussion thread for v2.7+ migrations. Skipping it when jumping from v2.6 to v2.8.7 can cause issues. Review the linked procedure before applying this update in environments running older Flux versions.

Open Policy Agent (OPA) v1.16.2 was released, but the published notes are too brief to summarize. See the original release notes for details.

Flatcar stable-4593.2.1 is a security-only update: 130+ Linux kernel CVEs patched and the kernel bumped to 6.12.87. Reboot nodes to apply.

• security130+ Linux kernel CVEs patched — reboot nodes promptly

  This release patches 130+ Linux kernel CVEs (CVE-2026-31xxx and CVE-2026-43xxx series), rolling up kernel versions 6.12.82 through 6.12.87. The sheer volume suggests a large stable-kernel backport batch. Treat this as a high-priority update — schedule a node rolling restart via your update operator or manually drain and reboot nodes running stable-4593.2.0 as soon as your change window allows.

• enhancementCA certificates updated to NSS 3.123.1 — check custom CA chains

  ca-certificates updated to NSS 3.123.1. If you have services doing TLS certificate validation at the OS level (not inside containers), verify that trust store changes don't affect any pinned or custom CA chains after the node reboots.

v0.152.0 fixes a silent Prometheus metric name regression when telemetry host is customized, changes AsString HTML-escaping behavior for map/slice values, and adds an in-flight exporter requests metric.

• breakingCheck Prometheus metric names if you customized telemetry host

  The Prometheus exporter boolean fields (WithoutScopeInfo, WithoutUnits, WithoutTypeSuffix) now default correctly when you explicitly set the telemetry host. Before this fix, those fields defaulted to false instead of true, so your metric names would silently change format. If you run a Collector with a custom telemetry host configured, verify your Prometheus metric names after upgrading — dashboards and alerts keyed on metric name format may need updating.

• breakingAsString output change for map/slice values — check downstream consumers

  pcommon.Value.AsString no longer HTML-escapes <, >, and & in map and slice values. If your pipeline or downstream consumers were relying on escaped output (e.g., &lt; or &gt;) from attribute maps or slices, the raw characters will now appear instead. Audit any log parsers, attribute processors, or exporters that inspect string representations of map/slice values.

• enhancementAdd otelcol_exporter_in_flight_requests to exporter dashboards

  A new UpDownCounter metric otelcol_exporter_in_flight_requests tracks concurrent export requests per exporter. Add it to your Collector dashboards to detect exporter worker pool saturation before it causes backpressure or dropped data. No config change needed — it emits automatically.

Harbor v2.14.4 is a patch release fixing session management bugs, scanner API issues, and DockerHub token auth, with Go 1.25.9 and dependency security bumps.

• securityUpgrade immediately for go-jose and OTel SDK dependency fixes

  The go-jose/go-jose and go.opentelemetry.io/otel/sdk packages were explicitly bumped in this release, which typically signals CVE remediation. If your Harbor instance handles sensitive registry credentials or is exposed to external traffic, this patch should be prioritized. Plan an upgrade from v2.14.3 to v2.14.4 — it's a patch release with no breaking changes, so the risk of upgrading is low.

• breakingSession behavior changes — test SSO and long-lived browser sessions before rollout

  Two session-related fixes land here: background polling no longer refreshes session TTL, and SessionRegenerate args/lifetime were corrected. If your users rely on the UI staying logged in while background tabs are open, their sessions will now expire as configured rather than being silently extended. Validate your session timeout settings in Harbor's config and communicate expected behavior changes to your users before upgrading in production.

• enhancementDockerHub replication broken? This patch fixes the token auth flow

  If you've been seeing replication failures from DockerHub registries (especially after DockerHub API changes), the fix to use the /v2/auth/token endpoint should resolve them. After upgrading, verify your DockerHub replication rules by triggering a manual sync and checking the replication job logs. Also retest any distribution instance edits that involve credentials — a separate fix addresses a bug where editing a distribution instance without credentials caused issues.

v1.12.4 is a security patch release fixing a DoS vulnerability in the webhook server plus two scheduler correctness bugs. Upgrade immediately if running v1.12.3 or earlier.

• securityPatch the webhook server OOM vulnerability now

  CVE-2026-44247 lets any pod with network access to the webhook endpoint kill the webhook server by sending an oversized HTTP body, taking down admission control for the entire cluster. The CVSS scope is 'Changed', meaning the blast radius extends beyond the attacking pod. Any workload that can reach the webhook service is a potential attacker. Upgrade to v1.12.4 immediately. If you cannot upgrade right now, restrict network access to the webhook endpoint using NetworkPolicy to limit which pods or namespaces can reach it.

• breakingMulti-queue preemption may have been silently producing wrong results

  The preemptorTasks overwrite bug means clusters using multi-queue preemption could have been making incorrect scheduling decisions — lower-priority jobs potentially not being preempted correctly, or QueueOrderFn being ignored entirely. After upgrading, review preemption behavior in your queues. If you have queue ordering policies configured, verify they're now being applied as expected and check whether any jobs were stuck or incorrectly scheduled before the upgrade.

• enhancementStartup race condition in the scheduler is resolved

  The event handler completion fix addresses a subtle race where the scheduler could begin making decisions before all event handlers were ready. This was most likely to surface during controller restarts or rolling upgrades. No action required beyond upgrading, but if you've seen intermittent scheduling failures shortly after Volcano restarts, this is likely the cause.

v1.13.3 patches a DoS vulnerability in the webhook server (CVE-2026-44247) plus four scheduler bug fixes. Upgrade immediately if running v1.13.2 or earlier.

• securityPatch CVE-2026-44247 immediately — all v1.13.x ≤ v1.13.2 are vulnerable

  Any pod with network access to the Volcano webhook endpoint can send an arbitrarily large HTTP body and OOM-kill the webhook server, blocking all admission for jobs and queues. CVSS 6.8 (Moderate) but the blast radius is high in multi-tenant clusters. Upgrade to v1.13.3 (or v1.12.4 / v1.14.2 depending on your branch). If you can't upgrade immediately, restrict network access to the webhook service via NetworkPolicy to limit who can reach port 443 on the webhook server.

• breakingMulti-queue preemption behavior changes — validate workloads after upgrade

  Two preemption fixes alter scheduling decisions: preemptorTasks no longer get overwritten across queues, and QueueOrderFn is now enforced during preemption. If you rely on specific preemption outcomes in multi-queue setups, run a staging environment validation after upgrading. Jobs that were previously preempting others may no longer do so, or vice versa, depending on your queue priority configuration.

• enhancementScheduler startup race eliminated — relevant for frequent restarts

  The fix ensuring event handlers complete before scheduling starts matters most in environments where the scheduler pod restarts frequently (e.g., OOM restarts, rolling updates). Previously, a narrow race window could cause the scheduler to miss events. No config change needed — just upgrade and monitor scheduler logs at startup for any anomalies.

v1.14.2 patches a denial-of-service CVE in the webhook server plus a dense cluster of scheduler correctness bugs — upgrade immediately if you're on any 1.12/1.13/1.14 branch.

• securityPatch CVE-2026-44247 now — all prior 1.12/1.13/1.14 versions are affected

  Any pod with network access to the Volcano webhook endpoint can send an arbitrarily large request body and OOM-kill the webhook server, blocking all workload admission. CVSS 6.8 (Moderate) but the blast radius is high — a downed webhook halts job submission cluster-wide. Upgrade to v1.14.2, v1.13.3, or v1.12.4 depending on your branch. If you cannot upgrade immediately, consider restricting network access to the webhook service via NetworkPolicy to limit which pods can reach the endpoint.

• breakingCheck for scheduler panic-on-install if you recently deployed 1.14.x

  A race condition caused the scheduler to panic and restart during initial install. If you observed unexplained scheduler CrashLoopBackOffs after a fresh 1.14.x deployment, this is the fix. Upgrade and verify the scheduler pod stabilizes. No config changes needed, but review your monitoring alerts — silent restarts in production may have caused missed scheduling cycles.

• enhancementMulti-queue preemption and queue ordering are now reliable — re-validate your preemption policies

  Two distinct bugs in multi-queue preemption (preemptorTasks overwrite and QueueOrderFn not being honored) are fixed. If you rely on preemption across queues with custom ordering functions, the scheduler was likely not behaving as configured. After upgrading, run a validation cycle against your preemption scenarios to confirm jobs are being preempted in the priority order you expect. No configuration changes are required, but the behavioral change is real.

Kubescape v4.0.8 is a focused patch release that fixes several VAP (Validating Admission Policy) bugs and adds a --timeout flag to the deploy-library command.

• breakingVAP label selector parsing was silently wrong — verify your policies

  The old code split label selectors on '=' directly instead of using Kubernetes' label parser. DoubleEquals (==) selectors were also incorrectly accepted. If you've generated VAP policies with Kubescape and used complex label selectors, re-generate and re-validate those policies with v4.0.8. Don't assume previously generated output was correct.

• enhancementUse --timeout with VAP deploy-library in slow clusters

  The new --timeout flag on the deploy-library command lets you tune how long Kubescape waits during VAP library deployment. If your cluster has slow API server response times or you're running in CI with strict time limits, set this explicitly rather than relying on the default. Test in staging first to find a safe value before enforcing it in pipelines.

• enhancementConnector URL back-propagation fix matters for cloud API setups

  A bug where connector URLs weren't back-propagated to the config object during cloud API initialization is now fixed. If you use Kubescape's cloud integration and noticed inconsistent scan result submissions, this patch addresses the root cause. Upgrade and re-run a scan to confirm results are reaching your backend correctly.

Kubescape v4.0.7 is a broad bug-fix and usability release: better input validation, safer concurrency in the HTTP handler, a new ControlInput CRD, and service discovery without a sidecar.

• breakingThreshold flags now fail fast — check your CI pipelines

  Severity-threshold, compliance-threshold, and fail-threshold flags are now validated before the scan starts. Scripts or CI jobs that pass invalid threshold values will now exit immediately with an error rather than completing the scan and ignoring the flag. Review your scan invocations to confirm all threshold flags are valid before upgrading.

• enhancementDrop the sidecar for service discovery

  Service discovery now queries the Kubernetes API directly. If you've been running a sidecar specifically to support Kubescape's service discovery, you can remove it. Audit your deployments before upgrading to avoid unexpected behavior from redundant sidecars.

• enhancementDeploy the ControlInput CRD for in-cluster tuning

  The new ControlInput CRD lets you configure control inputs directly in the cluster rather than through external files. This only activates during live cluster scans, so file-scan workflows are unaffected. Apply the CRD after upgrading if you want to centralize scan policy configuration in-cluster.