Dinky (1.2.5) - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/dinky-1.2.5/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioThu, 06 Aug 2026 23:31:20 +0000Authentication Bypass in Dinky SysConfigControllerhttps://feed.craftedsignal.io/briefs/2026-08-dinky-auth-bypass/Thu, 06 Aug 2026 23:31:20 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-08-dinky-auth-bypass/Dinky v1.2.5 and development builds contain an authentication bypass in the SysConfigController.getAll handler, allowing unauthenticated remote attackers to retrieve cleartext system credentials and service tokens.Dinky v1.2.5 and development branch builds contain an authentication bypass vulnerability (CVE-2026-70559) within the SysConfigController.getAll handler. The vulnerability stems from a method-level @SaIgnore annotation that overrides the class-level @SaCheckLogin, effectively disabling the Sa-Token interceptor for the /api/sysConfig/getAll endpoint. Consequently, any remote unauthenticated caller with network access to the Dinky HTTP port (default 8888) can trigger a parameterless GET request to retrieve the full live system configuration.

The leaked configuration data contains sensitive cleartext credentials, including LDAP passwords, OSS access/secret keys, DolphinScheduler tokens, and the internal Dinky service token. This exposure is particularly critical as it reveals the dinkyToken, which is the primary authentication gate for the /download/uploadFromRsByLocal endpoint, facilitating downstream arbitrary file write attacks. The issue affects the v1.2.5 release and the current development head (63b5a5a).

Impact

Successful exploitation allows unauthenticated attackers to harvest highly sensitive third-party integration credentials and administrative service tokens. Access to these credentials facilitates deeper lateral movement within the environment and persistent access to backend services such as LDAP servers, Object Storage, and job scheduling platforms. Furthermore, the leakage of the internal dinkyToken directly enables exploitation of arbitrary file write vulnerabilities, leading to potential remote code execution on the Dinky server.

Recommendation

  • Restrict network access to the Dinky HTTP port (8888) to trusted IP ranges only via host-based or network firewalls to prevent unauthorized access to /api/sysConfig/getAll.
  • Audit all third-party credentials (LDAP, OSS, DolphinScheduler) that were stored in the Dinky Settings Center, as these are considered compromised.
  • Implement monitoring on the /api/sysConfig/getAll endpoint to detect unauthorized GET requests from non-admin internal segments.
  • Review and rotate the dinkyToken immediately if the Dinky instance is network-accessible.
]]>highadvisoryCritical Path Traversal and RCE in Dinkyhttps://feed.craftedsignal.io/briefs/2026-08-dinky-path-traversal/Thu, 06 Aug 2026 23:29:42 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-08-dinky-path-traversal/Dinky v1.2.5 contains a path traversal vulnerability in the /download/uploadFromRsByLocal endpoint, which is protected by a hardcoded authentication token, allowing unauthenticated attackers to achieve arbitrary file write and remote code execution.Dinky v1.2.5 is vulnerable to a critical path traversal and arbitrary file write vulnerability within the POST /download/uploadFromRsByLocal handler. The application fails to validate the caller-supplied path parameter before passing it to Java file operations, allowing an attacker to write files outside of the intended directory. While the endpoint is intended to be secured, it is excluded from the application's primary authentication interceptor. Security relies solely on a header equality check against a 'dinkyToken' header. This token is hardcoded in the source code as 'efda1551-7958-4e0f-80a8-dfd107df3e38' and is identical across all deployments.

Attackers who reach the application's HTTP port (default 8888) can supply this hardcoded token to bypass access controls. Given that default installations often run with excessive write permissions in the /opt/dinky directory, this vulnerability allows for remote code execution by overwriting application classpath files or static assets, facilitating persistent access and browser-based attacks against administrators.

Impact

Successful exploitation allows an unauthenticated remote attacker to gain code execution as the Dinky service account (typically uid 9999). Observed impact includes the modification of static assets to execute JavaScript in administrative sessions and the overwriting of compiled Java classes within the application's classpath to execute arbitrary code upon JVM restart. This affects all deployments of Dinky v1.2.5 and the current development branch.

Recommendation

  • Deploy the Sigma rule below to detect unauthorized access attempts or suspicious file write operations.
  • Update Dinky to a patched version once released to remediate the hardcoded token and path validation flaws.
  • Audit and restrict file system permissions for the Dinky service account to prevent modification of application-critical files and directories.
  • Block inbound traffic to the Dinky HTTP port from untrusted networks and ensure that management interfaces are not exposed to the public internet.
]]>criticaladvisory