The State of Internet Exposure

Executive Summary

Every organization maintains two attack surfaces. The first is the one it knows about — the assets in its CMDB, the services behind its firewall, the cloud accounts on its bill. The second is the one the entire internet can already see: the forgotten database left listening on a public IP, the AI proxy a team spun up over a weekend, the production host running a version of software that attackers are exploiting this week, the credential committed to a public repository at 2 a.m. The gap between those two surfaces is where breaches happen. This report measures the second surface — the externally observable one — directly, from the same vantage point an adversary uses.

The findings below were collected over a four-to-five-week observation window from 2026-05-29 to 2026-06-28. This is an inaugural baseline, not a multi-year trend; readers should treat the absolute counts as a snapshot of the present state, and the patterns — not the slopes — as the signal. The methodology is deliberately constrained: every observation is passive, drawn from public data, and detect-only. We never authenticate, never exploit, and never read the contents of an exposed system. Findings are aggregated and host-redacted, and confirmed exposures are handled through responsible disclosure to the verifiable owner. The point is not to publish a target list. The point is to establish what is already visible — because if a passive observer can see it, so can a motivated one.

The same dynamic recurs in nearly every major breach of the last decade. Equifax (2017) ran a known-vulnerable, internet-reachable web component for months after a patch existed. Capital One (2019) and the DeepSeek open database (2025) were misconfigurations — an asset reachable from the public internet with access control missing or bypassable, not a novel zero-day. MOVEit (2023) and the OpenSSH regreSSHion flaw (CVE-2024-6387) were widely deployed software whose exposed instances became a mass-exploitation event the moment a working exploit circulated. None of these required the attacker to be inside first. Each began with something the whole internet could already see. This report quantifies how much of that visible surface still exists today.

The thesis: the surface is large, it is reachable, and most of it is unwatched

Across six independent passive radars, we observed exposure at internet scale spanning 137 countries for AI services alone and 161 countries for hosts running known-vulnerable software. The recurring theme is not exotic attack technique — it is the ordinary failure mode of fast-moving engineering: a store left open, a patch not applied, a DNS record not retired, a secret not rotated. These are not edge cases. They are the default state of an unmanaged external surface, and they are observable from outside without privileged access of any kind.

By the numbers

For context on the vulnerability data that underpins the KEV findings, EchelonGraph tracks a corpus of 340,552 CVEs, of which 1,621 appear on the CISA Known Exploited Vulnerabilities catalog, 326 are linked to ransomware, 33,409 are rated CRITICAL, and 7,624 were published in the last 30 days alone. Exposure is not a static problem against a fixed list of flaws; the list itself grows by thousands of entries a month.

The eight findings to act on this quarter

The remainder of this report develops each radar in depth. For an executive audience, the actionable signal reduces to eight findings. Each is stated with its headline number and the question it should prompt on your own surface.

1. Your AI build-out has created a public footprint of 82,416 services — and you almost certainly cannot enumerate it

We discovered 82,416 AI-related services across 137 countries: AI-workflow platforms, LLM proxies, model stores, notebooks, MCP servers, and vector databases. The honest reading of that number matters, because most of it is not dangerous on its own. The discovered footprint breaks down as follows.

The 2,050 confirmed-active, open services are the ones that matter: 1,743 open LLM proxies, 171 live vector databases, 2 MCP servers, and 81 AI-workflow instances, reachable on the public internet with no authentication in the way. An open LLM proxy is an uncapped bill and a data-exfiltration channel; an unauthenticated vector database is a verbatim copy of whatever proprietary corpus was embedded into it. This is the DeepSeek class of problem — an AI asset stood up in a hurry and left open — observed at scale. The so-what for a CISO: the authenticated 36,991 are evidence that your teams are deploying AI faster than security can inventory it, and the 2,050 are proof that some of those deployments are already open. The discovery is feasible from outside; the question is whether you find your share first. Note carefully that the authenticated and DNS-only sets are not exposed and must never be characterized as such.

2,050 AI services were confirmed active and open on the public internet — 1,743 of them LLM proxies — out of an 82,416-service footprint spanning 137 countries.

2. 21,299 hosts are exposed to vulnerabilities attackers are exploiting right now

We identified 36,416 hosts running software with known CVEs — 165,717 distinct host-to-CVE pairings across 6,519 organizations and 161 countries. The subset that should drive remediation priority is the 21,299 hosts exposed to vulnerabilities on the CISA KEV catalog (50 distinct KEV CVEs): not "you have a vulnerability," but "you are running, on a publicly reachable host, the specific flaw that is under active exploitation." A further 3,475 hosts carry ransomware-linked CVEs, and 36,365 carry high-EPSS (high exploit-probability) vulnerabilities. The exposed software population is dominated by the internet's load-bearing infrastructure.

