Semgrep-regler leter etter MCP-servere som glemte auth på én transport

En MCP-server som opprinnelig ble skrevet for SSE og senere fikk streamable HTTP bolt på, har to inngangsdører og risikerer å ha bare én lås. ShroudLabs har publisert et sett Semgrep-regler for akkurat det mønsteret, som de kaller Transport-Layer Auth Divergence. Utgangspunktet er NapthaAI sin http-oauth-mcp-server: den tilstandsfulle /sse-veien kjørte bearerAuthMiddleware, mens den tilstandsløse /mcp-veien ikke gjorde det. Det stateless endepunktet svarte HTTP 200 både uten token og med et falskt token. Feilen er klassifisert som CWE-306 med CVSS 9.8.

Poenget er ikke at autentiseringen manglet. Den lå i kodebasen, den var bare ikke koblet på alle transportene. Derfor bommer generiske auth-skannere: serveren ser autentisert ut fordi én vei er det. De to veiene deler som regel alt annet også, samme verktøy, samme handlere, samme data, så den ubeskyttede veien er ikke en begrenset flate. Den er hele serverens kapasitet med låsen fjernet.

ShroudLabs beskriver fire varianter. Manglende middleware på én transport er opphavstilfellet. Auth på feil lag vil si at token sjekkes ved oppstart av sesjonen, men ikke på hvert kall etterpå, slik at første forespørsel er portet og resten ikke. Divergerende styrke vil si at én vei krever bearer-token mens en annen godtar en nøkkel i spørrestrengen. Og så er det debug-, helse- og legacy-ruter montert ved siden av den autentiserte transporten uten vakt.

Signaturen i kildekoden er et fravær målt mot et søsken: et middleware-symbol som finnes i én transports registrering og mangler i en annen, i samme server. Statisk analyse kan ikke uttrykke det direkte, så reglene kjører i to pass. Første pass finner servere som registrerer auth i det hele tatt, altså de som har noe å avvike fra. Andre pass finner monteringspunkter og flagger dem som mangler auth-symbolet i registreringskjeden. Et repo teller først som kandidat når begge funnene slår ut.

Prosjektet er tydelig på hva det ikke er. Statisk analyse produserer kandidater, ikke bekreftelser, og et rent resultat er ingen frikjennelse, bare et fravær av treff på disse konkrete mønstrene. Reglene dekker Express- og FastAPI-formet kode. Repoet dokumenterer også sine egne falske positiver: den offisielle typescript-sdk-en ble flagget fordi eksempelmappen inneholder flere små, uavhengige demoservere som aldri kjører sammen, og socrata-mcp-server ble flagget på en Vitest-test som setter opp sin egen Express-app på localhost. Begge er nå ekskludert fra vurderingen på repo-nivå.

Hva bør du gjøre?

1. Tell transportene i din egen server før du kjører noe verktøy i det hele tatt. Har du både /sse og /mcp, har du to registreringspunkter for middleware, og det andre er det folk glemmer.
2. Bruk survey.py framfor triage.py hvis du skanner mer enn ett repo. Den leter etter auth som er lagt på globalt i en annen fil enn monteringen, som er nettopp den falske positiven reglene ellers produserer.
3. Bekreft alltid mot din egen lokale instans, aldri mot noen andres kjørende server. Send én forespørsel uten token og én med et syntaktisk gyldig falskt token. Kommer det 200 på noen av dem, er funnet reelt, og gjelder det andres kode går veien om koordinert offentliggjøring via huntr.dev eller en GitHub Security Advisory.