Consulting Briefing — 02.05.2026

boddenberg.de — ohne Schönfärberei, mit Patch-Plan

SQL Server 2025 RTM GDR Security Update KB5084814

Executive Summary

Microsoft hat am 14. April 2026 still und leise das Sicherheitsupdate KB5084814 für SQL Server 2025 RTM veröffentlicht. Auf der großen Bühne stand mal wieder Patch Tuesday im Rampenlicht, im Maschinenraum hat sich der Datenbank-Kollege aber eine saftige Eskalations-Lücke eingefangen. Die GDR (General Distribution Release) hebt die Engine auf Build 17.0.1110.1 (Datei-Version 2025.170.1110.1), bringt alle bisher veröffentlichten Sicherheits-Fixes mit und schließt zwei neue Schwachstellen: CVE-2026-32176 und CVE-2026-32167. Beide laufen in der CVSS-Sprache als Elevation of Privilege, in der Praxis lautet die Übersetzung: ein freundlicher Reporting-Login wird zum sysadmin, weil die Linked-Server- und SQL-Agent-Pfade Parameter nicht ordentlich validieren. Auf Deutsch: der Hausmeister mit Lese-Schlüssel hatte plötzlich einen General-Schlüssel im Schlüsselbund.

Heißt für dich: Wer SQL Server 2025 produktiv betreibt — egal ob On-Prem-Cluster, Azure VM, Linux-Container oder die brave Express-Edition unter dem Schreibtisch im Steuerbüro — sollte die Patch-Pipeline jetzt anwerfen, statt sie auf den nächsten Cumulative Update zu vertagen. Der Patch ist kumulativ, schmerzarm und ohne Datenmigration einspielbar. Die Faulheits-Prämie liegt diesmal nicht beim Abwarten, sondern beim Patchen.

Worum geht es im Detail? Und wo kommen wir her?

Microsoft führt für den SQL Server zwei parallele Patch-Schienen: Cumulative Updates (CU) sammeln Bugfixes und kleinere Verbesserungen. GDRs sind die schmale Spur — schlanke Sicherheits-Updates, nichts weiter. Wer auf dem CU-Branch unterwegs ist, bekommt die Sicherheits-Fixes später mit dem nächsten CU. Wer auf dem RTM-/GDR-Branch sitzt, kann jetzt patchen, ohne sich neue Engine-Features oder Telemetrie-Änderungen einzufangen. Genau das ist KB5084814: GDR pur, kumulativ und ohne Bonus-Material.

Der inhaltliche Kern besteht aus zwei dokumentierten Bug-Fixes. Bug 5029979 sitzt in PolyBase und betrifft die Art, wie Linked-Server-Aufrufe Berechtigungen weiterreichen. Klingt harmlos, ist es aber nicht: ein Login mit minimalen Rechten kann unter bestimmten Voraussetzungen über einen Linked Server an Funktionen andocken, die sonst dem sysadmin vorbehalten wären. Bug 4999182 sitzt im SQL Agent und ist klassisches Lehrbuch-Material: ein parametrisierter Aufruf in einer System-Stored-Procedure lässt sich so manipulieren, dass eingeschleuster T-SQL-Code im Sicherheitskontext des Agent-Dienstes ausgeführt wird. CWE-89, also gute alte SQL Injection — in 2026 immer noch ein Top-Hit, wie Hosen mit weitem Bein.

Die spannende Pointe: Microsoft hat CVE-2026-32176 zunächst als Denial-of-Service kommuniziert — das stand auch in den ersten Mitteilungen so. Im Lauf der ersten 48 Stunden hat das MSRC die Klassifizierung aber gehoben. Ein DoS sieht sich auf dem Papier harmlos an, in Wahrheit hebt der Fix einen Eskalationspfad weg, der über linked queries an OPENROWSET, OPENDATASOURCE und Verbindungen zu Fremd-Instanzen reicht. Das ist Klassiker-Material in Migrationsprojekten und BI-Landschaften: Reporting-Logins, die irgendwann mal von „darf nur lesen“ auf „kann via Linked Server alles“ gewachsen sind, ohne dass es jemand gemerkt hat.

