リリース

Rook v1.20.2は、バグ修正と細かい改善を中心としたルーティンパッチです。mgrのNetworkPolicyをイングレス専用に制限するセキュリティ強化と、Cephのデフォルトバージョンのv20.2.2への更新が主な変更点です。

• securitymgrのNetworkPolicyがイングレス専用に変更

  mgrのNetworkPolicyがイングレス専用に制限されました。mgrを外部からアクセス可能にしている構成では、エグレス方向の通信が遮断されないか確認し、必要に応じてポリシーを調整してください。

Vitess v24.0.2 is a patch release combining two security hardening fixes (gRPC auth timing, twopcz value escaping) with a broad set of bug fixes across backup/restore, VReplication, vtgate, VTOrc, and connection pooling. No breaking API or config changes are stated.

• securityTwo security hardening fixes: gRPC auth timing, twopcz reflected values

  Fixes for a timing side-channel in the static gRPC auth plugin's password comparison and a reflected-value escaping gap in the twopcz handler. Both apply unconditionally; upgrade to v24.0.2 if you run gRPC static auth or expose the twopcz endpoint.

v23.0.5 is a bug-fix rollup with two medium-severity security hardening fixes. Changes span connection pooling, query planning, VReplication, VTOrc, topology, and backup/restore, with no API, config, or default changes.

• securityTiming-safe password comparison in static gRPC auth plugin

  The static gRPC auth plugin now uses constant-time comparison for passwords, closing a potential timing-based credential leak. Applies to all deployments using static gRPC authentication.

• securityReflected-input escaping in twopcz handler

  The twopcz debug handler now escapes reflected form values, preventing reflected input injection. Applies to any deployment where the twopcz handler endpoint is reachable.

Rook v1.19.6 is a targeted patch release addressing OSD device class handling, Prometheus metric labeling, and a network-layer dependency vulnerability. Mainly operational refinements for Ceph clusters already in production.

• securityPatch golang.org/x/net vulnerability

  Rook v1.19.6 bumps golang.org/x/net twice (to fix govulncheck CI failures and address GO-2026-5026). If you run Rook in high-traffic environments or handle untrusted network input, review the golang.org/x/net advisory for the specific vulnerability. Upgrade to 1.19.6 to inherit the patched dependency, but do not delay if your Rook instance exposes networking logic to untrusted sources.

• enhancementOSD device class detection fixed in raw-mode

  OSD device class handling now works correctly in raw-mode prepare and reconcile operations (#17407). If you use device classes to segregate fast (NVMe) from slow (HDD) storage, verify after upgrading that your OSD topology reflects the correct device classes. Check `ceph osd crush tree` and OSD weight distribution to ensure placement rules work as intended.

• enhancementCluster label added to Prometheus metrics

  Prometheus scrape metrics now include a `cluster` label from upstream Ceph rules (#17544). If you aggregate Rook metrics across multiple Ceph clusters, this label addition improves metric cardinality and avoids collisions. Update any Prometheus rules, dashboards, or alerts that rely on the old label set; test in non-production first to catch any PromQL query breaks.

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.

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.

Harbor v2.15.1 is a patch release focused on CVE fixes, security hardening, and several behavioral bug fixes including proxy cache, session management, and GC credential leak.

• securityRedeploy now to stop Redis credentials leaking from GC job metadata

  Before this fix, the GC job stored the Redis URL (including credentials) in its extra attributes, which are accessible via the Harbor API and potentially logged. If you run GC jobs and have Redis auth configured, treat any previously captured GC job metadata as potentially containing plaintext credentials. Rotate Redis passwords and upgrade to v2.15.1 promptly.

• securityCVE patches in base image — upgrade before your next scan cycle

  The Photon base image was updated specifically to address CVEs, then stabilized on photon:5.0. If you're running v2.15.0 in a security-conscious environment, your vulnerability scanner will likely flag the older image. Upgrade to v2.15.1 to clear those findings before they become audit issues.

• enhancementSession behavior change: idle timeouts will now work as configured

  Background polling in the UI was silently keeping sessions alive indefinitely by resetting the TTL on every poll cycle. After this fix, sessions will actually expire when users are idle. If your org relies on session timeouts for compliance, this fix makes them effective. Warn users they may now be logged out after inactivity — this is correct behavior, not a regression.

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.

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.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.3 is a pure maintenance release focusing on dependency updates and security patches, with no functional changes for users.

• securityApply routine security updates

  This patch release includes dependency updates that may contain security fixes. Update your Dragonfly deployments to v2.4.3 during your next maintenance window. The upgrade should be seamless with no breaking changes or configuration updates required.

• enhancementImproved observability with OpenTelemetry updates

  The OpenTelemetry library updates from v0.63.0 to v0.67.0 provide better tracing capabilities. If you're using distributed tracing with Dragonfly, you may see improved trace collection and reduced overhead after upgrading.

Harbor v2.13.5 focuses on security improvements with stricter bearer token validation and removes sensitive configuration data from audit logs.

• securityBearer token security enforcement requires review

  Harbor now rejects bearer tokens issued before project creation, which could break existing integrations using older tokens. Audit your CI/CD pipelines and automation scripts that authenticate with Harbor to ensure they regenerate tokens after this upgrade.

• enhancementAudit log cleanup improves security posture

  Configuration payloads are no longer logged in audit trails, reducing exposure of sensitive settings. Review your log monitoring and compliance processes to ensure they still capture necessary security events without relying on configuration data in logs.

• enhancementUpdated Trivy brings latest vulnerability definitions

  Trivy v0.69.3 includes newer vulnerability databases and detection rules. Schedule a rescan of your container images to identify any newly discovered vulnerabilities that weren't caught in previous scans.

Harbor v2.14.3 delivers critical security fixes for bearer token validation and updates Trivy scanner to version 0.69.3, focusing on hardening authentication mechanisms and keeping vulnerability detection current.

• securityUpdate immediately for bearer token fix

  This release patches a security flaw where Harbor accepted bearer tokens issued before project creation. Deploy v2.14.3 immediately if you use token-based authentication, as this could allow unauthorized access to projects.

• enhancementBenefit from updated Trivy scanning

  Trivy v0.69.3 includes the latest vulnerability database and detection capabilities. Schedule a rescan of your critical images after upgrading to catch newly discovered vulnerabilities that older versions missed.

• enhancementReview audit log configurations

  Sensitive payload data has been removed from configuration audit logs to prevent credential exposure. Verify your log monitoring tools still capture the security events you need after this change.

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.