--- service: "Publicasta" schema_version: "1.0" article_id: 572 title: "AWS behebt Umgehungen des Lesemodus in Datenbank-MCP-Servern: Was Betreiber jetzt prüfen müssen" language: "de" default_language: "en" canonical_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=de" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=de" api_url: "https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=de" channel_url: "https://publicasta.com/api/public/v1/channels/it_today_news" channel_articles: "https://publicasta.com/api/public/v1/channels/it_today_news/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-10T07:01:39+00:00" updated_at: "2026-09-10T07:01:39+00:00" translations: - language: "ar" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ar" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=ar" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=ar" - language: "de" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=de" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=de" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=de" - language: "en" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=en" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=en" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=en" - language: "es" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=es" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=es" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=es" - language: "fr" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=fr" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=fr" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=pl" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=pl" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ru" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=ru" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=zh" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=zh" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=zh" --- # AWS behebt Umgehungen des Lesemodus in Datenbank-MCP-Servern: Was Betreiber jetzt prüfen müssen > Zwei AWS-Sicherheitsbulletins zeigen ein wiederkehrendes Problem bei MCP-Tools mit Datenbankzugriff: Ein Textfilter ist keine Autorisierungsgrenze. Betroffen sind selbst betriebene PostgreSQL- und MySQL-Server von AWS Labs. Zwei AWS-Sicherheitsbulletins vom 9. September 2026 machen ein Problem konkret, das sich bislang leicht abstrakt beschreiben ließ: Ein KI-Tool, das eine Produktionsdatenbank abfragen kann, darf eine Zeichenkettenprüfung nicht als letzte Schutzlinie behandeln. Die Meldungen betreffen zwei quelloffene, selbst gehostete Model-Context-Protocol-Server von AWS Labs – einen für PostgreSQL und einen für MySQL. Beide verfügen über einen Lesemodus, der verhindern soll, dass ein Assistent SQL-Anweisungen mit Änderungen ausführt. Letztlich entscheidet jedoch weiterhin das Datenbankkonto darüber, was möglich ist. ![Abstrakte Illustration eines KI-Netzwerks und einer Datenbank, getrennt durch ein Warnsymbol, das die Grenzen von Nur-Lese-Textfiltern darstellt.](https://publicasta.com/storage/projects/17/pages/572/2026/09/dda7b4d7-2f7d-4716-88da-cc06ee10f526.webp) Das PostgreSQL-Problem ist das schwerwiegendere der beiden. AWS führt dafür [CVE-2026-87911](https://aws.amazon.com/security/security-bulletins/2026-104-aws/) an. Eine Schwachstelle kann unter einer bestimmten Kombination aus Paketversion, Verbindungsart, Datenbankberechtigungen und Benutzerinteraktion die Ausführung von Betriebssystembefehlen ermöglichen. Die behobene Version ist 1.1.7. Die MySQL-Meldung, [CVE-2026-85788](https://aws.amazon.com/security/security-bulletins/2026-103-aws/), beschreibt einen anderen Fehler in der Lesemodusprüfung: Unter bestimmten Bedingungen konnten SQL-Inline-Kommentare den Filter umgehen. Betroffen sind die Paketversionen 1.0.21 und älter; laut AWS ist das Problem in Version 1.0.23 behoben. Es handelt sich nicht um serverseitige Schwachstellen in Aurora, RDS oder einer anderen verwalteten AWS-Steuerungsebene. Die Probleme liegen in clientseitigen Paketen, die Kunden selbst installieren und betreiben. Diese Unterscheidung ist für die Reaktion auf einen Vorfall wichtig, macht die Meldungen aber nicht nebensächlich. Die Pakete verbinden einen KI-Assistenten mit Datenbanken, Zugangsdaten und – je nach Konfiguration – mit dem Host, auf dem der Server läuft. Ein kleiner Fehler beim Parsen kann dadurch an der Stelle zu einem Zugriffskontrollproblem werden, an der natürlichsprachliche Anfragen in Datenbankoperationen übersetzt werden. ## Was AWS offengelegt hat Die beiden Bulletins wurden gemeinsam veröffentlicht, beschreiben aber unterschiedliche technische Voraussetzungen und sollten getrennt bewertet werden. Würde man sie als eine allgemeine MCP-Schwachstelle behandeln, wäre die Reaktion weniger präzise. Für `awslabs.postgres-mcp-server` erklärt AWS, dass Versionen vor 1.1.7 eine Schwachstelle zur Einschleusung von Betriebssystembefehlen in der SQL-Validierungskomponente der Lesemodusdurchsetzung enthalten. Das Bulletin nennt eine speziell erstellte PostgreSQL-Anweisung `COPY ... TO PROGRAM` als relevante Datenbankfunktion. In einer verwundbaren Bereitstellung konnten Inhalte, die während der Interaktion eines authentifizierten Benutzers mit dem MCP-Server verarbeitet wurden, diesen Pfad erreichen, obwohl der Server im standardmäßigen Lesemodus lief. Das Bulletin sagt nicht, dass jede Installation aus der Ferne ausnutzbar ist. Es benennt ein engeres Bereitstellungsprofil: einen selbst verwalteten PostgreSQL-Server mit der Verbindungsart `PG_WIRE_PROTOCOL` und einer konfigurierten Datenbankrolle, die Superuser-Rechte oder die Rolle `pg_execute_server_program` besitzt. AWS beschreibt als mögliche Folge die Ausführung von Betriebssystembefehlen auf dem Host des selbst verwalteten PostgreSQL-Servers. Das Wort „möglich“ ist hier entscheidend. Die Empfehlung beschreibt eine gefährliche Schwachstelle und die Bedingungen, unter denen sie relevant wird; sie belegt nicht, dass Kunden angegriffen wurden. Die PostgreSQL-Dokumentation erklärt, warum die Berechtigungsbedingung den Schweregrad verändert. Ein `PROGRAM`-Befehl wird vom Datenbankserver und nicht vom Client ausgeführt. PostgreSQL beschränkt diese Fähigkeit auf Superuser oder Benutzer, denen die Serverprogrammrolle gewährt wurde. Die Datenbankberechtigung ist also bereits ihrem Zweck nach weitreichend. Die MCP-Schwachstelle ist relevant, weil Eingaben eine Grenze überschreiten können, die der Lesemodus des Pakets eigentlich durchsetzen sollte. Für `awslabs.mysql-mcp-server` sagt AWS, dass Versionen bis einschließlich 1.0.21 unter bestimmten Bedingungen eine Anweisung ausführen können, obwohl die Lesemodusprüfung sie hätte blockieren sollen. Dafür konnten SQL-Inline-Kommentare eingesetzt werden. Das Bulletin beschreibt nicht denselben Pfad zur Betriebssystembefehlsausführung wie die PostgreSQL-Meldung. Es stellt fest, dass das Paket selbst gehostet wird und dass die Schwachstelle weder die Vertraulichkeit noch die Integrität eines AWS-Dienstes beeinträchtigt. Das praktische Risiko besteht darin, dass ein Datenbankkonto mit weitergehenden Rechten einen Schreibvorgang ausführen kann, den die Prüfung auf Anwendungsebene abzulehnen versucht hatte. Die behobenen Versionen sind die ersten operativen Fakten, die festgehalten werden sollten: PostgreSQL MCP Server 1.1.7 oder neuer und MySQL MCP Server 1.0.23 oder neuer. Ein Upgrade des einen Pakets behebt nicht automatisch das andere. Es handelt sich um getrennte Distributionen mit eigenen Versionslinien, und in einer Flotte können beide vorkommen. ## Warum „read-only“ für Verwirrung sorgt Viele Datenbanktools verwenden „read-only“, als wäre es eine einzige Eigenschaft. Das ist es nicht. Hinter diesem Begriff verbergen sich mindestens drei verschiedene Kontrollen. Die erste ist ein Parser oder Filter innerhalb der Anwendung. Er untersucht SQL-Text und weist Tokens zurück, die mit Schreibvorgängen, Sitzungsänderungen oder anderen sensiblen Operationen verbunden sind. Das ist schnell und für Rückmeldungen an Benutzer nützlich. Ein Filter kann gewöhnliche Fehler verhindern, etwa wenn ein Assistent ein `UPDATE` erzeugt, obwohl der Benutzer einen Bericht angefordert hat. Die zweite Kontrolle ist der Modus der Datenbanksitzung oder Transaktion. PostgreSQL und MySQL bieten jeweils Mechanismen, mit denen sich die Aktionen einer Sitzung begrenzen lassen. Das genaue Verhalten und mögliche Ausnahmen hängen jedoch von der Engine, der Verbindungsart und dem Konto ab. Eine Einstellung auf Sitzungsebene kann eine zusätzliche Schicht bilden, ersetzt aber weder Kontoberechtigungen noch eine Prüfung anhand der konkreten Arbeitslast. Die dritte Kontrolle ist die Identität der Datenbank selbst: die Rolle oder der Benutzer, der sich am Server authentifiziert. Diese Identität verfügt über Grants, Eigentumsrechte, Rollenzugehörigkeiten, Zugriff auf gespeicherte Prozeduren und möglicherweise besondere Serverfähigkeiten. Sie ist die dauerhafte Grenze, weil die Datenbank sie auswertet, nachdem die Anfrage den Client, den MCP-Server, den SQL-Parser und alle dazwischengeschalteten Richtlinien passiert hat. Die aktuelle README des PostgreSQL-Servers von AWS weist ausdrücklich darauf hin, dass die Durchsetzung des Lesemodus nur eine Best-Effort-Sicherheitsmaßnahme und keine Sicherheitsgrenze ist. Empfohlen wird eine eigene Datenbankrolle; von Superuser, `rds_superuser` und Cluster-Master-Benutzer wird abgeraten. Die MySQL-README formuliert denselben Grundsatz: Die SQL-Textprüfung ist Defense in Depth, während die konfigurierte Datenbankrolle die tatsächliche Grenze bildet. Die Offenlegungen machen diese Dokumentation praktisch relevant und nicht nur theoretisch. Textfilter arbeiten mit der Darstellung, die sie erkennen. SQL kennt Kommentare, in Anführungszeichen gesetzte Bezeichner, bedingte Syntax, gespeicherte Routinen, versionsabhängige Funktionen, mehrere Anweisungen und Parserverhalten, das sich im Laufe der Zeit ändern kann. Ein LLM bringt eine weitere Variationsquelle hinzu: Es kann ungewöhnliche, aber syntaktisch gültige Eingaben erzeugen und durch Inhalte beeinflusst werden, die aus einer Datenbank oder einem anderen Tool zurückkommen. Von einem regulären Ausdruck lässt sich nicht erwarten, dass er all diese Wechselwirkungen vollständig abbildet. Ein sicheres Design stellt deshalb zwei verschiedene Fragen. „Wird der MCP-Server diese Anfrage ablehnen?“ hilft, versehentliche Schreibvorgänge zu reduzieren. „Was kann das Datenbankkonto tun, wenn der Server sie akzeptiert?“ ist die Frage, die den möglichen Schaden begrenzt. Die zweite Antwort muss auch dann sicher bleiben, wenn die erste Kontrolle umgangen, falsch konfiguriert, veraltet oder schlicht unvollständig ist. ## Wer die Prüfung dringend vornehmen sollte Die PostgreSQL-Empfehlung ist vor allem für Organisationen relevant, die das AWS-Labs-Paket vor Version 1.1.7 installiert haben und über das Wire-Protokoll eine selbst verwaltete PostgreSQL-Bereitstellung anbinden. Die Datenbankrolle verdient sofortige Aufmerksamkeit, wenn sie Superuser ist oder `pg_execute_server_program` besitzt. Eine Bereitstellung mit Aurora oder einem anderen verwalteten Profil entspricht möglicherweise nicht dem ausdrücklich betroffenen Profil. Trotzdem sollte das Paket aktualisiert werden, weil Paketversionen Teil der Software-Lieferkette sind und die Sicherheitshinweise des Servers über eine einzelne Ausnutzungsbedingung hinaus gelten. Die MySQL-Meldung betrifft Installationen mit Version 1.0.21 oder älter. Da das Paket häufig über einen Versionsbereich oder eine dynamische Referenz auf `latest` gestartet wird, sollten Teams aus einer funktionierenden Konfiguration nicht ableiten, welche Version tatsächlich läuft. Ermitteln Sie die installierte Paketversion aus der realen Client-Umgebung, dem Container-Image, der Lockdatei oder dem Deployment-Artefakt. Halten Sie das Ergebnis fest, statt sich auf einen Paketnamen in einer Konfigurationsdatei zu verlassen. Außerdem sollte geprüft werden, wie Zugangsdaten ausgewählt werden. Die Dokumentation von AWS Labs beschreibt Verbindungen, bei denen AWS-Zugangsdaten Datenbankressourcen ermitteln und Secrets-Manager-Zugangsdaten zur Authentifizierung an der Datenbank verwendet werden. Ein MCP-Server mit Datenbankzugriff kann daher über zwei Berechtigungsebenen verfügen: AWS-IAM-Berechtigungen und Datenbankberechtigungen. Eine restriktive IAM-Rolle macht einen Datenbanklogin nicht automatisch schreibgeschützt. Umgekehrt verhindert eine schreibgeschützte Datenbankrolle nicht automatisch, dass der MCP-Server sensible AWS-Metadaten oder lokale Dateien liest, wenn die umgebende Konfiguration diese Fähigkeiten gewährt. Das Risiko steigt, wenn der Server auf einem Entwicklerarbeitsplatz läuft, auf dem sich Quellcode, Cloud-Zugangsdaten, SSH-Material, Build-Artefakte oder Browsersitzungen befinden. Es steigt ebenfalls, wenn der MCP-Server über ein Netzwerk erreichbar ist, von mehreren Benutzern gemeinsam verwendet wird oder mit einem weitreichenden Administratorkonto gestartet wird. Die Dokumentation des AWS API MCP Server warnt – obwohl sie ein verwandtes Paket betrifft –, dass sein lokales STDIO-Design von einem einzelnen Benutzer mit direktem Hostzugriff ausgeht. Sie erklärt außerdem, dass IAM die primäre Kontrolle bleibt und dass Leseklassifikationen nicht garantieren, dass eine Befehlsausgabe harmlos ist. Diese architektonischen Warnungen sind auch für Datenbank-MCP-Bereitstellungen nützlich. ## Die erste Reaktion sollte Bestandsaufnahme sein Wer auf diese Bulletins reagiert, muss nicht mit dem Nachweis beginnen, dass eine Ausnutzung möglich war. Das erste Ziel ist festzustellen, ob der verwundbare Code und die nötigen Berechtigungsbedingungen vorhanden sind. Eine kurze Bestandsaufnahme beantwortet die wichtigsten Fragen. - Erfassen Sie jede Installation von `awslabs.postgres-mcp-server` und `awslabs.mysql-mcp-server`, einschließlich lokaler Entwicklerkonfigurationen, Container, CI-Runner, gemeinsam genutzter Jump-Hosts und paketierter IDE-Umgebungen. - Notieren Sie für jede Installation die genaue Version, Startmethode, Verbindungsart, Datenbank-Engine und das Profil des Datenbankendpunkts. - Ordnen Sie den von jedem Server verwendeten Datenbankbenutzer beziehungsweise die Rolle den jeweiligen Grants und Mitgliedschaften zu. Suchen Sie gezielt nach PostgreSQL-Superuserstatus, `pg_execute_server_program`, administrativen MySQL-Berechtigungen, weitreichenden Schemazugriffen, der Ausführung gespeicherter Prozeduren und dem Eigentum an Produktionsobjekten. - Ermitteln Sie, ob der Server nur lokal oder über ein Netzwerk erreichbar ist und ob mehrere Personen oder Mandanten denselben Prozess aufrufen können. - Prüfen Sie, ob der Server in die Datenbank schreiben, lokale Dateien lesen, Cloud-APIs aufrufen oder Geheimnisse in Tool-Ausgaben zurückgeben kann. - Sichern Sie relevante Paketmanifeste, Container-Digests, Konfigurationshistorie, Authentifizierungsprotokolle, Datenbank-Auditaufzeichnungen und MCP-Client-Logs, bevor Sie die Umgebung verändern. Ziel ist ein belastbares Faktenbild. „Wir verwenden einen KI-Assistenten“ reicht für eine Bewertung nicht aus. Ein selbst verwalteter PostgreSQL-Server mit einer Rolle für Berichtsabfragen und minimalen Rechten ist etwas anderes als ein Entwicklerlaptop, der mit einem Cluster-Master-Konto auf eine Produktionsdatenbank zugreift. Beide können denselben Paketnamen verwenden. ## Aktualisieren und Berechtigungen reduzieren Das unmittelbare Mittel zur Behebung ist das Upgrade auf die vom Anbieter korrigierten Versionen: PostgreSQL MCP Server 1.1.7 oder neuer und MySQL MCP Server 1.0.23 oder neuer. Fixieren Sie die Version in dem Mechanismus, der den Server tatsächlich startet. Verwendet eine Konfiguration `@latest`, einen weiten Paketbereich oder ein nicht festgelegtes Container-Tag, kann das nächste Update zwar sicherer sein; der aktuelle Zustand bleibt aber schwer reproduzierbar und zu auditieren. Nutzen Sie eine Lockdatei, einen unveränderlichen Image-Digest oder einen vergleichbaren kontrollierten Freigabemechanismus. Nach dem Upgrade sollten die Datenbankberechtigungen angepasst werden, falls sie über den eigentlichen Zweck hinausgehen. Für einen Berichtsworkflow sollte eine eigene Rolle im Allgemeinen nur Zugriff auf die benötigte Datenbank, Schemas, Tabellen, Views und eng ausgewählte Routinen haben. Sowohl die PostgreSQL-Dokumentation als auch die README von AWS Labs raten für diese Art Integration von Superusern und Serverprogramm-Berechtigungen ab. Eine Rolle, die nur freigegebene Bericht-Views lesen muss, sollte keine Rolle erben, mit der sich der Cluster verwalten oder Programme auf dem Datenbankhost ausführen lassen. Für MySQL gilt dasselbe Prinzip. Die README von AWS Labs empfiehlt ein eigenes Konto mit ausschließlich den erforderlichen Grants, etwa `SELECT` auf der relevanten Datenbank und `EXECUTE` nur für ausdrücklich genehmigte Prozeduren. Sie erklärt auch, dass der serverseitige Filter gängige verändernde Anweisungen erkennen soll, aber keine Garantie gegen jede grammatikalische Sonderform oder künftige SQL-Funktion sein kann. Der verlässliche Fehlerfall ist ein Datenbankfehler wegen fehlender Berechtigung – nicht die selbstsichere Meldung eines Assistenten, ein Schreibvorgang sei blockiert worden. Versuchen Sie nicht, das Problem durch eine noch umfangreichere Prompt-Regel zu beheben. Prompt-Anweisungen können das Verhalten verbessern, sind aber keine Zugriffskontrolle. Steuerdateien, Systemnachrichten, Freigabelisten und menschliche Bestätigungsdialoge haben in einem mehrschichtigen Design ihren Wert; keine dieser Maßnahmen sollte die einzige Barriere zum Schutz von Produktionsdaten sein. Ein Benutzer oder ein eingeschleustes Dokument kann den an das Modell gesendeten Text beeinflussen, und ein Modell kann eine Anfrage erzeugen, die der Autor des Prompts nicht bedacht hat. Das Konto, das die Anfrage ausführt, muss den vorgesehenen Bereich trotzdem nicht überschreiten können. ## Die AWS-Berechtigungsebene getrennt prüfen Manche Teams konzentrieren sich auf den SQL-Filter und übersehen die AWS-Berechtigungen, die der MCP-Prozess verwendet. Die PostgreSQL-README erklärt, dass der Server ein AWS-Profil nutzen kann, um Cluster oder Instanzen zu ermitteln, und für den Pfad über die RDS Data API möglicherweise Berechtigungen zum Ausführen von Anweisungen benötigt. In den dokumentierten Konfigurationen verwendet er außerdem Secrets Manager, um Datenbankzugangsdaten abzurufen. Das sind getrennte Entscheidungen von den Grants des Datenbankbenutzers. Verwenden Sie für den Prozess eine speziell dafür vorgesehene IAM-Rolle oder ein entsprechendes Profil. Begrenzen Sie den Ressourcenzugriff, sofern der AWS-Dienst dies unterstützt, und hängen Sie keine Administratorrichtlinien an, nur weil der Assistent möglicherweise Infrastruktur untersuchen soll. Die IAM-Empfehlungen von AWS setzen auf geringstmögliche Berechtigungen, nach Möglichkeit temporäre Zugangsdaten für Workloads, eine regelmäßige Prüfung nicht genutzter Rechte und IAM Access Analyzer zur Verfeinerung von Richtlinien anhand beobachteter Aktivitäten. Beachten Sie, dass „read-only“ auf der AWS-API-Ebene nicht dasselbe bedeutet wie „sichere Ausgabe“. Manche Leseoperationen können Konfigurationen, Kennungen, Richtliniendokumente oder andere sensible Informationen zurückgeben. Die Dokumentation des AWS API MCP Server weist ausdrücklich darauf hin. Ein Datenbankassistent, der Cloud-Ermittlung, Geheimnisabruf, Datenbankabfragen und lokale Dateioperationen kombinieren kann, besitzt eine deutlich größere effektive Autorität, als die Bezeichnung „SQL read-only“ vermuten lässt. Trennen Sie Funktionen, wo immer es möglich ist. Ein Tool, das Fragen zu freigegebenen Daten beantwortet, benötigt nicht zwangsläufig die Berechtigung, Cluster zu erstellen, Netzwerkkontrollen zu verändern, beliebige Geheimnisse abzurufen oder Dateien zu schreiben. Benötigt ein Workflow solche Fähigkeiten, sollten sie hinter einem separat genehmigten Tool und einer eigenen Identität liegen, statt den allgemeinen Berichtsprozess zu erweitern. ## Die Nutzung verwundbarer Versionen überprüfen Die Empfehlungen belegen nicht, dass die Fehler tatsächlich ausgenutzt wurden. Eine öffentliche Diskussion über eine CVE ist kein Nachweis für einen Vorfall, und das Vorhandensein eines verwundbaren Pakets beweist nicht, dass ein Angreifer es erreicht hat. Eine Protokollprüfung ist trotzdem sinnvoll, weil der verwundbare Pfad benutzergesteuerte Inhalte mit einer Datenbankausführungsoberfläche verbindet. Prüfen Sie bei PostgreSQL Datenbankprotokolle und Auditaufzeichnungen auf eine ungewöhnliche Nutzung serverseitiger Datei- oder Programmfunktionen, unerwartete Rollenänderungen, die Erstellung unbekannter Funktionen, Änderungen an der Authentifizierungskonfiguration und Aktivitäten des MCP-Dienstkontos außerhalb seines normalen Abfragemusters. Untersuchen Sie die Telemetrie des Datenbankhosts auf Prozesse, Dateien, Netzwerkverbindungen oder Persistenzmechanismen, die sich nicht durch die Datenbankarbeitslast erklären lassen. Die Prüfung sollte der defensiven Erkennung dienen; ein Artikel oder ein Incident-Ticket sollte nicht zu einer Anleitung für die erneute Ausführung von Befehlen werden. Prüfen Sie bei MySQL Anweisungen, die eigentlich blockiert werden sollten, aber in Auditprotokollen erscheinen, unerwartete Änderungen an Produktionstabellen, die Nutzung administrativer oder dateibezogener Berechtigungen sowie Verbindungen des MCP-Kontos von ungewöhnlichen Clients oder zu ungewöhnlichen Zeiten. Vergleichen Sie beobachtete Anweisungen mit den natürlichsprachlichen Anfragen, aus denen sie entstanden sind, sofern diese Aufzeichnungen vorliegen. Eine Abweichung kann auf Prompt-Injection, einen zu weit gefassten Toolvertrag, ein Parserproblem oder einen gewöhnlichen Modellfehler hindeuten. CloudTrail kann bei der AWS-Seite der Untersuchung helfen, ersetzt aber weder Datenbank- noch Hosttelemetrie. Suchen Sie nach unerwarteten Secrets-Manager-Lesezugriffen, RDS- oder Cluster-Ermittlungen außerhalb des normalen Workflows, Änderungen an IAM oder Sicherheitsgruppen sowie Zugriffen von Identitäten, die dem MCP-Prozess zugeordnet sind. Bringen Sie Zeitstempel aus MCP-Client, Datenbank, Betriebssystem und Cloud-Protokollen zusammen. Wenn Hinweise auf unbefugten Zugriff vorliegen, folgen Sie dem Incident-Response-Prozess der Organisation: Isolieren Sie den betroffenen Prozess, rotieren oder widerrufen Sie Zugangsdaten nach Bedarf, bewahren Sie Beweismittel auf und bewerten Sie die Integrität von Datenbank und Host. Ein Upgrade allein ist keine vollständige Reaktion auf einen Vorfall, wenn ein privilegiertes Zugangskonto verwendet worden sein könnte. ## Was sich für das MCP-Bereitstellungsdesign ändert Die unmittelbaren Maßnahmen sind Paketaktualisierungen. Die weitergehende Lehre betrifft jedoch die Position einer KI-Integration in der Architektur. Ein MCP-Server, der natürlichsprachliche Eingaben in SQL übersetzt, ist nicht bloß ein praktischer Adapter. Er ist ein Interpreter zwischen Mensch, Modell, Tool-Protokoll und einem zustandsbehafteten System. Jede dieser Ebenen kann die Anfrage verändern oder mit zusätzlicher Bedeutung versehen. Deshalb braucht es Kontrollen, die auch bei unerwartetem Modellverhalten verständlich und wirksam bleiben. Eine sinnvolle Bereitstellung trennt schreibgeschützte Analysen vom operativen Datenbankzugriff. Sie verwendet eine eigens für die Integration eingerichtete Datenbankrolle, begrenzt diese auf freigegebene Objekte und hält Schreibvorgänge in der Produktion in einem Workflow mit einer getrennten Identität und einem ausdrücklichen Änderungsprozess. Wenn das Produkt für den Betrieb mit lokalem STDIO und einem einzelnen Benutzer ausgelegt ist, sollte der MCP-Server lokal oder anderweitig isoliert bleiben. Host, ausgehender Netzwerkverkehr, Geheimnisse und Dateisystemzugriff des Prozesses müssen begrenzt werden. Auch Versionen und Konfigurationen sollten beobachtbar sein. Das Team muss beantworten können, welches MCP-Paket mit welchen Argumenten, unter welcher Identität und gegen welche Datenbank lief und welcher Tool-Aufruf die jeweilige Abfrage erzeugt hat. Fehlen diese Informationen, führt eine Schwachstellenmeldung schnell zu einer langen Diskussion darüber, was möglicherweise installiert ist, statt zu einer raschen Entscheidung über die Behebung. Tests sollten den tatsächlichen Sicherheitsvertrag abdecken und nicht nur eine erfolgreiche Standardabfrage. Prüfen Sie, dass gewöhnliche Leseanfragen funktionieren, nicht autorisierte Schreibvorgänge an der Datenbank scheitern, der Prozess keine privilegierten Serverfunktionen verwenden kann, Fehler sicher abbrechen und eine fehlerhafte oder unerwartete Eingabe eine Richtlinie nicht stillschweigend deaktiviert. Testen Sie das Verhalten nach Abhängigkeits- und Datenbank-Engine-Upgrades. Ziel ist nicht der Nachweis, dass ein Filter jede mögliche SQL-Schreibweise erkennt. Ziel ist der Nachweis, dass eine nicht vertrauenswürdige Anfrage das erlaubte Ergebnis der Identität nicht überschreiten kann. ## Das praktische Fazit Die AWS-Bulletins vom 9. September erinnern daran, dass „read-only“ eine Designaussage ist, die an mehr als einer Stelle durchgesetzt werden muss. Das PostgreSQL-Problem erfordert besondere Aufmerksamkeit, wenn ein älteres Paket über das Wire-Protokoll mit einem selbst verwalteten Server verbunden ist und dort eine Superuser- oder `pg_execute_server_program`-Rolle verwendet. Das MySQL-Problem betrifft ältere Paketversionen und zeigt, dass SQL-Syntax, die für einen Textfilter harmlos aussieht, trotzdem relevant sein kann. Aktualisieren Sie beide Pakete, sofern sie vorhanden sind. Erfassen Sie die tatsächlich gestarteten Versionen und Verbindungsarten. Ersetzen Sie weitreichende Datenbankkonten durch eng begrenzte Rollen. Prüfen Sie IAM-Profil, Geheimniszugriff, Hostberechtigungen und Netzwerkerreichbarkeit rund um den MCP-Prozess. Nutzen Sie anschließend Datenbank-, Host- und Cloud-Protokolle, um zu entscheiden, ob die betroffenen Installationen lediglich verwundbar waren oder auch missbraucht wurden. Der dauerhafte Rat ist einfach, auch wenn seine Umsetzung Arbeit erfordert: Die Datenbank muss die Datenbankgrenze durchsetzen. Modellanweisungen und SQL-Filter sind hilfreiche Schichten um diese Grenze herum, aber kein Ersatz für sie. ## Quellen - [CVE-2026-87911 – Umgehung der Lesemodusdurchsetzung mit möglicher Ausführung von Betriebssystembefehlen im SQL-Validierungsbestandteil von Amazon awslabs postgres-mcp-server](https://aws.amazon.com/security/security-bulletins/2026-104-aws/) – Amazon Web Services, 9. September 2026. - [CVE-2026-85788 – Problem mit awslabs mysql-mcp-server](https://aws.amazon.com/security/security-bulletins/2026-103-aws/) – Amazon Web Services, 10. September 2026. - [AWS Labs postgres MCP Server: README und Sicherheitsmodell](https://github.com/awslabs/mcp/blob/main/src/postgres-mcp-server/README.md) – AWS Labs, 10. September 2026. - [AWS Labs mysql MCP Server: README und Sicherheitsmodell](https://github.com/awslabs/mcp/blob/main/src/mysql-mcp-server/README.md) – AWS Labs, 10. September 2026. - [PostgreSQL-Dokumentation zu COPY](https://www.postgresql.org/docs/15/sql-copy.html) – PostgreSQL Global Development Group, 20. August 2026. - [Sicherheits-Best-Practices für IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) – Amazon Web Services, 8. September 2026. - [AWS Identity and Access Management User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/iam-ug.pdf) – Amazon Web Services, 15. Januar 2026. - [aws-api-mcp-server: Migration zum AWS MCP Server](https://github.com/awslabs/mcp/issues/4115) – AWS Labs, 10. Juli 2026.