Exposed by Design: a live audit of 414 internet-facing MCP servers found 68 vulnerabilities

On 31 July 2026 Nicolás Padilla published Exposed by Design (arXiv:2608.00150), a 13-page preprint describing what he calls the first dynamic behavioural security assessment of internet-facing Model Context Protocol servers. Four measurement runs that month confirmed 640 live production servers, of which 414 were actively tested; the testing produced 68 reportable vulnerabilities, all filed with maintainers as GitHub Security Advisories. 380 of the 414 — 91.8% — had no OAuth authentication, and 687 tool instances advertised shell execution without access controls. Padilla reports no evidence that any of it was being exploited: testing stayed at proof of concept, no credentials were obtained and no data was exfiltrated. The record's full source list, severity grade and confidence assessment sit in the AI incident archive, alongside the other MCP and infrastructure findings filed around it.

What the audit actually did

The Model Context Protocol is the interface that lets an AI agent call tools hosted somewhere else — a document search, a database query, a shell helper. A server that speaks it over HTTP and is reachable from the internet is, in effect, a tool surface that anyone can address. Padilla's paper argues that the population of such servers has never been counted properly, and that counting them is the point: discovery is the hard part, and every earlier survey looked at a different slice.

His discovery stage merged eleven sources — crt.sh, Hugging Face, GitHub, npm, Smithery, PyPI, Censys, FOFA, Shodan, glama.ai and pulsemcp.com — on the argument that no single one of them captures the population. The active stage used Corvus, a framework Padilla built for the study: 34 test modules covering 10 MCP-specific vulnerability classes, split 13 static and 21 dynamic. It is published on GitHub under the CobaltoSec organisation and on PyPI as cobaltosec-corvus, and the repository's own statistics file records the same 34-module count.

The four runs took place on 15, 18, 21 and 24 July 2026. Earlier runs contributed confirmation numbers only; the last three scanned 3,485, 3,948 and 4,110 candidates and confirmed 140, 464 and 296 live servers respectively. Deduplicating 972 raw observations with 332 repeat appearances left 640 unique confirmed servers, of which 414 — 64.7% — accepted full dynamic testing. Padilla treats 640 as a lower bound. Censys, one of the discovery sources, had estimated more than 21,000 MCP-related endpoints worldwide in May 2026, and he uses that as the scale estimate rather than as a count of what he tested.

Read as a funnel, the numbers are the paper's real argument: a wide, cheap pass finds candidates faster than a careful pass can test them. Only 414 of the 640 confirmed servers were fully exercised, and Padilla does not claim that the tested subset resembles the untested remainder.

What it found

The headline finding is authentication, or the absence of it. Of the 414 servers tested, 380 (91.8%) had no OAuth. The paper says most of the remainder used static bearer tokens or API keys, often predictable or empty — a server that accepts a fixed string is not meaningfully authenticated either. Because the audit only tested servers that were publicly reachable without credentials, this figure describes the exposed population by construction; it is not an estimate for MCP servers in general.

The 68 reportable findings break down by class, and the class counts overlap rather than partition the total: 380 authentication deficiencies, 52 instances of protocol fuzzing acceptance, 47 tool poisoning, 38 command injection, 31 schema bypass, 29 server-side request forgery, 24 resource URI manipulation, 22 prompt injection, 18 token exposure and 14 supply-chain indicators. Denial-of-service modules were written but deliberately not run against production servers, which Padilla excludes on ethical grounds. The four vulnerability types named in the abstract — SQL injection, SSRF against cloud metadata services, prompt template injection and path traversal via cursor manipulation — each appear inside those classes.

The shell-execution figure needs one caveat the paper does not resolve. In its results section, 687 tool instances with shell execution and no authentication are counted across the 640-server confirmed pool. In the discussion, the same figure is introduced with the words "of the 414 dynamically audited servers" and then referred to the "broader confirmed set". The two framings do not agree, and the paper never gives a total tool count for the tested servers, so 687 cannot be turned into a percentage.

