CVE-2026-61625 in VictoriaMetrics
Summary
by MITRE • 08/20/2026
VictoriaMetrics is a scalable solution for monitoring and managing time series data. Prior to 1.122.25, 1.136.12, and 1.146.0, vmrestore does not validate backup part path components before using lib/backup/actions/restore.go and lib/backup/fslocal/fslocal.go to write restored data below storageDataPath. An attacker who can supply or modify an S3, GCS, Azure Blob Storage, or other backup source can place .. components in object names. When an operator restores that source, the crafted names can create or overwrite files outside the intended restore root within the filesystem permissions of the vmrestore process. This issue is fixed in versions 1.122.25, 1.136.12, and 1.146.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
VictoriaMetrics serves as a scalable infrastructure for monitoring and managing time series data, relying on robust backup and restore mechanisms to ensure data integrity and availability. The vulnerability identified in versions prior to 1.122.25, 1.136.12, and 1.146.0 centers on the vmrestore utility, which is responsible for retrieving archived metrics from external storage providers such as Amazon S3, Google Cloud Storage (GCS), Azure Blob Storage, or local file systems. The core technical flaw lies in insufficient input validation within the restore logic implemented in lib/backup/actions/restore.go and lib/backup/fslocal/fslocal.go. Specifically, the application fails to sanitize path components contained within object names retrieved from these backup sources before utilizing them as relative paths for writing restored data files. This lack of normalization allows an attacker who has control over or can manipulate the contents of a connected backup source to inject directory traversal sequences, specifically double-dot characters (..), into the object metadata or keys.
When an operator initiates a restore operation against a compromised or maliciously crafted backup source, the vmrestore process interprets these injected path components literally rather than validating them against the intended storage root. Consequently, instead of writing data exclusively within the designated storageDataPath directory structure, the application resolves the traversal sequences and writes files to arbitrary locations on the underlying filesystem. This behavior constitutes a classic Path Traversal vulnerability, formally categorized under CWE-22: Improper Limitation of a Pathname to a Restricted Directory. The severity of this flaw is significantly amplified by the operational context in which VictoriaMetrics typically runs; backup restoration processes often execute with elevated privileges or broad file system permissions necessary to manage large datasets and ensure data persistence.
The operational impact of this vulnerability extends beyond simple data corruption within the monitoring stack. An attacker can exploit this flaw to overwrite critical configuration files, inject malicious scripts into executable directories, or create symbolic links that redirect future writes to sensitive system locations. This capability effectively allows for arbitrary file write operations with the privileges of the vmrestore process. In a worst-case scenario, if the restoration service runs as root or has access to writable system directories such as /tmp or application binary folders, an attacker could achieve remote code execution by overwriting shared libraries or executable binaries that are subsequently loaded by other services. This aligns with ATT&CK technique T1036: Masquerading and potentially T1548: Abuse Elevation Control Mechanism if the process privileges allow for system-level modifications.
Mitigation strategies must prioritize immediate version upgrades to address this critical flaw. Organizations running affected versions of VictoriaMetrics should upgrade to 1.122.25, 1.136.12, or 1.146.0 and later releases where the path validation logic has been hardened to reject any object names containing directory traversal sequences before they are processed by the restore engine. In environments where immediate upgrading is not feasible due to operational constraints, administrators should implement strict access controls on backup storage buckets to prevent unauthorized modification of object keys or metadata. Additionally, running the vmrestore process with minimal required permissions and using chroot jails or containerized environments can limit the blast radius of any potential file system manipulation attempts until a permanent patch is applied. Regular auditing of restore logs for anomalous path resolutions should also be conducted to detect exploitation attempts early.