CVE-2026-27965 is a critical command injection flaw (CVSS 9.9) in Vitess. Anyone who can write to the backup storage location can alter a backup manifest so that arbitrary code runs when the backup is restored. Upgrade to 22.0.4 or 23.0.3. Workarounds exist. The record does not mark it as exploited in the wild.
What's affected
Vitess, the MySQL clustering system. Per the GitHub advisory:
- Affected: all versions before 22.0.4, and 23.0.0 up to but not including 23.0.3
- Fixed: 22.0.4 and 23.0.3
The affected components are vttablet and vtbackup, which read the manifest during restore. The precondition is read and write access to the backup storage, for example an object store bucket.
How to check if you're exposed
Check the Vitess version running in each environment.
vttablet --version
vtbackup --version
Then check the other half of the risk, who can write to the backup location. List the identities with write access to the bucket or path that holds backups, and review them. Check also how your vttablet and vtbackup processes are started.
ps aux | grep -E "vttablet|vtbackup" | grep external-decompressor
This shows whether the external decompressor flag is already set, which matters for the workaround below.
What to do now
- Upgrade Vitess to 22.0.4 or 23.0.3 or later, depending on your release line.
- Review and tighten write access to the backup storage location. Few identities should be able to modify backup objects.
- If you intend to use an external decompressor, set it explicitly in the external-decompressor flag for vttablet and vtbackup. That value overrides anything in the manifest.
- If you use neither an external nor an internal decompressor, set the flag to a harmless command such as cat or tee, as the advisory describes.
- Consider turning on object versioning or immutability for backups, then verify a test restore after upgrading.
Why it matters
The record says the restore process trusted a command value stored in the backup manifest. Whoever could modify the manifest could therefore get code run on the machine doing the restore, with access to the production environment and everything it can reach. The scope is rated changed, which explains the 9.9 score. NVD classifies the flaw as CWE-78 (OS Command Injection).
Backups are often stored with looser access than production, and restores happen in a hurry. A restore path that runs data from the backup as a command turns a storage permission problem into a production compromise.
What the manifest does
A Vitess backup includes a manifest file that describes the backup, including how its files were compressed. During restore, the tools read the manifest to decide how to decompress. The advisory says that value could be manipulated to run arbitrary code, so the manifest acted as an instruction source that an attacker with storage write access could change.
Why the workarounds work
The external-decompressor flag on vttablet and vtbackup overrides whatever the manifest says. If you use an external decompressor on purpose, setting it explicitly takes the choice away from the manifest. If you use no decompressor, setting a harmless command such as cat or tee gives restore a command that does nothing harmful. These are the workarounds the advisory lists, and they are stopgaps until you upgrade.
Securing the backup location
Even with the patch, who can write to backups deserves a review. Use a dedicated identity for backup writes, grant restore processes read only access, enable versioning or object lock where your storage supports it, and alert on changes to backup objects that your backup job did not make.
After upgrading
Confirm the version by running both binaries with their version flag, then run a restore into a test environment and check that it completes. Record the date and versions. If your backup bucket was writable by identities that should not have had that access, treat past backups as untrusted until you have verified them.
Questions to ask your team
Who can write to the backup bucket today, and why? When was the last restore test? Does anything alert you when a backup object changes? A flaw like this one turns those questions from housekeeping into security controls, and the answers help with the next incident as well.
Writing it up for your team
Note the two fixed versions, the workarounds, and the identities with write access to backups. Assign an owner for each Vitess cluster, with a date for the upgrade and a date for the restore test. Share the list with whoever runs your object storage, since they hold half of the fix.
Try it yourself
Tracking a fix across many environments is its own job. This demo shows a vulnerability management view.
Click through it at your own pace, or open it full screen.
Quick check
Can an outsider exploit this directly?
Not from the record alone. The attacker needs read and write access to the backup storage, so storage permissions are the first thing to review.
What does the workaround do?
Setting the external decompressor flag makes vttablet and vtbackup ignore the value in the manifest, per the advisory.
Sources
Last reviewed: 19 October 2026.
