Apr 11, 2026·5 min read·2 visits
Arcane versions prior to 1.17.3 are vulnerable to unauthenticated SSRF via the `/api/templates/fetch` endpoint. Attackers can leverage this to scan internal networks, access cloud metadata, and extract internal service data due to poor input validation and verbose error reflection.
Arcane, a web-based interface for managing Docker environments, contains a high-severity unauthenticated Server-Side Request Forgery (SSRF) vulnerability. Prior to version 1.17.3, the application exposed the `/api/templates/fetch` endpoint without authentication, allowing remote attackers to force the server to perform outbound HTTP GET requests to arbitrary destinations. The vulnerability exposes internal network services, cloud provider metadata endpoints, and internal application states through robust error-based side-channels and direct response reflection.
Arcane operates as a web-based management interface for Docker environments, requiring elevated access to orchestrate container deployments. The application exposes various API endpoints to facilitate management tasks. Prior to version 1.17.3, the software exposed an endpoint at /api/templates/fetch designed to retrieve external template definitions for container provisioning.
This endpoint suffers from a Server-Side Request Forgery (SSRF) vulnerability classified under CWE-918. The application accepts an arbitrary url parameter provided by the user and initiates a server-side HTTP GET request to the specified destination. The vulnerable implementation lacks fundamental input validation, access controls, and network-level restrictions.
Attackers can leverage this unprotected endpoint to bypass external firewalls and access internal network boundaries. The application acts as a proxy, masking the attacker's true IP address and allowing interaction with loopback interfaces, internal network services, and restricted cloud provider metadata endpoints.
The core defect resides in the backend routing logic for the /api/templates/fetch endpoint. The route definition was configured without authentication middleware, rendering it publicly accessible to any network-adjacent or remote attacker. The lack of access control allows arbitrary unauthenticated users to invoke the underlying handler logic.
Within the request handler, the application utilized the default Go http.Client to perform outbound HTTP GET requests. The implementation did not restrict protocol schemes, allowing any scheme supported by the Go standard library. Furthermore, the application failed to implement network-level destination filtering or DNS resolution validation prior to initiating the HTTP request.
The logic failed to validate resolved IP addresses against a blocklist of non-routable or private IP spaces. Requests directed at the loopback interface (127.0.0.1), RFC 1918 private network ranges, or the ubiquitous cloud instance metadata service at 169.254.169.254 were processed without restriction, completing the SSRF execution chain.
The remediation introduced in version 1.17.3, specifically within commit 8e67b3b1ff5e07814d3e67aa45721fe277e302e9, addresses the vulnerability through multiple defensive layers. The Huma API definition was updated to enforce BearerAuth or ApiKeyAuth on the affected endpoint, mitigating the unauthenticated access vector entirely.
The patch replaces the default HTTP client with a custom SafeOutboundHTTPClient. This specific implementation utilizes a custom DialContext function that performs DNS resolution and strictly validates the resulting IP address against a comprehensive blocklist before establishing the TCP connection. This approach prevents DNS rebinding attacks and Time-of-Check to Time-of-Use (TOCTOU) bypasses.
The enforced blocklist explicitly denies access to loopback (127.0.0.0/8), private networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and link-local addresses (169.254.0.0/16). The custom client also implements a strict CheckRedirect policy to validate subsequent hops in any HTTP redirect chain, terminating connections if a redirect attempts to traverse into restricted IP spaces.
// backend/pkg/utils/httpx/safe_remote.go
var blockedRemotePrefixes = mustParsePrefixesInternal(
"0.0.0.0/8", "100.64.0.0/10", "127.0.0.0/8", "169.254.0.0/16",
"192.0.0.0/24", "192.0.2.0/24", "198.18.0.0/15", "198.51.100.0/24",
"203.0.113.0/24", "224.0.0.0/4", "240.0.0.0/4", "::/128", "::1/128",
"2001:db8::/32", "fc00::/7", "fe80::/10", "ff00::/8",
)
func ValidateSafeRemoteURL(ctx context.Context, rawURL string, lookupIP LookupIPFunc) (*url.URL, error) {
// Implementation utilizes blockedRemotePrefixes to drop forbidden subnets
}Exploitation requires sending a standard HTTP GET request to the vulnerable endpoint with a crafted url payload. If the internal target service returns a JSON payload matching Arcane's expected template Data Transfer Object (DTO) structure, the application reflects the full response body back to the attacker. This enables direct data exfiltration from compatible internal REST APIs.
The vulnerable implementation introduces high-fidelity side-channels due to inadequate error handling and verbose exception propagation. When the target service returns non-JSON data, the Go JSON decoder fails to unmarshal the response. The raw error message is reflected to the client, effectively leaking the first byte of the internal response (e.g., invalid character '<' at line 1 confirms an HTML document).
The application also leaks low-level TCP transport errors. Attackers can reliably distinguish between a closed port (connection refused), a filtered or firewalled port (i/o timeout), and an open port based on the precise error string returned by the server. The HTTP status code returned by the internal target is also explicitly reflected in the response metadata.
These combined side-channels facilitate precise internal network reconnaissance. An attacker can map internal IP spaces, identify running web services via the first-byte HTML leak, and locate sensitive endpoints without requiring full direct response reflection.
The vulnerability achieves a High severity rating (CVSS 7.2) due to the complete lack of authentication requirements and the ability to pivot requests into internal network zones. The Arcane server acts as an open relay, circumventing perimeter security controls and exposing the internal network topology to arbitrary external actors.
Confidentiality impact is categorized as Low in the CVSS vector because the full response reflection requires the internal service to return specifically formatted JSON. However, the practical risk depends entirely on the deployment environment. Access to unprotected internal services, such as unauthenticated Docker daemon APIs, Redis instances, or cloud metadata endpoints, often leads to lateral movement or total environment compromise.
Integrity impact is context-dependent and constrained by the limitation to HTTP GET requests. While standard REST APIs mandate state modification via POST/PUT/DELETE methods, legacy internal administrative interfaces or poorly designed endpoints often perform state-modifying actions via GET parameters. An attacker can manipulate internal system configurations if such endpoints exist.
The comprehensive patch implemented in version 1.17.3 effectively eliminates the attack surface. The introduction of strict network boundaries, explicit error sanitization, and authentication requirements ensures that the Arcane application can no longer be utilized as an instrument for internal network interrogation.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
Arcane getarcaneapp | < 1.17.3 | 1.17.3 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-918 |
| Attack Vector | Network |
| CVSS Score | 7.2 (High) |
| Impact | Server-Side Request Forgery / Info Disclosure |
| Exploit Status | Unweaponized / Proof-of-Concept |
| CISA KEV | Not Listed |
Server-Side Request Forgery (SSRF)