Vitess Path Traversal in Backup Restore Fixed in v22.0.4 and v23.0.3 (CVE-2026-27969)

Vitess maintainers have confirmed a serious path traversal vulnerability in the project’s backup restore path that allows anyone with write access to backup storage to cause a restore operation to write files to arbitrary locations on the host where Vitess runs — a risk that can lead to data exposure, configuration tampering, or even remote code execution if system paths or executable locations are targeted.

Background / Overview​

Vitess is a widely used open‑source clustering system that scales MySQL for large deployments and cloud environments. Its backup and restore pipeline relies on metadata files (a backup MANIFEST) stored alongside backup blobs in object storage (for example, S3). That MANIFEST describes the archive contents and — in some workflows — contains instructions used during restore and decompression. Recent security releases from the Vitess project address two related but distinct risks involving backup manifests: one that removes automatic use of an external decompressor command embedded in a MANIFEST, and a second that prevents path traversal entries inside MANIFESTs from escaping the intended restore root.
Two security releases — v22.0.4 and v23.0.3 — were published to mitigate these problems. The path traversal fix is explicitly linked to CVE‑2026‑27969 and is referenced in Vitess release notes and advisory text; the decompressor fall‑back change (which prevents execution of arbitrary commands supplied by a malicious MANIFEST) was linked to CVE‑2026‑27965. Those releases change default behavior and include options for operators who depend on older behavior to opt in consciously.

---

What the vulnerability is — technically​

How backup MANIFESTs are abused​

A typical Vitess backup MANIFEST lists files (paths and sizes) and may include metadata used during restore. If an attacker can write or overwrite the MANIFEST in backup storage, they can place crafted file entries that include:

• Parent‑directory traversal sequences (e.g., ../../etc/ssh/authorized_keys), or
• Absolute system paths (e.g., /root/.ssh/authorized_keys), or
• Other paths designed to land files under privileged directories.

When the vulnerable restore path reads the MANIFEST and writes the listed files to disk without normalizing and enforcing that each target path stays inside the designated restore directory, files can be written to arbitrary host filesystem locations that the Vitess process has permission to write. That behaviour is the classic ZipSlip / path traversal on archive extraction category (CWE‑22).

Preconditions for exploitation​

This is not a blind remote RCE: exploitation requires the attacker to already have read/write access to the backup storage location used by Vitess (for example, an S3 bucket, GCS bucket, or similar object store). That level of access is not unheard of — misconfigured buckets, overly broad IAM roles, or a compromised CI/CD pipeline with storage credentials can all provide the required access. Once an attacker can write the MANIFEST, a restore operation performed by an operator (or automated restore job) that reads that MANIFEST is the vector that applies the malicious file writes.

Why the impact is high​

A restore process typically runs with the permissions of the Vitess instance (often a service account or system user). If that process can write into system directories or application directories, an attacker may:

• Drop SSH keys into authorized_keys to gain shell access;
• Plant scripts or binaries under startup locations to persist code execution;
• Replace configuration files or TLS material to intercept or exfiltrate data;
• Overwrite application binaries, causing data corruption or denial of service.

The severity comes from combining the ability to write arbitrary files with the fact that backups are often restored into production or staging hosts that run with significant privileges. Several advisories call this a high/critical risk and urge immediate patching.

---

Affected versions and the fix​

• Affected releases are the Vitess branches prior to v22.0.4 and in the 23.x line up to v23.0.3 (the fixes were shipped in v22.0.4 and v23.0.3). Operators should assume that any deployed Vitess prior to these fixes is vulnerable unless backported patches are in place.
• The Vitess project implemented two changes:
  • Do not use decompressor commands from the MANIFEST by default (breaking change; there’s now an explicit flag to opt in), which prevents a MANIFEST from supplying arbitrary shell commands to be executed during restore.
  • Reject or sanitize path entries in MANIFESTs so that entries cannot escape the configured restore target directory (the path traversal fix). The release notes reference PRs and issue numbers that implemented the corrections.
