リリース

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

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

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

v1.50.0 is a wide-ranging release with several breaking changes across auth, frontend APIs, and catalog. Key practical upgrades: AWS RDS IAM auth, Auth0 federated logout, catalog deadlock fixes, and security patches for rollup/glob.

• securityUpdate CLI and build tooling to pick up rollup path traversal fix

  rollup < v4.59 has a high severity path traversal vulnerability (GHSA-mw96-cpmx-2vgc). The @backstage/cli, repo-tools, and several CLI modules have been updated. Run the upgrade helper and update your lockfile. If you pin rollup versions anywhere in your workspace, update those pins to v4.59+. The glob dependency was also bumped to v13 to address vulnerabilities in v7/v8/v11.

• breakingVerify token decoding code before upgrading — ent claim removed by default

  auth.omitIdentityTokenOwnershipClaim now defaults to true, so Backstage user tokens no longer include the ent ownership claim. Any code that manually decodes tokens and reads ent will silently get nothing. Audit your codebase for raw token decoding and replace it with the userInfo core service. If you need time, set auth.omitIdentityTokenOwnershipClaim: false in your config temporarily, but plan to remove it — the setting will be dropped in a future release.

• breakingMigrate createSchemaFromZod to configSchema before upgrading frontend-plugin-api

  The deprecated createSchemaFromZod helper is gone in @backstage/[email protected]. Any extension or blueprint using it will fail at runtime. Check the 1.50 migration docs at backstage.io/docs/frontend-system/architecture/migrations#150 and switch to the configSchema option. Note that plain zod v3 schemas are not supported — use import { z } from 'zod/v4' from the zod v3 package or upgrade to zod v4.

containerd v2.2.3 patches CVE-2026-35469 in spdystream and fixes several bugs including whiteout handling in parallel unpacks, TOCTOU race in tar extraction, and Go 1.24 symlink regressions.

• securityPatch CVE-2026-35469: upgrade to v2.2.3 now

  CVE-2026-35469 affects moby/spdystream, which containerd uses for streaming connections. The fix is in spdystream v0.5.1, bundled in this release. If you're running any 2.2.x version, treat this as a mandatory upgrade — don't wait for your next maintenance window.

• breakingParallel unpack whiteout bug could mean corrupted layer state — verify images

  A bug caused whiteout files (which signal file deletions between layers) to be ignored when parallel unpack was enabled. If you've been using parallel unpack with overlayfs, layer deletion semantics may not have applied correctly. After upgrading, re-pull any images that were unpacked in parallel to ensure their layer state is consistent.

• enhancementGo 1.24 users on NixOS or symlink-heavy rootfs: this fixes your container startup failures

  Absolute symlink handling in rootfs user/group lookups regressed with Go 1.24. This affected systems where /etc/passwd or /etc/group are symlinks (common on NixOS-style setups). If you've seen user lookup failures or container start errors after moving to Go 1.24-built binaries, upgrading to v2.2.3 resolves this.

containerd 2.0.8 patches CVE-2026-35469 in spdystream, fixes a credential leak in CRI error messages, and resolves a CNI DEL lifecycle bug after containerd restarts.

• securityPatch CVE-2026-35469 by upgrading to 2.0.8 now

  CVE-2026-35469 lives in the moby/spdystream dependency. Details are in a GitHub security advisory. If you're running containerd 2.0.x in any cluster, upgrade to 2.0.8 — this is the primary reason for the release. Don't wait for your next maintenance window if the advisory turns out to be high severity.

• securityCheck your pod event logs for past credential exposure

  Before this fix, registry credentials or other secrets embedded in URLs could appear in plaintext inside CRI gRPC error messages and pod events. If you're shipping pod events to a logging backend (Datadog, Splunk, ELK, etc.), audit recent logs for query parameters that shouldn't be there. Going forward, 2.0.8 redacts these before they leave containerd.

• breakingValidate CNI network cleanup works correctly after upgrading

  The CNI DEL bug meant network namespaces and CNI plugin state weren't cleaned up when a pod was deleted after a containerd restart. This could leave stale network state on nodes. After upgrading to 2.0.8, verify that pod deletion properly invokes CNI DEL — especially on nodes that have experienced containerd restarts. If you've noticed orphaned network interfaces or IP allocation issues, this fix is the likely culprit.

