GitHub MCP Server 1.10.0 låser ned symlink-skriving og bearer-tokens

Elleve pull-requester ligger under overskriften «Safer by default» i utgivelsesnotatene for GitHub MCP Server 1.10.0, som kom 19. august. GitHub beskriver selv utgivelsen som en omfattende sikkerhets-, stabilitets- og kompatibilitetsoppdatering, og det er endringene i standardoppførselen du merker først hvis du kjører serveren selv.

Den mest inngripende gjelder symbolske lenker. Skriving gjennom en symlink krever nå at du eksplisitt setter allow_symlink_write: true, og get_file_contents markerer tydelig når innholdet du får tilbake er en dereferert lenke i stedet for filen du trodde du leste. Samtidig er bearer-tokens begrenset til de GitHub-vertene du faktisk har konfigurert, og GitHub Enterprise-verter tvinges over på HTTPS for å hindre at legitimasjon går i klartekst.

Konfigurasjonsfeil feiler nå lukket i stedet for stille. Et ugyldig statisk --tools-oppsett stopper serveren i stedet for å starte med et halvt verktøysett, forespørsler kan ikke lenger be seg fri fra lockdown-modusen serveren håndhever, og for store HTTP-kropper avvises tidlig i stedet for etter parsing.

Sletting av repo har fått sin egen bremse. Operasjonen krever nå bekreftelse via form elicitation, en MCP-klient som støtter det, og riktige scopes. Kjører du en eldre klient, forsvinner muligheten helt i stedet for å feile halvveis.

Hva bør du gjøre?

1. Kjør gjennom --tools-lista før du oppgraderer. Ett feilstavet navn er forskjellen på en server som starter og en som ikke gjør det.
2. Sett allow_symlink_write: true bare for de agentene som faktisk trenger å skrive gjennom symlinks, ikke som global default.
3. Test agenter som leser binære MCP-ressurser. Dobbel base64-koding er rettet i 1.10.0, så kode som kompenserte for feilen vil nå tolke innholdet galt.