GHSA-2p66-w3p3-5226: Dinky Unauthenticated Arbitrary File Write via /download/uploadFromRsByLocal Gated Only by Hardcoded Default Token

Published Aug 6, 2026

Updated

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.

Affected Software

1 affected component

dinky dinky=1.2.5, =development branch

Event History

Aug 6, 2026

CVE Published

via OSV·07:30 PM

Data Sourced

via OSV·07:30 PM

DescriptionSeverityWeakness

Frequently Asked Questions

Which deployments are most exposed?

Deployments where an attacker can reach Dinky's HTTP port are exposed, particularly the default Docker image, which listens on port 8888 without a proxy or authentication. The default image also makes /opt/dinky writable, allowing modification of application files, launch scripts, and static assets.

What does an attacker need to exploit this issue?

An attacker needs network access to the Dinky HTTP service and must supply the hardcoded default dinkyToken value in the request header. No authenticated Dinky account or user interaction is required.

What can an attacker modify, and what are the privilege limits?

An attacker can write arbitrary files with the permissions of the Dinky service account. In the described Docker setup, writes run as uid 9999 (flink), so protected locations such as /etc, /root, /home, and /usr are refused, while writable files under /opt/dinky can be overwritten.

What are the likely impacts of a successful write?

An attacker can replace static content such as index.html to serve malicious JavaScript to administrator browsers. They can also write a classpath-shadowing Dinky.class that executes as the Dinky service account after the JVM is restarted through script/bin/auto.sh.

GHSA-2p66-w3p3-5226: Dinky Unauthenticated Arbitrary File Write via /download/uploadFromRsByLocal Gated Only by Hardcoded Default Token

Affected Software

Event History

Frequently Asked Questions

Which deployments are most exposed?

What does an attacker need to exploit this issue?

What can an attacker modify, and what are the privilege limits?

What are the likely impacts of a successful write?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are most exposed?

What does an attacker need to exploit this issue?

What can an attacker modify, and what are the privilege limits?

What are the likely impacts of a successful write?