CVE-2026-21262: Wenn der Datenbankserver zur offenen Tür wird – SQL-Server-Härtung für den Mittelstand

Stellen Sie sich vor: Es ist ein gewöhnlicher Dienstagmorgen

Die Buchhaltung der Münchener Maschinenbau Vogel GmbH & Co. KG startet wie immer kurz nach acht. Die Sachbearbeiterin Sabine R. öffnet das ERP-System, gibt ihre Zugangsdaten ein – und bemerkt nichts Ungewöhnliches. Auch ihr Kollege in der Arbeitsvorbereitung loggt sich in die Produktionsplanungssoftware ein. Beide Systeme laufen auf einem Microsoft SQL Server 2022, der seit vier Jahren zuverlässig seinen Dienst tut und nie Anlass zur Sorge gegeben hat.

Was Sabine R. und ihr Kollege nicht wissen: Seit dem frühen Morgen hält sich ein Angreifer bereits auf diesem SQL Server auf. Er hat keine Passwörter geknackt, keine Phishing-Mail gesendet. Er hat lediglich einen niederprivilegierten Datenbankbenutzer – einen, der dem Softwareanbieter des ERP-Systems vor Jahren eingerichtet wurde, mit minimalen Rechten, scheinbar harmlos – genutzt, um sich über CVE-2026-21262 schrittweise bis zur Systemadministrator-Ebene hochzuarbeiten. Der SQL-Server gehört ihm jetzt.

Das hier ist keine Dystopie. Es ist das exakte Angriffsszenario, das mit dem Microsoft Patch Tuesday vom März 2026 adressiert wurde – und für das in Deutschland nach wie vor Hunderttausende von SQL-Server-Instanzen in kleinen und mittleren Unternehmen anfällig sind, solange der Patch nicht eingespielt wird.

Was ist CVE-2026-21262?

CVE-2026-21262 ist eine Elevation-of-Privilege-Schwachstelle (Privilegien-Eskalation) in Microsoft SQL Server. Sie wurde als öffentlich bekannter Zero-Day im Rahmen des März 2026 Patch Tuesday von Microsoft geschlossen. Mit einem CVSS-Score von 8,8 (High) ist die Schwachstelle als hochgradig gefährlich eingestuft – und die Einstufung als „Exploitation More Likely" durch Microsoft signalisiert, dass aktive Angriffe in der freien Wildbahn in Kürze wahrscheinlich sind oder bereits stattfinden.

Technisch handelt es sich um einen Improper Access Control-Fehler (CWE-284): SQL Server prüft in bestimmten Szenarien nicht korrekt, ob ein authentifizierter Nutzer die nötigen Berechtigungen hat, um bestimmte interne Systemfunktionen aufzurufen. Ein Angreifer, der sich mit einem beliebigen niederprivilegierten SQL-Konto anmelden kann – also beispielsweise als einfacher Datenbankbenutzer ohne administrative Rechte –, kann diese Lücke ausnutzen, um sich zum sysadmin hochzuarbeiten.

Der sysadmin-Status in SQL Server entspricht der vollständigen Kontrolle: Datenlesen, Daten verändern, Datenbankstruktur ändern, neue Logins erstellen, Betriebssystembefehle über xp_cmdshell ausführen (sofern aktiviert) und dauerhafte Hintertüren im Datenbankserver einrichten. Wer SQL-Server-sysadmin ist, besitzt in vielen Unternehmensumgebungen die Schlüssel zu nahezu allem – von Finanzdaten über Kundendatenbanken bis hin zu Produktionssteuerungssystemen.

Besonders beunruhigend: Die Schwachstelle war zum Zeitpunkt der Patch-Veröffentlichung bereits öffentlich bekannt. Das bedeutet, dass technische Details der Lücke potentiell verfügbar sind – und damit auch weniger versierte Angreifer in der Lage wären, sie auszunutzen. Microsoft hat CVE-2026-21262 ausdrücklich als „Public Disclosure" und „Exploitation More Likely" bewertet. Das ist eine ernste Kombination.

User Story: Die Metallverarbeitung Kramer & Söhne KG

