Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-06T22:18:26.227Z",
  "pubdate": "2026-08-06T22:18:26.227Z",
  "executiveSummary": "Dinky contains an arbitrary file write vulnerability within the POST /download/uploadFromRsByLocal handler, affecting Dinky v1.2.5 and the development branch. The root cause stems from improper input validation, where caller-supplied path parameters are passed directly to java.io.File constructors and file transfer utilities without adequate sanitization, leading to path traversal and arbitrary file creation capabilities.\nThe security posture of this endpoint relies heavily on a hardcoded default token (efda1551-7958-4e0f-80a8-dfd107df3e38) defined in the source code and shipped across deployments, bypassing the Sa-Token interceptor via @SaIgnore annotations and route exclusions for /download/**. Unauthenticated or remote attackers who can reach the Dinky HTTP port (8888 by default) can leverage this hardcoded credential.\nIn default containerized deployments where the service runs on port 8888 without a reverse proxy and utilizes permissive file permissions (chmod 777 on /opt/dinky), exploitation yields severe impact. Attackers can overwrite critical application assets such as /opt/dinky/config/static/index.html to inject malicious JavaScript targeting administrative browsers, or perform classpath shadowing by writing malicious compiled classes like /opt/dinky/org/dinky/Dinky.class.\nBecause the service runs under the flink service account (uid 9999) rather than root, write attempts against system directories such as /etc, /root, /home, and /usr are denied. However, successful exploitation of writable application paths allows for remote code execution upon the next JVM start via automated launch scripts like script/bin/auto.sh, severely compromising application integrity and confidentiality.",
  "technicalDetails": "The vulnerability resides in the POST /download/uploadFromRsByLocal handler within Dinky v1.2.5 and the active development branch. The vulnerable component directly ingests an untrusted, caller-supplied path parameter and instantiates a new java.io.File(path) object, subsequently utilizing the file.transferTo(dest) method to persist uploaded data to the disk without conducting path traversal checks or path canonicalization validation.\nAuthentication and authorization controls for this endpoint are insufficiently hardened. The route is explicitly annotated with @SaIgnore, and the entire /download/** URI namespace is explicitly excluded from the Sa-Token security interceptor. Consequently, access control relies entirely on a custom header equality check against a dinkyToken variable. The default value for this token (efda1551-7958-4e0f-80a8-dfd107df3e38) is hardcoded directly into the application source code and distributed natively with every deployment instance.\nThe attack flow proceeds as follows: First, an attacker establishes network connectivity to Dinky's listening HTTP port, which defaults to port 8888. Second, the attacker formulates an HTTP POST request targeting the /download/uploadFromRsByLocal endpoint, supplying the hardcoded dinkyToken value in the request headers to satisfy the weak authentication check. Third, the attacker includes a malicious payload along with a crafted path parameter designed to traverse directories relative to the application base path.\nIn default Docker deployments, the application container exposes port 8888 directly without an intervening proxy, implements no network-level authentication, and features overly permissive directory permissions (chmod 777 on /opt/dinky). This structural configuration permits the application process—running under the unprivileged flink service account (uid 9999)—to write files across the application directory structure. While system directories like /etc, /root, /home, and /usr remain protected due to POSIX file permissions enforced against uid 9999, application-owned paths are fully writable.\nPost-exploitation impact manifests in two primary vectors. First, an attacker can overwrite static assets such as /opt/dinky/config/static/index.html, resulting in the immediate delivery of malicious JavaScript payloads to administrative browsers accessing the web interface. Second, an attacker can perform classpath shadowing by writing malicious compiled Java class files, such as /opt/dinky/org/dinky/Dinky.class. When the JVM restarts, automated launch scripts such as script/bin/auto.sh load the shadowed classes into the classpath, resulting in arbitrary code execution under the privileges of the Dinky service account."
}