Eigene Forschung

CVE-2026-110787: Wie der MCP-Endpunkt von pREST die expose-Einstellungen umging

Von Lucas Weber, CyberSec42 · Stand 28.10.2026

CVE-2026-110787 ist eine Schwachstelle in der Zugriffskontrolle (CWE-284) des Open-Source-Projekts pREST: Der MCP-Endpunkt /_mcp beachtete die Einstellungen im Abschnitt [expose] nicht und listete Datenbanken, Schemata, Tabellen und Spaltennamen auch dann auf, wenn der Betreiber diese Auflistung abgeschaltet hatte. Die GitHub-Advisory GHSA-x62p-38px-pp73 bewertet sie mit CVSS 5.3 (mittel) und führt das Go-Modul github.com/prest/prest/v2 bis einschließlich Version 2.4.0 als betroffen, behoben ist sie in 2.4.1 vom 29.07.2026. Betroffen waren nur Installationen, die [expose] aktiv zum Verbergen ihres Katalogs nutzten, und sichtbar wurden Namen, keine Tabelleninhalte über das hinaus, was die Zugriffsregeln ohnehin erlaubten.

Die Fakten auf einen Blick

Hintergrund: Was pREST ist und was [expose] regelt

pREST ist ein in Go geschriebenes Open-Source-Projekt unter MIT-Lizenz. Es stellt für eine bestehende PostgreSQL-Datenbank, seit Version 2.5 auch für MySQL, ohne eigenen Backend-Code eine REST-API bereit: Lesen, Schreiben, Filtern, eigene SQL-Routen, Authentifizierung und Zugriffsregeln. Seit Version 2.1.0 vom 09.07.2026 bietet derselbe Server zusätzlich einen Endpunkt nach dem Model Context Protocol (MCP) unter /_mcp. Über ihn können KI-Agenten den Datenbankkatalog erkunden, Tabellen beschreiben und Zeilen lesen. Der Endpunkt ist laut Dokumentation bewusst nur lesend und nutzt dieselbe Authentifizierung und dieselben Zugriffsregeln wie die REST-API.

Für das Verständnis dieser Schwachstelle sind zwei Konfigurationsabschnitte wichtig, die pREST ausdrücklich voneinander trennt:

• [access] regelt, ob Daten gelesen oder geschrieben werden dürfen, auf Wunsch je Tabelle, Feld und Nutzer. Mit access.restrict = true sind nur ausdrücklich freigegebene Tabellen erreichbar.
• [expose] regelt laut Dokumentation den Zugang zur Auffindbarkeit („discovery“), also ob ein Aufrufer die Namen der Datenbanken, Schemata und Tabellen auflisten kann. Mit expose.enabled = true und databases, schemas oder tables auf false blendet der Betreiber diese Listen aus. Tabellen, deren Namen ein Aufrufer bereits kennt, bleiben im Rahmen von [access] abfragbar.

Beide Abschnitte sind standardmäßig offen: expose.enabled steht auf false, damit ist alles auflistbar, und access.restrict ebenfalls auf false. Auch die Authentifizierung (auth.enabled) ist in der Standardkonfiguration ausgeschaltet. Wer pREST öffentlich betreibt, schaltet diese Schutzschichten also bewusst ein. Grundsätzliches zur Absicherung von MCP-Servern steht in unserem Leitfaden zu MCP-Servern; hier geht es um den konkreten Fall.

Die Schwachstelle

In einfachen Worten

Stellen Sie sich ein Bürogebäude vor, das sein Mieterverzeichnis im Foyer abgehängt hat, damit Besucher nicht sehen, welche Firmen im Haus sitzen. Wer in welches Büro darf, regelt weiterhin die Zugangskarte, daran ändert das Verzeichnis nichts. Dann öffnet das Gebäude einen zweiten Eingang, und dort hängt das vollständige Verzeichnis noch an der Wand, samt Raumplan.

So verhielt sich pREST bis Version 2.4.0. Das abgehängte Verzeichnis sind die [expose]-Einstellungen für die REST-Routen, der zweite Eingang ist /_mcp, die Zugangskarte ist [access].

Technisch

pREST setzt [expose] an genau einer Stelle durch, in der ExposureMiddleware. Sie hängt im globalen Middleware-Stapel, sobald expose.enabled aktiv ist, und vergleicht den Pfad jeder Anfrage mit drei festen Präfixen: /databases, /schemas und /tables. Passt ein Präfix und ist die zugehörige Einstellung false, antwortet der Server mit HTTP 401 („unauthorized listing“). Jeder andere Pfad wird ohne Prüfung durchgereicht.