Um zu verstehen, wie CVE-2026-21262 in einem realen Unternehmenskontext wirkt, betrachten wir ein fiktives, aber realistisches Szenario: die Metallverarbeitung Kramer & Söhne KG, ein mittelständischer Betrieb mit 120 Mitarbeitern in Nordrhein-Westfalen, spezialisiert auf Präzisionsteile für die Automobilindustrie.

Das Unternehmen betreibt einen Windows-Server mit SQL Server 2022 Standard, auf dem mehrere geschäftskritische Anwendungen laufen: das ERP-System zur Auftragsabwicklung, die Produktionsplanung, das Qualitätsmanagementsystem und die Finanzbuchhaltung. Für jede dieser Anwendungen wurde seinerzeit vom Softwareanbieter ein separates SQL-Dienstkonto eingerichtet. Diese Konten haben jeweils nur die für die Anwendung nötigen Rechte – db_datareader und db_datawriter auf den jeweiligen Datenbanken. Eine solide Ausgangskonfiguration, wie sie empfohlen wird.

Der Angriff beginnt nicht am SQL Server, sondern in der Web-Applikation.

Ein Angreifer hat über eine Schwachstelle in der Webanwendung des ERP-Anbieters – konkret eine SQL-Injection-Lücke in einem selten genutzten Berichtsmodul, das direkt über den Browser erreichbar ist – Zugriff auf das Dienstkonto der ERP-Anwendung erlangt. Dieses Konto hat minimale SQL-Berechtigungen. Eigentlich kein Grund zur Panik.

Aber: Das Konto kann sich am SQL Server authentifizieren. Und der SQL Server ist nicht gepatcht. CVE-2026-21262 ermöglicht es dem Angreifer nun, vom niederprivilegierten ERP-Dienstkonto zum sysadmin zu eskalieren. Der Vorgang dauert in der Praxis wenige Minuten – ein automatisiertes Exploit-Skript erledigt das ohne menschliches Zutun.

Mit sysadmin-Rechten öffnet der Angreifer zunächst xp_cmdshell – eine SQL-Server-Funktion, mit der direkte Betriebssystembefehle auf dem Datenbankserver ausgeführt werden können – und installiert eine Backdoor auf dem Server. Von dort aus beginnt die laterale Bewegung im Netzwerk: Der SQL Server hat Verbindungen zu anderen Systemen, der Angreifer extrahiert Zugangsdaten aus dem Speicher und bewegt sich schrittweise in tiefere Netzwerkbereiche.

Wochen später, als der Angreifer die gesamte Netzwerktopologie kartiert und alle interessanten Daten – Kundenlisten, Konstruktionspläne, Finanzdaten – exfiltriert hat, aktiviert er Ransomware. Zuerst verschlüsselt er die Backup-Instanzen (der Backup-Server ist über das Netzwerk erreichbar). Dann die Produktionsdaten. Dann die Finanzdaten. Die Metallverarbeitung Kramer & Söhne KG steht am Montagmorgen vor einem vollständig verschlüsselten Betrieb. Der Schaden: geschätzte sechs Wochen Produktionsausfall, Datenverlust, Kundenabwanderung und ein Reputationsschaden, dessen Folgen noch Jahre spürbar sein werden.

Dieser Angriffspfad – von einer Anwendungsschwachstelle über SQL-Privilege-Escalation zum vollständigen Ransomware-Angriff – entspricht dem Muster, das bei einer Vielzahl tatsächlicher Vorfälle in deutschen KMU dokumentiert ist. CVE-2026-21262 ist der fehlende Link, der einen bereits begrenzten Zugriff in einen totalen Kompromiss verwandelt.

Technische Tiefe: Warum SQL-Server-Privilege-Escalation so gefährlich ist

Um zu verstehen, warum CVE-2026-21262 ein so kritisches Risiko darstellt, ist ein kurzer Blick auf die Architektur von Microsoft SQL Server notwendig.

SQL Server als Betriebssystem im Betriebssystem: SQL Server ist nicht einfach eine Datenbank. In seiner Standardkonfiguration ist er tief in das Windows-Betriebssystem integriert. Mit sysadmin-Rechten kann ein Angreifer über folgende Mechanismen direkt auf das Betriebssystem zugreifen:

