Durch PostgreSQL CVE-2026-6460 kann jemand, der Datenbankobjekte erstellen darf, Code mit den Rechten des Betriebssystembenutzers ausführen, unter dem die Datenbank läuft. Die Korrektur ist in PostgreSQL 18.7, 17.12, 16.16, 15.20 und 14.25 enthalten. Für ein kleines SaaS-Team ist ein Detail entscheidend: Mit dem Serverupdate allein ist die Arbeit möglicherweise noch nicht erledigt. Laut PostgreSQL müssen für vollständigen Schutz auch die C-Erweiterungen neu kompiliert werden; einige benötigen Änderungen am Quellcode. Prüfen Sie die laufende Installation und ihre Erweiterungen, bevor Sie die Behebung abschließen. ([Sicherheitshinweis](https://www.postgresql.org/support/security/CVE-2026-6460/), [Versionshinweise](https://www.postgresql.org/docs/17/release-17-12.html).)

Ein Ingenieur aktualisiert das Datenbank-Image, die Anwendung verbindet sich wieder, und das Patch-Ticket scheint erledigt. Das ist ein guter Anfang. Eine Frage bleibt jedoch: Enthält das bereitgestellte System tatsächlich alle Teile der Korrektur?

Diese Version zeigt, warum die Frage nötig ist. Der Server prüft nun zusammengesetzte Werte, deren Datenlayout nicht mehr zu dem Typ passt, mit dem sie interpretiert werden. Native Erweiterungen sind an dieser Verarbeitung beteiligt. Ein erfolgreicher Neustart und die erwartete Versionsnummer belegen deshalb noch nicht, dass diese Erweiterungen korrekt neu kompiliert wurden.

Sammeln Sie genügend Nachweise, um festzuhalten, was aktualisiert wurde, was tatsächlich läuft und welche Fragen noch offen sind. Dafür müssen Sie aus einem Sicherheitsupdate innerhalb derselben Hauptversion keine unnötige Datenbankmigration machen.

## Klären Sie, welche Zugriffsrechte die Schwachstelle voraussetzt

Der Sicherheitshinweis setzt voraus, dass ein Angreifer Datenbankobjekte erstellen kann. Berücksichtigen Sie das bei der Bewertung Ihrer Angriffsfläche. Wer Datenbankobjekte anlegen darf, hat andere Zugriffsmöglichkeiten auf PostgreSQL als ein Kunde, der lediglich die Formulare Ihrer Anwendung nutzt.

Ermitteln Sie für Ihre Installation, wer sich mit der Datenbank verbinden und Objekte erstellen kann: Anwendungsrollen, Migrationsrollen, Entwickler, Automatisierung und gegebenenfalls Kunden mit direktem SQL-Zugriff. Beziehen Sie Berechtigungen ein, die über Rollenmitgliedschaften wirksam werden. Können weniger vertrauenswürdige Benutzer diese Möglichkeiten nutzen, muss die für die Patch-Planung zuständige Person davon wissen.

Diese Bestandsaufnahme ist noch keine vollständige Schutzmaßnahme. Gehen Sie nicht davon aus, dass das Sperren einer einzelnen SQL-Operation die Lücke schließt; PostgreSQL beschreibt mehrere Angriffswege über DDL. Umgekehrt beweist eine betroffene Serverversion allein nicht, dass ein nicht angemeldeter Besucher Ihre SaaS-Anwendung ausnutzen kann. Dafür müssen Sie den Weg vom Besucher zu den erforderlichen Datenbankrechten nachweisen. ([PostgreSQL-Sicherheitshinweis](https://www.postgresql.org/support/security/CVE-2026-6460/).)

Beschreiben Sie auch die Auswirkungen präzise. Codeausführung mit den Rechten des PostgreSQL-Betriebssystembenutzers ist schwerwiegend. Ob daraus administrative Rechte auf dem Host, Zugriff auf Daten eines anderen Mandanten oder auf einen anderen Dienst entstehen, hängt von der jeweiligen Umgebung ab. Halten Sie solche weitergehenden Folgen ohne entsprechende Nachweise nicht als gesicherte Tatsachen in Ihrer Vorfallsdokumentation fest.

Für ein kleines Team genügt für diese Bewertung oft eine kurze Notiz: welche Datenbank, welche Rollen, wer das Update verantwortet und welche Zugriffswege noch geprüft werden. Wenn aus der Wartungsaufgabe eine Vorfallsbearbeitung wird, hilft ein [einseitiger Notfallplan für Sicherheitsvorfälle](/blog/solo-founder-incident-response-plan), die Zuständigkeiten klar zu halten.

## Wählen Sie die korrigierte Version für Ihren Versionszweig

Der PostgreSQL-Sicherheitshinweis nennt die folgenden ersten korrigierten Unterversionen, veröffentlicht am 12. November 2026:

| Ihr PostgreSQL-Versionszweig | Erste korrigierte PostgreSQL-Version |
| --- | --- |
| 18 | 18.7 |
| 17 | 17.12 |
| 16 | 16.16 |
| 15 | 15.20 |
| 14 | 14.25 |

Quelle: [Sicherheitshinweis zu CVE-2026-6460](https://www.postgresql.org/support/security/CVE-2026-6460/).

Beginnen Sie mit dem Update für Ihre derzeitige Hauptversion. PostgreSQL unterscheidet zwischen einem Update innerhalb einer Hauptversion und einem Wechsel der Hauptversion. Bei kleineren Updates bleibt das Datenspeicherformat erhalten. Üblicherweise wird der Server gestoppt, die Binärdateien werden aktualisiert und der Server wird neu gestartet. Für einen Hauptversionswechsel gilt ein eigenes Migrationsverfahren. Lesen Sie stets die Versionshinweise zu zusätzlichen Schritten und zu zwischenzeitlich übersprungenen Versionen. ([Versionsrichtlinie](https://www.postgresql.org/support/versioning/).)

Eine PostgreSQL-17-Installation auf 17.12 zu aktualisieren ist beispielsweise eine andere Aufgabe als der Wechsel auf PostgreSQL 18. Behandeln Sie den dringenden Patch und einen geplanten Hauptversionswechsel als getrennte Änderungen mit eigenen Abnahmekriterien.

Ein Anbieter eines verwalteten Dienstes oder eine Distribution kann die Korrektur zurückportieren und unter einer anderen Build-Kennung ausliefern. Fordern Sie dann einen Nachweis an, der den eingesetzten Build dieser CVE-Korrektur zuordnet. Eine Versionszeichenfolge, die von der korrigierten PostgreSQL-Version abweicht, ist Anlass zur Prüfung. Allein reicht sie weder aus, um den Dienst als gepatcht einzustufen, noch um ihn als verwundbar zu bewerten.

## Beziehen Sie native Erweiterungen in das Update ein

Die Anforderung an die Erweiterungen geht leicht verloren: Sie steht im Sicherheitshinweis, fehlt aber später in der Bereitstellungsaufgabe oder im Abschlusskommentar.

Die PostgreSQL-Versionshinweise verlangen für vollständigen Schutz eine Neukompilierung der C-Erweiterungen; bei einigen sind Änderungen am Quellcode nötig. Außerdem beschreiben sie den Serverparameter `composite_type_mismatch`, mit dem sich die neuen Prüfungen unter Sicherheitsrisiken deaktivieren lassen. Die Kompatibilität der Erweiterungen und die Schutzeinstellung gehören deshalb in die Patch-Dokumentation. ([Versionshinweise zu PostgreSQL 17.12](https://www.postgresql.org/docs/17/release-17-12.html).)

Fragen Sie vor der Bereitstellung beim Verantwortlichen für das Image, beim Paketlieferanten oder beim Datenbankanbieter nach, wie die Erweiterungs-Builds diese Änderung berücksichtigen. Kompiliert Ihr Team Erweiterungen selbst, legen Sie fest, wer die Kompatibilität prüft und den Ersatz-Build erstellt. Nehmen Sie nicht an, dass das neueste Serverpaket automatisch jede darin geladene native Komponente ersetzt.

Eine erste Bestandsaufnahme ist mit lesenden SQL-Abfragen möglich:

```sql
SELECT version();
SHOW server_version;
SELECT extname, extversion
FROM pg_extension
ORDER BY extname;
```

Führen Sie diese Abfragen am Datenbankendpunkt aus, den Sie prüfen möchten. PostgreSQL dokumentiert serverseitige Versionsinformationen unter [Systeminformationsfunktionen](https://www.postgresql.org/docs/17/functions-info.html). Die Version eines Clients auf Ihrem Laptop sagt dagegen nichts über die Version dieses Servers aus.

Die Liste der Erweiterungen hilft Ihnen, weitere Aufgaben zu erkennen. Ihre Versionsangaben beweisen nicht, dass die zugrunde liegenden nativen Binärdateien neu kompiliert wurden. Ergänzen Sie die Liste um einen Paket-, Image-, Build- oder Anbieternachweis, der die Anforderung an die Erweiterungen abdeckt. Hat jemand die neuen Prüfungen deaktiviert, um eine Erweiterung zum Laufen zu bringen, halten Sie diese noch ungeklärte Sicherheitsentscheidung ausdrücklich fest.

## Trennen Sie den Betrieb von der Nachweisführung Ihres Teams

Betreiben Sie PostgreSQL selbst, ist Ihr Team möglicherweise für das Serverartefakt, die Erweiterungen, den Neustart und die Anwendungstests zuständig. Bei einem verwalteten Dienst übernimmt der Anbieter womöglich den größten Teil dieser Arbeiten. Für die Nachweise muss trotzdem jemand auf Ihrer Seite verantwortlich sein.

Stellen Sie dem Anbieter eine Frage, die sich für Ihre konkrete Installation beantworten lässt: Enthält der aktuelle Build dieses Dienstes die Korrektur für CVE-2026-6460, und wie wurden seine nativen Erweiterungen berücksichtigt? Fragen Sie, ob Sie selbst Wartungsarbeiten ausführen müssen und ob der neue Schutz aktiv ist. Bewahren Sie die Antwort zusammen mit der Dienstkennung und dem Wartungsprotokoll auf.

Der [technische Bericht des Forschers](https://mehmetince.net/part-3-6-how-i-ended-up-turning-a-22-year-old-postgresql-type-confusion-primitive-into-rce-cve-2026-6460/) erklärt, warum auch verwaltete PostgreSQL-Dienste Teil der Untersuchung waren. Er belegt nicht den aktuellen Patch-Stand Ihres Anbieters oder Ihrer Instanz. Nutzen Sie ihn zur Einordnung; für den Abschluss benötigen Sie Nachweise zu Ihrer konkreten Installation.

Dasselbe gilt für Infrastruktur, die Ihr Team selbst betreibt. Eine geänderte Image-Referenz beschreibt zunächst die beabsichtigte Änderung. Ein Bereitstellungsprotokoll und eine Abfrage am laufenden Server helfen, das Ergebnis festzustellen. Wiederholen Sie die Prüfung für die relevanten Instanzen und Endpunkte. Eine erfolgreiche Verbindung allein belegt nicht den Zustand Ihrer gesamten Umgebung.

## Schließen Sie die Aufgabe mit einem kompakten Nachweis ab

Ein hilfreicher Abschlusskommentar macht das Ergebnis für andere Ingenieure nachvollziehbar, ohne dass sie die Bereitstellung aus Chat-Nachrichten rekonstruieren müssen.

| Frage zum Abschluss | Beizufügender Nachweis |
| --- | --- |
| Was haben wir aktualisiert? | Datenbankdienst oder Endpunkt, vorherige Version, Zielartefakt oder Anbieter-Build |
| Was läuft jetzt? | Ergebnis der serverseitigen Versionsabfrage und Protokoll der abgeschlossenen Bereitstellung oder Wartung |
| Wurden native Erweiterungen berücksichtigt? | Erweiterungsinventar sowie kompatible Neukompilierung oder Bestätigung des Anbieters |
| Ist der neue Schutz aktiv? | Konfigurationsprüfung einschließlich etwaiger Entscheidungen zu `composite_type_mismatch` |
| Funktioniert die Anwendung weiterhin? | Ergebnisse repräsentativer, zur Anwendung passender Prüfungen |
| Was bleibt offen? | Benannte zuständige Person und nächste Maßnahme für jeden offenen Punkt |

Richten Sie die Anwendungstests danach aus, was Ihr Produkt tatsächlich tut: Verbindungen herstellen, repräsentative Daten lesen und schreiben und wichtige Funktionen ausführen, die von Erweiterungen abhängen. Das sind Abnahmeprüfungen für Ihre Änderung. Sie beweisen nicht, dass sämtliche Sicherheitseigenschaften erfüllt sind.

Ist der Build-Stand einer Erweiterung unbekannt, lassen Sie diesen Punkt offen. Bestätigt der Anbieter eine Rückportierung, bewahren Sie die genaue Build-Referenz auf. Dasselbe Prinzip gilt beim [Prüfen nachgelagerter Behebungsmaßnahmen](/blog/revoked-certificates-downstream-remediation): Entscheidend sind sowohl die geänderte Komponente als auch die Systeme, die von ihr abhängen.

Wenn Sie die Schwachstelle in Kit erfassen, können Sie über den [Ablauf zur Sichtung von Meldungen](/docs/triaging-reports) Zuständigkeit, Korrespondenz und die menschliche Entscheidung über die Fix-Verifizierung zusammenhalten. Die Nachweise zum Patch, auf denen diese Entscheidung beruht, liefert Ihr Infrastrukturteam oder Ihr Anbieter.

## Behalten Sie weitere Aufgaben aus der Veröffentlichung im Blick

Die November-Veröffentlichung enthält weitere Korrekturen mit eigenen Wartungsanforderungen. Lesen Sie die Migrationshinweise für Ihren Versionszweig zu bedingten Indexreparaturen und Sicherungsmaßnahmen. Teams, die inkrementelle Sicherungen verwenden, empfiehlt PostgreSQL ausdrücklich, nach dem Update eine neue Vollsicherung zu erstellen und sie als Grundlage für spätere inkrementelle Sicherungen zu nutzen. Diese Folgeaufgaben bedeuten nicht, dass CVE-2026-6460 Ihre Indizes oder Sicherungen beschädigt hat. ([Veröffentlichungsankündigung](https://www.postgresql.org/about/news/postgresql-187-1712-1616-1520-1425-and-19-rc-2-released-3442/).)

Bei PostgreSQL 14 steht eine weitere Entscheidung an: 14.25 ist die letzte Veröffentlichung dieser Hauptversion; das Projekt hat ihr Supportende bekannt gegeben. Wenden Sie die verfügbare Korrektur an und planen Sie zugleich den Wechsel zu einer unterstützten Hauptversion. Benennen Sie dafür eine zuständige Person und einen Termin, statt diese Migration stillschweigend in den dringenden Patch einzubeziehen.

Am Ende Ihrer Patch-Dokumentation sollten die Nachweise klar benannt sein: der bereitgestellte Server-Build, der Stand der Neukompilierung der Erweiterungen, die Schutzkonfiguration und noch ausstehende Arbeiten. So kann der nächste Ingenieur das Ergebnis konkret prüfen, und Ihr Team kann nachvollziehbar begründen, warum es die Aufgabe abschließt.