Releases

Longhorn v1.11.3 is a bugfix rollup addressing over a dozen stability issues across volume operations, backups, and instance management. One upgrade prerequisite applies: the CSI external provisioner is now v6.3.0, requiring Kubernetes v1.34 or later when upgrading from v1.10.x or v1.11.0.

• breakingKubernetes v1.34+ required when upgrading from v1.10.x or v1.11.0

  The bundled CSI external provisioner is bumped to v6.3.0, which requires Kubernetes v1.34 or later. If your cluster runs an older Kubernetes version and you are upgrading from Longhorn v1.10.x or v1.11.0, bring Kubernetes to v1.34+ first before applying this upgrade.

Dragonfly v2.5.0 is a feature release adding Hugging Face/ModelScope model downloads, a P2P injector webhook, download blocklisting, and broad rate limiting, alongside a breaking removal of deprecated V1 preheat API endpoints and health check consolidation to /healthy. It also ships numerous bug fixes and Nydus subproject improvements.

• breakingV1 preheat API endpoints removed

  Applies unconditionally starting v2.5.0: the deprecated V1 preheat API endpoints have been removed. Any automation or integration still calling V1 preheat routes must migrate to the current preheat API before upgrading.

• breakingHealth checks consolidated to /healthy

  Applies unconditionally starting v2.5.0: health checks are consolidated onto a single /healthy endpoint. Update load balancer, Kubernetes probe, and monitoring configs that point at old or multiple health check paths.

• enhancementEmergency download blocklist

  Available now via Manager console: operators can configure a blocklist to disable specific downloads as an emergency brake. Blocked gRPC calls return PermissionDenied and blocked HTTP proxy calls return FORBIDDEN, useful for incident response.

• enhancementRate limiting across gRPC and client paths

  Available now across Manager/Scheduler gRPC servers and clients: rate limiting covers bandwidth, upload/download requests, and adaptive limiting. Review limits before rollout to avoid unexpected throttling of legitimate traffic.

Rook v1.20.1 is a patch release focused on Ceph operator stability: Ceph CSI driver compatibility, OSD major-version handling, and CSI-addons disabled by default to reduce unexpected behavior.

• breakingCSI-addons disabled by default — check cluster dependencies

  CSI-addons (snapshot, clone, and expansion features) are now disabled by default in v1.20.1. If your workloads rely on these features, you must explicitly enable them in the Ceph cluster spec or your RWX volume snapshots and clones will fail. Review helm values and operator configs to enable addons before upgrade if needed.

• enhancementUse node labels for OSD device class assignment instead of manual mapping

  Instead of hardcoding device class assignment per node, you can now use Kubernetes node labels (like `disk-type: ssd`) to automatically classify OSDs. This simplifies scaling clusters with mixed hardware. Apply node labels, then reference them in the Ceph cluster spec to avoid per-node configuration drift.

• enhancementOSD require-osd-release is now enforced after major Ceph upgrades

  After a major Ceph version upgrade (e.g., Quincy to Reef), Rook now sets `require-osd-release` automatically to prevent old OSDs from rejoining before the cluster is ready. Before upgrade, ensure all OSDs can be updated together; if you have pinned some OSDs to an older version, they will be blocked from joining until unpinned.

Rook v1.20 hands CSI driver management to the Ceph CSI operator — a breaking change for anyone with custom CSI config — while adding encrypted OSD resize, Vault Agent SSE-S3, and stabilizing concurrent cluster reconciliation.

• breakingMigrate CSI config to Ceph-CSI operator before customizing anything

  Existing clusters will survive the upgrade with previously applied CSI settings, but any future CSI changes must go through the Ceph-CSI OperatorConfig and Driver CRs — not the Rook configmap. Helm users need the ceph-csi-drivers chart for operator settings (custom images stay in rook-ceph chart values). Audit your current CSI customizations now and plan the migration path before upgrading. Don't wait until you need to change a CSI setting post-upgrade to figure this out.

• enhancementAudit CRUSH rules before upgrading if you rely on custom ones

  Rook now deletes unused CRUSH rules by default on mgr startup. If your environment has CRUSH rules that appear unused but are intentionally retained for failover or manual placement, set ROOK_DELETE_UNUSED_CRUSH_RULES=false in the operator config before upgrading. Losing custom CRUSH rules silently is the kind of thing that only hurts when you need them most.

• enhancementEnable concurrent cluster reconciliation if running multiple Ceph clusters

  ROOK_RECONCILE_CONCURRENT_CLUSTERS is now marked stable after testing in prior releases. If you manage multiple CephCluster objects in one operator, enable this setting to reduce reconciliation bottlenecks. This is especially useful in multi-tenant or multi-cluster operator deployments where one slow cluster previously blocked others.