containerd 2.1.7 patches CVE-2026-35469 in spdystream and ships several hardening fixes including credential leak prevention via gRPC and a TOCTOU race in tar extraction.

• securityPatch CVE-2026-35469 by upgrading to 2.1.7 now

  CVE-2026-35469 in moby/spdystream is fixed in this release. spdystream is used in the CRI streaming path, so any cluster running Kubernetes workloads with exec/attach/port-forward is potentially exposed. Upgrade containerd to 2.1.7 on all nodes. No config changes needed, just a binary swap and daemon restart.

• securityCredential leak via gRPC pod events is now closed

  Before this fix, raw errors containing registry credentials could surface in pod events visible to namespace-scoped users. If your clusters allow broad pod event access, assume credentials may have been exposed in logs or event streams. Rotate any registry pull secrets used on affected clusters, then upgrade to 2.1.7 to prevent recurrence.

• enhancementCNI DEL fix prevents IP/resource leaks after restarts

  A bug meant CNI DEL was never called for sandboxes cleaned up after a containerd restart, leaking network resources. If you've seen stale IPs or CNI state after node restarts, this is likely why. Upgrade to 2.1.7 and consider draining nodes before restarting containerd to clear any existing leaked state.

v1.7.31 patches CVE-2026-35469 in spdystream, fixes a CNI DEL regression after restarts, and closes a credential leak in pod events via gRPC error sanitization.

• securityPatch CVE-2026-35469 by upgrading to v1.7.31 now

  CVE-2026-35469 affects the moby/spdystream library used for SPDY multiplexing. The fix is in spdystream v0.5.1, bundled here. If you're running any 1.7.x release prior to this, upgrade immediately — especially on clusters where the CRI streaming server is exposed or where kubectl exec/attach/port-forward traffic flows through containerd.

• securityAudit pod event logs for previously leaked credentials

  A bug caused raw error messages — potentially containing registry credentials — to be returned over gRPC and surface in pod events. After upgrading, review historical pod event logs (kubectl get events, or your log aggregation system) for any entries containing auth tokens, passwords, or image pull secrets from before this fix was applied. Rotate any credentials you find.

• breakingVerify CNI network teardown is working correctly after upgrade

  The CNI DEL fix means containers that previously left behind stale network state after a containerd restart will now properly clean up. This is the right behavior, but if you have automation or scripts that assumed CNI DEL was idempotent-by-absence (i.e., expected cleanup to be skipped), test those workflows. Nodes with a history of unclean restarts may see cleanup activity on first pod deletion post-upgrade.

v2.12.7 is a targeted bug-fix release addressing ACL bypass vulnerabilities, multiple leafnode panics, a JetStream consumer stuck state, and an MQTT JWT regression from 2.12.6.

• securityPatch ACL bypass bugs immediately if you use deny rules or queue groups

  Two ACL enforcement bugs are fixed here. Overlapping wildcard patterns in deny ACLs were not enforced correctly, and queue subscriptions could bypass non-queue deny rules entirely. If your security model relies on deny-based ACLs — especially with wildcards or mixed queue/non-queue subscribers — treat this as a must-upgrade. Audit your ACL configurations after upgrading to confirm expected deny behavior is active.

• breakingMQTT users on 2.12.6 must upgrade — auth callout JWT was broken

  If you deployed 2.12.6 with MQTT clients using auth callout, JWTs were not being forwarded to the callout service, meaning your auth logic was silently bypassed or failing. This regression is fixed in 2.12.7. Upgrade immediately and verify MQTT client authentication is functioning end-to-end.

• enhancementmax_mem_store and max_file_store can now be increased via config reload

  You can now raise JetStream storage limits without restarting the server — just update the config and reload. Decreasing is still not supported via reload. Useful for capacity adjustments during peak periods without downtime. Plan your storage sizing with headroom so you can expand reactively if needed.

v2.11.16 is a security-focused patch fixing multiple ACL bypass vulnerabilities in queue subscriptions, leafnode inbound messages, and wildcard deny patterns — update immediately if you rely on NATS authorization.