Churn is the finding that most changes how the numbers should be read. Of the 464 servers confirmed on 21 July, 193 — 41.6% — were gone when the fourth run checked three days later. Nine of the 41 servers carrying a CRITICAL finding had also disappeared. Padilla reads this as deployment without review; it also means a finding confirmed on Monday may have no owner to patch it by Thursday.

The three case studies, and what can be checked

Three findings are written up in detail, each with a GitHub Security Advisory identifier. A SQL injection in lectorium-corpus-mcp (GHSA-m8qh-p8m5-8c48, rated CRITICAL) was confirmed with the payload ' OR 1=1 -- and a response-size differential, with no document content read or retained. An SSRF in epwforge (GHSA-r9fx-qwmc-rvx3, HIGH) was confirmed by timing: 11.9 seconds against an internal metadata address versus a 0.3-second baseline, with no metadata response content stored. A prompt template injection in frootai (GHSA-5h8f-r9g8-5w5p, HIGH) completes the set.

Two of the three can be checked directly. On 30 October 2026 the first two advisory pages resolved publicly in CobaltoSec's advisory repository, both published on 20 August 2026, both still listing "Patched versions: None" and no CVE. The third, GHSA-5h8f-r9g8-5w5p, returned not found at that address. CobaltoSec's repository listed 46 published advisories on the same date, covering MCP servers and adjacent AI tooling; the paper counted 19 as publicly disclosed and 49 still under embargo when it was written. A scan artifact for frootai dated 28 July 2026 sits in the Corvus repository, so the test happened; only the advisory is not visible.

The disclosure process itself is described in outline rather than in detail. All 68 findings went to maintainers through private GitHub Security Advisories under a 90-day coordinated embargo, and where private reporting was unavailable Padilla filed a public repository issue instead. The paper reports anecdotally that some maintainers patched within 24 hours, others did not answer for weeks, and some repositories were abandoned. It gives no count of maintainers contacted and no response-rate table, saying those will be reported in full at submission time.

What the paper does not establish

Exposed by Design is a single-author preprint. arXiv lists version 1, submitted 31 July 2026, with no journal reference and no peer-review statement. The archive grades the record confidence B — documented, but from a single source — and that grade holds for the whole of this piece: every figure above comes from Padilla's paper or from artifacts he publishes, not from an independent measurement.

No independent newsroom appears to have reported the study. Coverage exists — an AI-written analysis on forkast.news, LinkedIn and Medium posts, a Chinese-language security blog, a Japanese explainer — but it paraphrases the preprint without interviewing the author, checking the advisories or adding data. Derivative coverage is not corroboration.

Padilla states the limits himself, and they are unusually specific. Only HTTP transports were tested; stdio servers, the common local case, are out of scope. Discovery is best-effort, so 640 is a floor. The 226 confirmed servers that were not fully tested were excluded for 403 responses, connection resets, non-conforming JSON-RPC replies or simply being offline, and the paper says the resulting selection bias cannot be bounded. Detection rests on heuristics — timing oracles, differential responses, schema inspection — with no labelled benchmark and no published precision or recall for the 34 modules. The churn he documents undermines the temporal validity of individual findings. And a single researcher doing manual verification introduces a confirmation-bias risk he names and does not quantify.

What changed after

The practical outcome so far is the tool and the advisory stream. Corvus is installable and documented, and CobaltoSec's advisory repository carried 46 published entries on 30 October 2026, against the 19 public disclosures the paper counted at the end of July. Two of the paper's own case studies still carry no patched version — for those servers, disclosure has produced a public record but not, yet, a fix.

For defenders, the useful part of the study is its method rather than its headline. A 91.8% figure drawn only from servers that answered without credentials says something narrow and real: most of what is exposed was never locked, and the three-day churn suggests much of it was stood up for a demo, a prototype or a test and never hardened. What the paper cannot say is whether the same holds for the MCP servers organisations actually rely on, because those were never in the sample.