CVE-2026-40242: 
vulnerability analysis and mitigation

CVE-2026-40242 is an unauthenticated Server-Side Request Forgery (SSRF) vulnerability in Arcane, an open-source interface for managing Docker containers, images, networks, and volumes. The /api/templates/fetch endpoint accepts a caller-supplied url parameter and performs a server-side HTTP GET request to that URL without authentication or URL scheme/host validation, returning the server's response directly to the caller. All versions up to and including 1.17.2 of the Go backend (github.com/getarcaneapp/arcane/backend) are affected; the issue was fixed in version 1.17.3. Disclosed on April 10, 2026, it carries a CVSS v3.1 base score of 7.2 (High) with Scope: Changed, reflecting the potential to reach internal resources beyond the vulnerable component (Github Advisory, Security Advisory).

The root cause is CWE-918 (Server-Side Request Forgery): the /api/templates/fetch endpoint passes a caller-controlled url query parameter directly to an outbound HTTP GET request with no allowlist or denylist of destination hosts or CIDRs, and no authentication requirement. The vulnerability produces four distinct, observable response outcomes that enable blind and semi-blind SSRF: valid JSON responses are fully reflected; non-JSON HTTP 200 responses leak the first byte of the body (e.g., "Invalid JSON response: invalid character '<'..."); non-200 responses leak the HTTP status code; and TCP-level failures differentiate between closed ports ("connection refused") and filtered ports ("i/o timeout"). No special privileges or user interaction are required — any unauthenticated network request to a publicly reachable Arcane instance is sufficient to trigger the vulnerability (Security Advisory, Github Advisory).

An unauthenticated attacker can leverage this vulnerability to perform internal network reconnaissance, including port scanning of internal hosts and service discovery. The conditional response reflection allows attackers to enumerate open/closed/filtered ports and access internal HTTP services not exposed to the public internet, such as Kubernetes API servers, internal dashboards, and cloud metadata endpoints (e.g., http://169.254.169.254). While availability is not directly impacted, confidentiality and integrity are both affected as attackers can retrieve sensitive data from internal systems and interact with services that implicitly trust the Arcane server's IP address (Security Advisory, Github Advisory).

A proof-of-concept exploit is publicly documented in the official security advisory, consisting of a simple unauthenticated GET request to /api/templates/fetch?url=<target> — no exploit kit or specialized tooling is required (Security Advisory). Nuclei templates for automated detection of this vulnerability have been added to the ProjectDiscovery nuclei-templates repository, further lowering the barrier to exploitation. The EPSS score is reported at 0.932% (77th percentile) by the GitHub Advisory Database, indicating a moderate probability of exploitation in the wild. No confirmed in-the-wild exploitation or threat actor attribution has been reported as of the time of this report, and the vulnerability is not listed in the CISA KEV catalog (Github Advisory).

1. Reconnaissance: Identify publicly reachable Arcane instances (versions ≤ 1.17.2) using internet scanning tools such as Shodan or Censys, searching for the Arcane web interface or its API endpoints.
2. Confirm vulnerability: Send an unauthenticated GET request to the target's /api/templates/fetch endpoint with a known external URL to confirm the server makes outbound requests: GET /api/templates/fetch?url=http://<attacker-controlled-server>/ HTTP/1.1
3. Internal network enumeration (port scanning): Iterate over internal IP ranges and ports by supplying internal addresses as the url parameter (e.g., url=http://192.168.1.1:6443/). Differentiate open ports (JSON or first-byte leak), closed ports (connection refused), and filtered ports (i/o timeout) from the response.
4. Access internal services: Target discovered open services such as the Kubernetes API (http://10.0.0.1:6443), cloud metadata endpoints (http://169.254.169.254/latest/meta-data/), or internal dashboards to retrieve sensitive configuration data or credentials.
5. Exfiltrate data: For JSON-returning internal endpoints, the full response body is reflected to the attacker, enabling direct data exfiltration from internal APIs (Security Advisory, Github Advisory).

• Network: Unusual outbound HTTP GET requests originating from the Arcane server process to internal RFC-1918 addresses (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata endpoints (169.254.169.254); outbound connections to attacker-controlled external hosts from the Arcane backend.
• Logs: Arcane application/access logs showing repeated GET requests to /api/templates/fetch with varied url query parameters, especially targeting internal IP ranges or non-standard ports; error messages such as "Invalid JSON response: invalid character '<'...", "connection refused", or "i/o timeout" in application logs indicating port scanning activity.
• Process: Unexpected outbound TCP connections from the Arcane Go backend process to internal network hosts or cloud metadata services not normally accessed during routine operation.

The vulnerability is fixed in Arcane version 1.17.3, which includes the commit "validate and secure remote template registry fetching" (PR #2299). All users running Arcane ≤ 1.17.2 should upgrade to v1.17.3 immediately (Release v1.17.3). As interim mitigations, implement network-level egress filtering to restrict the Arcane server's outbound HTTP access to only necessary and explicitly allowed destinations, blocking access to internal RFC-1918 ranges and cloud metadata endpoints. Additionally, restrict network access to the /api/templates/fetch endpoint via firewall rules or reverse proxy ACLs if the Arcane instance is publicly reachable (Github Advisory).

The vulnerability was reported by security researcher msoneri and published by Arcane maintainer kmendell on April 10, 2026. A Nuclei detection template was contributed to the ProjectDiscovery nuclei-templates repository shortly after disclosure, indicating community interest in automated scanning for this vulnerability. Brief mentions appeared on Bluesky social media accounts tracking CVE disclosures (Github Advisory).