• securityACL bypass via queue subscriptions — patch now

  Queue subscribers could silently bypass deny rules intended for non-queue subscriptions. If your authorization model uses deny patterns to restrict subjects, those controls were not reliably applied. Audit your ACL configurations and update to v2.11.16 before anything else. This affects any multi-tenant or permission-isolated NATS deployment.

• securityLeafnode ACL enforcement was incomplete — verify your leaf configs

  Inbound messages on leafnode connections were not always checked against ACL permissions. If you run leafnode-connected clusters with per-account or per-user authorization, treat this as a potential unauthorized data access vector. After upgrading, review leafnode user credentials and their associated permission sets.

• breakingno_auth_user scope change may affect existing setups

  The no_auth_user option is now restricted to client connections only. If you had any tooling or configuration relying on no_auth_user applying to leafnode or other non-client connection types, those connections will now require explicit credentials. Test in staging before rolling this update to production leafnode infrastructure.

TiKV v8.5.6 brings column-level privileges, multi-dimensional slow query rules, shared locks for FK checks, and ~13 bug fixes including a memory leak in crossbeam skiplist and a rare pessimistic transaction data inconsistency.

• securityColumn-level privileges close a data isolation gap — audit your schemas

  TiDB now supports MySQL-compatible column-level GRANT/REVOKE. If you've been relying on view-based workarounds to restrict access to sensitive columns (PII, financial data), you can now enforce this at the privilege layer instead. Audit tables that contain sensitive columns and apply least-privilege grants. This also means existing privilege audits may be incomplete — review user grants against newly exposed column-level controls.

• breakingMigrate off Statistics Version 1 now — it's deprecated and removal is coming

  tidb_analyze_version=1 is deprecated in this release and will be removed in a future version. Run SHOW VARIABLES LIKE 'tidb_analyze_version' on all instances. If any are on v1, switch to v2 and re-run ANALYZE on affected tables. Version 2 produces more accurate histograms and is the only supported path going forward. Don't wait until the removal forces a rushed migration.

• enhancementEnable shared locks for FK checks to cut contention in write-heavy workloads

  If you run high-concurrency INSERT/UPDATE on child tables with foreign key constraints pointing to a small set of parent rows, you're likely hitting exclusive lock contention today. Set tidb_foreign_key_check_in_shared_lock=ON and benchmark — shared locks on the parent table allow concurrent FK checks without blocking each other. Test in staging first, as this changes locking semantics. Also pick up the fix for the pessimistic transaction prewrite retry inconsistency (issue #11187) — worth verifying your TiKV nodes are on this patch if you run pessimistic workloads.

v2.0.3 patches a NATS race condition, adds Kubernetes EndpointSlice support, hardens container security with non-root ownership, and expands Helm chart configurability.

• securityUpgrade now: containers finally run as non-root by default

  Previous releases ran with root ownership, which is a container security red flag. This release sets non-root ownership by default. If you have volume mounts or init containers with root-dependent file permissions, test before rolling to production — you may need to adjust fsGroup or runAsUser settings in your pod specs.

• breakingHelm chart image tag behavior changed — audit your values files

  The default image tag no longer falls back to a hardcoded value; it now uses the chart's appVersion. If you rely on overriding the tag in your values files, this likely works as-is. But if you were depending on the old default tag behavior for pinning, verify your deployed image versions after upgrading the chart.

• enhancementEnable EndpointSlice support if running Kubernetes 1.21+

  EndpointSlice is the modern replacement for Endpoints and scales better with large service backends. If your cluster runs Kubernetes 1.21 or later, enable this feature — it reduces load on kube-apiserver and avoids the scaling limits of the classic Endpoints API. Check your Helm values for the new endpointslice configuration option.

OpenCost v1.120.0 adds OVH cloud provider support, AWS CUR 2.0 compatibility, and fixes several resource leaks and bugs across AWS, DigitalOcean, and S3 integrations.

• breakingCheck PV cost accuracy after upgrading — unit parsing was broken

  PV capacity was previously mishandled for Ki/Mi/Gi/Ti units, which means PV cost allocations may have been wrong in earlier versions. After upgrading, verify your PV cost data looks correct, especially if you were seeing anomalous persistent volume costs.