• Where immediate upgrade is impossible, Vitess documentation and advisories reference configuration flags and operational workarounds (for example, the new --external-decompressor-use-manifest opt‑in flag). However, relying on old behavior leaves systems exposed; the safer path is to apply the security releases promptly.

---

Why backups are an attractive attack surface​

Backups contain a copy of application data and often include configuration, secrets, or metadata. Operators typically assume that backups are trustworthy because they were written by their own systems — but in modern cloud environments that trust assumption fails when:

• Storage credentials are reused across systems;
• CI/CD, automation tools, or third‑party services write to the same bucket;
• Object storage IAM policies are overly permissive or misapplied;
• Object lifecycle or versioning is not used, making silent replacement easier.

Attackers know this: compromising backup storage can let them inject malicious files that will be "whitelisted" by restore operations because restores are designed to accept backup metadata. That is exactly the chain exploited by the Vitess MANIFEST issues. Similar classes of attacks have been seen previously in other backup or archive extraction contexts, reinforcing the need to treat backups as high‑value, high‑risk assets.

---

Immediate operational steps (what you should do right now)​

1. Upgrade. If you run Vitess, schedule an immediate upgrade to v22.0.4 or v23.0.3 (or later) for any clusters that perform restores from external backup storage. This is the most direct fix.
2. Lock down backup storage. Audit and tighten IAM policies on buckets used for backups:
   • Restrict write (and delete) permissions to a minimal set of trusted operator principals.
   • Enable object versioning and immutable object options where supported.
   • Enable access logging and monitor changes to MANIFEST files specifically.
   • Use separate buckets for automated CI writes vs production backups.
3. Treat restores as a privileged operation. Ensure restores are performed only in isolated, auditable environments:
   • Run restores in a dedicated recovery host or container sandbox that has no write access to production system paths.
   • Verify backup integrity and manifest contents before executing a restore; do not restore from an untrusted or previously public bucket without verification.
4. Audit and rotate credentials if you suspect backup compromise. If MANIFESTs were overwritten by an attacker, assume credentials used by systems that write to that storage have been exposed. Rotate keys and secrets that were stored or used with the bucket.
5. Configure the decompressor behavior consciously. If your deployment relied on the MANIFEST‑supplied external decompressor, review the new default (which ignores the MANIFEST decompressor unless you set --external-decompressor-use-manifest) and decide whether the operational convenience is worth the security tradeoff. If you must re-enable it for compatibility, restrict bucket write access tightly and understand that you are reintroducing the risk the patch sought to remove.

---

Detection and threat hunting tips​

• Scan your object storage for unexpected writes to MANIFEST files or for sudden creation timestamps that align with suspicious CI jobs. Compare current MANIFEST contents against known good manifests (hashes, signatures).
• Search restore logs in Vitess hosts for restore operations that wrote files outside the expected restore tree or for unexpected file system operations performed during restores. System call tracing (strace, auditd) during a controlled restore test can reveal whether file writes attempted to leave the restore root.
• Look for newly added files in system directories that match recent restore timestamps, particularly SSH authorized_keys files, /etc files, init scripts, or service unit files. These are common persistence targets.
• If versioning is enabled on the bucket, enumerate object versions to detect overwritten manifests; version metadata can be the smoking gun that a manifest was tampered with.

---

Incident response — if you suspect compromise​

• Immediately isolate the cluster: stop network access for affected nodes and suspend any automated restores until you have confirmed backups are clean.
• Snapshot forensic evidence: preserve current object versions in the backup store, collect Vitess restore logs, and record file system metadata from restored hosts.
• Rotate credentials and service keys that had access to the backup store; assume they were exposed if manifests were tampered with.
• Rebuild from known‑good backups or snapshots where integrity has been verified. Avoid restoring from any backups that used the compromised storage until after full validation.
• Engage with legal and compliance teams where required — unauthorized writes into production systems or data exfiltration can trigger regulatory reporting obligations.