xp_cmdshell ermöglicht die direkte Ausführung von Windows-Befehlen im Kontext des SQL-Server-Dienstkontos. Standardmäßig in neuen Installationen deaktiviert, aber in vielen Altinstallationen noch aktiv – oder trivial wieder zu aktivieren, wenn man sysadmin-Rechte hat.

OLE-Automation-Prozeduren (sp_OACreate, sp_OAMethod) ermöglichen das Erstellen und Aufrufen von COM-Objekten, was zur Codeausführung missbraucht werden kann – ein oft übersehener Angriffsvektor.

Linked Server: SQL Server kann Verbindungen zu anderen Datenbanken und Servern aufbauen. Ein kompromittierter SQL Server kann als Sprungbrett in andere Datenbankinstanzen verwendet werden, auch über Netzwerkgrenzen hinweg. In Unternehmensumgebungen, in denen mehrere SQL-Server-Instanzen miteinander kommunizieren, kann ein einziger kompromittierter Server die gesamte Datenbanklandschaft gefährden.

SQL Server Agent: Der integrierte Job-Scheduler von SQL Server ermöglicht das automatisierte Ausführen von Betriebssystemskripten und kann für Persistenz missbraucht werden – ein Backdoor-Job, der alle 15 Minuten eine externe Verbindung aufbaut, fällt in vielen Monitoring-Systemen nicht auf.

Das Privilege-Escalation-Paradoxon: Viele Unternehmen sichern den Netzwerkzugang zum SQL Server sorgfältig ab – Port 1433 ist im Perimeter gefiltert, VPN-Zugang ist erforderlich. Aber die Schwachstelle erfordert keinen direkten externen Zugriff: Jede Anwendung, die im internen Netz mit dem SQL Server kommuniziert und ein gültiges Konto besitzt, ist ein potenzieller Ausgangspunkt für die Eskalation. ERP-Systeme, Buchhaltungssoftware, CRM-Systeme, Web-Apps, Monitoring-Tools – sie alle sind potenzielle Einstiegspunkte, wenn die vorgelagerte Anwendung eine eigene Schwachstelle hat.

SQL Server im deutschen Mittelstand: Eine unterschätzte Angriffsfläche

Microsoft SQL Server ist in der deutschen Mittelstandslandschaft omnipräsent. Eine deutliche Mehrheit aller ERP-Installationen in deutschen KMU läuft auf SQL-Server-Basis – von SAP Business One über Microsoft Dynamics 365 Business Central bis hin zu Sage, Infor und einer Vielzahl branchenspezifischer Lösungen. Hinzu kommen Produktionsplanungssysteme, Qualitätsmanagementsoftware, CRM-Systeme und Eigenentwicklungen, die über Jahrzehnte gewachsen sind.

Das Problem: Viele dieser SQL-Server-Instanzen laufen seit Jahren ohne strukturiertes Patch-Management. Updates werden oft erst dann eingespielt, wenn der Softwarelieferant sie explizit fordert oder wenn Kompatibilitätsprobleme auftreten. Das Ergebnis sind SQL-Server-Installationen, die mehrere Patchzyklen im Rückstand sind – und damit offen für bekannte Schwachstellen wie CVE-2026-21262.

Erschwerend kommt hinzu, dass SQL Server in der Praxis oft mit weitreichenden Berechtigungen betrieben wird: Datenbankkonten mit sysadmin aus Komfortgründen, das SQL-Server-Dienstkonto mit lokalen Administratorrechten auf dem Server, xp_cmdshell aktiviert für alte Skripte, die niemand mehr versteht, aber von denen alle abhängig sind. Diese Konfigurationsprobleme sind weit verbreitet und verwandeln jeden Patch-Rückstand in ein erhebliches Risiko.

Eine enge Verzahnung von Informationssicherheitsmanagement und gezieltem SQL-Server-Hardening ist daher für den deutschen Mittelstand keine optionale Maßnahme, sondern eine betriebliche Notwendigkeit. Und mit dem Inkrafttreten von NIS2 ist sie für eine wachsende Zahl von Unternehmen auch rechtlich verbindlich: Risikomanagement und regelmäßige Schwachstellenbehebung sind explizite Anforderungen des Gesetzes.

