AUGUST 30, 2026

194 S&P 500 Companies Expose POP3, IMAP, or SMTP Directly to the Internet — 97% Have No Bounty Program

More than a third of the index has a legacy mail protocol reachable from the open internet. 96.9% of those companies have zero HackerOne bounty coverage — a sixth consecutive report finding the same disclosure gap.

194 S&P 500 Companies Expose POP3, IMAP, or SMTP Directly to the Internet — 97% Have No Bounty Program

We checked live port-scan results across the whole index for the three legacy mail protocols that almost never need to face the open internet unencrypted: POP3, IMAP, and SMTP. More than a third of the S&P 500 has at least one host answering. The same disclosure-coverage gap our last five reports found holds again, on infrastructure most security teams assume is locked down by 2026.

NullBlocks Research — August 2026


Our last five reports each found the same shape from a different angle: subdomain-takeover risk, GraphQL introspection, Wayback-archived legacy pages, version-matched critical CVEs, and exposed database/remote-admin ports all concentrate outside the small cluster of companies that already run a bug-bounty program. This report checks a different, older piece of infrastructure: mail.

Methodology, up front

domrecon runs a TCP port scan across every live subdomain it discovers for each company, recording open ports and, where available, a service banner. We flagged the three classic unencrypted/legacy mail ports: POP3 (110), IMAP (143), and SMTP (25). None of these are inherently a vulnerability — plenty of legitimate mail infrastructure listens on them, often behind TLS wrappers, authentication, or IP allowlisting our passive scan can't see. But a host answering plaintext POP3 or IMAP on the open internet is a long-standing, well-understood credential-harvesting and enumeration target, and SMTP misconfiguration (open relay, backscatter, user enumeration via VRFY/EXPN) remains a real class of findings on mature bug-bounty programs today. We are not attempting authentication against any of these — this is a passive port-state observation only, the same free-tier scan any domrecon user gets by entering a domain.

1. 194 of 546 companies (35.5%) have at least one of these ports open

That's more than one in three S&P 500 companies with a legacy mail protocol directly reachable from the public internet, across 7,776 individual open-port findings on live subdomains:

Port Service Companies affected
143 IMAP 145
110 POP3 145
25 SMTP 143

The three protocols track each other almost exactly — POP3 and IMAP are tied at 145 companies each, and SMTP is only two companies behind at 143. That consistency is itself a signal: these aren't three independent findings scattered across different infrastructure, they're overwhelmingly the same mail stack answering on all three legacy ports at once, on the same hosts, for the same companies.

2. It skews toward Information Technology, not away from it

Sector Companies with exposure Share of sector
Information Technology 24 32.9% (24 of 73)
Consumer Discretionary 18 37.5% (18 of 48)
Health Care 17 28.8% (17 of 59)
Utilities 14 45.2% (14 of 31)
Consumer Staples 13 35.1% (13 of 37)
Real Estate 12 38.7% (12 of 31)
Materials 11 42.3% (11 of 26)
Communication Services 8 36.4% (8 of 22)
Energy 6 28.6% (6 of 21)

Unlike our database/admin-port report — where Financials led — mail-port exposure is broadly distributed and actually skews slightly toward sectors you'd assume run tighter infrastructure. Utilities shows the highest per-sector rate at 45.2%, which tracks with a pattern this series keeps surfacing: legacy protocol debt correlates more with organizational size and history than with how security-conscious a sector's brand reputation suggests.

3. The overlap: 188 of 194 companies (96.9%) have zero HackerOne coverage

This is the sixth time we've run this cross-reference against bounty_coverage, and the sixth time it's landed in the same place. Of the 194 companies with at least one exposed legacy mail port, only 6 have any matched HackerOne bounty program. The other 188 — including several of the highest-exposure-volume companies in the dataset — have no HackerOne program at all:

Company Hosts exposed HackerOne coverage
Workday, Inc. 1,023 None
Arthur J. Gallagher & Co. 685 None
Johnson Controls 577 None
American International Group 494 None
McKesson Corporation 358 None
MGM Resorts 334 None
Dominion Energy 306 None
Motorola Solutions 305 None
Southern Company 234 None
Gartner 193 None

The overlap with our exposed-database/admin-port report's top-10 list (Workday, Arthur J. Gallagher, Johnson Controls, AIG, McKesson, MGM Resorts, Dominion Energy, Motorola Solutions, Southern Company all appear on both) is itself worth noting: this isn't six independent samples of which companies happen to be exposed — it's frequently the same under-resourced or acquisition-heavy infrastructure footprint showing up across every technique we check.

To be clear about a real limitation here: an open port is not the same as an exploitable vulnerability. Some of these may be legitimate mail relays behind additional access control, VPN-only in practice despite answering on the public interface, or decommissioned systems that were never fully firewalled off. Raw finding count also reflects how many subdomains share the same exposed backend, not how many independent systems are at risk. This table is a starting point for investigation, not a ranked "worst company" list. What it does establish reliably, a sixth time in six independent exposure classes: real exposure exists broadly, and it does not track with whether a company has a paid disclosure channel.

An honest caveat

This pass only checks HackerOne — Bugcrowd and self-hosted security.txt-only programs aren't in this cross-reference yet, so treat "no H1 coverage" as "no H1 program found," not "no path to responsibly disclose at all." An open mail port also isn't automatic proof of a viable attack path — this is a passive TCP-state observation, not an authentication attempt or exploit. This is a signal for where to look, not a confirmed finding you can report as-is.

What this means if you hunt bug bounties

  1. A plaintext mail port is a starting point, not a payday by itself. Confirm what's actually behind it (STARTTLS support, auth requirements, whether VRFY/EXPN respond, whether it's the real production mail path) before assuming it's reportable anywhere.
  2. Check security.txt and Bugcrowd before writing a company off — this pass is H1-only, same caveat as our last five reports.
  3. Cross-reference against our exposed database/admin-port report — the overlap in affected companies here is not coincidental. Once you've scoped a target with an open database port, checking for legacy mail ports on the same infrastructure is now a worthwhile second look.
  4. This is now a six-for-six pattern across independent exposure classes (subdomain takeover, GraphQL introspection, Wayback legacy pages, version-matched critical CVEs, exposed database/admin ports, and now legacy mail protocols). If you're deciding where to spend hunting time, "companies outside the ~15-name mature-program cluster" is consistently where the S&P 500's real, unaddressed technical risk sits.

Check your own footprint

Everything above came from the same free tool anyone can run right now: domrecon.com — enter a domain, get a plain-English risk grade, open-port inventory, full technology stack, and live subdomain data, including whether we've matched it to a known bug-bounty program. No signup required.

If you want the aggregate, cross-company view instead of one domain at a time — the kind of query that produced this report — that's what we built next: Graph Explorer, continuous scanning of the S&P 500's public attack surface as one interactive graph. See what's in it →


Data as of 2026-08-30, one point-in-time snapshot from our port-scanning pipeline and nightly HackerOne sync — not continuous monitoring. Spot an error, or want the underlying query for a specific company? Reply — we read every message.

NullBlocks Systems — domrecon attack-surface intelligence.