Longhorn v1.12.0 promotes the V2 Data Engine to GA, ships dual-stack/IPv6 support, and fixes critical instance-manager panics and replica scheduling bugs that caused cascading volume failures.

• breakingMigrate V2 backing image volumes before upgrading

  Any V2 volume created from a backing image cannot be upgraded in-place. Before upgrading to v1.12.0, back up each affected volume, delete it, and restore from backup — the restored volume has no backing image dependency. Skipping this step will cause attach failures post-upgrade. Use CDI for future VM disk image imports.

• breakingDetach V2 volumes before patch-level upgrades

  V2 volumes do not support live upgrades between v1.12.x patch releases. Plan maintenance windows to detach all V2 volumes before applying patch upgrades. Live upgrade across minor versions (v1.12 to v1.13) is planned but not yet available.

• breakingEncrypted migratable volumes need engine image upgrade before live migration

  The LUKS2 header pre-allocation fix for encrypted volumes introduces a constraint: live migration of encrypted volumes requires engine image CLI API version 12 or later. Upgrade the engine image to v1.12.0+ before attempting live migration; otherwise migration will fail.

• enhancementReview SPDK CPU allocation on existing V2 deployments

  The default CPU mask now uses 2 cores instead of 1. For clusters already running V2 volumes with a manually set single-core mask, consider increasing it — single-core configs under heavy I/O cause RPC starvation and operational instability. On ARM64 with NVMe-backed node disks, avoid multi-core SPDK configs for now and use AIO-backed disks until the stuck I/O bug is resolved.

• enhancementEnable dual-stack networking — but verify node IP family ordering first

  Dual-stack Kubernetes clusters are now supported, but only when all nodes have IP families configured in the same order (all IPv4-first or all IPv6-first). Audit your node network configs before enabling. Mixed ordering causes replica-to-engine connectivity failures with no obvious error surface.

Rook v1.18.11 patches liveness probe stability, OSD disk handling, and CSI priority class assignment. No major breaking changes, but one CSI component fix may shift pod scheduling.

