The flaw in Dinky’s SysConfigController allows any remote caller who can reach port 8888 to retrieve the entire system configuration through a simple unauthenticated GET request to /api/sysConfig/getAll. The controller method is protected by a @SaIgnore annotation that bypasses the class‑level @SaCheckLogin check, so the Sa‑Token interceptor does not perform any session or role validation. As a result, 54 configuration entries are returned, including several credential‑bearing fields that are exposed in cleartext, such as sys.env.settings.dinkyToken, sys.ldap.settings.userPassword, sys.resource.settings.oss.accessKey and secretKey, and sys.dolphinscheduler.settings.token. The hard‑coded dinkyToken and minioadmin credentials that ship with a fresh installation are also leaked, and any credentials set via the Settings Center are also exposed. The disclosed dinkyToken is the single token that protects the arbitrary file‑write endpoint, so a credential leak directly undermines that mitigation.

DataLinkDC’s Dinky is affected in its 1.2.5 release (the current version as of 2025‑11‑05) and the development branch at commit 63b5a5a. The vulnerability exists in the source code that is byte‑identical between these two branches.

With a CVSS score of 8.7 the vulnerability is classified as high severity. No EPSS score is published, and the issue is not listed in the CISA KEV catalog, however the lack of any authentication requirement and the fact that the vulnerable endpoint is exposed on the default HTTP port mean that an attacker can reliably exploit the flaw from any network location that can reach port 8888. Once exploited, an attacker gains full visibility into the system configuration and any third‑party credentials, enabling further compromise such as arbitrary file writes, LDAP or OSS credential theft, and full domination of the Dinky instance.