The vulnerability resides in Dinky’s POST /download/uploadFromRsByLocal endpoint, which accepts a client‑supplied path and directly constructs a File object and uses file.transferTo without any path validation. The route bypasses authentication by being marked @SaIgnore and excluded from the Sa-Token interceptor; the only remaining guard is a header equality check against a hard‑coded token value (efda1551‑7958‑4e0f‑80a8‑dfd107df3e38). Because the token is embedded in the source and shipped with every deployment, any host that can reach the service’s HTTP port 8888 can write to any file location that the Dinky service account can access. In the default Docker image the writable directory /opt/dinky is world‑editable, allowing attackers to replace application assets and class files. Demonstrated impact includes overwriting /opt/dinky/config/static/index.html to deliver malicious JavaScript to privileged browsers and dropping a crafted Dinky.class file that is loaded on the next JVM startup, enabling persistent code execution.

The affected system is the DataLinkDC Dinky product, version 1.2.5, and the current development branch, both of which contain identical code. The vulnerability exists in the bundled Docker image that exposes port 8888, runs without a reverse proxy or authentication layer, and mounts /opt/dinky with 0777 permissions. The service account used for file writes operates under UID 9999 (flink). Direct write access is limited to the application’s own files and directories; system directories such as /etc, /root, /home, and /usr are protected by filesystem permissions.

The CVSS score of 9.3 indicates critical severity. The EPSS score is not available, but the lack of authentication, the presence of a hard‑coded token, and the existence of a publicly reachable write endpoint make exploitation highly feasible. The vulnerability is not listed in the CISA KEV catalog. An attacker with network reachability to the service can trivially perform arbitrary file writes, potentially leading to remote code execution as the Dinky service account. Because the service account uid 9999 is non‑root, compromise is limited to the application’s writable files, but this is sufficient for persistent compromise through classpath modification or injection of malicious JavaScript.