Bots som leter etter WordPress-installasjoner og glemte .env-filer er gammelt nytt i enhver webserverlogg. Nytt er at de samme loggene nå fylles av gyldige JSON-RPC-kall mot /mcp. SANS Internet Storm Center gikk gjennom fjorten dager med Apache- og ModSecurity-logger fra én liten, lavtrafikkert delt webserver og fant rundt 200 forespørsler rettet spesifikt mot KI-infrastruktur: MCP-handshakes, konfigurasjonsfiler fra Claude, Cursor og VS Code, og API-endepunkter for Ollama og OpenAI-kompatible servere.
Forskjellen fra vanlig katalogskanning er at trafikken faktisk snakker protokollen. Forespørslene bar en korrekt strukturert MCP initialize-kall med JSON-RPC 2.0 og protokollversjon 2025-03-26, altså den forhandlingen en klient og server gjør før verktøy kan oppdages. Et vellykket svar røper ikke bare at du kjører en MCP-server, det kan liste ut verktøyene, ressursene og bakenforliggende tjenester serveren eksponerer. Handshake-kategorien kom fra 49 ulike IP-adresser.
«En eksponert og uautentisert MCP-server er nær verste tenkelige tilfelle. Den er en maskinlesbar meny, tilgjengelig over nett, over alt en agent kan ta på.» — Manuel Humberto Santander Peláez, SANS Internet Storm Center
Det farlige er kombinasjonen. Samme kampanje sendte SSRF-forsøk mot metadata.google.internal og 169.254.169.254, og roterte parameternavnet mellom url, uri, path og dest. På Google Compute Engine kan en arbeidslast hente OAuth-token for sin egen service-account fra metadata-tjenesten. Klarer angriperen å få serveren din til å gjøre det kallet, er tokenet ute. MCP-servere er et uvanlig godt mål her, fordi «hent denne URL-en» er et av de vanligste verktøyene folk gir dem. Da ligger både oppdagelsen og SSRF-primitivet i samme grensesnitt.
Dette er ikke teoretisk. CVE-2026-27826 i mcp-atlassian er nøyaktig denne feilen i praksis: en uvalidert HTTP-header (X-Atlassian-Jira-Url) lot serveren hente en vilkårlig adresse. Sårbarheten fikk CVSS 8.2 og ble tettet i versjon 0.17.0 i februar. Bare HTTP-transport var rammet, ikke standard stdio.
«Enhver angriper med nettverkstilgang kan potensielt stjele serverens IAM-rolle-legitimasjon via metadata-tjenesten, og få full tilgang til alle skyressurser den rollen tillater.» — RAXE Labs, i rådgivningen om CVE-2026-27826
Kjører du en selvhostet MCP-server bak en tunnel eller på en VPS, er du i målgruppen for denne skanningen enten du vet det eller ikke. Det samme gjelder en Ollama-instans som svarer på /api/tags uten autentisering. Og bruker du HEAD-forespørsler som mål: skannerne sjekker om .claude/, .cursor/mcp.json og .credentials.json ligger under webroten din, uten å laste dem ned.
Hva bør du gjøre?
- Søk i tilgangsloggene etter POST /mcp, /sse, /v1/models, /api/tags, metadata.google.internal og 169.254.169.254. Kjører du ingen offentlig MCP-server, er treff ren rekognosering og et godt grunnlag for å blokkere kilden.
- Krev autentisering foran hver MCP-server som er nåbar fra internett, og gi hvert verktøy sin egen autorisasjon i stedet for én felles nøkkel som åpner alt.
- Avvis link-local, loopback, private og metadata-adresser i alt som henter URL-er, etter DNS-oppslag og på hver eneste redirect. På AWS gir IMDSv2 et ekstra krav om sesjonstoken som stopper mange av disse mønstrene.
Bakgrunn
MCP kobler språkmodeller til verktøy, filsystemer, databaser og interne API-er gjennom et felles grensesnitt. Prisen for den bekvemmeligheten er at én eksponert server beskriver hele koblingsflaten sin på forespørsel. Sørg for at .claude, .cursor, .vscode og .mcp aldri følger med inn i produksjonsartefakter, og la webserveren nekte skjulte konfigurasjonskataloger eksplisitt i stedet for å stole på at de aldri havner der.