CVE-2026-27969: 
NixOS vulnerability analysis and mitigation

CVE-2026-27969 is a path traversal vulnerability in Vitess, a database clustering system for horizontal scaling of MySQL, that allows attackers with read/write access to backup storage locations to write arbitrary files to any accessible path on the production system during restore operations. It affects all Vitess versions prior to 22.0.4 and versions 23.0.0 through 23.0.2. The vulnerability was published on February 25, 2026, and patched versions were released on February 27, 2026. It carries a CVSS v3.1 score of 8.8 (High) and a CVSS v4.0 score of 9.3 (Critical) (GitHub Advisory, NVD).

The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory), specifically in the fullPath() function within Vitess's builtinbackupengine.go. The backup MANIFEST file contains a FileEntries array with a Name string field that specifies where each file should be restored; Vitess trusted this field without validation, allowing an attacker to embed path traversal sequences (e.g., ../../etc/passwd) to write files outside the intended base directories ($VTDATAROOT/vt_*/data, innodb/data, innodb/logs, bin-logs). The fix replaced the unsafe path.Join() call with fileutil.SafePathJoin(), which validates that the resolved path does not escape the base directory (GitHub PR #19470, Patch Commit).

Successful exploitation results in complete compromise of confidentiality, integrity, and availability of the affected Vitess deployment. An attacker can write arbitrary files — including web shells, cron jobs, or configuration overrides — to any location accessible by the restore process, enabling unauthorized access to sensitive data and arbitrary command execution on the production environment. This can facilitate lateral movement within the infrastructure and full takeover of the database cluster (GitHub Advisory, Feedly).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The vulnerability requires the attacker to already have read/write access to the backup storage location (e.g., an S3 bucket), which limits the attack surface to insiders or attackers who have previously compromised storage credentials. The EPSS score is approximately 0.04, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory, Feedly).

1. Gain storage access: Obtain read/write access to the Vitess backup storage location (e.g., an S3 bucket, GCS bucket, or NFS share) through compromised credentials, misconfigured bucket policies, or insider access.
2. Locate or create a backup MANIFEST: Identify an existing backup MANIFEST file in the storage location, or create a new one. The MANIFEST contains a FileEntries JSON array with Base, Name, and optional ParentPath fields.
3. Craft malicious MANIFEST entries: Modify or inject FileEntry objects where the Name field contains path traversal sequences, for example: {"Base": "Data", "Name": "../../etc/cron.d/backdoor"}. The content of the corresponding backup file should be the malicious payload (e.g., a cron job or SSH authorized_keys entry).
4. Upload malicious files: Upload both the tampered MANIFEST and the malicious payload files to the backup storage location so they appear as a valid backup set.
5. Trigger a restore operation: Wait for or induce a Vitess restore operation (e.g., via vtbackup or tablet restore) that references the malicious backup. During restore, Vitess's fullPath() function constructs the destination path using the attacker-controlled Name field without sanitization.
6. Achieve arbitrary file write: The restore process writes the attacker-supplied file content to the traversed path (e.g., /etc/cron.d/backdoor), enabling persistent access, privilege escalation, or arbitrary command execution on the production host (GitHub PR #19470, GitHub Advisory).

• File System: Unexpected files written outside of the standard Vitess data directories ($VTDATAROOT/vt_*/data, innodb/data, innodb/logs, bin-logs); new or modified files in sensitive locations such as /etc/cron.d/, /etc/passwd, ~/.ssh/authorized_keys, or web-accessible directories.
• Logs: Vitess restore logs (vtbackup or tablet restore logs) referencing file paths containing ../ sequences or paths outside expected base directories; errors from fileutil.SafePathJoin on patched systems indicating attempted traversal.
• Network: Unusual access patterns to backup storage buckets (S3, GCS, etc.) — particularly PUT/write operations on MANIFEST files from unexpected IP addresses or IAM principals; unexpected downloads of backup content followed by restore operations.
• Process: Unexpected processes spawned by the Vitess service account (e.g., cron jobs, shells) shortly after a restore operation; new scheduled tasks or cron entries created under the Vitess process user.

Upgrade Vitess to version 22.0.4 or 23.0.3, which contain the patch that validates file paths during restore to prevent traversal outside the intended base directories. No configuration-based workarounds are available. As a defense-in-depth measure, restrict read/write access to backup storage locations (S3 buckets, GCS buckets, etc.) to only authorized systems and personnel, and monitor restore operations for file paths containing traversal sequences (../, ..\) (GitHub Advisory, Patch Commit).

The vulnerability was credited to researcher NeuroWinter, who published a technical write-up in May 2026 detailing RCE and arbitrary file write via untrusted MANIFEST fields in Vitess vtbackup. SecurityOnline.info covered the issue under the headline "Critical Backup Flaws Expose Vitess Environments to Complete Takeover." Red Hat and Microsoft both tracked the vulnerability in their respective security advisories. Community discussion was noted on Bluesky and various CVE aggregator platforms shortly after disclosure (GitHub Advisory, SecurityOnline).