To hull i Consul MCP-server lekker tokenet, fikset i 0.1.4

HashiCorp publiserte bulletinen HCSEC-2026-24 den 29. juli og melder om to sårbarheter i consul-mcp-server, MCP-serveren som gir KI-agenter tilgang til en Consul-klynge. Alle versjoner fra 0.1.0 til og med 0.1.3 er rammet, og begge hullene er tettet i 0.1.4.

Den første, CVE-2026-16328, ligger i en funksjon som lot klienten overstyre adressen til Consul-backenden per forespørsel. Adressen ble aldri validert, så en tilkoblet klient kunne få serveren til å sende Consul-trafikken sin, med legitimasjonen den er konfigurert med, til et endepunkt angriperen kontrollerer. HashiCorp beskriver konsekvensen som mulig tyveri av legitimasjon eller server-side request forgery mot alt serveren kan nå. Har du ingen Consul-token satt i miljøet, er du ikke utsatt for tokentyveriet.

Den andre, CVE-2026-16326, er mer interessant nå enn den ville vært for en uke siden. I stateless-modus isolerte ikke serveren sesjonstilstanden ordentlig, slik at en autentisert Consul-klient fra én sesjon kunne bli gjenbrukt for en annen klients forespørsler. I praksis betyr det at verktøykall kan kjøre med en annen brukers token. Bare oppsett i stateless-modus med mer enn én klient er rammet; kjører du stateful, går du klar. Timingen er verdt å merke seg, for MCP-spesifikasjonen droppet nettopp håndtrykket og sesjonene i revisjonen 2026-07-28, og stateless blir dermed normalen flere beveger seg mot.

HashiCorp krediterer He Wei for CVE-2026-16328, mens det andre funnet kom fra et internt team.

Hva bør du gjøre?

1. Oppgrader consul-mcp-server til 0.1.4. Sjekk versjonen du faktisk kjører, ikke den du tror du installerte.
2. Får du ikke oppgradert med en gang, begrens nettverkstilgangen til MCP-serveren til klienter du stoler på.
3. Kjører du stateless med flere klienter, roter Consul-tokenene etter oppgradering: et lekket token er fortsatt gyldig selv når hullet er tettet.