Exposé par conception : un audit en direct de 414 serveurs MCP exposés sur Internet a révélé 68 vulnérabilités

Le 31 juillet 2026, Nicolás Padilla a publié Exposed by Design (arXiv:2608.00150), un préprint de 13 pages décrivant ce qu'il présente comme la première évaluation dynamique de la sécurité comportementale de serveurs Model Context Protocol exposés sur Internet. Quatre campagnes de mesure ce mois-là ont confirmé 640 serveurs de production actifs, dont 414 ont été testés activement ; les tests ont produit 68 vulnérabilités signalables, toutes déposées auprès des mainteneurs sous forme de GitHub Security Advisories. 380 des 414 — 91,8 % — n'avaient aucune authentification OAuth, et 687 instances d'outils annonçaient une exécution de shell sans contrôles d'accès. Padilla ne rapporte aucune preuve d'exploitation : les tests sont restés au stade de preuve de concept, aucun identifiant n'a été obtenu et aucune donnée n'a été exfiltrée. La liste complète des sources, la note de gravité et l'évaluation de confiance de l'enregistrement se trouvent dans les archives d'incidents liés à l'IA, aux côtés des autres constats MCP et d'infrastructure déposés à la même période.

Ce que l’audit a réellement fait

Le Model Context Protocol est l’interface qui permet à un agent IA d’appeler des outils hébergés ailleurs — une recherche documentaire, une requête à une base de données, un utilitaire shell. Un serveur qui parle ce protocole via HTTP et est joignable depuis Internet constitue, de fait, une surface d’outils que n’importe qui peut solliciter. L’article de Padilla soutient que la population de ces serveurs n’a jamais été correctement dénombrée, et que les recenser est précisément l’enjeu : la découverte est la partie difficile, et toutes les enquêtes antérieures n’ont examiné qu’une tranche différente.

Sa phase de découverte a fusionné onze sources — crt.sh, Hugging Face, GitHub, npm, Smithery, PyPI, Censys, FOFA, Shodan, glama.ai et pulsemcp.com — en partant du principe qu’aucune d’entre elles, prise isolément, ne capture la population. La phase active a utilisé Corvus, un framework que Padilla a conçu pour l’étude : 34 modules de test couvrant 10 classes de vulnérabilités spécifiques à MCP, répartis en 13 modules statiques et 21 dynamiques. Il est publié sur GitHub sous l’organisation CobaltoSec et sur PyPI sous le nom de cobaltosec-corvus, et le fichier de statistiques du dépôt lui-même consigne le même total de 34 modules.

Les quatre exécutions ont eu lieu les 15, 18, 21 et 24 juillet 2026. Les exécutions précédentes n'ont fourni que des chiffres de confirmation ; les trois dernières ont analysé 3 485, 3 948 et 4 110 candidats et confirmé respectivement 140, 464 et 296 serveurs actifs. La déduplication de 972 observations brutes comportant 332 occurrences répétées a laissé 640 serveurs confirmés uniques, dont 414 — 64,7 % — ont accepté des tests dynamiques complets. Padilla considère 640 comme une borne inférieure. Censys, l'une des sources de découverte, avait estimé à plus de 21 000 le nombre de points de terminaison liés à MCP dans le monde en mai 2026, et il utilise ce chiffre comme estimation de l'ampleur plutôt que comme un décompte de ce qu'il a testé.

Interprétés comme un entonnoir, les chiffres constituent le véritable argument de l’article : un passage large et peu coûteux trouve des candidats plus rapidement qu’un passage minutieux ne peut les tester. Seuls 414 des 640 serveurs confirmés ont été entièrement testés, et Padilla ne prétend pas que le sous-ensemble testé ressemble au reste non testé.

Ce qu’il a trouvé

