Arcane patches unauthenticated SSRF in template fetch endpoint

TL;DR — Arcane’s unauthenticated /api/templates/fetch can be abused for SSRF, enabling internal network reconnaissance and access to otherwise-unreachable HTTP services (including Kubernetes API) from any publicly reachable instance.

What happened

Arcane is a management interface for Docker containers, images, networks, and volumes. A GitHub security advisory describes an unauthenticated SSRF issue where the /api/templates/fetch endpoint performs a server-side HTTP GET to an attacker-controlled url parameter without authentication and without URL scheme/host validation.

The advisory notes the endpoint’s response behavior gives attackers useful signals for internal enumeration (e.g., whether the target returned JSON, whether the port is closed vs filtered, and whether the target returned a non-200 status).

SSRF in “management plane” software is disproportionately risky because these services often run with broad network reach (internal subnets, cluster control planes), turning a single exposed endpoint into a pivot for discovery and data access.

Who is impacted

• Publicly reachable Arcane deployments running versions marked as affected in the advisory (<= 1.17.2).
• Environments where the Arcane host has network access to sensitive internal HTTP services (service discovery endpoints, internal dashboards, Kubernetes API, and other control-plane/admin surfaces).
• Deployments without strong egress restrictions from the Arcane service/container to internal ranges and metadata endpoints.

What to do now

• Follow vendor remediation guidance and apply a patched release (the advisory lists 1.17.3 as patched).
• Confirm Arcane is not unnecessarily internet-exposed; treat this endpoint as remotely reachable SSRF surface.
• Add/verify network egress controls for the Arcane runtime (deny access to internal CIDRs and sensitive link-local targets where applicable) to reduce SSRF blast radius.
• Review access logs for unexpected requests to /api/templates/fetch and investigate for signs of internal scanning behavior (e.g., rapid iteration over hosts/ports, repeated timeouts/connection-refused patterns).