Unauthenticated full-read SSRF on ESA Euclid Data Space Portal reaches internal Kubernetes network

Summary

The Euclid Data Space Portal, operated by the European Space Agency, exposes a REST API for managing scientific data collections. One endpoint, POST /api/v1/collections/{acronym}/overview/link, accepted a URL in the request body, fetched it server side, stored the response, and returned the full response body to the caller. The endpoint required no authentication. An anonymous attacker could make the server issue HTTP requests to any destination and read the complete response back.

The server applied no egress restriction beyond rejecting the file scheme. Internal services on loopback and the Kubernetes pod network were reachable and readable from the internet. The internal application backend health endpoint on port 8000 was read in full, and the Kubernetes API server at kubernetes.default.svc was reached over the pod network, confirmed by the cluster CA’s self-signed certificate error.

Root cause

The overview link route fetched the caller-supplied URL with no authentication, no entitlement check, no host or scheme allowlist, and no block on private, loopback, or link-local address ranges. The full response body was both stored on the collection record and returned to the caller.

Impact

Unauthenticated, unfiltered, full-read server side request forgery from an internet-facing ESA data portal into the internal Kubernetes network behind it. An attacker with no account could enumerate and read internal services on the pod network and on loopback, providing a path to internal reconnaissance and to reading services, databases, and management endpoints not intended to be internet-reachable.

Timeline

• 09 Oct 2026 · ReportedSubmitted through the ESA vulnerability disclosure program on Intigriti.
• 12 Oct 2026 · TriagedConfirmed reproducible. Severity assessed at CVSS 7.5 High. Forwarded to ESA.
• 14 Oct 2026 · FixedESA removed the vulnerable endpoint entirely and added authentication to the collection DELETE route. Retest confirmed the fix: the POST returns 404 and the DELETE returns 401.
• 14 Oct 2026 · ResolvedAccepted and closed by the vendor.

Verification

On the patched deployment, the POST to /api/v1/collections/{acronym}/overview/link returns 404 Not Found across multiple collections. The route that performed the server-side fetch has been removed. The unauthenticated DELETE on /overview now returns 401, closing the secondary unauthenticated write.

Credit

Reported by Merrick Hare, Enterprise Hare LLC. The full technical write-up is published at merrickhare.com.

No proof-of-concept code is published. The vendor has remediated the issue.