The so-what: regreSSHion (CVE-2024-6387) appears on 5,713 exposed hosts, and the Citrix NetScaler family — the lineage behind the "Citrix Bleed" exploitation wave — is present on 1,709. These are precisely the products that turn into mass-compromise events when an exploit circulates, which is the pattern Equifax, MOVEit, and the regreSSHion disclosure each followed. Across the population, host severity tallies 24,292 CRITICAL, 26,482 HIGH, and 19,329 MEDIUM. Patch prioritization keyed to KEV and EPSS — not raw CVSS — is the single highest-leverage action a security team can take against this surface. Full host-redacted detail is available at the KEV exposure radar.

3. 6,607 databases are open to the internet with no authentication at all

We confirmed 6,607 open, unauthenticated databases across 1,723 organizations and 120 countries. A critical framing applies here, and it is non-negotiable: our classification is conservative. We detect that the store is open via a single read-only probe; we do not read its contents. We therefore make no claim about the volume of data inside — there is no "millions of records" assertion in this report, because we never looked. Only 3 stores were conservatively classified as holding PII and 1 as in PCI scope on the basis of externally visible metadata alone; the true figure is unknowable without doing the thing an attacker would do, which we will not do. The exposure is concentrated in caching and search engines that ship insecure-by-default.

The so-what: an open Redis or Memcached instance is not merely a data-leak risk — it is a foothold, frequently writable, and a recurring initial-access vector in commodity intrusions. The DeepSeek disclosure (2025) was a single open database that made global news; this radar found 6,607 doors of the same kind, standing open today. Detail at the exposed databases radar.

4. ~2,600 AWS credentials are being served by the applications meant to protect them

We found 750 hosts serving secrets directly to the public internet — applications handing out the very configuration they were never meant to expose. The dominant exposure vector is the environment file: 2,571 served .env files, alongside 80 exposed Git configs, 61 exposed Git directories, 17 credential files, 3 database dumps, and 2 private keys. The credential material recovered from those served files is overwhelmingly cloud keys: 1,319 AWS secret keys and 1,284 AWS access-key IDs — on the order of 2,600 AWS credentials — plus 2 GitHub tokens and a PEM key. Severity rows tally 1,386 critical and 1,304 high. As with every radar, we detect that the file is being served; we never read or test a key, because using it would be the attack.

The so-what: a leaked AWS key is not a future risk, it is a present one — automated harvesters scrape .env endpoints continuously, and a live key can be abused within minutes of exposure. Capital One (2019) demonstrated what a single mis-scoped cloud credential can unlock. Every served .env on this list is a standing invitation. Detail at the exposed AI keys radar.

5. 619 live secrets are sitting in 478 public Git repositories

Separately from web-served secrets, we identified 619 secrets across 478 public Git repositories. The provider breakdown — 249 generic, 228 Google, 63 AWS, 53 Telegram, 13 Discord, 2 OpenAI, 2 HuggingFace — shows that credential leakage now spans far beyond cloud IAM into bot tokens, messaging platforms, and, increasingly, AI-service keys. Severity tallies 301 high, 273 medium, and 45 critical. The so-what: source control is a primary exfiltration surface, and a committed secret is exposed from the moment of git push — rotation, not deletion, is the only effective response, because the history persists. Detail at the leaked credentials radar.

6. 134 confirmed subdomain takeovers let an attacker speak as your brand

We observed 7,952 dangling DNS records and confirmed 134 as vulnerable to subdomain takeover — a forgotten CNAME pointing at a deprovisioned SaaS endpoint that an attacker can re-claim and serve content from. The exposure clusters on the platforms teams adopt and abandon fastest: Shopify (4,869 observed dangling records), GitHub Pages (1,563), Heroku (773), SmugMug (331), and Fastly (170). The so-what: a hijacked subdomain inherits your domain's trust — it is a turnkey phishing, cookie-theft, and brand-impersonation platform under yourcompany.com. The 134 confirmed cases are the ones where the takeover is demonstrably claimable; the gap between 7,952 observed and 134 confirmed reflects deliberately conservative validation, not a lack of risk in the remainder. Detail at the subdomain takeover radar.

7. The vulnerability backlog grows faster than any patch cadence — by 7,624 new CVEs in 30 days

