CVE-2026-110254 in Dockhand
Summary
by MITRE • 10/14/2026
Finsys Dockhand before 1.0.45 contains a server-side request forgery vulnerability in the ipCategory() function in src/lib/server/url-safety.ts, which fails to check NAT64, 6to4, and Teredo IPv6 transition ranges. Authenticated attackers can embed loopback, cloud metadata, or private IPv4 addresses in transition IPv6 literals within notification, backup, template, registry, git, or secret provider URLs to reach internal services.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in Finsys Dockhand prior to version 1.0.45 represents a critical server-side request forgery flaw rooted in the application's handling of IPv6 address transitions within its URL safety validation logic. Specifically, the ipCategory function located in src/lib/server/url-safety.ts fails to adequately inspect or block specific IPv6 transition ranges such as NAT64, 6to4, and Teredo prefixes. These mechanisms are designed to facilitate communication between IPv6-only networks and legacy IPv4 infrastructure by embedding IPv4 addresses within IPv6 literals. The security failure occurs because the validation routine does not recognize that these embedded structures can be exploited to mask internal or loopback destinations behind seemingly valid external-looking IPv6 formats, thereby bypassing standard access control checks designed for IP address categorization.
From a technical perspective, this flaw allows authenticated attackers to craft malicious URLs containing transition-style IPv6 literals where the underlying payload resolves to private IPv4 addresses, local host addresses like 127.0.0.1, or cloud metadata endpoints such as those found at 169.254.169.254 in AWS environments. By injecting these crafted URLs into various configuration vectors including notification services, backup destinations, template engines, registry settings, git integrations, and secret provider configurations, an attacker can force the server to initiate HTTP requests to internal resources that are otherwise inaccessible from the public internet or external network segments. This effectively transforms the application into a proxy for attacking other systems within the same trust boundary, leveraging the server's own privileges and network access to probe or exploit backend services.
The operational impact of this vulnerability is significant as it enables unauthorized lateral movement and data exfiltration within an organization's internal infrastructure. Attackers can use this vector to scan internal networks, extract sensitive configuration details from cloud metadata endpoints which often contain authentication tokens and instance credentials, or interact with administrative interfaces of internal applications that are not exposed publicly. This capability undermines the principle of least privilege by allowing authenticated users to access resources they should not have permission to reach, potentially leading to full system compromise if combined with other vulnerabilities in the targeted internal services. The vulnerability is classified under CWE-918 Server-Side Request Forgery and aligns with ATT&CK technique T1557 which covers Adversary-in-the-Middle scenarios involving LLMNR/NBT-NS poisoning or SMB relay, although here it specifically facilitates SSRF to access internal endpoints rather than credential harvesting directly.
To mitigate this risk, organizations running Finsys Dockhand versions earlier than 1.0.45 must upgrade immediately to the patched version where the ipCategory function has been updated to properly validate and reject IPv6 transition addresses that contain private or loopback ranges. In environments where upgrading is not immediately feasible, network-level controls such as firewall rules should be implemented to restrict outbound connections from the Dockhand server to internal IP ranges unless explicitly required for business operations. Additionally, input validation on all URL fields accepting user-supplied data should enforce strict allow-listing of permitted domains and protocols, ensuring that even if a bypass occurs at the application layer, network segmentation prevents access to sensitive backend resources. Regular security audits focusing on SSRF prevention patterns are recommended to identify similar weaknesses in other components of the platform.