La conclusion principale concerne l’authentification, ou plutôt son absence. Sur les 414 serveurs testés, 380 (91,8 %) n’utilisaient pas OAuth. L’article indique que la plupart des serveurs restants utilisaient des jetons bearer statiques ou des clés API, souvent prévisibles ou vides — un serveur qui accepte une chaîne fixe n’est pas non plus authentifié de manière significative. Étant donné que l’audit n’a testé que des serveurs accessibles publiquement sans identifiants, ce chiffre décrit par construction la population exposée ; il ne s’agit pas d’une estimation pour les serveurs MCP en général.

Les 68 constatations signalables se répartissent par classe, et les décomptes des classes se chevauchent plutôt qu’ils ne partitionnent le total : 380 déficiences d’authentification, 52 cas d’acceptation de fuzzing de protocole, 47 empoisonnements d’outils, 38 injections de commandes, 31 contournements de schéma, 29 falsifications de requête côté serveur, 24 manipulations d’URI de ressource, 22 injections d’invite, 18 expositions de jetons et 14 indicateurs de chaîne d’approvisionnement. Des modules de déni de service ont été écrits, mais volontairement non exécutés contre des serveurs de production, ce que Padilla exclut pour des raisons éthiques. Les quatre types de vulnérabilités cités dans le résumé — injection SQL, SSRF contre des services de métadonnées cloud, injection de modèle d’invite et traversée de répertoires via manipulation de curseur — apparaissent chacun dans ces classes.

Le chiffre relatif à l’exécution de shell nécessite une mise en garde que l’article ne résout pas. Dans sa section consacrée aux résultats, 687 instances d’outils avec exécution de shell et sans authentification sont recensées dans le bassin confirmé de 640 serveurs. Dans la discussion, le même chiffre est introduit par les mots « parmi les 414 serveurs audités dynamiquement », puis renvoyé à « l’ensemble confirmé plus large ». Les deux formulations ne concordent pas, et l’article ne donne jamais de nombre total d’outils pour les serveurs testés, si bien que 687 ne peut pas être converti en pourcentage.

Le churn est le constat qui modifie le plus la manière dont les chiffres doivent être lus. Sur les 464 serveurs confirmés le 21 juillet, 193 — 41,6 % — avaient disparu lorsque la quatrième exécution a vérifié trois jours plus tard. Neuf des 41 serveurs portant un constat CRITIQUE avaient également disparu. Padilla l’interprète comme un déploiement sans revue ; cela signifie aussi qu’un constat confirmé le lundi peut n’avoir aucun propriétaire pour le corriger dès le jeudi.

Les trois études de cas, et ce qui peut être vérifié

Trois résultats sont documentés en détail, chacun avec un identifiant d’avis de sécurité GitHub. Une injection SQL dans lectorium-corpus-mcp (GHSA-m8qh-p8m5-8c48, classée CRITIQUE) a été confirmée avec la charge utile ' OR 1=1 -- et un différentiel de taille de réponse, sans aucun contenu de document lu ni conservé. Une SSRF dans epwforge (GHSA-r9fx-qwmc-rvx3, ÉLEVÉE) a été confirmée par chronométrage : 11,9 secondes pour une adresse de métadonnées interne, contre 0,3 seconde de référence, sans contenu de réponse de métadonnées stocké. Une injection de modèle d’invite dans frootai (GHSA-5h8f-r9g8-5w5p, ÉLEVÉE) complète l’ensemble.

Deux des trois peuvent être vérifiés directement. Le 30 octobre 2026, les deux premières pages d'avis étaient accessibles publiquement dans le dépôt d'avis de CobaltoSec, toutes deux publiées le 20 août 2026, toutes deux indiquant encore « Versions corrigées : Aucune » et aucun CVE. La troisième, GHSA-5h8f-r9g8-5w5p, a renvoyé « introuvable » à cette adresse. Le dépôt de CobaltoSec listait 46 avis publiés à la même date, couvrant des serveurs MCP et des outils d'IA adjacents ; l'article en comptait 19 comme divulgués publiquement et 49 encore sous embargo au moment de sa rédaction. Un artefact de scan pour frootai daté du 28 juillet 2026 se trouve dans le dépôt Corvus, donc le test a bien eu lieu ; seul l'avis n'est pas visible.

