Releases

Security-only patch fixing a path traversal vulnerability in chart extraction. Upgrade immediately if you pull charts from untrusted sources.

• securityPatch a chart extraction path traversal — upgrade now

  A crafted Chart.yaml using dot-segments (e.g., '..') in the chart name could cause Helm to write files outside the intended extraction directory. This is a classic directory traversal attack vector. If your pipelines pull charts from public repos, third-party registries, or any source you don't fully control, treat this as critical and upgrade to v3.20.2 today. Teams operating fully air-gapped with only internally authored charts have lower immediate risk, but should still upgrade on the next maintenance window.

Pure dependency maintenance release — proxy bumped to v2.348.0, multiple Go/Rust/JS deps updated. No feature changes or bug fixes to speak of.

• securitylodash updated in web dashboard — low urgency, but worth knowing

  lodash went from 4.17.23 to 4.18.1. The Linkerd dashboard is typically internal-facing, so exposure is limited. Still, if your team audits frontend dependency CVEs, confirm this resolves any open advisories in your SBOM tooling.

• enhancementProxy v2.348.0 — check the proxy changelog if you're chasing specific behavior

  The proxy is the only component here with potentially meaningful runtime changes. The release notes don't surface proxy-level details directly, so if you're tracking a specific fix or behavior change, pull up the linkerd2-proxy v2.348.0 release notes separately before promoting this edge build to production.

• enhancementSkip this edge unless you need the proxy bump

  This is a housekeeping release. If you're already tracking edge builds for the proxy, upgrading is straightforward. For anyone evaluating edge-26.4.x for broader testing, there's no functional regression risk here, but also nothing compelling enough to rush an upgrade from edge-26.4.1.

Falco 0.43.1 is a minimal patch release bumping libs to 0.23.2 and the container plugin to 0.6.4. No functional changes, no bug fixes — purely a dependency update.

• enhancementUpdate if you care about container plugin fixes in 0.6.4

  This release exists primarily to ship the container plugin 0.6.4 update alongside libs 0.23.2. If your environment relies on container metadata enrichment in Falco rules, check the container plugin 0.6.4 changelog for fixes that may affect your alerting fidelity. Otherwise, upgrading from 0.43.0 is low risk and low urgency — treat it as a routine dependency bump.

Helm v4.1.4 is a security-only patch fixing three vulnerabilities: chart extraction path traversal, plugin signature bypass, and plugin version path traversal enabling arbitrary file writes.

• securityUpgrade immediately — all three CVEs are exploitable via untrusted input

  Two of these bugs (chart extraction collapse and plugin version path traversal) allow writing files to arbitrary locations on the filesystem. The third lets anyone install an unsigned plugin if they control the distribution channel. If your CI/CD pipeline pulls charts or plugins from external or semi-trusted sources, you are exposed on any Helm version before this patch. Upgrade to v4.1.4 (or v3.20.3 when released April 8) now. Don't wait for a maintenance window.

• securityAudit your plugin sources before upgrading — unsigned plugins may have slipped through

  The provenance bypass (GHSA-q5jf-9vfq-h4h7) means any Helm installation that had plugin verification enabled could still have installed unsigned plugins if the .prov file was simply absent. Before upgrading, audit installed plugins with 'helm plugin list' and verify their origins manually. After upgrading, reinstall any plugins from official sources to ensure provenance is properly checked.

• enhancementPin Helm in CI to this exact version now

  If you use a floating version reference like 'latest' or a minor-pinned tag in your CI pipeline, update it to v4.1.4 explicitly. The Helm team also pinned the CodeQL action to a commit SHA in this release — a good reminder to apply the same discipline to your own toolchain dependencies.

Keycloak 26.6.0 graduates several preview features to fully supported — JWT Authorization Grant, Federated Client Auth, Workflows, and zero-downtime patch releases — while fixing a notable set of security bugs across UMA, SCIM, and Organizations.

• securityPatch SCIM and UMA vulnerabilities immediately

  Two separate SCIM bugs allowed IDOR-style resource modification and authorization bypass in group management. UMA permission grant accepted expired ID tokens and tokens issued to other clients. These are fixed in 26.6.0. If you use SCIM or UMA, upgrade now — no config change needed, but verify your SCIM plugin/extension is compatible with the new validation.

