Problem
POST /v2/validate fetches the GTFS ZIP from a caller-supplied url server-side. ValidationService.validateFromUrl validates only that the scheme is http/https — there is no block on private/loopback/link-local ranges or the cloud metadata endpoint (169.254.169.254). On any deployment with public ingress this is a server-side request forgery (SSRF) vector: the service becomes a fetch primitive against the deployment's internal network and instance metadata.
Proposal
- After DNS resolution, reject targets in loopback / private (RFC 1918) / link-local / unique-local ranges and the metadata IP, guarding against DNS-rebinding (re-check the resolved address actually used for the connection), and/or
- A config flag to disable the by-URL endpoint entirely for deployments that only need
validate-upload.
Happy to contribute. Context: surfaced while test-driving #1 for a publicly-reachable deployment that only uses validate-upload.
Problem
POST /v2/validatefetches the GTFS ZIP from a caller-suppliedurlserver-side.ValidationService.validateFromUrlvalidates only that the scheme ishttp/https— there is no block on private/loopback/link-local ranges or the cloud metadata endpoint (169.254.169.254). On any deployment with public ingress this is a server-side request forgery (SSRF) vector: the service becomes a fetch primitive against the deployment's internal network and instance metadata.Proposal
validate-upload.Happy to contribute. Context: surfaced while test-driving #1 for a publicly-reachable deployment that only uses
validate-upload.