Le processus de divulgation lui-même est décrit dans ses grandes lignes plutôt qu’en détail. Les 68 constats ont tous été transmis aux mainteneurs par le biais de GitHub Security Advisories privés dans le cadre d’un embargo coordonné de 90 jours, et lorsque le signalement privé n’était pas disponible, Padilla a plutôt ouvert une issue publique dans le dépôt. L’article rapporte de manière anecdotique que certains mainteneurs ont corrigé dans les 24 heures, que d’autres n’ont pas répondu pendant des semaines et que certains dépôts ont été abandonnés. Il ne donne ni le nombre de mainteneurs contactés ni de tableau des taux de réponse, indiquant que ces éléments seront rapportés dans leur intégralité au moment de la soumission.

Ce que l'article n'établit pas

« Exposed by Design » est un préprint à auteur unique. arXiv indique la version 1, soumise le 31 juillet 2026, sans référence de revue et sans mention d’évaluation par les pairs. L’archive attribue à la notice un niveau de confiance B — documenté, mais issu d’une source unique — et ce niveau vaut pour l’ensemble de cet article : chaque chiffre ci-dessus provient de l’article de Padilla ou des artefacts qu’il publie, et non d’une mesure indépendante.

Aucune rédaction indépendante ne semble avoir relayé l’étude. Des couvertures existent — une analyse rédigée par IA sur forkast.news, des publications sur LinkedIn et Medium, un blog de sécurité en chinois, un article explicatif en japonais — mais elles paraphrasent le preprint sans interviewer l’auteur, vérifier les avis ni ajouter de données. Une couverture dérivée ne vaut pas corroboration.

Padilla énonce lui-même les limites, et elles sont inhabituellement précises. Seuls les transports HTTP ont été testés ; les serveurs stdio, cas local courant, sont hors du périmètre. La découverte est menée au mieux, donc 640 constitue un plancher. Les 226 serveurs confirmés qui n’ont pas été entièrement testés ont été exclus en raison de réponses 403, de réinitialisations de connexion, de réponses JSON-RPC non conformes ou simplement d’une indisponibilité, et l’article affirme que le biais de sélection qui en résulte ne peut être borné. La détection repose sur des heuristiques — oracles temporels, réponses différentielles, inspection de schéma — sans benchmark étiqueté ni précision ou rappel publiés pour les 34 modules. L’instabilité qu’il documente fragilise la validité temporelle des conclusions individuelles. Et un seul chercheur effectuant une vérification manuelle introduit un risque de biais de confirmation qu’il nomme sans le quantifier.

Qu’est-ce qui a changé après

Le résultat concret à ce jour, ce sont l'outil et le flux d'avis. Corvus est installable et documenté, et le dépôt d'avis de CobaltoSec comptait 46 entrées publiées au 30 octobre 2026, contre les 19 divulgations publiques recensées par l'article à la fin du mois de juillet. Deux des études de cas de l'article lui-même n'ont toujours pas de version corrigée — pour ces serveurs, la divulgation a produit un dossier public, mais pas encore de correctif.

Pour les défenseurs, l’intérêt de l’étude réside dans sa méthode plutôt que dans son titre. Un chiffre de 91,8 % tiré uniquement des serveurs qui ont répondu sans identifiants dit quelque chose d’étroit et de réel : l’essentiel de ce qui est exposé n’a jamais été verrouillé, et le renouvellement en trois jours suggère qu’une bonne partie a été mise en place pour une démo, un prototype ou un test, sans jamais être durcie. Ce que l’article ne peut pas dire, c’est si la même chose vaut pour les serveurs MCP sur lesquels les organisations s’appuient réellement, car ceux-ci n’ont jamais fait partie de l’échantillon.