The KEV findings sit on top of a structural problem: the supply of vulnerabilities is accelerating. The EchelonGraph corpus holds 340,552 CVEs, including 33,409 CRITICAL and 103,468 HIGH, with 7,624 new entries in the last 30 days and 5,190 AI-related CVEs. Of the total, 1,621 are CISA-KEV and 326 are ransomware-linked. The so-what: a remediation program scoped to "patch the criticals" is mathematically losing, because criticals arrive in the tens of thousands. The defensible posture is exposure-led prioritization — fix what is reachable, exploited, and yours, in that order — which is exactly what radars 2 through 6 enable. The full enrichment (CVSS v3/v4, EPSS, KEV tiering, SSVC, ransomware and AI flags) is available at EchelonGraph Pulse.

8. Almost none of this surface is being watched on the owner's behalf

The unifying finding is the one that does not reduce to a single radar. Every exposure above was discoverable passively, from public data, by an outside observer with no special access. In each historical breach we cited, a researcher or an attacker found the open door before the owner did — the only variable was who got there first, and what they did next. The so-what for the board: the external attack surface is already enumerated by adversaries continuously; the asymmetry is that most organizations are not enumerating their own. Closing that asymmetry — knowing what the internet can see about you, before it is used against you — is the single strategic posture this report argues for. Organizations can begin with a self-directed check of their own surface at the surface scanner, map blast radius at the attack graph, and tie exposure to obligations at the compliance view.

How to read the rest of this report

The chapters that follow take each radar in turn: methodology, the full data, what it means, who it hits hardest, and the parallels to incidents the reader will recognize. Two cautions carry throughout. First, this is a baseline — a four-to-five-week first measurement, not a trend line; we report what is, and resist over-reading direction from a single window. Second, every figure in this report is an observed, passively collected, detect-only count, handled with host redaction and responsible disclosure. We measure the open door. We do not walk through it.

Methodology & How We Found This

Every figure in this report was produced the same way: by looking at data that is already public, from the outside, without ever logging in, sending an exploit, or touching a single record. That constraint is not a limitation we apologize for — it is the entire point. An attacker probing your perimeter sees exactly what we see. The difference is that we tell you, and we tell only you, before someone less friendly arrives at the same open door. This chapter documents precisely how each of the seven radars works, what our liveness and confidence labels actually mean, how we decide whether a finding belongs to a named company, and — just as importantly — what these numbers are not. Read this chapter before you read any number in the rest of the report. The numbers are only as trustworthy as the method that produced them, and we would rather you understand the method than over-trust the number.

The stance: passive, public-data, detect-only

The most important fact about this report is the smallest: we never authenticated to anything, we never wrote anything, we never validated a found credential by using it, and we never claimed a dangling resource. Each of those actions would, under the Computer Fraud and Abuse Act and its international analogues, constitute unauthorized access — and each would also make our findings legally and ethically unusable. So we built the constraint into the architecture rather than the policy. Our radars consume four classes of strictly public data:

• Certificate Transparency logs — the append-only public ledgers every certificate authority is required to write to. When an organization provisions TLS for llm.internal-tool.example.com, that hostname becomes a permanent public record, whether or not the service behind it was ever meant to face the internet.
• Internet-wide scan banners (Shodan) — the service fingerprints, software names, and version strings that hosts volunteer to anyone who connects to an open port.
• Public DNS — forward, reverse, and CNAME records that anyone can resolve.
• Public source-code commits (GitHub / GH‑Archive) — the diffs of every commit pushed to a public repository.

Where a finding required a confirmation step beyond passive data — for example, distinguishing a genuinely open database from one that merely looks open behind a client-side login — we permitted ourselves exactly one action: a single anonymous, read-only HTTP GET, the same request a browser makes when it loads a page. Nothing more. We confirm that the door is open. We do not walk through it. Every outbound probe also identifies itself (see Identified scanning below), so any administrator who sees us in their logs can confirm it was us and reach us to ask us to stop.

Detect-only, end to end. Zero authentications. Zero exploit attempts. Zero records read. Where confirmation was needed, the strongest action we took was one anonymous read-only GET.

The observation window: a baseline, not a trend

This is our inaugural report, and honesty about its time horizon matters more than the impressiveness of any single figure. All findings were collected between 29 May 2026 and 28 June 2026 — roughly four to five weeks. That makes this a baseline, not a multi-year trend line. We deliberately do not draw growth curves, year-over-year deltas, or directional claims from this window; we have no prior year to compare against. Where a per-month split appears — for example, the AI attack-surface count rising from 10,679 discovered footprints in May to 71,737 in June — that jump reflects our scanner fleet ramping its coverage of the public internet, not a real-world surge in exposure over those weeks. We flag it as such wherever it appears, and you should read it that way. Future editions, with multiple baselines behind them, will support trend analysis. This one establishes the starting line.