• enhancementMigrate to AWS CUR 2.0 if you haven't already

  AWS is deprecating CUR 1.0 — this release adds CUR 2.0 support. If you're still on CUR 1.0 exports, now is the time to update your AWS billing export configuration and point OpenCost at the new format. Don't wait for AWS to force the migration.

• enhancementSuppress noisy Spot feed warnings with the new toggle

  Teams not using AWS Spot instances were getting misleading log warnings about spot data feeds. You can now explicitly disable the Spot Data Feed via config. Set the toggle if you're not using Spot — it cleans up your logs and removes the misleading provider log noise fixed in this release.

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

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

Prometheus v3.11.2 patches a stored XSS vulnerability (CVE-2026-40179) in the web UI, plus two Consul SD fixes. Upgrade immediately if your UI is exposed.

• securityPatch CVE-2026-40179 immediately if your Prometheus UI is reachable

  A stored XSS can be triggered by crafted metric names or label values — meaning any scrape target you ingest data from could potentially inject malicious scripts into your UI. If your Prometheus endpoint is accessible to users beyond the ops team (internal dashboards, federated setups), treat this as urgent. Upgrade to v3.11.2 now. If you can't upgrade immediately, restrict UI access via network policy or auth proxy until you can.

• breakingVerify Consul SD behavior after the Health API filter fix

  The filter parameter was previously applied incorrectly to the Consul Health API. After upgrading, your Consul service discovery results may change if you were relying on that filter — intentionally or not. Review your Consul SD configs and validate that the services being scraped post-upgrade match your expectations before rolling out to production.

• enhancementUse `health_filter` in Consul SD to reduce noise from unhealthy services

  The new `health_filter` field lets you filter Consul Health API responses directly at the SD layer. If you've been working around this with relabeling rules to drop unhealthy instances, you can now clean that up. Set `health_filter` to `healthy` in your Consul SD config to only scrape passing services and reduce unnecessary target churn.

Prometheus v3.5.2 was released, but the published notes are too brief to summarize. See the original release notes for details.

v0.150.0 is a maintenance release with targeted bug fixes: corrects the print-config unredacted output, redacts internal telemetry OTLP headers in marshaled config, and fixes a bounds-check crash in the debug exporter.

• securityTelemetry exporter headers now redacted in marshaled config

  Internal telemetry OTLP exporter headers are now redacted when configuration is marshaled. If you log or store marshaled config output anywhere, headers (which may contain auth tokens) were previously exposed in plaintext. Upgrade and audit any stored config snapshots.

• enhancementFix print-config unredacted mode to show defaults

  The print-config command's unredacted mode previously dropped all default-valued options from output. Fixed by introducing confmap.WithUnredacted MarshalOption. If your team uses print-config for auditing or debugging configuration, re-run it after upgrading — the output is now complete and trustworthy.

Patch release fixing a Helm chart YAML generation bug when webhook.config and webhook.volumes are both set, plus Go 1.26.2 upgrade to address dependency vulnerabilities.

• securityDependency vulnerabilities patched — upgrade to get the fixes

  The Go runtime and dependencies were bumped specifically to address reported CVEs. The release notes don't call out specific CVE IDs, but don't let that slow you down — cert-manager sits in a privileged position in your cluster handling certificate issuance, so keeping it current on security patches is non-negotiable. Schedule an upgrade in your next maintenance window.

• breakingUpgrade immediately if you use both webhook.config and webhook.volumes

  If your Helm values set both webhook.config and webhook.volumes, the chart has been generating invalid YAML — meaning your webhook may have silently deployed with incorrect configuration. Upgrade to v1.20.2 and redeploy, then verify the webhook pod is running with the expected volume mounts and config.

Envoy v1.37.2 is a patch release fixing three runtime bugs: a crash on listener removal, incomplete body forwarding in dynamic module filters, and a request hang on buffer overflow during internal redirects.

• breakingUpgrade immediately if using process-level access log rate limiting

  If your Envoy config uses a process-level access log rate limiter and you perform any listener hot-reload or removal, you are hitting a crash path. This is not a low-probability edge case — listener removal happens during routine config updates via xDS. Upgrade to v1.37.2 before your next config push.

