shinycolumn/cve-2025-56799OS Command Injection Vulnerability via Cache Clearing Scheduler in Reolink Desktop Application
The Reolink Desktop Application (version 8.18.12) contains an OS command injection vulnerability in its cache clearing scheduler (coverCacheClearScheduler) feature. The application constructs an OS shell command using a temporary folder path read from a configuration file located within . As this path value lacks proper input sanitization, an attacker can manipulate it to inject arbitrary OS commands.
%LOCALAPPDATA%This vulnerability is triggered by the scheduler, which runs automatically every day at 3:00 AM, providing the attacker with persistence on the system. Furthermore, the injected command is executed as part of the legitimate, digitally-signed Reolink.exe process, which grants stealth by evading detection from security solutions.
The application initializes a scheduler to run every day at 3:00 AM:
{
key: "clearCoverCacheRegularly",
value: function () {
if (this.coverCacheClearScheduler) {
var e = new Date(),
t = new Date(
e.getFullYear(),
e.getMonth(),
e.getDate(),
3,
0,
0,
).getTime();
(e.getTime() > t &&
(t = new Date(
e.getFullYear(),
e.getMonth(),
e.getDate() + 1,
3,
0,
0,
).getTime()),
this.coverCacheClearScheduler.add({
id: this.clearCoverCacheTaskId,
name: "clearCoverCache",
unit: r.ETaskUnit.DAY,
interval: 1,
args: !1,
execute: this.removeCoverCacheDir,
nextTime: t,
isInExact: !0,
}),
this.coverCacheClearScheduler.start());
}
},
}
The function executed by the scheduler constructs a shell command string using the following logic:
p(
"darwin" === process.platform
? "rm -rf ".concat(t)
: "rd /s /q ".concat(t),
function (t) {
//...
On Windows, the resulting command is:
rd /s /q %LOCALAPPDATA%\Temp\reolink\<TEMP_FOLDER>\playback-covers
On macOS, the resulting command is:
rm -rf ~/Library/Caches/reolink/<TEMP_FOLDER>/playback-covers
Since <TEMP_FOLDER> is not properly sanitized, an attacker can inject additional commands via folder name manipulation, leading to command execution:
rd /s /q %LOCALAPPDATA%\Temp\reolink\& <COMMAND> &\playback-covers
rm -rf ~/Library/Caches/reolink/& <COMMAND>; echo /playback-covers
Triggering the attack requires local file modification, which necessitates another vulnerability, malware execution, or physical access to the system.
Although the initial trigger is relatively difficult, the attack is highly effective once successful, as it provides persistence by re-executing the payload automatically every 3:00 AM. This persistence is further enhanced by the application's nature as a physical security tool, which is often left running 24/7. It also supports a 'start on boot' feature, ensuring the payload survives reboots.
Furthermore, the attacker gains significant stealth. The command executes as part of the trusted, digitally-signed Reolink.exe process, making it highly effective at bypassing EDR and application whitelisting solutions. This is a classic Living Off the Land (LOTL) technique.
The attack can be executed by running poc.py, which modifies the local configuration file. This is made possible by chaining other vulnerabilities related to insufficient encryption (CVE-2025-56801 and CVE-2025-56802), which are used to decrypt and re-encrypt the configuration file.
Normally, the payload would only trigger at 3:00 AM. However, because the application does not utilize ASAR packaging, the code can be patched to trigger the vulnerability immediately for demonstration purposes.
The execution result is as follows:
For more details, please refer to CVE-2025-56801 for the AES-CFB IV Generation Vulnerability and CVE-2025-56802 for the AES-CFB Key Generation and Management Vulnerability.
To fundamentally resolve this OS command injection vulnerability, you must avoid directly including values read from untrusted external sources, such as user configuration files, into OS shell command strings. The recommended solution is to replace the use of shell commands like rd or rm with native APIs that treat the path as pure data, not as a command, such as Node.js's fs.rm(). This method completely eliminates this class of vulnerability.
If constructing a shell command is absolutely unavoidable, a defensive logic must be implemented to strictly validate and either sanitize or escape all special characters that could cause command injection, such as &, |, and ;.