Radar 1 — AI Attack Surface (Certificate Transparency + Shodan)

So what: the AI build-out is creating internet-facing services faster than security teams can inventory them, and Certificate Transparency makes every one of them publicly discoverable the moment it gets a certificate. This radar tails CT logs and Shodan for the signatures of AI infrastructure — LLM proxies, vector databases, Jupyter notebooks, model stores, MCP servers, and AI-workflow tools (Flowise, Langflow, and the rest of the zoo) — using a large, maintained library of hostname patterns and Shodan service dorks. Across the window we discovered 82,416 AI-related footprints spanning 137 countries. See the live Shadow AI Radar.

The discipline that makes that 82,416 number defensible is what we do after discovery. A certificate or a banner only proves a hostname exists — not that anything is listening, and certainly not that it is open. So every discovered footprint is run through a liveness verifier that performs DNS resolution plus a lightweight, category-aware HTTPS probe (for a notebook, /api/kernels; for an Ollama-class proxy, /api/tags; for a Flowise-class workflow tool, /api/config). The verifier is conservative by construction: any sign of an authentication gate — a 401 or 403, a redirect to a login page, login-form markers in the body — or any inconclusive result is treated as authenticated, never as open. We only ever label a host active when we positively confirmed there was no gate in front of it. This collapses the single largest class of false positive in surface scanning and is the reason the headline number and the "active" number differ by more than an order of magnitude.

What "discovered," "authenticated," "resolved," and "confirmed active" actually mean

So what: this is the most consequential paragraph in the report, because the difference between these labels is the difference between a real exposure and a non-event — and conflating them is how vendors manufacture scary headlines. We do not conflate them. Of the 82,416 AI footprints we discovered, here is the exact breakdown:

The 2,050 confirmed-active set decomposes into 1,743 open LLM proxies, 171 live vector databases, 2 MCP servers, and 81 AI-workflow tools. When this report says "exposed AI services," it means those 2,050 — not the 82,416 we discovered, and emphatically not the 36,991 that are doing exactly what they should by requiring a login. We state this plainly because the temptation in this industry is to report the discovery count as the exposure count. We consider that dishonest, and we do not do it.

82,416 discovered ≠ 82,416 exposed. Only 2,050 were confirmed anonymously reachable with no authentication. The other 80,366 either enforce a login, resolve to nothing, or are dead hostnames.

Radar 2 — KEV Exposure (banner fingerprinting × CVE correlation)

So what: "you have a vulnerability" is noise; "you are running, on the public internet, the exact software version that attackers are exploiting this week" is a fire alarm. This radar produces the second statement, not the first. We take Shodan's view of what software a host is running — product and version, parsed from the service banner — and correlate it against our CVE corpus by product and version match. We then keep a finding only if it is either CISA‑KEV-listed (confirmed exploited in the wild) or carries a high EPSS exploit-probability score. A plain CVE with no exploitation signal is discarded; the radar's entire purpose is to surface what is reachable and under active attack. See KEV Exposure.

Across the window this surfaced 36,416 hosts running software with known CVEs — 165,717 distinct host-to-CVE pairs across 6,519 organizations and 161 countries. Of those hosts, 21,299 are exposed to a vulnerability on CISA's actively-exploited KEV catalog, mapping to 50 distinct KEV CVEs; 3,475 run software tied to ransomware campaigns. The honest framing is the one we used in the previous sentence: 36,416 hosts run software with known CVEs, and 21,299 of them are exposed to actively-exploited ones. We keep those two populations distinct because they carry very different urgency. The top exposed software by host count — OpenSSH (12,889), Apache Tomcat (5,219), Apache httpd (3,491), MongoDB (3,230), VMware ESXi (2,816) — and the top CVEs, led by the Terrapin SSH attack (CVE‑2023‑48795, 9,942 hosts) and regreSSHion (CVE‑2024‑6387, 5,713 hosts), are analyzed in the KEV chapter. One caveat travels with all banner-based correlation: a version string can be stale or back-patched, so a banner match is strong evidence of exposure but not proof a host is unpatched. We surface the correlation; we do not assert exploitation has occurred.

Radar 3 — Exposed Data Stores (banner + a single read-only verifier probe)