Erst recht aufmerken sollten alle, die mit SAP, Dynamics oder klassischen ERP-DBs arbeiten und parallel ein Data Warehouse betreiben. Der Linked-Server-Dschungel zwischen OLTP-Quelle, Staging und DWH ist genau das Biotop, in dem die Lücke ihre Eleganz entfaltet. In Nicht-OLTP-Systemen mit nur einem Login und ohne Linked Server bist du näher am „Patch in Ruhe“-Szenario — aber auch da gilt: kumulative Sicherheits-Updates schiebt man nicht auf die lange Bank. Lange Bänke sind in der IT der Vorhof zum Audit-Befund.

Abb. 1 — Eskalationspfad über Linked Server und SQL Agent.

Wer den Pfad nachzeichnet, sieht schnell: ein durchschnittliches BI-Konto mit Lese-Rechten in der Reporting-DB ist genug Boden. Über den Linked Server zur Master-Instanz wird ein präparierter Aufruf in eine System-Stored-Procedure abgesetzt. Die Engine fasst den Parameter falsch an, der eingeschleuste T-SQL-Schnipsel wird im höchsten Kontext ausgeführt — und schon ist aus dem Reporting-Login der freundliche neue sysadmin. Das Patch-Paket entkernt genau diesen Pfad: parametrisierte Behandlung in PolyBase, härteres Parsing im SQL Agent, Kontextprüfung in den betroffenen System-Stored-Procedures.

Was sind Chancen? Was sind Risiken?

Die Chance liegt diesmal nicht im neuen Feature, sondern im sauberen Schnitt. KB5084814 ist GDR — du bekommst die Sicherheits-Verbesserungen, ohne neue Engine-Eigenheiten auf dem Tisch zu haben. Für regulierte Branchen ist das Gold wert: die Bank-IT, die seit Wochen mit dem CISO um die Linked-Server-Architektur verhandelt, hat einen offiziellen Anlass, den Patch zu setzen, ohne dass die Fachseite gleich anfängt, über Performance-Regressionen zu klagen.

Zweite Chance, die gerne übersehen wird: Microsoft liefert eine GDR für alle Editionen — Express, Web, Standard, Enterprise, Developer, dazu Windows und Linux. Es gibt also keine Ausrede mehr für „die Express-Instanz im Backoffice ist zu klein zum Patchen“. Auch die in Vergessenheit geratenen SQL-Server-Pakete auf Buchhaltungs-PCs und Maschinen-Steuer-Servern bekommen das Update — vorausgesetzt, jemand erinnert sich an deren Existenz. Das ist erfahrungsgemäß der schwerste Schritt.

Die Risiken liegen in den üblichen Ecken. Erstens: Cluster und Always-On-Availability-Groups. Wer den Patch unkoordiniert in den primären Knoten schiebt, kann sich ein ungewolltes Failover einhandeln, samt Anwendungsfehlern auf der Frontseite. Zweitens: SSIS-Pakete, SSRS-Reports und Linked-Server-Konfigurationen, die bisher mit den unsauberen Parameter-Pfaden gelebt haben. Wenn dein Reporting-Stack genau da ansetzt, kannst du nach dem Patch Fehler sehen, die vorher Komfort waren. Drittens: Lizenz-Diskussionen. Auf einigen Express-Installationen liegt eine alte Engine-Version, die über den Patch erstmals zwangsweise auf 17.0.1110.1 hochgeht — und damit fällt manche Drittsoftware in ihren Inkompatibilitäts-Modus. Prüfen, nicht hoffen.

Und der Klassiker, der nie alt wird: Backups. Vor dem Patch ein vollständiges Backup, geprüfte Wiederherstellbarkeit, Rollback-Plan auf Papier. Wer in der Produktion patcht und den Restore nicht mindestens einmal testweise durchgespielt hat, hat eigentlich keine Backup-Strategie, sondern eine Backup-Hoffnung. Hoffnung ist im Maschinenraum keine Methode.

Abb. 2 — Empfohlene Patch-Pipeline: Lab, Test, Pilot, Produktion.

Praxisbeispiel aus einem Engagement der letzten zehn Tage: ein mittelständisches Logistik-Unternehmen, eine Hauptinstanz auf SQL Server 2025 in einer Azure VM, drei Linked Server zu Lager-, Buchhaltungs- und Reporting-DBs. Der ITler hatte den Patch direkt in der Produktion eingeplant — „ist ja nur ein Sicherheits-Update“. Wir haben ihn um eine Etage gebremst, eine Lab-VM aus dem letzten Backup gezogen, den Patch dort eingespielt, ein Reporting-Paket durchgejagt — und Erstaunliches festgestellt: ein lange übersehener Linked-Server-Eintrag wies auf eine stillgelegte Instanz, die der Patch beim Start überprüft hat. Ergebnis im Lab: Verzögerung beim Service-Start. Im echten Leben wäre das ein Failover gewesen, samt Anwender-Tickets. So etwas fängt der Lab-Schritt ab — oder eben nicht, wenn man ihn auslässt.