• breakingCSI priority class name correction

  CSI provisioner and plugin priority class names were swapped in earlier v1.18.x releases (PR #17361). If you've set custom CSI priority classes, check your PVCs and plugin pods after upgrade — the correct priority class will now apply to the right component, potentially changing scheduling behavior for storage workloads.

• enhancementFix liveness probe script formatting

  Rook v1.18.11 removes newlines from liveness probe scripts (PR #17420). If your Ceph cluster's liveness probes are flaky or generating spurious restarts, upgrade immediately — the whitespace issue could be interfering with probe output parsing. No breaking changes, but the fix eliminates a source of operational noise.

• enhancementDisk zapping for forced OSD installation

  The disk zapping feature for forced OSD installation (PR #17533) gives you explicit control over device reuse. If you're adding storage to existing nodes or recovering failed OSD slots, update to v1.18.11 and review your OSD discovery workflow — you can now force installation on previously used disks without manual intervention.

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.

Vitess v24.0.1 is a focused patch release fixing a VTGate query planner bug with DML subqueries, reverting a problematic VTOrc flag, and resolving flaky VTTablet unit tests.

• breakingRemove VTOrc --cells-to-watch flag if you added it

  The 'cells to watch' flag introduced in #19354 has been reverted. If you added this flag to your VTOrc configuration or startup scripts after upgrading to v24.0.0, remove it before upgrading to v24.0.1 — VTOrc will fail to start with an unrecognized flag error.

• enhancementUpgrade if you use DML subqueries through VTGate

  A query planner bug affected IN/NOT IN subqueries inside DML statements (INSERT/UPDATE/DELETE). Merged subqueries weren't being substituted correctly via ListArg placeholders, which could produce wrong query behavior. If your application runs DML with subqueries routed through VTGate, this patch directly addresses that correctness issue — upgrade promptly.

v23.0.4 is a stability-focused patch release fixing multiple panics in VTOrc, VTGate, and ERS, plus critical VReplication and routing rule bugs that could silently misdirect traffic.

• securityGo upgraded to 1.25.9 — check your custom builds

  The Go runtime was bumped from 1.25.8 to 1.25.9 within this release cycle. If you build Vitess from source or maintain custom images, rebuild against go1.25.9 to pick up any runtime-level fixes included in that Go patch release.

• breakingUpgrade immediately if you use ERS or semi-sync replication

  Three separate ERS bugs were fixed: nil pointer panics during errant GTID detection, broken cancellation logic, and IO threads not restarting on replicas after ERS failure. Any of these can leave your cluster in a degraded state after a failover. If you run semi-sync with VTOrc, the ReplicationStopped + PrimarySemiSyncBlocked deadlock fix is equally critical — it could stall recovery entirely. Upgrade before your next planned maintenance window at the latest.

• enhancementRouting rule and schema-tracker fix affects multi-keyspace setups

  VTGate was not rebuilding routing rules after schema-tracker updates, and was dropping the target keyspace during routing rule AST rewrites. Both are silent bugs — queries appear to work but may land on the wrong keyspace. If you use routing rules with multiple keyspaces, validate query routing behavior after upgrading to confirm traffic is going where you expect.

Longhorn v1.11.2 is a stability-focused patch fixing CSI scheduling breakage in compute/storage split architectures, infinite replica scheduling loops, and memory bloat in longhorn-manager.

• breakingFix CSI scheduling in compute/storage split clusters — action required

  If you run a dedicated compute/storage node architecture and use WaitForFirstConsumer PVCs, your pods may have been stuck pending due to compute nodes reporting 0 CSI capacity. Upgrade to v1.11.2 and configure the new CSIStorageCapacity setting to prevent capacity reporting on non-storage nodes. Check your Longhorn settings after upgrade and validate that pending PVCs now schedule correctly.

• breakingReplica Auto-Balance infinite loop — upgrade if you use Auto-Balance

  A bug caused Replica Auto-Balance to enter an infinite scheduling loop, which wastes CPU and can destabilize volume operations. If Auto-Balance is enabled in your cluster, this is a strong reason to prioritize this patch. No config change needed after upgrade — the fix is in the reconciliation logic.

• enhancementMemory savings in longhorn-manager — relevant for large clusters

  Informer caching for longhorn-manager has been optimized to reduce cluster-wide memory consumption. In large clusters with many nodes and volumes, this can meaningfully reduce the manager pod's footprint. No action required beyond upgrading, but worth monitoring memory usage before and after to quantify the improvement in your environment.

Vitess v24 ships structured JSON logging by default, window function pushdown for sharded keyspaces, OpenTelemetry tracing, and a security fix for backup manifest command injection. 460 PRs merged.

• securityBackup MANIFEST command injection is now blocked by default

  Prior to v24, an attacker with write access to backup storage could modify the MANIFEST file to inject arbitrary shell commands that VTTablet would execute during restore. This is now blocked — the MANIFEST decompressor field is ignored unless you explicitly pass --external-decompressor-use-manifest. If you're on v23 or earlier, treat backup storage access controls as a security boundary and audit who can write to it.

• breakingAudit backup restore configs for MANIFEST decompressor

  If your VTTablet restore process relied on the decompressor command stored in backup MANIFESTs (i.e., you never set --external-decompressor but backups still decompressed), restores will silently skip decompression in v24 and likely fail. Add --external-decompressor-use-manifest to your VTTablet config to preserve old behavior, but read the security advisory first: a compromised backup store could execute arbitrary commands on your tablet. Evaluate whether you actually need this or can pass --external-decompressor explicitly instead.

• breakingRemove deprecated VTOrc API endpoint and metric references

  The /api/replication-analysis endpoint returns 404 in v24 — any monitoring scripts, Grafana dashboards, or alerting rules hitting that URL will break silently or with errors. Switch to /api/detection-analysis (same params, same response format). Also replace DiscoverInstanceTimings with DiscoveryInstanceTimings in dashboards. Do this before deploying v24 to production.

• enhancementMigrate tracing to OpenTelemetry now, not in v25

  opentracing-jaeger and opentracing-datadog are deprecated in v24 and will be removed in v25. The migration is straightforward: replace --tracer opentracing-jaeger with --tracer opentelemetry, and swap --jaeger-agent-host host:port for --otel-endpoint host:4317. Jaeger v1.35+ accepts OTLP on port 4317 by default. Datadog users should point to the Agent's OTLP ingestion endpoint. Do this upgrade cycle, not the next one.

• enhancementAdd --cell flag to VTOrc now

  --cell is optional in v24 but becomes required in v25. Multi-cell deployments especially should add it now — startup validation against the topology will catch misconfiguration early, and it unblocks future cross-cell recovery logic in VTOrc. One flag, no downtime, avoids a forced change next release.

Rook v1.19.5 patches several operator bugs including a CSI priority class swap, OSD CRUSH device class fix, and more reliable mon drain behavior.

• breakingAudit CSI priority classes after upgrade — they were swapped

  The provisioner and plugin priority class names were assigned to the wrong CSI components. If you set custom values for these fields, verify that your workloads are getting the priority you intended post-upgrade. Clusters running latency-sensitive storage I/O with tiered priority classes are most at risk. Check the assigned priority classes on CSI pods after the upgrade and adjust your Helm values if needed.

• enhancementUpgrade if you've hit silent CRUSH device class failures on OSD re-discovery

  When OSDs were re-discovered (e.g., after node replacement or OSD recreation), the CRUSH device class wasn't being reapplied. This caused OSDs to land in the wrong CRUSH bucket, potentially breaking data placement rules. If you use device classes (hdd/ssd/nvme) for pool or rule targeting, verify your OSD tree after upgrading to confirm correct class assignments.

• enhancementSet ROOK_UNREACHABLE_NODE_TOLERATION_SECONDS via Helm now

  Previously this required patching the operator deployment directly. With this release it's a first-class Helm value. If you've been working around this with post-install patches or custom operator manifests, clean those up and move the setting into your values file to avoid drift.

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

• breakingMulti-cluster deployments: apply the RBAC fix immediately

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

• enhancementForceful OSD replacement is now cleaner with disk zap

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

• enhancementAdd labels to RGW services for better traffic routing

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

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.

Rook v1.19.3 delivers targeted fixes and additions across CSI, pool management, OSD operations, and RGW — with a notable shift to ceph-csi-operator for CSI deployments.

• breakingCSI now deploys via ceph-csi-operator — verify your deployment model

  The shift to ceph-csi-operator for deploying Ceph-CSI/NVMe-oF changes how CSI components are managed. If you have customized CSI sidecar configurations or rely on specific deployment behavior, audit your setup before upgrading. The ceph-csi-operator introduces its own CRDs and reconciliation loop, so any direct overrides you've applied to CSI DaemonSets or Deployments may be overwritten or ignored post-upgrade.

• enhancementEncrypted OSD users: apply the lockbox key rotation fix now

  The lockbox key rotation bug for encrypted OSDs could leave your cluster in an inconsistent encryption state over time. If you're running encrypted OSDs, upgrade to v1.19.3 and verify key rotation is functioning correctly afterward. This is especially relevant if you've observed any anomalies during OSD replacement or key rotation workflows.

• enhancementRGW on IPv6? The secret formatting fix is a must

  The incorrect IPv6 formatting in object store user secrets would cause connection failures in IPv6-only or dual-stack environments. If your RGW deployment uses IPv6 addressing, this fix directly unblocks proper user secret generation. After upgrading, recreate or reconcile affected object store users to pick up correctly formatted secrets.

Rook v1.18.10 patches several OSD reliability issues, tightens RBAC permissions, and adds minor operational improvements to the Ceph exporter and NFS server.

• securityAudit your Rook RBAC after upgrading — nodes/proxy grant is gone

  The operator's nodes/proxy RBAC permission has been removed. If any custom tooling or monitoring in your environment relied on Rook's ServiceAccount having that grant, it will break silently after upgrade. Review any pipelines or dashboards that use the Rook operator ServiceAccount before rolling this out to production.

• breakingEncrypted OSD users should test key rotation after upgrading

  The lockbox key rotation logic for encrypted OSDs was updated. Encrypted OSD clusters should run a non-production upgrade first and explicitly verify key rotation still works end-to-end. The CephX key init fix (no overwrite on failure) also changes behavior during error recovery — test any failure/retry scenarios you have documented.

• enhancementUse the new CephNFS image fields to pin or customize NFS server images

  The new spec.server.image and spec.server.imagePullPolicy fields let you specify a custom NFS Ganesha image per CephNFS resource. This is useful if you need to pin a specific version for compliance or test a patched image without waiting for a Rook release. Update your CephNFS manifests if you currently work around this with other hacks.

Harbor v2.15.0 delivers proxy cache connection limits, per-endpoint CA certs, Cosign v3 bundle support, and a critical bearer token security fix alongside a Trivy supply chain incident bump.

• securityUpdate immediately: Trivy supply chain incident and bearer token bypass

  Two separate security issues landed in this release. First, Trivy was bumped to v0.69.3 after a supply chain incident affecting the scanner — run this update before your next scan cycle. Second, the bearer token fix rejects tokens issued before their associated project was created, which plugs an authorization gap. Both issues warrant prompt upgrades rather than waiting for a maintenance window.

• breakingGCR replication adapter removed — migrate any existing GCR replication rules

  The Google Container Registry adapter is gone. If you have replication rules targeting GCR endpoints, they will break silently after upgrading. Migrate those rules to use Artifact Registry (GAR) endpoints before upgrading to v2.15.0. Also, if you were using proxy cache projects pointed at GCR, those need to be reconfigured.

• enhancementCap proxy cache upstream connections to protect upstream registries

  The new `max_upstream_conn` parameter lets you throttle outbound connections per proxy cache project. If you're running Harbor as a pull-through cache for Docker Hub or other rate-limited registries, set this to avoid hitting upstream rate limits or overwhelming self-hosted registries. Configure it per-project via the UI or API after upgrading.

Longhorn v1.11.1 delivers critical bug fixes including a major memory leak in instance manager pods and backup failures with S3-compatible storage, making it an urgent upgrade for v1.11.0 users.

• securityBackup restore functionality compromised

  S3-compatible backup targets (Storj, GCS) were failing due to AWS SDK v2 authorization issues. Test your backup and restore workflows after upgrading, especially if using non-AWS S3 endpoints. Verify large backup transfers complete successfully.

• breakingUrgent upgrade required for v1.11.0 users

  Users running v1.11.0 experiencing high memory usage in instance manager pods must upgrade immediately. The memory leak can cause cluster instability and pod evictions. Plan upgrade maintenance window and monitor memory usage during rollout.

• enhancementImproved scheduling with topology awareness

  New CSI topology-aware nodeAffinity controls provide better volume placement. Review your storage class configurations to leverage allowedTopologies and strictTopology settings for multi-zone deployments and specific node scheduling requirements.

Dragonfly v2.4.2 adds gRPC rate limiting and scheduler cluster configuration while improving security scores and fixing several configuration inconsistencies.

• breakingUpdate configuration files for renamed fields

  The rateLimit configuration field was renamed to bandwidthLimit. Check your configuration files and update any references to use the new naming convention to avoid configuration parsing errors.

• enhancementConfigure gRPC rate limiting for production

  The new gRPC rate limiting feature protects against resource exhaustion attacks. Review your current traffic patterns and configure appropriate rate limits in your Dragonfly configuration to prevent service degradation under load.

• enhancementLeverage new scheduler cluster management

  With scheduler cluster de-registration support, implement proper cluster lifecycle management in your deployment scripts. This helps maintain cluster health and prevents orphaned schedulers from affecting performance.

Security-focused release addressing two critical CVEs related to backup MANIFEST file vulnerabilities that could allow arbitrary command execution and path traversal attacks.

• securityImmediate upgrade required for CVE-2026-27965 and CVE-2026-27969

  Two critical CVEs allow attackers with backup storage write access to execute arbitrary commands and perform path traversal attacks. Upgrade immediately to v22.0.4 and review backup storage access controls to ensure only trusted entities have write permissions.

• securityAudit and secure backup storage access

  Since these vulnerabilities require write access to backup storage, review who has write permissions to your backup locations. Implement proper access controls and consider using immutable backup storage where possible to prevent tampering.

• breakingUpdate VTTablet configuration if using MANIFEST-based decompressors

  External decompressor commands from MANIFEST files are ignored by default. If your restore process relies on this behavior, add the --external-decompressor-use-manifest flag to your VTTablet configuration, but understand this reintroduces security risks.

Vitess v23.0.3 is a critical security release addressing two CVEs related to backup restore vulnerabilities, with breaking changes to external decompressor handling.

• securityImmediate Upgrade Required for Backup Security

  This release fixes critical vulnerabilities (CVE-2026-27965, CVE-2026-27969) that allow attackers with backup storage write access to execute arbitrary commands or perform path traversal attacks. Upgrade immediately if you use Vitess backups, especially in environments where backup storage might be compromised. Review backup storage access controls and audit recent backup operations for suspicious activity.

• breakingUpdate VTTablet Configuration for External Decompressors

  If your backup/restore process relies on external decompressors defined in MANIFEST files, you must add the --external-decompressor-use-manifest flag to your VTTablet configuration. Without this flag, restores will fail if they depend on MANIFEST-specified decompressors. Review your backup strategy and explicitly configure decompressor commands instead of relying on MANIFEST files for better security.

• enhancementStrengthen Backup Security Posture

  Take this opportunity to review and harden your backup security practices. Implement strict access controls on backup storage, use dedicated service accounts with minimal permissions, and consider encrypting backup storage. The new security model provides better isolation but requires explicit configuration of decompression tools rather than trusting backup metadata.