So what: an unauthenticated database on the public internet is the DeepSeek-class failure — a production datastore left open on the internet with no password, readable by anyone who found it. We hunt that class at scale. The challenge is that a banner alone cannot always tell an open store from a secured one: modern web-fronted engines (Kibana, Elasticsearch) render their login screens client-side, so a password-walled instance emits the same banner as an open one. So for HTTP-fronted engines we send one anonymous, read-only GET to an authentication-gated endpoint — one that returns 401 or a login redirect when the instance is secured — and report the host only if it answers with open, data-serving content. We deliberately avoid endpoints that stay public even on secured instances (Kibana's /api/status, CouchDB's welcome page) precisely because they would generate false positives. Raw-protocol engines (Redis, MongoDB, Memcached, Cassandra) are not probed at all; their banner already encodes auth state (Redis announces NOAUTH), and we never speak their wire protocol. See Exposed Databases.

This surfaced 6,607 open, unauthenticated databases across 1,723 organizations and 120 countries, led by Redis (4,243 hosts) and Memcached (1,756). The single most important sentence in this entire report follows, and it governs how every data-store number must be read:

We detect that the store is open. We never read its contents. Our classification is conservative — of 6,607 open stores, we flagged only 3 as likely holding PII and 1 as likely PCI, from metadata alone. We make no claim about how many records any store holds.

You will not find the phrase "millions of records exposed" anywhere in this report, because we did not read a single record and we cannot honestly count what we did not read. The PII and PCI classifications are conservative inferences from structural metadata — field and index names visible without authentication — not from data we extracted. When in doubt, we did not classify. This is the opposite of the prevailing breach-report style, and it is deliberate.

Radar 4 — Secret Sprawl on the web (path probing + redacting regex)

So what: in the rush to ship, applications routinely serve their own configuration straight to the internet — a .env file, a .git directory, a credential file sitting at a public URL with no authentication — and those files frequently contain cloud keys in plaintext. This radar checks public hosts for those well-known exposure paths and, when one is being served, runs the body through a redacting secret detector. We confirmed that the file is being served; we never read, tested, or used a single key. Doing so would be the attack. Across the window this surfaced 750 hosts, dominated by exposed environment files (2,571 instances), and within those bodies roughly 2,600 AWS credentials (1,319 secret keys and 1,284 access-key IDs). See Exposed AI Keys.

Radar 5 — Leaked Credentials in public Git (commit diffs + a six-stage validator)

So what: credentials committed to public repositories are a top root-cause of breaches, but the naive approach — regex-matching commit text — produces so many false positives (documentation examples, placeholder values) that the output is unusable. We engineered for precision over recall: we would rather miss a real credential than show you a fake one. A regex match is only the first of six gates a candidate must clear before it is ever stored or shown:

1. Diff-awareness — only newly added (+) lines can introduce a secret; removed, context, and hunk-header lines are ignored.
2. Known-example rejection — famous documentation and test credentials are dropped.
3. Placeholder rejection — templated values, env-references, and your-key-here strings are dropped.
4. Structural verification — provider checksums and decoders that prove a value is well-formed (GitHub token CRC32, JWT base64+JSON decode, AWS base32). "Verified" here means structurally verified by shape — never confirmed live, because confirming a key live would require using it.
5. Example-context rejection — for unverified values, a test/docs/example file path drops the hit (the classic "token pasted as a code sample" false positive).
6. Entropy and shape — unverified token values must clear a Shannon-entropy floor and character-diversity check, with no long repeats or monotonic sequences.

Only candidates that survive all six are surfaced — and even then the raw secret is never stored; we persist a redacted form and a fingerprint. This yielded 619 secrets across 478 repositories, spanning generic (249), Google (228), AWS (63), and other providers. Because "verified" means structurally verified by checksum and never confirmed by use, no number in this radar should be read as "619 live, working keys" — it is "619 strings that are shaped like real credentials and survived a six-stage anti-false-positive gauntlet." See Leaked Credentials.

Radar 6 — Subdomain Takeover (dangling-CNAME fingerprinting)

So what: when a subdomain's CNAME still points at a third-party service whose underlying resource has been deprovisioned — a cancelled SaaS, a deleted bucket — an attacker can register that resource and serve their own content from your subdomain, enabling phishing, cookie theft, and OAuth abuse. We detect these the way the established tooling (subjack, nuclei) does: a subdomain whose CNAME delegates to a known service and whose single anonymous read-only GET returns that service's "unclaimed" fingerprint is takeover-able. We never register or claim the dangling resource — that would be exploitation; we store only the matched fingerprint as evidence.