---

Why the Vitess project’s fix is important — and what to watch for​

Vitess’ approach does two things of practical importance:

• It removes an implicit trust boundary: MANIFEST contents and embedded commands are no longer automatically executed by restore, lowering the risk that an attacker who can write to backup storage can also execute code during restore. This is a defensive default that aligns with principle of least surprise.
• It hardens path handling during restore by normalizing and validating file paths so that they cannot leave the designated restore root. That is the specific mitigation against the path traversal vector (CWE‑22 / ZipSlip type issues).

However, the change also contains an operational tradeoff: the decompressor behavior change is a breaking change for workflows that relied on MANIFEST‑declared decompressor commands. The project provides a flag to opt back in, but operators should treat that opt‑in as a conscious acceptance of risk and verify that the storage location is fully trusted and access is strictly controlled.

---

Broader context and precedent​

Attacks that target backup and archive extraction are not new: the security community has repeatedly observed that unzip/untar‑style extraction code that fails to sanitize paths is a recurring source of high‑impact vulnerabilities (examples in other projects include path traversal issues in tar/unzip handling and archive extraction libraries). Backup services and backup agents historically have been targeted because they are trusted to place files onto hosts and often run with elevated privileges. The Vitess MANIFEST issues follow a well‑known class of failures and the recommended mitigations — strong access controls, integrity checks, and defense‑in‑depth — are proven best practices.

---

Developer and security team checklist (concise)​

• Upgrade Vitess to v22.0.4 or v23.0.3+ immediately.
• Audit and restrict backup storage write access; enable versioning and logging.
• Verify any required decompressor behavior and only opt into --external-decompressor-use-manifest if absolutely necessary and safe.
• Run a controlled test restore in a sandbox to confirm the behavior of patched code in your environment before trusting production restores.
• Add manifest integrity checks (signing, hashes) to your backup pipeline so MANIFEST files cannot be silently replaced without detection.

---

Critical analysis — strengths, gaps, and residual risks​

• Strengths: Vitess’ two‑pronged response is well‑targeted. Removing implicit execution of MANIFEST‑supplied decompressor commands by default eliminates a major escalation vector, and normalizing/whitelisting restore paths mitigates the canonical ZipSlip attack surface. The project’s release note transparency (explicit PR and issue references) helps operators validate and test the fix.
• Gaps and residual risks: The fix reduces the attack surface but does not change the underlying principle that backup storage is trusted infrastructure. If attackers already have write access to the bucket, they can still cause other damage (replace backup blobs, poison metadata in other ways, or craft data that leads to logical corruption). Also, operators who re‑enable MANIFEST‑driven decompression reintroduce the RCE risk unless storage is strictly locked down. Finally, not every environment will upgrade immediately; unmanaged or lagging clusters remain at risk.
• Unverifiable claim note: public reporting at the time of patch publication does not show confirmed in‑the‑wild exploit campaigns specifically weaponizing CVE‑2026‑27969. However, lack of public reports is not proof of non‑exploitation; by design, backup‑level tampering may be noisy or intentionally stealthy. Treat the environment as compromised if you find evidence of MANIFEST tampering.

---

Final takeaway​

Backups are not just insurance — they are a part of your attack surface. The Vitess CVE‑2026‑27969 path traversal and the related decompressor issues show how a single trusted metadata file can be weaponized when storage controls are weak. The corrective releases (v22.0.4 and v23.0.3) close the immediate technical holes, but the practical lesson for operators is broader: lock down backup storage, make restores an auditable and isolated operation, and treat any storage writable by multiple systems as hostile until proven otherwise. Apply the patches, harden your storage policies, and run a verified restore workflow test in a sandbox before trusting any production restore to an earlier backup.
Conclusion: patch promptly, assume manifests can be tampered with if storage is writable, and rebuild restore procedures so that backups are verified artifacts rather than implicit trust anchors.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center