CVE-2026-70558 in Dinky
Summary
by MITRE • 08/07/2026
Dinky's POST /download/uploadFromRsByLocal handler passes the caller-supplied path parameter directly to new File(path) and file.transferTo(dest) with no path validation. The route is marked @SaIgnore and /download/** is excluded from the Sa-Token interceptor, so the only guard is a header equality check against a dinkyToken value whose default (efda1551-7958-4e0f-80a8-dfd107df3e38) is hardcoded in source and shipped to every deployment. Anyone who can reach Dinky's HTTP port (8888 by default) and supplies the hardcoded token can write arbitrary files as the Dinky service account. The default Docker image runs on 8888 with no proxy or authentication and chmod 777 on /opt/dinky, so the application's own classpath, launch scripts, and static assets are writable. Demonstrated impact: overwriting /opt/dinky/config/static/index.html served attacker JavaScript to admin browsers immediately, and writing /opt/dinky/org/dinky/Dinky.class executed attacker code as the Dinky service account at the next JVM start via a classpath-shadow launched by script/bin/auto.sh. Writes are uid 9999 (flink), not root, so /etc, /root, /home, and /usr are refused. Affects Dinky v1.2.5 (the current release) and the development branch, where the code is byte-identical.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/07/2026
The vulnerability described represents a critical path traversal and arbitrary file write flaw within Dinky's web application framework that stems from insufficient input validation and overly permissive access controls. The core issue manifests in the POST /download/uploadFromRsByLocal endpoint which directly incorporates user-supplied path parameters into file system operations without any sanitization or validation mechanisms. This handler utilizes new File(path) and file.transferTo(dest) constructs, creating a classic insecure direct object reference condition that allows attackers to manipulate file system paths beyond intended boundaries. The vulnerability is exacerbated by the @SaIgnore annotation which bypasses the Sa-Token security interceptor for the /download/** route, effectively removing any authentication or authorization checks for this specific endpoint.
The security controls in place are fundamentally flawed and provide minimal protection against unauthorized access. A simple header equality check against a hardcoded dinkyToken value serves as the sole barrier to exploitation, with the default token value efda1551-7958-4e0f-80a8-dfd107df3e38 embedded directly in the source code and distributed with every deployment. This hardcoding approach violates fundamental security principles and creates a universal attack vector that remains consistent across all installations. The vulnerability affects both the current stable release v1.2.5 and development branches, indicating this is not an isolated incident but rather a systemic flaw in the application's architecture.
The operational impact of this vulnerability extends far beyond simple file corruption, as it enables complete arbitrary code execution within the application's security context. The default Docker deployment configuration compounds the risk significantly by running on port 8888 without any reverse proxy or authentication mechanisms, while maintaining world-writable permissions (chmod 777) on the entire /opt/dinky directory structure. This allows attackers to not only write files but also modify critical application components including launch scripts and classpath elements. Demonstrated exploitation techniques include immediate JavaScript injection via overwrite of /opt/dinky/config/static/index.html which serves malicious code directly to administrator browsers, as well as persistence mechanisms through modification of /opt/dinky/org/dinky/Dinky.class that executes attacker code during the next JVM startup process initiated by script/bin/auto.sh.
The technical implementation of this vulnerability aligns with CWE-22 Path Traversal and CWE-73 Improper Neutralization of Special Elements in Output Used by a Downstream Component, while also demonstrating characteristics of CWE-352 Cross-Site Request Forgery when combined with the header-based authentication mechanism. From an attacker perspective, this vulnerability maps directly to ATT&CK techniques including T1059 Command and Scripting Interpreter and T1078 Valid Accounts for privilege escalation within the application's security context. The fact that writes occur with uid 9999 (flink user) rather than root creates a limited attack surface but still provides significant operational capabilities including code injection, configuration modification, and persistence establishment. The vulnerability represents a critical failure in defense-in-depth principles where multiple security controls have been bypassed or rendered ineffective through poor implementation choices, creating a path for attackers to compromise the application's integrity and potentially escalate privileges through the application's own execution mechanisms.
The exploitation chain demonstrates the true severity of this vulnerability as it enables both immediate impact through web-based code injection and persistent backdoor capabilities. The attack surface is maximized by the combination of exposed HTTP port, hardcoded authentication token, and overly permissive file system permissions. This vulnerability fundamentally undermines the security model of the application and represents a serious risk to any organization deploying Dinky without proper network segmentation or additional access controls. The fact that this flaw affects both stable and development versions indicates that it has been present for an extended period and likely represents a broader architectural issue within the application's security design approach.