Sicherheitsforschung: CVEs aus koordinierter Offenlegung

Die Funde

Vier CVEs, jede mit Quelle.

Sortiert nach Schwere. Wo der CVE-Eintrag bei MITRE noch nicht veröffentlicht ist, führen wir die Kennung als „zugeteilt“ und verlinken die GitHub-Advisory des Projekts.

CVE-2026-15583behoben

Grafana MCP Servergrafana/mcp-grafana

Was ein Angreifer hätte tun können: die Zugangsdaten des MCP-Servers zu Ihrem Grafana an einen eigenen Server umleiten.

Über den Header X-Grafana-URL konnte der Aufrufer bestimmen, an welchen Host der Server seine Zugangsdaten aus der Umgebung schickt. Fachbegriff: SSRF beziehungsweise Confused Deputy.

Schwere: CVSS 8.6 (laut CVE-Eintrag)
Betroffen: bis einschließlich 0.17.1
Behoben: in 0.17.2 (Release 13.07.2026)
Veröffentlicht: 15.07.2026, Grafana als CNA
Credit: CyberSec42 (im CVE-Eintrag)

Technischer Beitrag → CVE-Eintrag Grafana-Advisory GHSA-7cfp-pmw3-4j7r

CVE-2026-114123behoben

d365fo-mcp-servernpm: d365fo-mcp

Was ein Angreifer hätte tun können: ohne Anmeldung proprietären X++-Quellcode über das Internet abrufen.

Die offizielle Azure-One-Click-Bereitstellung lief standardmäßig ohne Anmeldung. Dadurch war proprietärer X++-Quellcode über das Internet erreichbar. Klassen: fehlende Authentifizierung und unsicherer Standardwert (CWE-306, CWE-1188).

Schwere: CVSS 7.5, hoch (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)
Betroffen: bis einschließlich 1.10.1
Behoben: in 1.11.0
Veröffentlicht: Advisory 12.08.2026, CVE 21.10.2026
Credit: lwebmedia (CyberSec42) auf der GitHub-Advisory

Technischer Beitrag → GHSA-8764-fh3m-wf7g CVE-Eintrag

CVE-2026-104776zugeteiltbehoben

mcp-server-kubernetesnpm: mcp-server-kubernetes

Was ein Angreifer hätte tun können: Dateien vom Server lesen, auf dem der MCP-Server läuft.

Dem Werkzeug kubectl_patch fehlte bei entferntem Transport die Pfad-Prüfung, die alle Geschwister-Werkzeuge hatten. Über patchFile ließen sich dadurch beliebige Dateien auf dem Server lesen (CWE-73).

Schwere: CVSS 7.1, hoch
Betroffen: bis einschließlich 4.1.0
Behoben: in 4.1.1
Veröffentlicht: Advisory 02.10.2026, CVE zugeteilt
Credit: lwebmedia (CyberSec42) auf der GitHub-Advisory

Technischer Beitrag → GHSA-6963-p4fp-2wxw

CVE-2026-110787zugeteiltbehoben

pRESTprest/prest, Go

Was ein Angreifer hätte tun können: Datenbanken, Schemata und Tabellen einsehen, die verborgen sein sollten.

Der MCP-Endpunkt /_mcp lief an der ExposureMiddleware vorbei und machte Datenbanken, Schemata und Tabellen sichtbar, die per expose.* verborgen sein sollten (CWE-284).

Schwere: CVSS 5.3, mittel
Betroffen: bis einschließlich 2.4.0
Behoben: in 2.4.1
Veröffentlicht: Advisory 29.07.2026, CVE zugeteilt
Credit: lwebmedia (CyberSec42) auf der GitHub-Advisory

Technischer Beitrag → GHSA-x62p-38px-pp73

Wir danken den Maintainern von Grafana MCP Server, d365fo-mcp-server, mcp-server-kubernetes und pREST für die Zusammenarbeit in der koordinierten Offenlegung. Stand der Angaben: 28.10.2026.

Das Muster dahinter

Die Lücken sitzen an Vertrauensgrenzen.

Keiner dieser Funde ist ein exotischer Trick. Jeder entsteht an der Stelle, an der ein System einer Eingabe, einer Voreinstellung oder einem neuen Zugang mehr vertraut, als es sollte. Genau diese Stellen prüfen wir zuerst.

01 · CVE-2026-104776

Einem Werkzeug fehlt eine Prüfung, die seine Geschwister haben

Alle Werkzeuge prüfen den Pfad, eines nicht. Solche Lücken fallen erst auf, wenn man jedes Werkzeug gegen dieselbe Regel hält.

02 · CVE-2026-114123

Die Standardkonfiguration kommt ohne Anmeldung

Wer der offiziellen Bereitstellung folgt, übernimmt ihre Voreinstellungen. Ist dort keine Anmeldung vorgesehen, ist der Dienst offen.

03 · CVE-2026-110787

Ein neuer MCP-Zugang umgeht bestehende Zugriffskontrolle

Die Regeln, was sichtbar sein darf, galten für den bisherigen Weg. Der neue MCP-Endpunkt lief daran vorbei.

04 · CVE-2026-15583

Zugangsdaten folgen einer vom Aufrufer gesetzten URL

Bestimmt der Aufrufer das Ziel, und der Server hängt seine eigenen Zugangsdaten an, landen diese dort, wo der Aufrufer will.

So melden wir

Koordinierte Offenlegung: erst der Fix, dann die Veröffentlichung.

Schritt 1

Privat melden

Wir melden den Fund vertraulich über den Meldeweg des Projekts, mit Beschreibung und Nachweis. Öffentlich sagen wir nichts.

Schritt 2

Fix abwarten

Die Maintainer beheben die Lücke und veröffentlichen eine korrigierte Version. Bis dahin bleibt der Fund vertraulich.

Schritt 3

CVE über CNA oder GitHub

Die CVE-Kennung vergibt eine CNA: der Hersteller selbst, wie Grafana, oder GitHub über die Security-Advisory des Projekts.

Schritt 4

Erst dann veröffentlichen

Erst nach Fix und Advisory nennen wir den Fund hier, mit Kennung, betroffener und behobener Version und Quelle.

Was das für Ihre Prüfung heißt

Dieselbe Methode, auf Ihre Systeme angewandt.

Die Funde oben stammen aus derselben Arbeitsweise, mit der wir Kundensysteme prüfen: Vertrauensgrenzen kartieren, jedes Werkzeug gegen dieselbe Regel halten, jeden Befund vor der Meldung mit einem Nachweis belegen. Bei Ihnen geschieht das als autorisierte Prüfung im schriftlich vereinbarten Umfang. Ein öffentlicher Fund belegt die Methode, er ist keine Aussage über die Sicherheit Ihres Systems.

→