SQL-Server-Härtung: Sieben konkrete Maßnahmen gegen CVE-2026-21262

1. Patch sofort einspielen – keine Verzögerung

Die unmittelbarste und wichtigste Maßnahme ist die Installation des März-2026-Patches für Microsoft SQL Server. Microsoft stellt kumulative Updates (CU) oder GDR-Patches für alle noch unterstützten SQL-Server-Versionen bereit. Priorisieren Sie alle SQL-Server-Instanzen, auf denen Geschäftsanwendungen mit potenziell niederprivilegierten Dienstkonten laufen – das ist faktisch jede Instanz.

Prüfen Sie außerdem, ob alle Ihre SQL-Server-Versionen noch im Microsoft-Support-Lebenszyklus liegen. SQL Server 2014 ist Ende Juli 2024 aus dem erweiterten Support gefallen. Wer noch auf dieser Version läuft, erhält keine Patches mehr und ist dauerhaft auf dem Stand seiner letzten aktuellen Version eingefroren – CVE-2026-21262 bleibt dort für immer offen. Ein Upgrade auf eine unterstützte Version ist in diesem Fall unvermeidlich.

2. Least Privilege für alle SQL-Dienstkonten durchsetzen

Überprüfen Sie alle SQL-Dienstkonten in Ihrer Umgebung. Kein Konto, das von einer Anwendung genutzt wird, sollte sysadmin-Rechte besitzen – es sei denn, das ist zwingend für die Funktion der Anwendung erforderlich, was in der Praxis extrem selten der Fall ist. Erteilen Sie Dienstkonten nur die minimal notwendigen Datenbankrechte.

Eine praktische SQL-Abfrage, um alle Logins mit sysadmin-Berechtigung zu identifizieren:

SELECT sp.name, sp.type_desc, sp.is_disabled
FROM sys.server_principals sp
INNER JOIN sys.server_role_members srm
  ON sp.principal_id = srm.member_principal_id
INNER JOIN sys.server_principals role_sp
  ON srm.role_principal_id = role_sp.principal_id
WHERE role_sp.name = 'sysadmin'
ORDER BY sp.name;

Überprüfen Sie das Ergebnis kritisch: Jedes Konto in dieser Liste, das kein explizit autorisiertes Administratorkonto ist, sollte sofort herabgestuft werden. Besondere Aufmerksamkeit verdienen Konten, die von externen Softwareanbietern eingerichtet wurden und über die Jahre vergessen wurden.

3. xp_cmdshell deaktivieren

In modernen SQL-Server-Installationen ist xp_cmdshell standardmäßig deaktiviert. Altinstallationen oder Softwareanbieter, die diese Funktion aktiviert haben, hinterlassen damit eine gefährliche Öffnung. Sobald ein Angreifer sysadmin-Rechte erlangt – sei es über CVE-2026-21262 oder eine andere Route –, ist xp_cmdshell der schnellste Weg zum Betriebssystem. Deaktivieren Sie es, wenn es nicht zwingend benötigt wird:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE;

Wenn einzelne Anwendungen xp_cmdshell wirklich benötigen, prüfen Sie, ob die entsprechende Funktion nicht durch sicherere Alternativen (SSIS-Pakete, SQL Agent-Jobs mit eingeschränkten Proxy-Konten) ersetzt werden kann.

4. OLE-Automation-Prozeduren deaktivieren

Ähnlich wie xp_cmdshell können OLE-Automation-Prozeduren für die Ausführung beliebiger Betriebssystembefehle missbraucht werden. Wenn sie nicht benötigt werden, sollten sie konsequent deaktiviert werden:

EXEC sp_configure 'Ole Automation Procedures', 0;
RECONFIGURE;