/_mcp passt auf keines der drei Präfixe. Die MCP-Werkzeuge prest.list_databases, prest.list_schemas und prest.list_tables lieferten denselben Katalog wie die REST-Routen, fragten die [expose]-Konfiguration aber nicht ab. Hinzu kam die Discovery-Antwort auf ein einfaches GET /_mcp: Sie zählt die verfügbaren Werkzeuge auf, darunter je ein Lesewerkzeug pro Tabelle, dessen Name Datenbank, Schema und Tabelle trägt und dessen Beschreibung die Spaltennamen enthält. Ein Aufrufer, dem GET /databases korrekt verweigert wurde, sah den Katalog über /_mcp also vollständig, ohne ein einziges Werkzeug aufzurufen.

Wichtig für die Einordnung: Die Lesewerkzeuge auf /_mcp unterlagen weiterhin [access]. Mit access.restrict = true filterte pREST auch die Schema- und Tabellenlisten nach diesen Regeln, laut Advisory mit Ausnahme der Datenbankliste. Offengelegt wurden Metadaten, nicht der Inhalt von Tabellen, die der Aufrufer nicht ohnehin hätte lesen dürfen.

Zur Einordnung des Vektors: PR:N spiegelt die dokumentierte Standardkonfiguration, in der auth.enabled ausgeschaltet ist und /_mcp keine Anmeldung verlangt. Ist die Authentifizierung aktiv, braucht der Aufrufer ein gültiges Konto mit beliebigen Rechten; die Advisory nennt dafür PR:L und einen Basiswert von 4.3. C:L steht für einen begrenzten Verlust an Vertraulichkeit, Integrität und Verfügbarkeit sind nicht betroffen. Wir haben beide Basiswerte anhand der Formel der CVSS-3.1-Spezifikation nachgerechnet.

Schematischer Ablauf

1. Der Betreiber setzt expose.enabled = true und schaltet die Auflistung von Datenbanken, Schemata oder Tabellen ab.
2. Ein Aufrufer, der den HTTP-Endpunkt von pREST erreicht, fragt /databases ab und erhält korrekt eine Ablehnung.
3. Derselbe Aufrufer ruft /_mcp ab. Die Middleware erkennt den Pfad nicht als Katalogroute und reicht die Anfrage weiter.
4. Die Discovery-Antwort und die Listenwerkzeuge des MCP-Endpunkts geben Datenbank-, Schema-, Tabellen- und Spaltennamen zurück.
5. Welche Tabelleninhalte der Aufrufer danach lesen kann, bestimmt weiterhin [access], genau wie bei einer direkten REST-Abfrage.

Wir veröffentlichen bewusst keinen Exploit-Code. Die Beschreibung reicht, um die eigene Installation einzuordnen und den Fix nachzuvollziehen.

Wer betroffen war

Die Advisory führt das Go-Modul github.com/prest/prest/v2 in allen Versionen bis einschließlich 2.4.0 als betroffen. Den Endpunkt /_mcp gibt es laut Release-Notes und Dokumentation erst seit Version 2.1.0; im Quellcode von 2.0.0 ist er nicht registriert. Praktisch relevant war die Schwachstelle nur für Betreiber, die [expose] tatsächlich zum Verbergen ihres Katalogs eingesetzt hatten.

Wie viel ein offengelegter Katalog im Einzelfall verrät, hängt von den Namen ab. Tabellen wie orders sagen wenig, Schemata, die nach Kunden oder Projekten benannt sind, mehr. Und davon, wer den HTTP-Endpunkt erreichen konnte: nur der lokale Rechner, ein internes Netz oder das Internet.

Behebung und was Betreiber jetzt tun sollten

Was der Fix in 2.4.1 ändert

