MCPStore.nl

Gepubliceerd:

Officiële MCP-referentieservers naar 2.0: fetch blokkeert nu interne adressen, en dat kan uw configuratie raken

Kort: het MCP-project bracht op 11 oktober 2026 v1.0.0 en op 19 oktober v2.0.0 uit van zijn referentieservers (fetch, filesystem, git, memory en andere). De belangrijkste wijziging: mcp-server-fetch weigert sinds versie 2026.10.10 standaard verzoeken naar interne en cloud-metadata-adressen, de fix voor SSRF-lek CVE-2026-104120. Versie 2.0 ondersteunt de specificatie van 28 juli 2026 en vraagt voor de TypeScript-servers Node 24.

De referentieservers in de repository modelcontextprotocol/servers zijn de voorbeeldimplementaties die het MCP-project zelf onderhoudt. Ze zijn bedoeld als lesmateriaal: de README waarschuwt letterlijk dat het "educational examples" zijn en geen productierijpe oplossingen. In de praktijk staan servers als fetch, filesystem en git wel in talloze configuraties van Claude Desktop, Cursor en VS Code, vaak zonder vaste versie via uvx of npx -y. Wie dat doet, krijgt deze nieuwe versies automatisch bij de volgende start.

Wat is er precies uitgebracht?

Het project publiceerde twee releases kort na elkaar.

Daarnaast bevatten beide releases fixes voor de filesystem-server rond roots, de mappen waartoe een client de server toegang geeft. Een van die fixes trekt de toegang in wanneer een update van de roots geen geldige map meer overlaat.

Welk beveiligingsprobleem is opgelost in fetch?

De fetch-server haalt een webpagina op en geeft die als tekst aan het model. Tot en met 2026.8.18 volgde hij doorverwijzingen zonder te controleren waar die naartoe gingen. Een URL die het model aanlevert, of een doorverwijzing vanaf een gewone publieke site, kon zo uitkomen bij 127.0.0.1, interne netwerkadressen of het metadata-endpoint van een cloudomgeving (169.254.169.254), waar vaak tijdelijke inloggegevens op te halen zijn. Dat is server-side request forgery (SSRF), hetzelfde patroon dat we eerder beschreven in ons artikel over protocol pivoting.

Het lek kreeg op 2 oktober het nummer CVE-2026-104120 (toegekend door VulDB; CVSS 3.1-score 7,3). Het CVE-record noemt versies tot en met 2026.6.4. De beveiliging zat echter pas in 2026.10.10, dus ook de tussenliggende releases misten haar. In de pull request met de fix (#5033) laten de onderhouders zien hoe een doorverwijzing via een publieke site een geheim van een lokale testserver ophaalde vóór de fix, en geweigerd werd erna.

Sinds 2026.10.10 controleert de server bij elk verzoek, elke doorverwijzing en het ophalen van robots.txt naar welke adressen een hostnaam verwijst, en weigert hij alles wat niet publiek routeerbaar is. Met de nieuwe optie --allow-private-ips zet u die controle uit. Die optie staat in de configuratie van de host, zodat het model haar niet zelf kan omzetten. De README is eerlijk over de grenzen: tegen DNS-rebinding tussen controle en verbinding beschermt dit niet, en hostnamen die alleen een proxy kan opzoeken worden niet gecontroleerd.

Waarom moet een IT-team hier iets mee?

Om twee redenen die elkaar tegenspreken. Ten eerste: wie een oudere, vastgepinde versie van fetch draait op een machine met toegang tot interne systemen of een cloudomgeving, heeft een bekend lek. Ten tweede: wie niet vastpint, krijgt nu ongemerkt gedrag dat bestaande werkwijzen kan breken. Een agent die via fetch een interne wiki, een lokale ontwikkelserver of een intranetpagina ophaalde, krijgt sinds deze maand een foutmelding. En een filesystem- of memory-server die via npx -y start op een machine met een Node-versie ouder dan 24, draait niet meer op een ondersteunde versie.

Ons advies

(1) Zoek in de MCP-configuraties binnen uw organisatie (Claude Desktop, Cursor, VS Code, interne agents) naar mcp-server-fetch en de @modelcontextprotocol/server-*-pakketten. (2) Pin een versie in plaats van altijd de nieuwste te laden: fetch ≥ 2026.10.10, en bij voorkeur 2026.10.19 of 2.0.0 na een test. (3) Zet --allow-private-ips niet standaard aan om een gebroken workflow te repareren. Heeft een agent echt toegang tot een interne bron nodig, geef hem dan een eigen server met een beperkte lijst toegestane adressen. (4) Behandel referentieservers als wat ze zijn: voorbeelden. Voor productie hoort er een server met een eigenaar, een updatebeleid en netwerksegmentatie bij. Meer in veiligheid & watchouts en betrouwbare bronnen.

Wat zegt deze release over het MCP-project?

Onze duiding: de releases laten zien dat het project zijn eigen voorbeeldcode serieuzer neemt. De onderhouders legden eerst testsuites vast die bekende fouten expliciet markeerden, losten die fouten op en migreerden pas daarna naar de nieuwe SDK. De keerzijde zit in de tijdlijn. Het SSRF-probleem was publiek bekend: een onderzoeker vroeg op 8 juli in een openbare issue of drie beveiligingsmeldingen van 5 juni waren gezien, en die issue staat nog open. Voor organisaties is de les dezelfde als bij de SDK-adviezen van eerder deze maand: wacht niet op een advies, maar houd zelf bij welke MCP-componenten u draait en werk ze actief bij.

Bronnen

Veelgestelde vragen

Welke versie van mcp-server-fetch is veilig voor CVE-2026-104120?

Versie 2026.10.10 of hoger. Vanaf die versie weigert de server standaard verzoeken en doorverwijzingen naar private, loopback-, link-local- en cloud-metadata-adressen. Het CVE-record noemt versies tot en met 2026.6.4, maar ook 2026.7.10 en 2026.8.18 hebben de controle nog niet. De nieuwste versie is 2026.10.19.

Mijn agent kan via fetch geen interne pagina's meer ophalen. Wat nu?

Dat is het nieuwe standaardgedrag. Met --allow-private-ips in de serverconfiguratie zet u de controle uit, maar dan is de SSRF-bescherming ook weg. Heeft een agent echt toegang tot interne bronnen nodig, gebruik dan liever een aparte server die alleen de benodigde interne adressen toestaat.

Zijn de MCP-referentieservers geschikt voor productie?

Volgens het MCP-project zelf niet: de README noemt ze voorbeeldimplementaties en geen productierijpe oplossingen. Gebruikt u ze toch, pin dan een versie, wijs een eigenaar aan en beperk hun netwerk- en bestandstoegang.

Laatst bijgewerkt: