The vulnerability arises because Dinky's POST /download/uploadFromRsByLocal handler directly uses a caller-supplied path parameter to create and write files without validating the path. The route bypasses the Sa-Token interceptor and only checks a hardcoded header token, which is shipped with every deployment. An attacker with network access to the HTTP port and knowledge of the token can upload arbitrary files as the Dinky service account (uid 9999). The default Docker image runs with no proxy or authentication and has world-writable permissions on /opt/dinky, allowing overwriting of critical application files such as static assets and class files. This enables immediate JavaScript injection in admin browsers and remote code execution on JVM restart via classpath shadowing.

Successful exploitation allows an unauthenticated attacker to write arbitrary files as the Dinky service account, leading to full compromise of the application. This includes overwriting static web assets to serve malicious JavaScript to administrators and placing malicious class files that execute code with the service account privileges on JVM restart. The attack surface includes the default Docker deployment with no authentication and permissive file permissions. The attacker cannot write to system directories owned by root but can fully control the application environment.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, restrict network access to the Dinky HTTP port (default 8888) to trusted users only. Change or remove the default hardcoded dinkyToken value if possible. Avoid running the default Docker image in production environments without additional access controls or file permission hardening. Monitor for unusual file changes in the /opt/dinky directory and consider disabling or restricting the vulnerable upload endpoint if feasible.