The CVE description focuses on a hardcoded dinkyToken, but the token is largely irrelevant to the actual attack surface. What matters is the combination of two independent failures that together enable reliable remote code execution without any secondary misconfiguration.
First, the @SaIgnore annotation on the file upload endpoint bypasses the entire authentication chain—not just the token, but the entire Sa-Token framework. This annotation makes the endpoint invisible to standard security scanners that rely on method-level annotations for coverage. Second, and critically, the official Docker image applies chmod 777 to /opt/dinky, making the application's classpath (org/dinky/*.class), launch scripts (bin/auto.sh), and static assets world-writable. When the container runs as uid 9999 (the Dinky user), this collapses the attack surface from 'write anywhere uid 9999 can reach' to 'write anything the JVM will execute.'
The exploit is straightforward: write a malicious class file to org/dinky/ that shadows a legitimate one, then trigger its loading through the unauthenticated file write endpoint. This survives container restarts via volume mounts, creating a persistent backdoor. The world-writable classpath is also invisible to Dockerfile-only security reviews—the chmod 777 likely came from a wildcard instruction inside a RUN command that doesn't appear in the published Dockerfile, meaning standard DevSecOps auditing will miss it.
Defenders should: immediately restrict /opt/dinky permissions to 755 or 644 via a rebuilt image; audit all @SaIgnore annotations in the codebase and remove any not tied to explicit design decisions; rotate any exposed tokens; and recognize that fixing the token alone leaves the @SaIgnore + classpath vector exploitable. The Flink trust relationship means compromise of Dinky can pivot to Flink job injection or checkpoint tampering—make sure network segmentation accounts for this.