CVE-2026-3052: Dinky Dinky SSRF Vulnerability

CVE-2026-3052 Overview

A Server-Side Request Forgery (SSRF) vulnerability has been identified in DataLinkDC Dinky versions up to 1.2.5. The vulnerability exists within the proxyUba function located in the file dinky-admin/src/main/java/org/dinky/controller/FlinkProxyController.java of the Flink Proxy Controller component. This flaw allows authenticated remote attackers to manipulate server-side requests, potentially enabling access to internal systems and services that should not be directly accessible from external networks.

Critical Impact

Authenticated attackers can exploit this SSRF vulnerability remotely to access internal services, scan internal networks, and potentially bypass security controls designed to protect backend systems.

Affected Products

• DataLinkDC Dinky versions up to and including 1.2.5
• Dinky Flink Proxy Controller component

Discovery Timeline

• 2026-02-24 - CVE CVE-2026-3052 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-3052

Vulnerability Analysis

This Server-Side Request Forgery (SSRF) vulnerability is classified under CWE-918 (Server-Side Request Forgery). The vulnerability resides in the Flink Proxy Controller component, specifically within the proxyUba function. When exploited, an attacker with low privileges can manipulate the application to send crafted requests to arbitrary destinations, including internal services that would otherwise be protected by network segmentation.

The vulnerability enables remote exploitation through the network without requiring user interaction. An attacker can leverage this flaw to probe internal infrastructure, access metadata services in cloud environments, or interact with internal APIs that trust requests originating from the application server.

Root Cause

The root cause of this vulnerability is insufficient validation of user-supplied input within the proxyUba function in the FlinkProxyController.java file. The application fails to properly sanitize or validate URLs or request parameters before making server-side HTTP requests. This allows attackers to craft malicious requests that instruct the server to connect to arbitrary internal or external destinations.

Attack Vector

The attack is conducted remotely over the network and requires the attacker to have low-level authentication privileges. Once authenticated, the attacker can manipulate request parameters sent to the Flink Proxy Controller endpoint. By supplying specially crafted URLs or hostnames, the attacker forces the server to make requests on their behalf to internal services, cloud metadata endpoints, or other network resources.

The SSRF vulnerability can be leveraged to:

• Access internal services not exposed to the internet
• Retrieve cloud provider metadata (potentially including credentials)
• Scan internal network ports and services
• Bypass IP-based access controls
• Interact with internal APIs using the server's trusted identity

The exploit details have been made public and are available through the GitHub Issue Discussion. The vendor was contacted about this disclosure but did not respond.

Detection Methods for CVE-2026-3052

Indicators of Compromise

• Unusual outbound HTTP/HTTPS requests from the Dinky application server to internal IP ranges (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x)
• Requests to cloud metadata endpoints such as 169.254.169.254 originating from the application
• Abnormal request patterns to the Flink Proxy Controller endpoint with suspicious URL parameters
• Log entries showing requests to localhost or loopback addresses (127.0.0.1) from the proxy function

Detection Strategies

• Monitor application logs for requests to the /api/flink/proxy or similar proxy-related endpoints with unusual URL parameters
• Implement network-level monitoring to detect outbound connections from the Dinky server to internal network ranges or cloud metadata services
• Deploy web application firewall (WAF) rules to detect and block SSRF payloads in request parameters
• Analyze authentication logs for accounts making excessive or unusual requests to proxy endpoints

Monitoring Recommendations

• Enable detailed request logging on the Dinky application server to capture all incoming requests with full parameter data
• Configure egress filtering alerts for the application server to detect connections to internal network segments
• Set up intrusion detection signatures specifically targeting SSRF patterns in HTTP requests
• Implement real-time alerting for any connections to cloud metadata endpoints from application servers

How to Mitigate CVE-2026-3052

Immediate Actions Required

• Restrict network-level access to the Dinky administrative interface to trusted IP ranges only
• Implement egress filtering on the application server to block connections to internal network ranges and cloud metadata endpoints
• Review and audit user accounts with access to the Flink Proxy Controller functionality
• Consider disabling the proxy functionality temporarily if not critical to operations

Patch Information

At the time of publication, no vendor patch has been made available. The vendor was contacted about this disclosure but did not respond. Organizations should monitor the official Dinky project repositories for security updates. Additional technical details can be found in the VulDB entry #347410 and the associated GitHub issue.

Workarounds

• Apply strict input validation on any proxy-related endpoints to ensure only allowlisted destinations can be accessed
• Implement network segmentation to isolate the Dinky application server from sensitive internal resources
• Configure web application firewall rules to block requests containing internal IP addresses, localhost references, or cloud metadata URLs in parameters
• Apply the principle of least privilege by restricting which authenticated users can access proxy functionality

# Example: Network-level mitigation using iptables to block outbound SSRF targets
# Block requests to internal network ranges from the application server
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -d 169.254.169.254 -j DROP