Abb. 3 — Risiko-Matrix: Eintrittswahrscheinlichkeit gegen Geschäftsfolge.

Was musst du jetzt schon vorbereiten?

Erstens: Inventar. Wer betreibt SQL Server 2025 überhaupt? Klingt banal, ist es aber nicht. In jeder zweiten Umgebung tauchen plötzlich noch zwei Express-Instanzen auf, die irgendein Fachverfahren mitschleppt. Die Patch-Strategie funktioniert nur, wenn dein CMDB-Eintrag mehr als ein hoffnungsvolles Lippenbekenntnis ist. Wenn du noch keine Inventarisierung hast: PowerShell mit Get-Service *MSSQL* und ein zentrales Sammelskript reichen für den Anfang.

Zweitens: Patch-Pipeline. Lab, Test, Pilot, Produktion — in genau dieser Reihenfolge. Wer noch keinen Lab-Schritt hat, hat in 2026 überhaupt keinen Patch-Prozess. Eine kleine Azure-VM mit Restore aus dem letzten Backup reicht. Dort wird KB5084814 zuerst eingespielt, anschließend werden die wichtigsten Workloads getestet: Reporting, ETL, SSIS, gegebenenfalls Replikation und Always-On-Failover. Gerade SSIS-Pakete reagieren manchmal sensibel auf veränderte Linked-Server-Sessions — lieber im Lab finden als in der Produktion.

Drittens: Berechtigungs-Review. Der Patch schließt die Türen, aber er räumt nicht die zugemüllten Schlüssel-Schubladen auf. Reporting-Logins mit Linked-Server-Rechten zu Master-Instanzen, alte Service-Accounts mit sysadmin aus Bequemlichkeit, vergessene OPENROWSET-Pfade in Stored Procedures. Eine ehrliche Stunde sp_helprolemember und sp_linkedservers zahlt sich an dieser Stelle aus.

Viertens: Monitoring. Vor dem Patch eine Performance-Baseline ziehen — wait stats, Plan Cache, CPU. Nach dem Patch 24 bis 48 Stunden vergleichen. Das Plan-Cache-Flush, das ein GDR mit sich bringt, kann kurz für höhere Latenzen sorgen, ist aber kein Drama. Drama ist nur, wenn dein Monitoring keine Vergleichswerte hat und du jeden Anstieg für einen Patch-Fehler hältst.

Fünftens: Kommunikation. Sag deinen Anwendern Bescheid, dass es ein Wartungsfenster gibt — und zwar bevor das Wartungsfenster da ist, nicht währenddessen. Kündige an, dass kurze SSIS- oder Reporting-Spitzen am Tag nach dem Patch normal sind. Wer Erwartungen vorab managt, fängt sich keine Tickets ein, die in Wahrheit Frage-Tickets sind.

Checkliste für die nächsten Tage

Inventar aller SQL-Server-2025-Instanzen erfassen (Express, Standard, Enterprise, Developer, Linux).

SHA256 88F80B69B269B44586A9F13C1F15D56BEDF9A15641408EC59D90175528603774 für das Paket prüfen.

Lab-Instanz aus aktuellem Prod-Backup aufsetzen, KB5084814 einspielen, Smoke-Test für SSIS, Linked Server, SQL Agent.

Linked-Server-Liste in jeder Instanz auditieren: sp_linkedservers, sp_helplinkedsrvlogin.

Reporting-, Service- und Integrations-Konten auf sysadmin-Bedarf prüfen, ggf. abrüsten.

Always-On-Cluster: Patch-Reihenfolge planen (Secondary → Failover → Primary).

Wartungsfenster anmelden, Anwender und Fachseite vorab informieren.

Vor dem Patch: Voll-Backup, Rollback-Plan, Restore mindestens einmal testen.

Nach dem Patch: Performance-Baseline 48 Stunden gegenüberstellen, Wait Stats vergleichen.

CU-Branch-Instanzen separat verfolgen: GDR ist kein Ersatz für den nächsten CU.