Kritische Sicherheitslücken in Red Hat Enterprise Linux: Was IT-Verantwortliche jetzt wissen müssen

Veröffentlicht: 21. Juli 2026 | Quelle: BSI WID Advisory | Schweregrad: Hoch

Einleitung: Eine Warnung mit Sprengkraft für Unternehmensinfrastrukturen

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat am 21. Juli 2026 ein neues Advisory mit der Einstufung „hoch" veröffentlicht. Betroffen ist Red Hat Enterprise Linux (RHEL) – eines der am weitesten verbreiteten Linux-Betriebssysteme in deutschen Unternehmensrechenzentren, Behörden und kritischen Infrastrukturen. Die Schwachstellen betreffen die Komponenten sssd, glib und c-ares.

Warum ist das für deutsche Unternehmen besonders relevant? RHEL ist nicht irgendein Nischensystem. Es läuft auf Produktionsservern, Datenbanken, Cloud-Instanzen und virtuellen Maschinen quer durch alle Branchen – vom Mittelstand bis zum DAX-Konzern. Wer diese Schwachstellen ignoriert, riskiert nicht nur Datenverlust oder Systemausfälle, sondern möglicherweise auch empfindliche Bußgelder nach NIS2 und DSGVO.

Technischer Hintergrund: Was steckt hinter sssd, glib und c-ares?

Um die Tragweite dieser Schwachstellen zu verstehen, lohnt ein kurzer Blick auf die betroffenen Komponenten:

sssd – System Security Services Daemon

Der sssd ist ein zentraler Authentifizierungsdienst unter Linux. Er verbindet lokale Systeme mit Verzeichnisdiensten wie Active Directory, LDAP oder Kerberos. Auf gut Deutsch: sssd entscheidet, wer sich an einem Linux-System anmelden darf. Eine Schwachstelle hier ist gleichbedeutend mit einem potenziell offenen Schlosswechsel an der Eingangstür Ihres Rechenzentrums.

glib – The GNOME Library

glib ist eine fundamentale Basisbibliothek, die von unzähligen Linux-Anwendungen genutzt wird. Sie stellt grundlegende Datenstrukturen, Hilfsfunktionen und Abstraktionen bereit. Weil glib so tief im System verankert ist, haben Schwachstellen hier eine besonders breite Angriffsfläche – viele Applikationen könnten indirekt betroffen sein, ohne dass dies auf den ersten Blick sichtbar ist.

c-ares – Asynchrone DNS-Bibliothek

c-ares ist eine C-Bibliothek für asynchrone DNS-Anfragen. Sie wird häufig in Netzwerkanwendungen, Proxys und Diensten eingesetzt, die schnelle, nicht-blockierende Namensauflösung benötigen. DNS-Schwachstellen sind besonders kritisch, weil sie häufig als Einstiegspunkt für Man-in-the-Middle-Angriffe oder zur Umleitung von Netzwerkverkehr missbraucht werden können.

Die Angriffsvektoren im Überblick

Laut BSI-Advisory kann ein Angreifer durch die Kombination dieser Schwachstellen:

Besonders gefährlich ist das Zusammenspiel dieser Vektoren: Ein Angreifer könnte theoretisch zunächst über c-ares DNS-Abfragen manipulieren, sich dann mittels sssd-Schwachstellen erhöhte Rechte verschaffen und schließlich über glib systemkritische Prozesse zum Absturz bringen oder Daten kompromittieren.

Auswirkungen für Deutschland und NIS2-Relevanz

Wer ist betroffen?

Alle Organisationen, die Red Hat Enterprise Linux in ihren Produktiv- oder Testumgebungen betreiben, sollten jetzt aktiv handeln. Das betrifft insbesondere:

• KRITIS-Betreiber (Energie, Wasser, Transport, Gesundheit, Finanzwesen)
• Unternehmen mit NIS2-Pflichten (Betreiber wesentlicher und wichtiger Einrichtungen gemäß §§ 28–29 BSIG n.F.)
• Behörden und öffentliche Verwaltungen
• Mittelständische Unternehmen mit RHEL-basierter IT-Infrastruktur

NIS2 und die Meldepflicht

Die NIS2-Richtlinie (umgesetzt durch das novellierte BSIG) verpflichtet betroffene Einrichtungen zu einem proaktiven Sicherheitsmanagement. Das bedeutet konkret:

• Artikel 21 NIS2 / § 30 BSIG n.F.: Technische und organisatorische Maßnahmen müssen dem Stand der Technik entsprechen. Bekannte, als „hoch" eingestufte Schwachstellen müssen zeitnah behoben werden.
• Meldepflicht bei Sicherheitsvorfällen: Wird eine dieser Schwachstellen aktiv ausgenutzt und kommt es zu einem erheblichen Sicherheitsvorfall, greift die 24/72-Stunden-Meldepflicht gegenüber dem BSI.
• Bußgeldrisiko: Bei nachgewiesener Vernachlässigung bekannter, hochkritischer Schwachstellen drohen nach NIS2 Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes – je nachdem, welcher Betrag höher ist.

DSGVO-Dimension nicht vergessen

Werden durch die Ausnutzung dieser Schwachstellen personenbezogene Daten kompromittiert, löst dies zusätzlich eine DSGVO-Meldepflicht gegenüber der zuständigen Datenschutzbehörde aus (Art. 33 DSGVO, innerhalb von 72 Stunden). Die mögliche Datenmanipulation durch Angreifer macht dieses Szenario durchaus realistisch.

