Critical Backup Flaws Expose Vitess Environments to Complete Takeover

Vitess is a cloud-native horizontally-scalable distributed database system that is built around MySQL. It allows organizations to achieve unlimited scaling through generalized sharding, and operators can even split and merge shards as their needs grow with an atomic cutover step that takes only a few seconds. Because Vitess sits at the core of massive data infrastructures, any security flaw within its architecture represents a severe risk to an organization’s operations.

Recently, two severe vulnerabilities were disclosed that target a critical administrative phase: database restoration. By tampering with how backups are processed, attackers can bypass normal database security and take over the production environment.

Both of the newly disclosed vulnerabilities share the same initial attack vector. They rely on an attacker first gaining read and write access to the location where the database backups are stored, such as an S3 bucket.

Once the attacker has access to this storage area, they can silently manipulate the backup manifest files. These manifest files act as a blueprint, telling the database how to rebuild itself during a restore operation. By poisoning these blueprints, the attacker sets a trap that springs the moment an administrator attempts to restore the database.

The first and most severe vulnerability is tracked as CVE-2026-27969 (CVSS 9.3). This is a common Path Traversal security issue.

When an administrator restores the database from a poisoned manifest, the manipulated file instructions trick the system. Instead of writing the backup data strictly to the correct database folders, the files are written to any accessible location on the server. This effectively provides the attacker with unintended and unauthorized access to the production deployment environment. From there, the attacker can access sensitive information available in that environment or execute additional arbitrary commands.

The second vulnerability, CVE-2026-27965 (CVSS 8.4), operates on the same principle but focuses directly on executing malicious instructions.

By altering the backup manifest files in the storage location, the attacker can ensure that arbitrary code is later executed when that backup is restored. Just like the first flaw, this grants the attacker unintended and unauthorized access to the production deployment environment, allowing them to steal data or run any additional arbitrary commands on the host system.

If you are running a Vitess cluster, you must address these vulnerabilities to ensure your backup and restore pipelines cannot be weaponized against you.

The maintainers have addressed both of these flaws in the latest releases. Administrators should update their systems to either v23.0.3 or v22.0.4 to fully patch both vulnerabilities.

If you cannot patch immediately, you can protect your systems by taking control of the decompression process during a restore.

• If you intend to use an external decompressor, you can specify that decompressor command in the –external-decompressor flag value for vttablet and vtbackup. Doing so overrides any malicious value specified in the manifest file.
• If you did not intend to use an external decompressor, nor an internal one, then you can specify a value such as cat or tee in the –external-decompressor flag value for vttablet and vtbackup. This ensures that a harmless command is always used.