Description

Dinky's SysConfigController.getAll() handler for GET /api/sysConfig/getAll carries a method-level @SaIgnore annotation that short-circuits the class-level @SaCheckLogin, so the Sa-Token interceptor lets the request through with no session or role check. Any remote unauthenticated caller who can reach the Dinky HTTP port (8888 by default) receives the full live system configuration (54 entries on a stock v1.2.5 install) with one parameterless GET. Only one credential field (sys.maven.settings.repositoryPassword) has a desensitization handler wired; the other credential-bearing fields (sys.env.settings.dinkyToken, sys.ldap.settings.userPassword, sys.resource.settings.oss.accessKey and secretKey, and sys.dolphinscheduler.settings.token) return in cleartext. A bare install leaks the shipped defaults, including the hardcoded dinkyToken efda1551-7958-4e0f-80a8-dfd107df3e38 and minioadmin/minioadmin OSS keys; once an operator configures LDAP, object storage, or DolphinScheduler through the Settings Center, those live third-party credentials leak from the same endpoint. Because dinkyToken is the sole gate on the sibling POST /download/uploadFromRsByLocal arbitrary file write, this disclosure defeats token rotation as a mitigation for that vulnerability. Affects Dinky v1.2.5 (the current release, 2025-11-05) and the development branch (dev HEAD 63b5a5a), where the affected code is byte-identical.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-06T22:18:26.387Z",
  "pubdate": "2026-08-06T22:18:26.387Z",
  "executiveSummary": "Dinky suffers from an unauthenticated sensitive information disclosure vulnerability affecting the system configuration endpoint. The vulnerability stems from improper access control configuration within the SysConfigController where method-level authorization bypasses class-level security checks. Unauthenticated remote attackers who can reach the Dinky HTTP port can exploit this flaw to retrieve the complete live system configuration via a single parameterless GET request. The impact includes the plaintext exposure of critical credentials and sensitive configuration parameters, such as directory tokens, LDAP passwords, object storage access and secret keys, and scheduler tokens. A bare installation leaks shipped defaults, while instances with configured third-party integrations expose live operational credentials. This disclosure has severe downstream security implications, as leaked tokens can be leveraged to bypass security controls on sibling endpoints, such as arbitrary file write functionality. The vulnerability affects Dinky v1.2.5 and the development branch at dev HEAD 63b5a5a, requiring no prior authentication or specialized privileges for successful exploitation beyond network reachability to the default port 8888.",
  "technicalDetails": "The vulnerability resides in the SysConfigController component of Dinky, specifically within the getAll() handler mapped to the GET /api/sysConfig/getAll route. The root cause of the flaw is an authorization bypass introduced by a method-level @SaIgnore annotation. This annotation explicitly short-circuits the class-level @SaCheckLogin enforcement, allowing the underlying Sa-Token interceptor to process and fulfill the incoming request without performing any valid session or role verification.\nNetwork exposure is present by default on TCP port 8888, where any remote unauthenticated caller can issue a parameterless HTTP GET request to the vulnerable endpoint. Upon processing the request, the application returns the full live system configuration, exposing dozens of configuration entries in a stock installation.\nWhile a single credential field (sys.maven.settings.repositoryPassword) includes a desensitization handler, multiple other sensitive credential-bearing fields are returned entirely in cleartext. These include sys.env.settings.dinkyToken, sys.ldap.settings.userPassword, sys.resource.settings.oss.accessKey and secretKey, and sys.dolphinscheduler.settings.token.\nThe attack flow proceeds as follows: First, an unauthenticated attacker establishes network connectivity to the Dinky HTTP service on port 8888. Second, the attacker sends an HTTP GET request to /api/sysConfig/getAll. Third, because the @SaIgnore annotation bypasses the Sa-Token authentication interceptor, the application successfully executes the getAll() method and returns the JSON-formatted system configuration containing plaintext secrets. Finally, the attacker harvests credentials such as the hardcoded dinkyToken (efda1551-7958-4e0f-80a8-dfd107df3e38), default minioadmin credentials, or active third-party integration secrets.\nPost-exploitation impact is amplified by the exposure of the dinkyToken parameter, which acts as the sole authentication gate for the sibling POST /download/uploadFromRsByLocal arbitrary file write endpoint. Consequently, this configuration disclosure completely defeats token rotation as a remediation or mitigation strategy for downstream vulnerabilities, allowing attackers to pivot from information disclosure to potential remote code execution or system compromise.\nThe vulnerability affects Dinky v1.2.5 and the development branch (dev HEAD 63b5a5a) where the vulnerable code implementation is byte-identical."
}