CVE-2026-108980 in Blinko
Summary
by MITRE • 10/12/2026
Blinko through 1.8.8 allows directory traversal, overwriting startup files as root, via installPlugin. It builds the plugin install path from an unsanitized name in server/routerTrpc/plugin.ts, and the plugin.installPlugin tRPC procedure is open to any authenticated user. Thus, a name containing ../ sequences writes the downloaded plugin files outside the plugins directory. Because the official Docker image runs as root, an authenticated attacker overwrites a root-owned startup file and achieves remote code execution as root. Self-registration for an account may be possible.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in Blinko versions through 1.8.8 represents a critical security failure involving directory traversal and privilege escalation that ultimately leads to remote code execution with root privileges. This flaw is rooted in the application's plugin installation mechanism, specifically within the server/routerTrpc/plugin.ts module where the path for installing plugins is constructed using an unsanitized user-supplied name parameter. The technical core of this issue lies in the lack of input validation on the filename provided during the installPlugin tRPC procedure. Because the system does not adequately sanitize or restrict special characters such as dot-dot-slash sequences, it allows attackers to manipulate the file path structure. When a malicious actor provides a plugin name containing ../ sequences, the application resolves this relative path incorrectly, causing downloaded files to be written outside of the intended plugins directory and into arbitrary locations on the server's filesystem.
The operational impact of this vulnerability is severe due to the deployment configuration commonly used for Blinko via its official Docker image. This containerized environment typically runs with root privileges by default. Consequently, when an authenticated user exploits the path traversal flaw to overwrite files outside the plugin directory, they are effectively writing as the root user. By targeting specific startup or initialization scripts that are executed upon application launch or restart, an attacker can inject malicious code into these critical system files. Once the service is restarted or initialized under new conditions, the injected payload executes with full administrative privileges, granting the attacker complete control over the underlying host environment. This transforms a standard authenticated user account into a vector for total system compromise.
From a classification perspective, this vulnerability aligns closely with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which describes flaws where software does not properly neutralize special elements within file paths that could resolve to parent directories or other files outside the intended scope. Furthermore, the exploitation technique maps directly to MITRE ATT&CK techniques related to Persistence and Privilege Escalation, specifically those involving modification of system startup scripts or configuration files to maintain access and elevate privileges from a standard user context to root-level administrative control. The fact that the installPlugin procedure is accessible to any authenticated user significantly lowers the barrier for entry, as it does not require initial administrator credentials, although self-registration capabilities may further expand the attack surface if enabled by default or configured permissively.
Mitigation strategies must address both the immediate code flaw and the broader deployment security posture. The primary remediation involves implementing strict input validation on all file path parameters within the plugin installation logic to ensure that only alphanumeric characters and safe delimiters are accepted, effectively preventing directory traversal sequences from being processed. Additionally, developers should enforce canonicalization of paths before writing files to guarantee they remain within the designated plugins directory regardless of user input. Beyond code fixes, it is crucial to adhere to the principle of least privilege by configuring the Blinko Docker container to run under a non-root user account with minimal permissions. This would prevent an attacker from overwriting root-owned startup files even if path traversal were successfully achieved. Regular security audits and static analysis tools should be employed to detect similar input handling vulnerabilities across other endpoints within the tRPC API surface.