Die Korrektur (Pull Request #1016) definiert an einer zentralen Stelle, was [expose] erlaubt: drei Prüffunktionen für Datenbank-, Schema- und Tabellenlisten. Die REST-Middleware und die MCP-Werkzeuge fragen seitdem dieselben Funktionen ab. Ein Kommentar im Code begründet das ausdrücklich damit, dass ein neuer Discovery-Endpunkt die Kontrolle nicht mehr unbemerkt umgehen soll.

Auf /_mcp bedeutet das laut Dokumentation: Ist eine Liste abgeschaltet, verschwindet das passende prest.list_*-Werkzeug aus der Discovery-Antwort, und ein direkter Aufruf endet mit „unauthorized listing“. Ist irgendeine Liste abgeschaltet, zählt die Discovery-Antwort auch die Lesewerkzeuge pro Tabelle nicht mehr auf, weil deren Namen und Beschreibungen den Katalog verraten würden. Die allgemeinen Werkzeuge prest.describe_table und prest.select_table bleiben im Rahmen von [access] verfügbar, für Aufrufer, die ihr Ziel bereits kennen. Der Fix ergänzt Tests für genau diese Fälle und erweitert den Kommentar in der Beispielkonfiguration um den MCP-Endpunkt. Derselbe Commit enthält außerdem eine davon unabhängige Härtung der Parameterprüfung für Skripte, die nicht Gegenstand dieser Advisory ist.

Empfehlungen für Betreiber

Die folgenden Schritte sind unsere Empfehlungen, keine Vorgaben des Projekts.

Zeitleiste

Aufgeführt sind nur Daten, die sich aus öffentlichen Quellen belegen lassen.

Zwischen dem Anlegen der Advisory und der korrigierten Version lagen damit zwei Tage. Wann die CVE-Nummer zugeteilt wurde, ist öffentlich nicht dokumentiert und deshalb nicht aufgeführt.

Das Muster dahinter: Ein neuer MCP-Zugang umgeht eine bestehende Kontrolle

Hinter CVE-2026-110787 steht ein Muster, das mit dem Einzug von MCP häufiger werden dürfte. Ein bewährtes Produkt hat eine Zugriffskontrolle, die an bestimmten Routen hängt. Später kommt ein MCP-Endpunkt hinzu, der dieselben Daten über einen neuen Weg liefert. Die alte Kontrolle kennt den neuen Weg nicht, und niemand bemerkt es, weil die alten Routen weiterhin korrekt ablehnen. Für den Betreiber sieht die Einstellung wirksam aus.

In unserer Erläuterung der OWASP MCP Top 10 entspricht das der Klasse 8, Autorisierung, die über die Protokollfläche ungleich angewandt wird, mit einem Einschlag von Klasse 4, einer Kontrolle, die mehr verspricht, als sie abdeckt. Für Entwickler, die einer bestehenden Anwendung einen MCP-Zugang geben, lassen sich daraus vier Regeln ableiten:

• Die Kontrolle an die Funktion binden, nicht an den Pfad. Eine Prüfung, die an URL-Präfixen hängt, erfasst nur die Wege, die es bei ihrem Bau gab. Eine zentrale Prüffunktion, die jede Stelle mit Katalogdaten aufrufen muss, macht auch neue Wege prüfbar. In diese Richtung geht der pREST-Fix.
• Neue Oberfläche, neue Inventur. Wer einen MCP-Endpunkt ergänzt, listet vorher jede bestehende Einstellung auf, die Daten oder Metadaten einschränkt, und prüft sie für den neuen Weg einzeln.
• Beschreibungen sind Ausgaben. Werkzeugnamen und Werkzeugbeschreibungen in einer Discovery-Antwort können genau die Information tragen, die eine Kontrolle verbergen soll.
• Den Negativfall auf jeder Oberfläche testen. Ein Test „Liste abgeschaltet, REST und MCP müssen beide ablehnen“ fängt diese Klasse dauerhaft ab. Der Fix ergänzt solche Tests.

Für Betreiber gilt die Kehrseite: Ein MCP-Endpunkt in einer bestehenden Anwendung ist eine zusätzliche Schnittstelle zu Ihren Daten. Prüfen Sie, ob alle Einstellungen, auf die Sie sich verlassen, dort ebenfalls greifen. Weitere dokumentierte Funde dieser Art finden Sie auf unserer Seite Forschung.

Dank an die Maintainer von pREST

Wir danken den Maintainern von pREST für die schnelle und sachliche Zusammenarbeit in der koordinierten Offenlegung. Die Meldung lief vertraulich als Security-Advisory im Repository. Zwei Tage nach dem Anlegen der Advisory waren Fix, Tests, angepasste Dokumentation und Release 2.4.1 veröffentlicht, die Advisory nennt CyberSec42 als Melder. Die Korrektur behebt nicht nur den gemeldeten Weg, sondern bündelt [expose] in einer zentralen Definition, auf die sich auch künftige Discovery-Endpunkte stützen können.

Zum Vorgehen: Wir haben ausschließlich den öffentlichen Quellcode des Projekts geprüft. Laut Advisory wurde keine laufende pREST-Instanz, keine Datenbank und kein fremdes System kontaktiert, alle Beispielwerte in der Meldung sind erfunden, und auf GitHub wurden keine Issues, Pull Requests, Kommentare oder Branches angelegt oder verändert.

Häufige Fragen

Weiterlesen

• Forschung: unsere öffentlich dokumentierten Funde
• Die OWASP MCP Top 10, praktisch erklärt
• MCP-Server absichern: der praktische Leitfaden
• Leistung: KI-Pentest & MCP-Sicherheit

Quellen

• GitHub Security Advisory: GHSA-x62p-38px-pp73 (prest/prest)
• GitHub: pREST Release v2.4.1
• GitHub: pREST Pull Request #1016
• GitHub: Änderungen zwischen v2.4.0 und v2.4.1
• GitHub: pREST Release v2.1.0 (MCP über HTTP)
• pREST-Dokumentation: Configuring pREST (Expose Data)
• pREST-Dokumentation: MCP over HTTP
• MITRE: CWE-284
• FIRST: CVSS v3.1 Specification