• breakingSwitch to KCRAW_ prefix if secrets contain $ characters

  If you inject passwords or secrets via environment variables and they contain $ characters (e.g., from a secrets manager), the KC_ prefix silently mangles them via SmallRye expression evaluation. Use KCRAW_<KEY> instead of KC_<KEY> to preserve literal values. Audit your current env var injection before upgrading — any secrets with ${ or $$ patterns may have been silently broken in prior versions.

• enhancementEnable zero-downtime rolling updates in your Operator deployments

  Zero-downtime patch releases are now on by default. If you run Keycloak via the Operator, explicitly set the update strategy to Auto to benefit. Also review the new graceful HTTP shutdown defaults (1s delay, 1s timeout) — adjust these upward if your reverse proxy takes longer to drain connections, especially in non-Kubernetes setups with longer-lived connections.

Flux v2.8.5 patches a cache race condition that could freeze Kustomizations, fixes Azure Blob prefix handling, and adds GCR Receiver verification fields.

• breakingStuck Kustomizations? This patch likely fixes you

  If you've seen Kustomizations get stuck after a reconciliation timeout or cancellation — often requiring a manual flux reconcile or pod restart to unblock — the race condition fix in kustomize-controller v1.8.3 directly addresses this. Upgrade to v2.8.5 and monitor your reconciliation loops post-upgrade. No config changes needed, but watch for Kustomizations that were previously stuck to automatically recover.

• breakingVerify Azure Blob prefix filtering actually works after upgrade

  If you're using Bucket sources backed by Azure Blob Storage with a prefix configured, that prefix was not being applied — meaning your source-controller was fetching more objects than intended. After upgrading to v2.8.5, the prefix filter will now take effect. Validate that your expected subset of blobs is still being synced correctly and that no previously-ignored paths break your deployments.

• enhancementTighten GCR webhook security with email and audience verification

  The GCR Receiver now accepts optional 'email' and 'audience' fields. If you're using GCR image push webhooks to trigger Flux reconciliation, add these fields to your Receiver spec to validate the service account identity and token audience — reducing the risk of forged webhook requests. This is opt-in, so existing setups won't break, but teams with strict security postures should configure it.

Flux v2.8.4 is a CLI-only patch fixing two bugs: Windows compatibility for 'flux build/diff ks' and source flag validation in 'create kustomization'.

• breakingCheck your 'create kustomization' scripts for invalid --source values

  The '--source' flag now validates input properly. Scripts or pipelines passing malformed source references that previously slipped through will now fail explicitly. Test your automation before rolling out the updated CLI in CI/CD pipelines.

• enhancementWindows users: upgrade to unblock 'flux build/diff ks'

  If your team uses Windows workstations or CI runners for Flux kustomization diffs, these commands were silently broken. Upgrade the CLI to v2.8.4 — the fix is CLI-side only, so no cluster-side changes are needed.

v1.14.0 fixes a potential deadlock in ListObjects, improves intersection algorithm performance, and adds BatchCheck caching — plus a SQL serialization bug fix that affects PostgreSQL users.

• securityPostgreSQL users: apply the SQL serialization fix

  The TupleOperation serialization and pgx.ErrNoRows fixes could cause silent data inconsistencies or incorrect error handling in PostgreSQL deployments. If you're running OpenFGA on Postgres, this fix alone justifies upgrading. Verify your tuple write/read behavior post-upgrade.

• breakingReview CVE-2026-33729 and upgrade immediately

  The changelog explicitly references CVE-2026-33729. The release notes don't detail the full scope, but a CVE update in a patch/minor release demands immediate attention. Upgrade to v1.14.0 now and audit your deployment's exposure before the CVE details become widely known.

• enhancementListObjects deadlock fix is critical for high-concurrency workloads

  A deadlock in the ListObjects pipeline is the kind of bug that only shows up under real production load. If you use ListObjects extensively — especially with concurrent callers — this fix is essential. After upgrading, stress-test ListObjects under your typical concurrency patterns to confirm stability.

• enhancementBatchCheck caching reduces authorization latency at scale

  If your application calls BatchCheck repeatedly with overlapping tuples or conditions, the new caching layer will cut latency and backend load. No configuration changes are mentioned, so the benefit should be automatic — but monitor cache behavior through the new tuple iterator query stats to validate the improvement in your environment.

Lima v2.1.1 is a focused patch release adding Windows binary artifacts and fixing a handful of edge-case bugs, with an important bundled nerdctl security update.

• securityUpdate nerdctl distribution for BuildKit and CNI security fixes

  The bundled nerdctl was bumped from v2.2.1 to v2.2.2, which updates BuildKit to 0.28.1 and CNI plugins to 1.9.1. Both upstream releases include security patches. If you use Lima's nerdctl template for container workloads, upgrade to v2.1.1 promptly and check the BuildKit and CNI plugin release notes to assess CVE impact for your environment.

• enhancementWindows users can now consume official Lima binaries

  Lima v2.1.1 ships pre-built Windows artifacts for the first time. If your team has Windows developers using Lima (e.g., via WSL2), point them at the official release binaries rather than maintaining custom builds. This simplifies onboarding and keeps everyone on a verified, reproducible build.

• enhancementFix UID range issues for enterprise/LDAP-managed macOS users

  macOS guests now accept UIDs outside the conventional range. If any users in your org run Lima on corporate-managed Macs with directory-assigned UIDs (common with LDAP or Active Directory integration), this fixes silent failures that were hard to diagnose. No config change needed — just upgrade.

Mostly a dependency maintenance release with two proxy bumps (v2.346.0, v2.347.0), a multicluster RBAC fix, and a Prometheus config correction for viz admin port names.

• securityCrypto dependency updates — low urgency but keep your upgrade cadence

  openssl, rustls-webpki, aws-lc-rs, and aws-lc-sys all received patch bumps this cycle. None carry disclosed CVEs, but these are core cryptographic libraries in the proxy. Stay on a regular edge upgrade cadence rather than skipping multiple releases, so these patches don't accumulate.

• breakingCheck Prometheus metrics after upgrading if you use Linkerd Viz

  The Prometheus config was corrected to match new admin port names. If you're running Linkerd Viz and upgraded from an earlier edge build, verify your dashboards still show expected metrics after the upgrade. Gaps in scraping could have silently existed before this fix — cross-check your Prometheus targets to confirm scrape health.

• enhancementMulticluster users: review Server/AuthorizationPolicy coverage

  Missing Server and AuthorizationPolicy resources were added for the multicluster extension. If you use Linkerd multicluster, upgrade and audit your cross-cluster authorization posture. The previous gap meant some traffic paths lacked proper policy objects, which could have caused unexpected allow/deny behavior depending on your default policy.

26.5.7 is a critical security release patching 7 CVEs, including privilege escalation, redirect URI bypass, and unauthorized cross-user permission grants. Upgrade immediately.

• securityPatch now — multiple high-severity CVEs in this release

  Seven CVEs are fixed here, spanning privilege escalation (CVE-2026-4282), redirect URI bypass (CVE-2026-3872), cross-user permission injection (CVE-2026-4636), and an unauthenticated DoS via scope processing (CVE-2026-4634). These aren't theoretical — attackers with basic access or even anonymous access could exploit several of these. Upgrade to 26.5.7 as fast as your change process allows. If you use UMA policies or expose the Admin REST API, treat this as an emergency patch.

• securityAudit Admin REST API access and UMA policy configurations post-upgrade

  CVE-2025-14083 (Admin API info disclosure) and CVE-2026-4636 (UMA cross-user permission grants) suggest that access controls around admin and UMA endpoints were not properly enforced. After upgrading, review which clients and service accounts have Admin REST API access, and audit your UMA resource/policy definitions for unexpected grants. Don't assume the patch alone closes the exposure if misconfigured principals already exploited these paths.

• enhancementQuarkus upgraded to 3.27.3 — monitor for runtime behavior changes

  The Quarkus runtime bump also pulls in a fix for CVE-2026-1002 (vertx-core static handler cache manipulation causing DoS on static files). If you serve static content through Keycloak or have customized themes, verify those assets load correctly after upgrade. Quarkus minor upgrades occasionally shift default configurations, so a smoke test on your login flows is worth running.

Prometheus v3.11.0 ships significant new discovery capabilities, TSDB experimental features, and a critical retention bug fix that could cause data to be kept 1,000,000x longer than configured.

• breakingFix TSDB retention unit bug before your disk fills up

  A unit mismatch in the config file parser caused `storage.tsdb.retention.time` to be interpreted as 1,000,000x the intended value. If you set retention via the config file (not CLI flags), your TSDB may be holding far more data than expected. Upgrade to 3.11.0 immediately and verify disk usage post-upgrade. Also note: CLI flag values are now the fallback when retention is removed from config, so review your configuration carefully.

• breakingMigrate Hetzner hcloud SD label references before July 2026

  `__meta_hetzner_datacenter` and `__meta_hetzner_hcloud_datacenter_location*` labels are deprecated for hcloud roles and will stop working after July 1, 2026. Audit all relabeling configs and recording rules that reference these labels. Replace with `__meta_hetzner_hcloud_location` and `__meta_hetzner_hcloud_location_network_zone`. The robot role keeps the old label for backward compatibility.

• enhancementCap TSDB disk usage with retention.percentage

  The new `storage.tsdb.retention.percentage` setting lets you define a maximum percentage of available disk that TSDB can use. This is a cleaner safety net than estimating byte-based retention limits, especially in environments with variable data volumes. Consider pairing it with the existing time-based retention rather than replacing it — both constraints apply.

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

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

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

• enhancementUse SBOM and cosign artifacts for supply chain verification

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

CRI-O v1.35.2 is a focused bug-fix patch addressing image pull credential verification, metrics reporting gaps, and OCI artifact store contamination issues.

• breakingVerify credential provider workflows after upgrading

  The PullImage fix changes what gets returned during image pulls. If you use Kubernetes credential provider plugins or have automation that validates image pull behavior, test those flows before rolling this to production. The old behavior could silently bypass credential checks in edge cases.

• enhancementAudit your metrics pipelines — you may have been missing data

  The metrics bug means any cluster running v1.35.x before this patch was likely returning incomplete metrics when 'all' was set. After upgrading, expect metric cardinality to increase. Check dashboards and alerting thresholds — a spike in metrics volume is expected and correct, not a problem.

• enhancementUse additional_artifact_stores for air-gapped or mirrored artifact setups

  If you run air-gapped clusters or internal artifact mirrors, the new 'additional_artifact_stores' option lets you configure multiple read-only sources without hacking around existing config. Pair this with the pinned_images fix to ensure pinned artifacts are pulled from the right store consistently.

CRI-O v1.34.7 is a patch release with no code changes or dependency updates from v1.34.6 — essentially a rebuild or release process artifact.

• enhancementSafe to skip unless you need the rebuild

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

v2.0.2 is a focused patch: wasmtime runtime bumped to v43, a new Kubernetes Host pod reconciler added, and install scripts smoothed out.

• enhancementUpdate to pick up wasmtime 43 runtime improvements

  Wasmtime 43 includes upstream bug fixes and performance work. If you're running v2.0.1 in production, this is a low-risk upgrade worth taking. No API changes expected on the wasmCloud side — just redeploy your hosts.

• enhancementKubernetes operators: test the new Host pod reconciler

  The Host pod reconciler adds smarter lifecycle handling for wasmCloud hosts running as Kubernetes pods. If you're using the wasmCloud operator, deploy this in a staging cluster first and validate that host pod restarts and scheduling behave as expected before rolling to production.

• enhancementWindows users can now install wash via winget

  wash is now in the winget package registry. Windows-based teams can standardize installs with 'winget install wash' instead of manual binary downloads — useful for onboarding and CI pipelines on Windows runners.

etcd v3.6.10 is a patch release in the 3.6 series. Release notes are minimal — check the full CHANGELOG for specifics before upgrading.

• breakingRead the upgrade guide before rolling this out

  The release explicitly warns of potential breaking changes in v3.6. Before upgrading any cluster, check the official upgrade guide for v3.6 and review the full CHANGELOG-3.6.md. Don't treat this as a routine drop-in patch without that review.

• enhancementPrefer gcr.io images over quay.io for production pulls

  etcd now designates gcr.io/etcd-development/etcd as the primary registry and quay.io/coreos/etcd as secondary. If your image pull policy or air-gapped mirror config still points primarily to quay.io, update it to reduce dependency on a secondary source.

etcd v3.5.29 is a maintenance release on the 3.5 branch with no detailed changelog published in the release notes themselves.

• securityVerify container image source after upgrade

  If you pull etcd images in CI/CD pipelines, confirm you're pointing to gcr.io/etcd-development/etcd as the primary registry. The quay.io mirror is secondary and may lag. Pin to the exact digest rather than the floating tag to avoid supply chain risk.

• breakingReview the official upgrade guide even for patch releases

  The release explicitly calls out that breaking changes may exist even in 3.5.x patch versions. Don't skip the upgrade guide. Test in a staging environment first, especially if you're running etcd as the backing store for Kubernetes — a botched etcd upgrade can take down your entire control plane.

• enhancementCheck CHANGELOG-3.5.md before upgrading

  The release notes here are skeletal — no specific fixes or changes are listed. Before upgrading any etcd cluster, pull up CHANGELOG-3.5.md on the etcd GitHub repo and filter for v3.5.29 entries. Patch releases on 3.5 typically carry bug fixes and CVE patches that aren't always obvious from the version bump alone.

etcd v3.4.43 is a maintenance release on the 3.4 branch. Release notes are sparse — check the full CHANGELOG for specifics before upgrading.

• breakingAlways consult the upgrade guide on 3.4 patch bumps

  Even on patch releases, the etcd team occasionally introduces subtle behavioral changes or deprecations. The official upgrade guide for v3.4 should be checked — don't assume a patch bump is always safe to apply without review, especially in etcd's case given its role as a control plane data store.

• enhancementReview CHANGELOG before upgrading

  The release notes themselves contain no inline change details. Before upgrading, pull up CHANGELOG-3.4.md directly and diff against your current version. 3.4.x patches typically carry bug fixes and CVE backports, so skipping the review risks missing a relevant fix or behavioral change.