Führen Sie eine Bestandsaufnahme durch: Welche Anwendungen und Skripte setzen OLE-Automation-Prozeduren voraus? Oft sind es veraltete Skripte, die niemand mehr aktiv nutzt, aber die seit Jahren im SQL Agent laufen. Diese sollten identifiziert, dokumentiert und durch modernere Alternativen ersetzt werden.

5. Netzwerksegmentierung und Host-Firewall-Regeln

SQL-Server-Ports (Standard: TCP 1433, 1434 für SQL Server Browser) sollten nur für die Systeme erreichbar sein, die tatsächlich auf den SQL Server zugreifen müssen. Implementieren Sie Firewall-Regeln, die nur autorisierte Quell-IP-Adressen zulassen. Eine SQL-Server-Instanz sollte niemals direkt aus dem Internet erreichbar sein – und auch im internen Netz nicht pauschal für alle Systeme offen stehen.

Nutzen Sie die Windows-eigene Firewall auf Host-Ebene, um den eingehenden Datenverkehr auf dem SQL Server explizit zu beschränken. In Umgebungen mit Active Directory können Sie zusätzlich IPsec-Richtlinien einsetzen, um SQL-Server-Kommunikation auf authentifizierte, domänengebundene Systeme zu beschränken – was den Missbrauch gestohlener Credentials aus nicht-domänengebundenen Angreifermaschinen erheblich erschwert.

6. SQL Server Audit und SIEM-Integration aktivieren

SQL Server bietet eingebaute Audit-Funktionalität, die in vielen Installationen nicht genutzt wird. Aktivieren Sie Auditing für sicherheitsrelevante Ereignisse:

CREATE SERVER AUDIT AuditSicherheitsereignisse
TO FILE (FILEPATH = 'C:\SQLAudit\')
WITH (QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE);

ALTER SERVER AUDIT AuditSicherheitsereignisse WITH (STATE = ON);

CREATE SERVER AUDIT SPECIFICATION SicherheitsSpec
FOR SERVER AUDIT AuditSicherheitsereignisse
ADD (FAILED_LOGIN_GROUP),
ADD (SUCCESSFUL_LOGIN_GROUP),
ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP),
ADD (SERVER_PRINCIPAL_CHANGE_GROUP),
ADD (DATABASE_ROLE_MEMBER_CHANGE_GROUP)
WITH (STATE = ON);

Integrieren Sie die Audit-Logs in Ihr SIEM-System oder nutzen Sie Windows Event Log Forwarding, um verdächtige Ereignisse zentral zu überwachen. Alerts sollten ausgelöst werden bei: unerwarteten Anmeldungen außerhalb der Geschäftszeiten, Änderungen an Server-Rollen (insbesondere Hinzufügen eines Kontos zu sysadmin), Aktivierung von xp_cmdshell oder OLE-Automation, Erstellung neuer SQL-Logins sowie einer ungewöhnlich hohen Anzahl fehlgeschlagener Anmeldeversuche.

7. Regelmäßigen Patch-Management-Prozess etablieren

Ein einmaliger Patch reicht nicht. Etablieren Sie einen strukturierten Patch-Management-Prozess, der sicherstellt, dass SQL-Server-Updates zeitnah nach Veröffentlichung getestet und eingespielt werden. Nutzen Sie Microsoft SQL Server Best Practices Analyzer oder Drittanbieter-Tools wie Tenable.io, Qualys oder Rapid7 InsightVM, um regelmäßige Schwachstellenscans Ihrer SQL-Server-Instanzen durchzuführen.

Für Unternehmen, die ihren Compliance-Anforderungen unter NIS2 nachkommen müssen, ist ein nachweisbarer Patch-Management-Prozess ohnehin verpflichtend. Dokumentieren Sie Patches, Testzyklen und Rollout-Zeitpläne so, dass Sie im Fall einer BSI-Prüfung eine lückenlose Historie vorweisen können.

Erkennung: Anzeichen einer laufenden SQL-Server-Kompromittierung

Wenn Sie CVE-2026-21262 noch nicht gepatcht haben, sollten Sie Ihre SQL-Server-Instanzen auf Anzeichen einer möglichen Kompromittierung untersuchen. Hier sind die wichtigsten Indikatoren:

