CVE-2026-27965: Vitess Database Clustering RCE Vulnerability

CVE-2026-27965 Overview

CVE-2026-27965 is a Command Injection vulnerability affecting Vitess, a database clustering system designed for horizontal scaling of MySQL. The vulnerability allows attackers with read/write access to backup storage locations (such as S3 buckets) to manipulate backup manifest files, resulting in arbitrary code execution when the compromised backup is restored.

Critical Impact

Attackers can gain unauthorized access to production deployment environments, access sensitive information, and execute arbitrary commands on affected systems during backup restoration operations.

Affected Products

• Vitess versions prior to 23.0.3
• Vitess versions prior to 22.0.4
• Vitess deployments using external backup storage (e.g., S3, GCS)

Discovery Timeline

• 2026-02-26 - CVE-2026-27965 published to NVD
• 2026-02-26 - Last updated in NVD database

Technical Details for CVE-2026-27965

Vulnerability Analysis

This vulnerability stems from an OS Command Injection weakness (CWE-78) in how Vitess handles decompressor commands stored within backup manifest files. When a backup is restored, Vitess reads the external decompressor command from the MANIFEST file and executes it without proper validation. An attacker who has gained write access to the backup storage location can modify the manifest file to inject malicious commands that execute with the privileges of the Vitess user during the restoration process.

The attack requires network access and some level of privileged access to the backup storage infrastructure. However, once that access is obtained, the attacker can achieve high impact on both confidentiality and integrity of the target system, with potential lateral movement capabilities within the production environment.

Root Cause

The root cause is the implicit trust placed in the MANIFEST file contents within backup storage. Prior to the patch, Vitess would automatically use the decompressor command specified in the manifest without requiring explicit opt-in from administrators. This design allowed the manifest file to effectively become a vector for command injection when an attacker could modify files in backup storage locations.

Attack Vector

The attack vector is network-based, targeting the backup restoration workflow. An attacker who has compromised or obtained credentials to the backup storage location (such as an S3 bucket or GCS bucket) can inject malicious commands by modifying the external-decompressor value in the backup manifest file. When administrators or automated processes restore from this tampered backup, the malicious commands execute on the Vitess tablet or backup server with full system access as the Vitess user.

The following patch introduces the --external-decompressor-use-manifest flag that makes loading decompressor commands from the manifest an explicit opt-in behavior:

       --external-compressor string                                  command with arguments to use when compressing a backup.
       --external-compressor-extension string                        extension to use when using an external compressor.
       --external-decompressor string                                command with arguments to use when decompressing a backup.
+      --external-decompressor-use-manifest                          allows the decompressor command stored in the backup manifest to be used at restore time. Enabling this is a security risk: an attacker with write access to the backup storage could modify the manifest to execute arbitrary commands on the tablet as the Vitess user. NOT RECOMMENDED.
       --file-backup-storage-root string                             Root directory for the file backup storage.
       --gcs-backup-storage-bucket string                            Google Cloud Storage bucket to use for backups.
       --gcs-backup-storage-root string                              Root prefix for all backup-related object names.

Source: GitHub Commit Changes

Detection Methods for CVE-2026-27965

Indicators of Compromise

• Unexpected modifications to backup manifest files in storage locations (S3, GCS, or local file storage)
• Unusual commands or processes spawned during backup restoration operations
• Anomalous network connections or system calls originating from vttablet or vtbackup processes
• Unauthorized access logs or authentication events for backup storage buckets

Detection Strategies

• Monitor backup storage locations for unauthorized file modifications, particularly to MANIFEST files
• Implement file integrity monitoring on backup storage to detect tampering
• Audit vttablet and vtbackup process activity during restore operations for unexpected child processes
• Review cloud storage access logs (S3 CloudTrail, GCS audit logs) for suspicious read/write patterns

Monitoring Recommendations

• Enable detailed logging for all backup and restore operations in Vitess
• Configure alerts for changes to manifest files outside of normal backup windows
• Monitor for execution of non-standard decompressor commands during restore operations
• Implement runtime security monitoring on systems running Vitess components to detect command injection attempts

How to Mitigate CVE-2026-27965

Immediate Actions Required

• Upgrade Vitess to version 23.0.3 or 22.0.4 immediately
• Audit backup storage permissions and restrict write access to only necessary service accounts
• Review recent backup manifests for any signs of tampering or unexpected decompressor commands
• Implement the recommended workarounds if immediate patching is not possible

Patch Information

The Vitess project has released patched versions that address this vulnerability. Version 23.0.3 and version 22.0.4 contain the security fix that changes the behavior of loading decompressor commands from manifest files to be opt-in rather than automatic. The patch introduces a new flag --external-decompressor-use-manifest that administrators must explicitly enable if they want to use manifest-specified decompressors. For complete technical details, refer to the GitHub Security Advisory GHSA-8g8j-r87h-p36x, the GitHub Pull Request, and the GitHub Issue Discussion.

Workarounds

• For deployments using an external decompressor: Always specify the decompressor command explicitly via the --external-decompressor flag for vttablet and vtbackup to override any manifest values
• For deployments not using an external decompressor: Set --external-decompressor to a harmless command such as cat or tee for vttablet and vtbackup
• Restrict write access to backup storage locations to only essential, highly-secured service accounts
• Implement additional verification of backup manifest integrity before restoration

# Configuration example - Override manifest decompressor with explicit flag
# For vttablet:
vttablet --external-decompressor="cat" [other flags]

# For vtbackup:
vtbackup --external-decompressor="cat" [other flags]

# Or specify your known-good decompressor explicitly:
vttablet --external-decompressor="/usr/bin/zstd -d" [other flags]