Apr 11, 2026·5 min read·40 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)
CVE-2026-49858 is a vulnerability in API Platform Core's JSON:API and HAL item normalizers where conditionally secured attributes are cached globally in memory. When deployed in long-running PHP execution environments such as FrankenPHP worker mode, Swoole, or RoadRunner, this persistent caching bypasses property-level security constraints, allowing unprivileged users to access sensitive, unauthorized fields cached during privileged requests.
CVE-2026-5078 is a log injection vulnerability in Morgan, the widely deployed Node.js HTTP request logging middleware. The vulnerability arises because the ':remote-user' logging token decodes and outputs basic authentication usernames containing control characters, such as Carriage Return (CR) and Line Feed (LF), without sanitization. An unauthenticated attacker can bypass native HTTP header parsers by Base64-encoding CRLF sequences in the Authorization header. When Morgan logs the request, these control characters force newlines in the log stream, enabling log forging, SIEM evasion, and system activity spoofing.
CVE-2026-48861 is a client-side HTTP request-line CRLF (Carriage Return Line Feed) injection vulnerability in the popular Elixir HTTP client library, Mint. The vulnerability permits HTTP Request Splitting and HTTP Request Smuggling when an application forwards untrusted, attacker-controlled inputs to Mint's HTTP client requests as either the HTTP request method or target. By embedding CRLF characters within these parameters, an attacker can terminate the request line prematurely, inject malicious headers, or pipeline entirely independent requests. These smuggled requests are then processed by upstream or downstream proxy servers as separate HTTP queries on the same TCP connection. While Mint version 1.7.0 introduced target validation to secure the request target, the HTTP request method parameter remained completely unvalidated. This flaw allows attackers to bypass routing filters, access restricted internal APIs, or poison HTTP caches under default configurations.
An Inconsistent Interpretation of HTTP Requests (HTTP Request/Response Smuggling) vulnerability in the Elixir Mint HTTP client allows attacker-controlled HTTP/1 servers to desynchronize response framing on shared connections due to over-lenient parsing of sign-prefixed Content-Length headers.
An allocation of resources without limits or throttling vulnerability in Elixir Mint allows an attacker-controlled HTTP/2 server to exhaust memory in a Mint client. The vulnerability is exploited by sending a HEADERS frame without the END_HEADERS flag followed by an infinite stream of CONTINUATION frames. Because the client lacks limits on the incoming header-block accumulator, the client continuously consumes memory until an out-of-memory crash occurs.
CVE-2026-48596 is an Improper Neutralization of CRLF Sequences in HTTP Headers (HTTP Request/Response Splitting, CWE-113) in the Elixir Tesla HTTP client. The flaw resides in how multipart content-type parameters are joined and serialized, enabling attackers to inject arbitrary headers or split HTTP requests when applications pass untrusted inputs to the parameters of multipart uploads.