The gap between observation and confirmation here is enormous and instructive: we observed 7,952 subdomains delegating to takeover-prone services, but confirmed only 134 as actually vulnerable. The other 7,818 mostly resolve to live, properly-claimed services — a CNAME to a known provider is not a finding unless the resource behind it is genuinely unclaimed. We report the 134, not the 7,952, as the exposure. Two guardrails suppress the most common false positives: a domain the owner has provably verified with the provider cannot be claimed by anyone else (downgraded), and a wildcard delegation where unrelated subdomains share the same target is an intentional configuration, not a forgotten record (downgraded). See Subdomain Takeover.

The CVE corpus behind the correlation

So what: the KEV-exposure radar is only as good as the vulnerability intelligence it correlates against, so the corpus deserves its own accounting. It comprises 340,552 CVEs, of which 1,621 are CISA‑KEV-listed, 326 are ransomware-associated KEV entries, 33,409 are rated CRITICAL, and 5,190 are AI-related. Each CVE is enriched per-record with CVSS v3 and v4, FIRST EPSS exploit-probability, CISA‑KEV status with our own tiering, SSVC decision points, GitHub Security Advisory data, ransomware and AI-relatedness flags, and a synthesized EchelonGraph score. The full scoring methodology — including where we diverge from NVD and where we deliberately do not claim superiority — is documented separately; here it is enough to know that the KEV correlation rides on this enriched, continuously-refreshed corpus rather than a static feed. See CVE Pulse.

Attribution: forward-confirmed reverse DNS, and rare by design

So what: the most dangerous thing a report like this can do is attribute an exposure to the wrong company — both because it is wrong, and because telling Company A about Company B's open database leaks B's exposure to A. So we attribute conservatively, on provable ownership only, and we leave the unattributable in an aggregate bucket rather than guess. There are two cases:

• Host-based findings (an exposed config file, a takeover, a spoofable domain): we attribute only when the host is the company's registrable domain or a subdomain of it — because only the domain owner can create records under *.their-domain.
• IP-based findings (KEV hits, exposed databases): we require forward-confirmed reverse DNS (FCrDNS). The IP's reverse-DNS hostname must resolve forward back to that same IP and sit under the company's domain. Reverse DNS alone is forgeable; the matching forward record is not. A lookup that times out is treated as "not confirmed" — we exclude rather than guess.

Anything that fails this bar — an organization-name match alone, a PaaS-hosted application whose individual tenant we cannot identify, an IP that does not forward-confirm — is never attributed to a named company and never contacted. The cost of a false attribution is far higher than the cost of missing a true one. As a direct consequence, confident company-level attribution is rare: the figures in this report are aggregate and host-redacted, and the small subset where we can prove ownership is what feeds responsible disclosure, not publication.

Identified scanning and responsible disclosure

So what: anonymous internet-wide scanning is indistinguishable from reconnaissance for an attack, which is why we made ours the opposite of anonymous. Every outbound probe carries a self-describing User-Agent naming EchelonGraph and linking to our responsible-disclosure page, plus an RFC 7231 From header with a monitored contact address. Direct host probes additionally carry a one-off signed receipt — an HMAC-SHA256 token over the IP, port, radar, and timestamp — that any administrator can paste into a public verifier to confirm a request genuinely came from us (and, by the same token, identify impostors who merely put our name in their User-Agent). Where we can prove ownership, the platform renders a disclosure draft — the verified exposures and their specific fixes — that a human sends from their own mailbox. We never auto-send, never include a raw secret in the body, and never lead with a sales pitch. The unattributable majority is reported only in aggregate, as it appears throughout this document.

What this report is not

We close the methodology with its boundaries, stated as plainly as we can, because a finding misunderstood is worse than a finding never made:

• This is not a penetration test. It is a record of what is observable from public data, from the outside, without authentication or exploitation. We confirmed open doors; we did not enter any building.
• Absence of a finding is not proof of safety. If your organization does not appear in our data, it means we did not observe a qualifying exposure in this window through these sources — not that you have none. We see what Certificate Transparency, Shodan, public DNS, and public Git reveal, on the cadence we scan them, nothing more.
• This is a four-to-five-week baseline, not a trend. No directional or year-over-year claim is supported; month-over-month movement reflects scanner ramp, not real-world change.
• "Discovered" is not "exposed," "known-CVE" is not "actively-exploited," and "structurally verified" is not "confirmed live." Each distinction is preserved in every figure, and the smaller, more defensible number is always the one we headline.
• We never read data, so we never count records. Any claim about the contents or record-count of an exposed store would be fabrication; we make none.
• Attribution is provable or absent. Aggregate figures are exactly that; company-level claims exist only where ownership is DNS-provable.

