CVE-2026-70559 in Dinky
Summary
by MITRE • 08/07/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/07/2026
The vulnerability identified in Dinky's SysConfigController represents a critical authentication bypass flaw that undermines the application's security model through improper access control implementation. This issue manifests in the getAll() method of the SysConfigController which handles GET requests to /api/sysConfig/getAll and contains a method-level SaIgnore annotation that explicitly disables the class-level SaCheckLogin protection. The Sa-Token framework interceptor, designed to enforce session and role validation across the application, is effectively circumvented for this specific endpoint, allowing any unauthenticated remote attacker with network access to the Dinky HTTP port to retrieve complete system configuration data without providing valid credentials.
The technical implications of this vulnerability extend far beyond simple information disclosure, as it exposes sensitive credential information in cleartext format. The response contains 54 configuration entries from a stock v1.2.5 installation, with only one credential field (sys.maven.settings.repositoryPassword) receiving desensitization treatment while all other sensitive fields remain fully exposed. These include dinkyToken values that serve as the primary authentication mechanism for sibling endpoints, LDAP user passwords, OSS access keys and secrets, and DolphinScheduler tokens. The exposure of these credentials represents a direct violation of security best practices and creates multiple attack vectors for adversaries seeking to escalate privileges or compromise connected systems.
The operational impact of this vulnerability is severe and multifaceted, particularly given that the dinkyToken serves as the authentication mechanism for the POST /download/uploadFromRsByLocal endpoint which enables arbitrary file writing capabilities. This creates a complete chain of compromise where credential disclosure directly enables remote code execution or system takeover through file upload attacks. The vulnerability affects both the current stable release (v1.2.5) and development branch, indicating this is not an isolated issue but rather a systemic flaw in the authentication architecture that persists across versions. Additionally, default configuration values are exposed including hardcoded dinkyToken and minioadmin/minioadmin credentials, which provides attackers with immediate access to production systems without requiring any additional reconnaissance or exploitation steps.
This vulnerability maps directly to CWE-285 (Improper Authorization) and represents a failure in the principle of least privilege enforcement within the application's security architecture. The flaw also aligns with ATT&CK technique T1078 (Valid Accounts) as it enables attackers to leverage exposed credentials for unauthorized access, while simultaneously supporting T1566 (Phishing) through the exposure of system configuration that could aid in crafting more convincing social engineering attacks. The bypass of session validation mechanisms creates a persistent security weakness that affects all endpoints requiring authentication, particularly those with elevated privileges or sensitive operations such as file upload capabilities.
Mitigation strategies must address both immediate and long-term security concerns in this scenario. Immediate remediation requires removal of the @SaIgnore annotation from the getAll() method and proper enforcement of authentication checks for all system configuration endpoints. The application should implement comprehensive credential desensitization across all sensitive fields, including dynamic generation of default tokens and keys rather than hardcoded values. Additionally, the system should enforce role-based access control for configuration endpoints, ensuring that only authorized administrators can access sensitive system settings. Regular security audits should be implemented to identify similar bypass patterns throughout the application codebase, while automated scanning tools should be configured to detect unauthorized use of security annotation bypasses. The development team must also address the root cause by establishing clear security guidelines for method-level annotations and ensuring proper review processes for authentication-related code changes to prevent similar issues from reoccurring in future releases.