• breakingCheck dynamic module filter pipelines for body truncation

  If you run dynamic module filters alongside other filters that buffer request or response bodies (e.g., ext_proc, gRPC transcoding, JWT body inspection), you may have been forwarding truncated payloads upstream or to clients without any error. Audit logs for unexpected body size mismatches and validate behavior in staging after upgrading.

• breakingInternal redirect with large request bodies could hang — patch this now

  Any route config using internal redirects combined with upstream services that can trigger redirects on large POST/PUT bodies is a hang risk. The request stalls rather than returning an error, which means your upstream timeout is the only safety net. This is a silent reliability failure. Upgrade and consider temporarily tightening request buffer limits on affected routes as a short-term guard.

Envoy v1.36.6 is a patch release fixing two bugs: incomplete body delivery in dynamic module filters and a request hang when internal redirect triggers buffer overflow.

• breakingUpgrade if you use dynamic module filters with buffering neighbors

  If your filter chain mixes dynamic module filters with any filter that buffers the body (e.g., ext_proc, grpc-web, or custom buffering filters), you were silently receiving incomplete bodies. This is a data-correctness bug, not just a performance issue. Upgrade to v1.36.6 immediately and validate that your dynamic modules are processing full payloads post-upgrade.

• breakingInternal redirect + buffer overflow caused indefinite request hang

  Any deployment using internal redirects where the request body can exceed the configured buffer limit was exposed to hung requests — requests that never complete and hold connections open. This is particularly dangerous under load. Upgrade now; in the interim, consider raising buffer limits or disabling internal redirects if you're seeing stuck requests.

v1.14.1 patches a host-header poisoning vulnerability in AuthZEN discovery and removes a vulnerable Docker dependency, plus minor ListObjects performance gains.

• securityPatch the AuthZEN host-header poisoning vulnerability now

  The AuthZEN well-known discovery endpoint was returning URLs built from the request's Host header. An attacker could poison this to redirect clients to a malicious endpoint. If you expose the AuthZEN discovery metadata publicly, upgrade to v1.14.1 immediately. No config change needed — the fix is automatic once upgraded, as long as authzen.baseURL is correctly set in your server config.

• securityAudit your image builds if you ship the OpenFGA test binary

  The github.com/docker/docker package carries known CVEs and was only used in test code. Production builds are unaffected, but if your pipeline somehow includes test binaries or vendor directories in container images, verify they no longer include the vulnerable package after upgrading.

• enhancementSet an explicit server shutdown timeout for Kubernetes workloads

  The new shutdown timeout config option lets you control how long OpenFGA waits to drain in-flight requests before exiting. Without this, abrupt shutdowns can cause request errors during pod restarts. Set this to slightly less than your Kubernetes terminationGracePeriodSeconds to ensure clean handoff.

Dapr 1.17.4 patches seven bugs spanning workflow correctness, Pulsar OOM risk, actor freeze under placement pressure, and a Go stdlib security update. Deploy promptly if you use any of these features.

• securityUpgrade immediately for Go stdlib CVE fixes

  Go 1.25.9 patches vulnerabilities in archive/tar, crypto/tls, crypto/x509, html/template, and the compiler. All Dapr binaries and Docker images are rebuilt with the patched toolchain. Update your Dapr runtime to 1.17.4 now — no config changes needed, just the version bump.

• breakingPulsar processMode behavior has changed — validate your component config

  If you set processMode in Pulsar component YAML before this fix, it was silently ignored and you were running in default mode. After upgrading, the setting takes effect. If you had processMode: sync expecting ordered processing but were unknowingly running async, behavior will change. Also, async mode now caps concurrency at maxConcurrentHandlers (default 100). Review your Pulsar component metadata and test throughput behavior before rolling to production.

• enhancementEliminate actor/workflow freeze risk from placement slowness

  The placement dissemination freeze bug could cause cascading health check failures during rolling updates — Kubernetes would declare pods unhealthy and restart them, worsening the cycle. With 1.17.4, a slow peer triggers reconnect rather than a fatal teardown. If you've seen unexplained actor hangs or zombie daprd processes during rollouts, this is likely the cause. No configuration change needed; upgrading is sufficient.

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

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

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.

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

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

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

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.

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

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

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

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.

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

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

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

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.