Unerwartete sysadmin-Mitgliedschaften: Führen Sie die oben genannte Abfrage aus und vergleichen Sie das Ergebnis mit einer bekannten Baseline. Jede unerwartete Ergänzung – besonders von Dienstkonten, die dort nicht sein sollten – ist ein Warnsignal erster Ordnung.

Ungewöhnliche Anmeldeereignisse: Anmeldungen zu ungewöhnlichen Zeiten (nachts, am Wochenende) oder von unerwarteten IP-Adressen aus bekannten Dienstkonten sind ein starkes Indiz für eine Kompromittierung. Prüfen Sie die SQL-Server-Logs oder Windows-Ereignisprotokolle auf solche Anomalien.

Aktivierung von xp_cmdshell: Wenn xp_cmdshell in Ihrer Umgebung deaktiviert war und plötzlich aktiviert ist, ist das ein klares Alarmsignal. Prüfen Sie:

SELECT name, value_in_use
FROM sys.configurations
WHERE name = 'xp_cmdshell';

Neue SQL-Server-Logins: Überprüfen Sie regelmäßig alle SQL-Logins:

SELECT name, create_date, modify_date, type_desc, is_disabled
FROM sys.server_principals
WHERE type IN ('S', 'U')  -- SQL und Windows Logins
ORDER BY create_date DESC;

SQL-Agent-Jobs: Prüfen Sie den SQL Server Agent auf unbekannte Jobs, die Betriebssystembefehle ausführen:

SELECT j.name, j.enabled, j.date_created,
       s.step_name, s.subsystem, s.command
FROM msdb.dbo.sysjobs j
JOIN msdb.dbo.sysjobsteps s ON j.job_id = s.job_id
WHERE s.subsystem IN ('CmdExec', 'PowerShell')
ORDER BY j.date_created DESC;

Wenn Sie einen oder mehrere dieser Indikatoren feststellen, ist sofortiges Handeln geboten: Isolieren Sie den betroffenen Server vom Netzwerk, sichern Sie Logs und Speicher-Dumps für die forensische Analyse und kontaktieren Sie umgehend Ihr Sicherheitsteam oder externe Incident-Response-Spezialisten. Das pleXtec-Team steht für schnelle Unterstützung im Ernstfall zur Verfügung.

Ausblick: SQL Server Security als kontinuierliche Aufgabe

CVE-2026-21262 ist eine ernste Schwachstelle – aber sie ist auch eine, die sich mit den richtigen Maßnahmen zuverlässig schließen lässt. Der Patch existiert. Die Härtungsmaßnahmen sind bekannt und erprobt. Was in vielen Unternehmen fehlt, ist der strukturierte Prozess, der sicherstellt, dass diese Maßnahmen auch tatsächlich und zeitnah umgesetzt werden.

Die zunehmende Häufigkeit von Privilege-Escalation-Schwachstellen in weit verbreiteten Infrastrukturkomponenten wie SQL Server – und die steigende Professionalisierung der Angreifer – macht deutlich, dass reaktives Handeln nicht mehr ausreicht. Unternehmen, die erst dann patchen, wenn ein Vorfall eingetreten ist, bezahlen den Preis in Form von Datenverlust, Produktionsausfällen, Reputationsschäden und steigenden Compliance-Risiken unter NIS2.

Proaktive SQL-Server-Härtung ist kein einmaliges Projekt, sondern eine kontinuierliche Aufgabe. Sie erfordert einen Patch-Management-Prozess, regelmäßige Konfigurationsprüfungen, aktives Monitoring und geschultes Personal – oder einen verlässlichen externen Partner, der diese Aufgaben übernimmt und sicherstellt, dass Ihre Datenbankinfrastruktur auch morgen noch sicher ist.

pleXtec unterstützt mittelständische Unternehmen bei der strukturierten Absicherung ihrer Datenbankinfrastruktur – von der initialen Sicherheitsanalyse über die Härtung nach Industriestandards bis hin zu laufendem Monitoring und Compliance-Reporting. Sprechen Sie uns an, bevor CVE-2026-21262 für Sie mehr als eine Schlagzeile wird. Jetzt Kontakt aufnehmen.