The historical incidents this report references — the Equifax breach, the Capital One exposure, the DeepSeek open database, the MOVEit and regreSSHion campaigns — share a single property: in each, the failing surface was reachable and observable before it was abused. Someone could have looked on the victim's behalf and did not. That is the gap this methodology exists to close: a passive, identified, responsibly-disclosed view of the open doors anyone on the internet can already see, delivered to the people who can close them. Test your own surface at our self-check.

The AI Attack Surface

The most important number in this chapter is the one we did not report. Across the observation window we discovered 82,416 internet-facing AI services in 137 countries. We could have published that figure as "82,416 exposed AI systems" and it would have travelled. It would also have been wrong. The honest finding is smaller, harder-won, and far more useful to a security leader: of those 82,416, the overwhelming majority are either secured behind authentication or are nothing more than a DNS record. The genuinely dangerous set — services we confirmed to be live, reachable, and answering without credentials — numbers 2,050. That distinction is the entire point of this chapter, and we ask you to carry it into every conversation that follows.

82,416 AI services discovered. 2,050 confirmed active and open. The gap between those two numbers is where most "AI exposure" reporting goes wrong.

What we counted, and what we refused to count

"Shadow AI" has become a boardroom phrase without a boardroom-grade definition. We use it narrowly: AI infrastructure that an organization is running on the public internet, often outside the visibility of its own security team — model-serving proxies, vector databases, notebooks, model registries, agent frameworks, and the emerging class of Model Context Protocol (MCP) servers that broker tool access to large language models. We find these passively, from Certificate Transparency logs and public internet scan data. We never authenticate, never log in, and never send a prompt. We observe that a service exists, we classify what it is, and — where it is determinable without interaction — we record whether it answered us without asking for a credential.

That last step is where discipline matters. A hostname appearing in a Certificate Transparency log proves only that someone requested a TLS certificate for it. It does not prove the service is running, reachable, or unprotected. Treating certificate evidence as exposure evidence is the single most common error in this category, and it inflates headline numbers by an order of magnitude. We therefore resolve every discovered footprint into one of four liveness states, and we report all four.

We dwell on the 36,991 authenticated services deliberately, because they are the part of the story that resists a clean headline. These are organizations running AI infrastructure on the public internet and gating it correctly. That an LLM proxy is internet-reachable is not, by itself, a finding; reachable-and-authenticated is the normal, defensible posture for a great deal of production AI. Conflating the 36,991 with the 2,050 would be the same mistake in the opposite direction — manufacturing alarm out of systems that are behaving exactly as they should. The number that should occupy a CISO's attention is 2,050.

The shape of the footprint: where AI is sprawling

Before narrowing to the active set, it is worth understanding the composition of everything we discovered, because it maps the directions in which AI infrastructure is proliferating fastest. The 82,416 services break down by category as follows.

The dominance of AI-workflow and orchestration platforms is the structural signal here. The fastest-growing slice of the AI attack surface is not the model itself but the connective tissue around it — the agent frameworks, proxies, and protocol servers that wire models to tools and data. These are typically deployed by application teams rather than platform or security teams, they ship with permissive defaults, and they accumulate access. That is precisely the profile of infrastructure that drifts out of a security organization's line of sight.

The real risk: 1,743 open LLM proxies and 171 live vector databases

Within the 2,050 active and open services, two categories carry disproportionate consequence. We confirmed 1,743 open LLM proxies and 171 live vector databases answering on the public internet with no authentication, alongside a small number of open MCP and AI-workflow endpoints. These are not parked names or polite 401 responses. They are running services that returned data to an unauthenticated request.

1,743 open LLM proxies and 171 live, unauthenticated vector databases — answering anyone on the internet, no credential required.

An open LLM proxy is, in practical terms, someone else's inference budget and someone else's model — handed to the entire internet. The immediate harm is the obvious one: unmetered consumption of a paid model, billed to the operator. The more serious harms are second-order. A proxy is a position of trust between an application and a model; depending on configuration it may expose system prompts, leak the contents of prior conversations held in context, accept prompt-injection that redirects the model's behaviour, or — where the proxy fronts tool-calling — become a pivot into whatever the model is permitted to do. An unauthenticated proxy is not merely a billing leak; it is an open door into an application's reasoning layer.

