176 S&P 500 Companies Have a Live FTP Server on the Public Internet — 97% Have No Bounty Program
FTP is a 1971 protocol that sends credentials and file contents in plaintext. We checked how much of the S&P 500 still runs one facing the open internet, and cross-referenced it against real bug-bounty coverage. One in three companies with an exposed FTP server has zero place to report what a researcher finds there.
NullBlocks Research — August 2026
Our last several reports have each picked one exposure class — subdomain takeover, GraphQL introspection, Wayback-archived legacy pages, version-matched critical CVEs, database/admin ports, expired TLS certs, reverse-WHOIS sister domains, missing HSTS, missing clickjacking defenses — and matched it against bug-bounty coverage. Every time, the same shape holds: real, observable risk concentrates outside the small set of companies that actually run a program. This report adds a tenth data point, and it's arguably the blandest, oldest exposure of the series: plain FTP.
Methodology, up front
domrecon runs a TCP port scan against every live subdomain it discovers for each company and records the service banner where one is offered. We isolated port 21 (FTP) specifically — not because FTP is inherently a vulnerability, but because unencrypted FTP has no confidentiality or integrity guarantee at the protocol level: usernames, passwords, and file contents all travel in cleartext unless the specific server enforces FTPS/TLS wrapping, which most default configurations do not. We did not attempt to authenticate against any of these servers — this is a passive port-and-banner observation only, the same free-tier scan any domrecon user gets by entering a domain.
1. 176 of 546 companies (32.2%) have at least one FTP server reachable from the public internet
That's across 5,368 individual open-port findings on live subdomains — some companies have a single legacy FTP box, others have hundreds of subdomains all answering on port 21:
| Company | FTP hosts found |
|---|---|
| Kroger | 1,855 |
| Workday, Inc. | 493 |
| Arthur J. Gallagher & Co. | 316 |
| American International Group | 235 |
| Johnson Controls | 222 |
| McKesson Corporation | 166 |
| MGM Resorts | 162 |
The banners we collected are a mix of Microsoft FTP Service, vsFTPd, ProFTPD, Pure-FTPd, and at least one enterprise managed-file-transfer product — a real cross-section of what's actually still running, not a single misconfigured template.
2. 170 of those 176 (96.6%) have zero matched HackerOne bounty coverage
Consistent with every prior report in this series: companies with a real, observable network-facing service have almost no formal channel for a researcher who finds something wrong with it to report it. Workday and American International Group — both firmly in this dataset's top 5 by FTP host count — show zero matched HackerOne program coverage in our data.
3. What this does and doesn't mean
To be precise about what we're claiming: an open FTP port is not proof of a breach or an active compromise. Plenty of these are legitimate internal tooling exposed behind IP allowlists we can't observe from outside, or low-value static-file mirrors. What it is proof of: a live, unencrypted protocol with a decades-long history of credential-stuffing and anonymous-login misconfiguration, running on production infrastructure, with no visible channel to report a real finding if one exists. That's the same structural gap every report in this series has found — the coverage problem is broader than any single technique.
Why this matters if you do attack-surface work for a living
If you're a bug-bounty hunter or pentester, "does this company even have a program" is the first filter before you spend an hour anywhere. If you're running a security practice for clients, "what's actually reachable on their subdomains right now, including ports we've stopped thinking about in 2026" is exactly the kind of unglamorous, ongoing question a manual audit misses between engagements. That's the gap NullBlocks/DomRecon is built to keep closing automatically — this report used data already sitting in the platform, not a one-off scan built for a blog post.