Praktische Schutzmaßnahmen: 6 konkrete Handlungsempfehlungen

Gute Nachrichten: Die Schwachstellen sind bekannt und es gibt klare Gegenmaßnahmen. Handeln Sie jetzt, bevor Angreifer die Schwachstellen aktiv ausnutzen.

1. Sofortige Bestandsaufnahme aller RHEL-Systeme

Erstellen Sie umgehend einen vollständigen Überblick über alle Systeme, auf denen Red Hat Enterprise Linux läuft. Nutzen Sie dafür Asset-Management-Tools oder befragen Sie Ihre Systemadministratoren. Prüfen Sie insbesondere, welche RHEL-Versionen und Patchstände in Ihrer Umgebung aktiv sind.

# RHEL-Version prüfen
cat /etc/redhat-release

# Installierte Paketversionen prüfen
rpm -q sssd glib2 c-ares

2. Patches umgehend einspielen

Red Hat stellt Sicherheitsupdates über den Red Hat Customer Portal und über yum/dnf bereit. Spielen Sie die verfügbaren Updates für die betroffenen Pakete so schnell wie möglich ein – priorisieren Sie dabei produktionskritische und dem Internet zugewandte Systeme.

# Sicherheitsupdates für betroffene Pakete einspielen
sudo dnf update sssd glib2 c-ares --security

Testen Sie Patches zunächst in einer Staging-Umgebung, um Produktionsausfälle zu vermeiden – dies sollte jedoch die Geschwindigkeit des Rollouts nicht übermäßig verzögern.

3. Netzwerksegmentierung und Zugriffsbeschränkungen prüfen

Begrenzen Sie den Netzwerkzugang zu betroffenen Systemen auf das absolut notwendige Minimum. Systeme, die sssd für die Authentifizierung nutzen, sollten nicht unnötig aus dem Internet oder aus unsicheren Netzwerksegmenten erreichbar sein. Überprüfen Sie Ihre Firewall-Regeln und ACLs.

4. Privilegierte Zugänge überwachen (PAM/IAM)

Da sssd direkt die Authentifizierung betrifft, sollten Sie alle privilegierten Zugänge (Root, Sudo, Service Accounts) auf Ihren RHEL-Systemen sofort einer Überprüfung unterziehen. Aktivieren Sie erweiterte Auditlogging-Funktionen, um unberechtigte Anmeldeversuche oder Rechteerweiterungen frühzeitig zu erkennen.

# Auditd für privilegierte Zugriffe aktivieren
auditctl -w /etc/passwd -p wa -k identity
auditctl -w /etc/sudoers -p wa -k sudoers

5. Intrusion Detection und Log-Monitoring schärfen

Konfigurieren Sie Ihr SIEM oder Log-Management-System so, dass es auf Anomalien im Zusammenhang mit DNS-Auflösungen (c-ares), Authentifizierungsereignissen (sssd) und Systemabstürzen (glib) aufmerksam macht. Indikatoren für eine Kompromittierung (Indicators of Compromise, IoCs) sollten aus aktuellen Threat-Intelligence-Feeds bezogen werden.

6. Notfallplan und Meldewege vorbereiten

Stellen Sie sicher, dass Ihr Incident-Response-Plan für genau dieses Szenario aktualisiert ist. Klären Sie intern, wer im Falle eines Vorfalls das BSI informiert (für NIS2-pflichtige Einrichtungen: über das BSI-Portal oder per CERT-Bund), welche internen Eskalationswege gelten und wie die Kommunikation mit der Geschäftsführung erfolgt.

Fazit: Jetzt handeln, nicht abwarten

Die als „hoch" eingestuften Schwachstellen in Red Hat Enterprise Linux sind keine abstrakte Gefahr – sie betreffen konkrete, weit verbreitete Systemkomponenten, die täglich in deutschen Unternehmensnetzen im Einsatz sind. Das Schadenspotenzial ist erheblich: Administratorrechte können übernommen, Sicherheitsmaßnahmen ausgehebelt, Daten manipuliert und Dienste lahmgelegt werden.

Für NIS2-pflichtige Einrichtungen kommt noch ein weiterer Druck hinzu: Die Nichtbeachtung bekannter, hochkritischer Schwachstellen kann als Verletzung der Sorgfaltspflichten gewertet werden – mit entsprechenden rechtlichen und finanziellen Konsequenzen. Das BSI hat unmissverständlich signalisiert: Patch-Management ist kein optionales Extra, sondern eine gesetzliche Pflicht.

Call-to-Action: NIS2-Compliance systematisch im Griff behalten

Einzelne Schwachstellen wie diese sind oft nur die sichtbare Spitze eines größeren Problems: dem fehlenden Überblick über den eigenen Sicherheitsstatus. Moderne NIS2-Compliance-Software hilft IT-Verantwortlichen dabei, BSI-Advisories automatisiert zu verfolgen, den Patch-Status ihrer Systeme zentral zu dokumentieren und Meldepflichten fristgerecht einzuhalten. Wenn Sie noch kein strukturiertes Tool für Ihr Vulnerability- und Compliance-Management nutzen, ist jetzt ein guter Zeitpunkt, dies zu ändern – bevor das nächste Advisory mit Einstufung „kritisch" erscheint.

Quellen: BSI WID Advisory (21.07.2026), BSI-Grundschutz, BSIG (novelliert), NIS2-Richtlinie (EU) 2022/2555, Red Hat Security Advisories, ENISA Threat Landscape 2025