I recently performed a vulnerability scan using HostedScan on my application (ecoride-test). The scan reported a high-severity vulnerability indicating that TCP port 0 is open on my server.
My fly.toml configuration does not specify port 0 anywhere—only the standard ports (80 and 443), which internally map to my application’s port 3000.
Why does port 0 appear to be open?
Whether this could be a false positive related to Fly.io infrastructure?
How can I ensure that there is no actual security risk to my application?
What you’re seeing is normal and it does not represent a security risk or misconfiguration. Here’s a detailed explanation.
A common element in vulnerability scans is doing a “port scan” on the destination IP and seeing which services/ports are “open”. Typically these scans will return the alarming but benign finding that “all ports are open on Fly.io servers!”.
From the outside it looks as though Fly.io has all ports open; connections on any port are forwarded to the Fly proxy, which explains why they are initially accepted, which is what a “does this port respond” test is doing. However, the proxy will correctly handle only the ports you declare in your configuration, using the handler you configured (typically https or http but you can also configure raw TCP handling which works like a “pass-through” to your service).
Crucially, the proxy will almost immediately close any connection for which the app owning the destination IP address does not have a configured service. You can test this by using nc or another “connect to port, send data” utility and trying to type some data to send to the service; the connection will close almost immediately, typically after you press ENTER or CTRL-D.
Consequently, the fact that the proxy accepts connections on all TCP ports does not constitute a vulnerability directly, nor does it mean that we’re running the service that’s usually hosted in the port in question (e.g. port 9 is the “discard” service but we do NOT run a “discard” service fleet-wide).