A live, unauthenticated vector database is the more acute exposure of the two, and it is the one we want security leaders to internalize. A vector store is the memory of a retrieval-augmented application. Organizations populate it by embedding their private corpora — support tickets, internal wikis, contracts, source code, customer records — into vectors so a model can retrieve them. Crucially, those stores frequently retain the original text alongside the vector, as metadata, so the application can show a human the source passage. An open vector database, therefore, is not an abstract index of numbers. It is, very often, a queryable copy of the exact private documents an organization fed into its AI — sitting on the internet without a password.

Why AI infrastructure is uniquely dangerous

A traditional exposed database is a serious problem; an exposed AI service can be a worse one, for a reason that is specific to how these systems are used. AI infrastructure concentrates raw, unstructured, high-sensitivity data at the exact moment it is least protected.

• The payloads are raw and unredacted. Conventional applications pass structured, minimized fields between tiers. AI systems pass whole documents, full conversations, and complete records — because the model needs context to be useful. The data crossing an LLM proxy or sitting in a vector store has typically not been through the redaction and minimization that a normal data tier would apply. Personally identifiable information arrives intact, inside the payload, as a matter of course.
• Retrieval stores hold copies, not references. A vector database does not point at the system of record; it ingests a duplicate. Every access control, retention policy, and audit boundary that governs the source system has to be re-implemented on the copy — and when the copy is stood up by an application team in a hurry, it usually is not.
• The tooling is young and ships open by default. Much of this software is pre-1.0. Authentication is frequently opt-in rather than mandatory, default credentials are common, and the developer-convenience defaults that make a tool easy to try are the same defaults that make it dangerous to expose. The 36,991 authenticated services prove the secure path exists; the 2,050 open ones show how easy it is to skip.
• Agentic services hold access, not just data. An MCP server or an agent framework is provisioned with credentials and tool access so the model can act. Exposing one does not merely leak information; it can hand an attacker the model's permissions — to read files, call internal APIs, or reach systems the model was trusted to reach.

The combination is what makes the category distinctive. An exposed AI service tends to leak the most sensitive data in the most usable form, from infrastructure the security team did not know was there.

The parallel: DeepSeek's open database, 2025

This is not a hypothetical. In early 2025, security researchers reported that an internet-facing database belonging to the AI company DeepSeek was publicly accessible without authentication, and that it exposed operational data associated with the service. The episode became a reference point for AI-era exposure for a simple reason: a frontier-scale AI provider, under intense growth pressure, left a backing store open to the internet — the same failure mode that has produced data exposures for two decades, now sitting directly behind an AI product.

We invoke the DeepSeek incident as a pattern, not to restate its particulars, because the pattern is exactly what our data describes at scale. The 171 open vector databases and 1,743 open LLM proxies we confirmed are 1,914 instances of the same class of mistake — an AI backing service reachable without a credential — distributed across the internet, most of them at organizations that have no idea the door is open. DeepSeek made headlines because of the name attached to it. The thousand-plus equivalents in this dataset are anonymous only because no researcher has knocked yet.

The deeper continuity is with the pre-AI canon of exposure incidents. The mechanics that produced the 2017 Equifax breach and the 2019 Capital One breach — an unpatched edge, an over-permissioned path to data, a store reachable from where it should not have been — have not changed. What has changed is the content behind the open door. Where an exposed store once leaked structured database rows, an exposed vector store leaks the raw documents an organization trusted to its AI, and an open proxy leaks the live reasoning of the application itself. AI did not invent the failure; it raised the value of the loot.

Reading the trajectory honestly

We discovered 10,679 of these services in May and 71,737 in June. That is not a measurement of the internet's AI footprint growing sixfold in a month. The jump is overwhelmingly the result of our own discovery capacity ramping during this inaugural window — more Certificate Transparency patterns, more scan coverage, more categories under watch. We surface the monthly split for transparency, and we caution explicitly against reading it as a growth rate. This is a baseline, established over roughly five weeks. Its value is as a fixed point to measure against in future editions, not as a trend in itself.

What the baseline does establish, firmly, is the shape of the problem. AI infrastructure is now a first-class category of internet exposure, distributed across 137 countries, dominated by orchestration and proxy layers that live outside traditional security visibility. Most of it is either inert or correctly secured. A meaningful, concrete minority — 2,050 services, with 1,743 open proxies and 171 open vector databases at its core — is live, unauthenticated, and holding exactly the kind of data and access that makes AI systems worth attacking.