The vulnerability exists in Dinky v1.2.5's POST /download/uploadFromRsByLocal handler, which directly uses a caller-supplied path parameter to create and write files without validating the path. The endpoint bypasses the Sa-Token interceptor and relies solely on a hardcoded dinkyToken header value for access control. Since the default Docker image runs on port 8888 without proxy or authentication and grants write permissions (chmod 777) on /opt/dinky, an attacker who knows the hardcoded token can overwrite critical files such as static assets and class files. This allows immediate injection of malicious JavaScript into admin browsers and remote code execution as the Dinky service account upon JVM restart. The service runs as uid 9999 (flink), restricting writes to certain system directories but still enabling significant compromise.

An attacker with network access to the Dinky HTTP port and knowledge of the hardcoded token can upload arbitrary files as the Dinky service account. This enables immediate compromise of the web interface by injecting malicious scripts and persistent remote code execution by overwriting class files loaded on JVM startup. The vulnerability leads to full confidentiality, integrity, and availability impact on the affected system. The service account's limited permissions restrict some system-wide damage but do not prevent significant application-level compromise.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, restrict network access to the Dinky HTTP port (default 8888) to trusted users only. Change the hardcoded dinkyToken value if possible and monitor for unauthorized file changes in the /opt/dinky directory. Avoid deploying the default Docker image in untrusted environments without additional access controls.