CVE-2026-118992 in CallBackery
Summary
by MITRE • 10/30/2026
CallBackery versions before 0.62.0 for Perl allow OS command execution via sqlite3 shell commands in a restored configuration backup.
restoreConfigBlob() feeds the database dump in a backup to the sqlite3 command-line shell. The shell runs lines starting with a dot as its own commands, so .shell or .system in the dump runs an OS command and .load loads native code.
Anyone who can supply a backup to be restored can run arbitrary commands as the application user.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in CallBackery versions prior to 0.62.0 represents a critical server-side request forgery leading to remote code execution, specifically categorized under CWE-78 Improper Neutralization of Special Elements used in an OS Command commonly known as OS Command Injection. This flaw resides within the application's configuration restoration mechanism, where the function restoreConfigBlob() processes user-supplied backup data without adequate sanitization or validation before passing it directly to the sqlite3 command-line shell utility. The underlying technical failure stems from a misunderstanding of how the SQLite interactive mode interprets input streams; specifically, any line in the database dump that begins with a dot is treated as an internal SQLite directive rather than standard SQL syntax. This architectural oversight allows attackers who possess the ability to upload or supply a malicious configuration backup file to inject arbitrary operating system commands into the execution context of the application process.
The operational impact of this vulnerability is severe, granting an attacker full control over the underlying host operating system under the privileges of the user account running the CallBackery service. By crafting a specially formatted database dump that includes lines starting with .shell or .system followed by arbitrary commands, an adversary can execute any command permitted by the application's runtime environment. Furthermore, the vulnerability extends beyond simple shell execution; it also permits the loading of native dynamic libraries via the .load directive. This capability allows for more sophisticated exploitation techniques, such as executing code within a shared library that may contain custom logic or exploit payloads, thereby expanding the attack surface significantly. The ability to load arbitrary binaries can facilitate privilege escalation if combined with other local vulnerabilities or misconfigurations on the host system.
From an offensive security perspective, this vulnerability aligns closely with MITRE ATT&CK technique T1059 Command and Scripting Interpreter, specifically sub-techniques related to Unix shell commands like sh or bash. The attack vector typically involves a remote authenticated user who has access to the configuration management interface of the application. Since the exploitation requires uploading a file that is then processed by the backend service, it also touches upon aspects of CWE-434 Unrestricted Upload of File with Dangerous Type if the upload mechanism itself lacks proper extension or content validation prior to processing. The persistence and impact are determined entirely by the permissions assigned to the CallBackery process user on the target system, which in many default configurations may have read-write access to sensitive application data directories but limited root privileges.
Mitigation strategies must focus on immediate patching and defensive coding practices for future development. Users running affected versions of CallBackery should upgrade immediately to version 0.62.0 or later where this input validation has been addressed. For environments where upgrading is not immediately feasible, a temporary workaround involves restricting the file upload capabilities within the application interface to trusted administrators only and implementing strict allow-listing for backup file contents at the web server level if possible. From a development standpoint, the restoreConfigBlob function must be refactored to avoid invoking system shells directly with unsanitized input. Instead of piping raw dump files into sqlite3, the application should parse the SQL statements programmatically using safe database APIs that do not interpret special directives as executable commands. Additionally, implementing strict file type validation and content inspection before any restoration process begins can prevent malicious payloads from reaching the vulnerable code path entirely.