{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/vendors/dinky/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2026-70558"}],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Dinky (1.2.5)"],"_cs_severities":["critical"],"_cs_tags":[],"_cs_type":"advisory","_cs_vendors":["Dinky"],"content_html":"\u003cp\u003eDinky 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.\u003c/p\u003e\n\u003cp\u003eAttackers 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.\u003c/p\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule below to detect unauthorized access attempts or suspicious file write operations.\u003c/li\u003e\n\u003cli\u003eUpdate Dinky to a patched version once released to remediate the hardcoded token and path validation flaws.\u003c/li\u003e\n\u003cli\u003eAudit and restrict file system permissions for the Dinky service account to prevent modification of application-critical files and directories.\u003c/li\u003e\n\u003cli\u003eBlock inbound traffic to the Dinky HTTP port from untrusted networks and ensure that management interfaces are not exposed to the public internet.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-08-06T23:29:42Z","date_published":"2026-08-06T23:29:42Z","id":"https://feed.craftedsignal.io/briefs/2026-08-dinky-path-traversal/","summary":"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.","title":"Critical Path Traversal and RCE in Dinky","url":"https://feed.craftedsignal.io/briefs/2026-08-dinky-path-traversal/"}],"language":"en","title":"CraftedSignal Threat Feed - Dinky","version":"https://jsonfeed.org/version/1.1"}