Server & Hosting Archive - RDDZ

PHP2Shell: Über 34 Millionen PHP-Dienste melden noch betroffene Versionen – was die Zahlen bedeuten

dennis_rddz — Fri, 23 Oct 2026 18:17:37 +0000

SICHERHEIT · PHP · STAND 23.10.2026

PHP2Shell: Über 34 Millionen PHP-Dienste melden noch betroffene Versionen – was die Zahlen bedeuten

Das öffentliche Censys-Dashboard zeigt auch zwei Tage nach der Veröffentlichung der korrigierten Versionen mehr als 34 Millionen PHP-Dienste, die eine Version aus dem betroffenen Bereich melden. Das sind keine 34 Millionen nachweislich hackbaren Server, aber ein deutliches Zeichen, wie schwer sich eine Korrektur über die gesamte Webinfrastruktur verteilt.

CENSYS · ABRUF 23.10.2026

● Momentaufnahme

34,3 Mio.

melden betroffene Version

7,1 Mio.

auf korrigierte Version gewechselt

49,7 Mio.

ohne sichtbare Version

PHP 7.4.33ca. 6,43 Mio.

PHP 8.1.34ca. 2,05 Mio.

PHP 5.2.6ca. 1,56 Mio.

PHP 5.6.40ca. 1,52 Mio.

PHP 8.0.30ca. 1,16 Mio.

Gemeldete Versionen, keine bestätigte Verwundbarkeit. Backports bleiben von außen unsichtbar.

✓ Zahlen aus dem öffentlichen Censys-Dashboard

✓ Die Werte sind eine Obergrenze

✓ Alte PHP-Zweige als Kernproblem

✓ Gründe für den Patch-Rückstand

DIE ZAHLEN

Millionen Dienste melden weiterhin betroffene Versionen

Die Sicherheitsforscher von Censys erfassen weltweit öffentlich erreichbare PHP-Dienste, deren gemeldete Version im betroffenen Bereich für PHP2Shell (CVE-2026-109618 und CVE-2026-109619) liegt. Die korrigierten Versionen erschienen am 21. Oktober. Trotzdem zeigt das öffentliche Live-Dashboard auch am 23. Oktober noch einen enormen Bestand. Es verfolgt, wie sich die Zahl der erfassten Dienste seit Bekanntwerden der Lücken verändert, und wird laut Censys stündlich aktualisiert.

Beim Abruf am 23. Oktober 2026 zeigte das Dashboard diese Werte:

Kennzahl	Erfasster Stand
Seit Beginn der Erfassung mit betroffener Version gesehen	41.400.836 Dienste
Bei der jüngsten Erfassung weiterhin mit betroffener Version	34.280.868 Dienste
Seit Beginn auf eine als korrigiert erkannte Version gewechselt	7.128.257 Dienste
PHP-Dienste ohne öffentlich erkennbare Versionsangabe	49.695.981 Dienste

Die Werte sind eine Momentaufnahme und verändern sich mit jeder neuen Erfassung. Auch Änderungen an der Erkennung können dazu führen, dass Dienste neu eingeordnet werden.

Rund 34,3 von 41,4 Millionen sind etwa 83 Prozent der Dienste, die seit Beginn als betroffen erkannt wurden. Umgekehrt haben gut 17 Prozent auf eine korrigierte Version gewechselt. Beides ist eine Orientierung anhand der Zähler, keine exakte Patchquote: Neu entdeckte Dienste, verzögerte Scans und geänderte Erkennung beeinflussen die Werte. Außerdem liegen erst zwei Tage zwischen Release und Abruf.

EINORDNUNG

Warum das nicht 34 Millionen verwundbare Server sind

📦

Dienste sind keine Server

Censys zählt Dienste, nicht einzelne physische Server oder Betreiber. Ein Host kann viele Websites und Dienste auf verschiedenen Ports bereitstellen.

🔧

Backports bleiben unsichtbar

Linux-Distributionen können Korrekturen zurückportieren, ohne die gemeldete Versionsnummer anzuheben. Die versionsbasierte Zählung ist laut Censys deshalb eine Obergrenze der möglichen Betroffenheit.

❓

Ohne Version heißt nicht sicher

Fast 50 Millionen Dienste verraten ihre Version nicht. Sie dürfen weder automatisch als verwundbar noch als sicher eingestuft werden.

Die Daten sind keine vollständige Schwachstellenprüfung. Sie sind ein deutlicher Hinweis darauf, wie groß die öffentlich sichtbare Angriffsfläche ist.

ALTE ZWEIGE

Besonders problematisch: PHP 7.4 und älter

Im Dashboard gehören diese Versionsstände zu den am häufigsten gemeldeten:

PHP 7.4.33: rund 6,43 Millionen Dienste
PHP 8.1.34: rund 2,05 Millionen Dienste
PHP 5.2.6: rund 1,56 Millionen Dienste
PHP 5.6.40: rund 1,52 Millionen Dienste
PHP 8.0.30: rund 1,16 Millionen Dienste

Diese Zahlen beziehen sich auf gemeldete Versionsstände und beweisen nicht, dass jedes dieser Systeme ungepatcht ist. Zur Zeile PHP 5.2.6: Laut Forschern und Censys beginnt der betroffene Bereich bei PHP 5.4. Das Dashboard zählt diese Version offenbar trotzdem mit, die Einordnung hängt also an dessen Methode.

Für PHP 8.2 bis 8.5 gibt es reguläre korrigierte Releases. PHP 8.2 wird allerdings nur noch bis zum 31. Dezember 2026 mit Sicherheitsupdates versorgt. PHP 8.1 und ältere Zweige liegen außerhalb des Upstream-Supports, für 7.4, 8.0 und 8.1 existieren nur Quellcode-Backports, und Distributionen oder Supportanbieter liefern teils eigene Korrekturen. Für PHP 5.4 bis 7.3 gibt es laut Censys keinen Fixpfad mehr.

Wer eine solche Version betreibt, kann deshalb nicht einfach das nächste offizielle PHP-Update installieren. Oft ist eine Migration auf einen unterstützten Zweig nötig, und das ist in gewachsenen Umgebungen der schwierigere Teil.

URSACHEN

Warum sind nach dem Fix noch so viele Systeme betroffen?

Die Censys-Auswertung liefert dafür keine vollständige Erklärung, denn sie zeigt den Zustand der Dienste, nicht die Abläufe ihrer Betreiber. Es gibt aber plausible Gründe, die nicht für jeden einzelnen Eintrag gelten müssen:

Ein PHP-Update ist nicht nur ein Paketupdate

In produktiven Umgebungen hängt PHP an Webserver, PHP-FPM-Pools, CMS, Plugins, Frameworks und eigenen Anwendungen. Updates werden deshalb oft erst getestet und in Wartungsfenstern ausgerollt. Bei einer kritischen Lücke braucht es dann aber eine Zwischenmaßnahme und einen klaren Zeitplan.

Unklar, wo überall PHP läuft

PHP kann in mehreren Versionen parallel, über PHP-FPM oder in Container-Images und Drittanbieterprodukten laufen. Ein korrigiertes Hostpaket hilft nicht, wenn ein Container seine eigene Runtime mitbringt.

Alte Anwendungen blockieren die Migration

Alte Frameworks und Erweiterungen sind oft nicht mit aktuellen PHP-Versionen kompatibel. Ein Wechsel von 7.4 auf 8.4 ist dann kein Routineeingriff. Eine nur mit einem ungepflegten Zweig lauffähige Anwendung muss modernisiert, isoliert oder ersetzt werden.

Hosting-Plattformen vergrößern den Aufwand

Auf Hostingplattformen laufen viele Websites mit unterschiedlichen Anforderungen und mehreren parallelen PHP-Runtimes. Betreiber müssen die tatsächlich genutzten Runtimes erfassen und sicherstellen, dass die Prozesse die neuen Versionen verwenden.

Der Patchstand ist von außen unklar

Eine alte Versionsnummer kann bereits einen Backport enthalten. Umgekehrt belegt eine neue Nummer nicht, dass jede Runtime und jeder Prozess aktualisiert wurde. Ein Teil des scheinbaren Rückstands kann deshalb an der externen Erkennung liegen.

Es wäre falsch, jeden Eintrag als nachlässigen Administrator zu bezeichnen. Genauso falsch wäre es, die Zahlen mit diesem Hinweis abzutun.

AUSWIRKUNG

Die eigentliche Gefahr: was danach passiert

PHP2Shell betrifft die Verarbeitung von Webanfragen in der PHP-Laufzeit. Unter geeigneten Bedingungen kann ein nicht authentifizierter Angreifer Code im Kontext des Webserver- oder PHP-Prozesses ausführen. Das ist nicht automatisch eine vollständige Übernahme des Servers: Welche Rechte ein Angreifer erhält und wie weit er sich bewegen kann, hängt von Berechtigungen, Isolation und Konfiguration ab. Möglich sind etwa das Sammeln von Systeminformationen, der Start weiterer Programme oder eine Webshell als späterer Zugang.

Zur tatsächlichen Ausnutzung hat Censys mehrere widersprüchliche Meldungen zusammengetragen. Amazon beobachtete Versuche in Honeypots seit dem 17. Oktober, watchTowr meldet Versuche gegen beide Lücken, VulnCheck sah einen erfolglosen Webshell-Versuch. Andere Stellen, darunter das Canadian Centre for Cyber Security, meldeten bis zum 21. Oktober keine aktive Ausnutzung, und beide CVEs standen laut Censys am 22. Oktober nicht im CISA-Katalog bekannter ausgenutzter Schwachstellen. Die Lage ist deshalb anhand der einzelnen Quellen und ihrer Zeitstempel zu beurteilen.

Wer eine betroffene Version öffentlich erreichbar betrieben hat, sollte bei Verdachtsmomenten auch auf mögliche Kompromittierung prüfen. Wie das geht, zeigt unser Beitrag PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab.

MASSNAHMEN

Was Betreiber daraus mitnehmen

Die Auswertung ist ein guter Anlass, die eigene PHP-Landschaft zu erfassen, statt sich an einer öffentlichen Zahl zu orientieren. Die konkreten Schritte, korrigierten Versionen und Praxisbefehle stehen im PHP2Shell-Hauptbeitrag. Drei Punkte sind hier besonders wichtig:

Alte Zweige nicht ignorieren

Bei PHP 7.4 und älter klären, ob ein bestätigter Backport existiert. Sonst eine Migration auf einen unterstützten Zweig einplanen. Dass ein Zweig seit Jahren ohne sichtbare Probleme läuft, macht ihn nicht sicher.

Fixstand der Plattform prüfen

Bei distributionsverwalteten Systemen zählen die Sicherheitsmeldungen und Paketstände des Anbieters. Ein zurückportierter Fix kann vorhanden sein, auch wenn die Versionsnummer abweicht.

Nicht auf die Statistik warten

Censys kann die weltweite Exposition schätzen, aber nicht die eigene Inventarisierung ersetzen. Verlässlich sind die eigenen Paketstände und die tatsächlich laufenden Runtimes.

BEI RDDZ

Was wir bei RDDZ daraus ableiten

Wir bieten bei RDDZ aktuell nur noch PHP ab Version 8.3 an. Ältere Zweige, wie sie in der Censys-Auswertung ein großer Teil des Bestands sind, gehören damit nicht zu unserem aktuellen Angebot.

Die Auswertung zeigt zugleich, warum die Frage nach dem Patchstatus nicht bei einer einzelnen Versionsnummer enden darf. In komplexeren Umgebungen müssen zusätzliche PHP-Runtimes, Container und Anwendungen berücksichtigt werden, und der Zustand einer öffentlich sichtbaren Runtime sagt nicht automatisch etwas über alle Komponenten eines Hosts aus.

Wichtig ist uns eine klare Trennung: Ein Sicherheitsupdate behebt die bekannte Schwachstelle in der korrigierten Runtime, ist aber kein rückwirkender Beweis dafür, dass ein System vorher nicht angegriffen wurde. Die öffentlichen Zahlen belegen außerdem nicht, dass ein bestimmter Anbieter oder eine bestimmte Infrastruktur kompromittiert ist. Sie sind ein ernstes Signal dafür, wie groß die Aufgabe ist, kritische Updates im gesamten Web zeitnah umzusetzen.

FAZIT

Das Problem ist größer als ein einzelner PHP-Patch

Mehr als 34 Millionen öffentlich erfasste PHP-Dienste melden laut Censys weiterhin eine Version aus dem betroffenen Bereich, und fast 50 Millionen weitere geben ihre Version nicht preis. Der hohe Anteil alter PHP-Zweige zeigt, dass es nicht nur um die Geschwindigkeit von Updates geht: Ein Teil der Webinfrastruktur hängt an Anwendungen und Laufzeiten, für die Sicherheitsupdates nicht mehr selbstverständlich verfügbar sind.

Die Zahlen dürfen nicht als garantiert verwundbare Server missverstanden werden. Die zentrale Aussage bleibt trotzdem: Eine Korrektur kann an einem Tag erscheinen, bis sie in Millionen Installationen, Containern und Hosting-Plattformen wirksam ist, dauert es deutlich länger. Entscheidend ist nicht, ob ein Patch existiert, sondern ob er auf jedem relevanten System angekommen ist und dort läuft.

QUELLEN

Quellen und weiterführende Informationen

Wissen Sie, welche PHP-Version Ihre Website nutzt?

Alte PHP-Zweige, Container und mehrere Runtimes sind schnell übersehen. Sprechen Sie uns an, wir unterstützen bei Bestandsaufnahme, Migration und Betrieb.

Der Beitrag PHP2Shell: Über 34 Millionen PHP-Dienste melden noch betroffene Versionen – was die Zahlen bedeuten erschien zuerst auf RDDZ.

PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab

dennis_rddz — Thu, 22 Oct 2026 21:16:55 +0000

SICHERHEIT · PHP · STAND 22.10.2026

PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab

Die kritischen PHP-Schwachstellen PHP2Shell (CVE-2026-109618 und CVE-2026-109619) sind öffentlich bekannt, Sicherheitsanbieter berichten von Ausnutzungsversuchen. Wer inzwischen aktualisiert hat, sollte noch eine Frage klären: Gibt es Hinweise darauf, dass vor dem Update bereits jemand versucht hat, die Lücken auszunutzen? Wir zeigen, welche Spuren sich prüfen lassen, welche Befehle helfen und wo die Grenzen liegen.

SPURENSUCHE · PHP2SHELL

● Erste Orientierung

17.10.2026

Frühester beobachteter Versuch

3 Stufen

Exploit, Versuch, Erfolg

Mehrere

Datenquellen kombinieren

Webserver-Logs● Body oft nicht geloggt

PHP-Fehlerlogs● Fehler auch ohne Angriff

Prozesse● nur Momentaufnahme

Dateien● Zeitstempel manipulierbar

Netzwerk● nur aktueller Zustand

Jede Quelle hat Grenzen. Erst das Zusammenspiel liefert belastbare Hinweise.

✓ Praxisbefehle für Debian und Ubuntu

✓ Prüfzeitraum ab 17. Oktober 2026

✓ Mit ehrlichen Grenzen der Analyse

✓ Vorgehen bei konkretem Verdacht

LAGE

Was ist über tatsächliche Angriffsversuche bekannt?

Ein erfolgreiches Update behebt die bekannte Schwachstelle in der aktualisierten PHP-Laufzeit. Es kann aber nicht rückwirkend ausschließen, dass ein Angreifer vorher bereits Code ausgeführt, Dateien verändert oder weitere Zugänge eingerichtet hat. Die Hintergründe zu den Schwachstellen und den korrigierten Versionen findest du in unserem PHP2Shell-Hauptbeitrag.

PHP2Shell umfasst zwei kritische Schwachstellen im PHP-Kern. Unter bestimmten Voraussetzungen kann ein nicht authentifizierter Angreifer darüber Code auf einem verwundbaren System ausführen. Am 21. Oktober 2026 wurden die korrigierten PHP-Versionen veröffentlicht.

Amazon Threat Intelligence berichtet von einem Ausnutzungsversuch gegen die eigene Honeypot-Infrastruktur bereits am 17. Oktober sowie von weiteren Aktivitäten am 21. Oktober. Die ersten öffentlich kursierenden Proofs of Concept tauchten laut Amazon noch am 21. Oktober gegen 02:00 UTC auf, also vor der Veröffentlichung der Updates um 14:00 UTC. Das PHP-Projekt erklärte laut Tenable allerdings, in den ihm bekannten PoCs zum Zeitpunkt der Veröffentlichung keine funktionsfähigen Exploits gefunden zu haben. Die Funktionsfähigkeit einzelner Codes ist also nicht unabhängig bestätigt, und angeblicher Exploit-Code im Netz kann selbst Schadsoftware enthalten.

Es geht damit nicht mehr nur um eine theoretische Angriffsmöglichkeit, denn es gibt konkrete Berichte über Versuche. Allerdings müssen drei Dinge auseinandergehalten werden:

Ein Exploit ist verfügbar

Ein technischer Ansatz zur Ausnutzung ist beschrieben oder im Umlauf. Ob konkreter Code funktioniert, ist damit noch nicht gesagt.

Ein Angriff wurde beobachtet

Ein System hat eine Anfrage oder Aktivität erkannt, die mit dem Exploit zusammenhängt. Das beweist keine erfolgreiche Kompromittierung.

Ein Angriff war erfolgreich

Es gibt belastbare Hinweise, dass tatsächlich Code ausgeführt oder das System kompromittiert wurde.

Diese Aussagen sind nicht gleichbedeutend. Umgekehrt lässt sich eine frühere Kompromittierung nicht allein deshalb ausschließen, weil keine offensichtlichen Fehlermeldungen gefunden werden.

SCHRITT 1

Zuerst feststellen, welche Systeme betroffen waren

Bevor Logs ausgewertet werden, sollte klar sein, welche PHP-Installationen überhaupt exponiert waren. Dabei reicht es nicht, nur den Hauptwebserver zu betrachten. PHP kann auf einem System in mehreren Versionen und Betriebsarten installiert sein, und Anwendungen können ihre eigene Runtime mitbringen. Relevant sind insbesondere:

PHP-FPM hinter Nginx oder Apache
Apache mit mod_php
php-cgi
PHP innerhalb von Docker-Containern
PHP-basierte Verwaltungsoberflächen
Drittanbieterprodukte mit integrierter PHP-Laufzeit
ältere Anwendungen auf nicht mehr unterstützten PHP-Versionen

Die PHP-Sicherheitsmeldung nennt diese Betriebsarten ausdrücklich. Besonders kritisch ist laut PHP die Konfiguration mit Apache mod_php, weil ein präparierter Request die Schwachstelle auslösen kann, bevor der eigentliche Anwendungscode ausgeführt wird.

🔍

Installierte Versionen und Prozesse

Auf Debian und Ubuntu liefern diese Befehle eine erste Übersicht:

Bash

php -v

dpkg -l | grep -E 'php[0-9.]|php-fpm|libapache2-mod-php'

ps -eo pid,ppid,user,lstart,args \
  | grep -E '[p]hp-fpm|[p]hp-cgi|[a]pache2|[h]ttpd'

Wichtig: php -v zeigt die Version der PHP-CLI. Diese muss nicht der Version entsprechen, die eine Website tatsächlich verwendet. Auch Paketlisten reichen nicht, um PHP in Containern oder Drittanbieterprodukten zu erfassen.

📦

Docker

Zeigt zunächst nur laufende Container und deren Images:

Bash

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

Ob und welche PHP-Version enthalten ist, muss anschließend innerhalb der jeweiligen Runtime oder anhand des Images geprüft werden, etwa mit docker exec php -v.

SCHRITT 2

Webserver-Logs auf auffällige Requests untersuchen

Ein wichtiger Ansatzpunkt sind die HTTP-Zugriffe. Bei PHP2Shell sind insbesondere POST-Anfragen mit multipart/form-data relevant, das Format, das etwa bei Datei-Uploads verwendet wird. Außerdem ist das Feld PHP_SESSION_UPLOAD_PROGRESS von Interesse: Amazon Threat Intelligence empfiehlt ausdrücklich, nach POST-Anfragen zu suchen, die dieses Feld enthalten, und Webserver-Logs auf verdächtige Aktivitäten zu prüfen.

Das bedeutet nicht, dass jede solche Anfrage bösartig ist. Uploads gehören bei vielen Anwendungen zum normalen Betrieb. Entscheidend sind Kontext, Häufigkeit, Aufbau der Anfrage und mögliche Folgeaktivitäten.

Die Grenze klassischer Access-Logs

Klassische Access-Logs enthalten die HTTP-Methode, den Pfad, den Statuscode und die Antwortgröße, aber weder den Content-Type noch den Inhalt des Request-Bodys. Ein einfacher Textfilter nach multipart/form-data findet dort deshalb nichts, und ein Filter nach POST liefert auf aktiven Websites Tausende Treffer. Wenn der Inhalt einer Anfrage nicht protokolliert wurde, kann ein einfacher Textfilter den Angriff nicht erkennen.

Systeme mit zentraler Protokollierung, vorgeschaltetem Reverse Proxy, CDN oder Web Application Firewall müssen gegebenenfalls an mehreren Stellen untersucht werden.

🔒

POST-Anfragen mit Serverfehler

Als grobe Orientierung lassen sich POST-Anfragen herausfiltern, die mit HTTP 500 endeten. Das Beispiel geht vom üblichen Combined-Log-Format aus, bei dem der Statuscode das neunte Feld ist:

Bash

sudo zgrep -h '"POST ' \
  /var/log/nginx/access.log* \
  /var/log/apache2/access.log* 2>/dev/null \
  | awk '$9 == 500' | head -50

Ein Treffer ist kein Beweis, Treffer häufen sich aber auch bei fehlerhaften Anwendungen. Abweichende Log-Formate müssen angepasst werden.

🔍

Nach PHP_SESSION_UPLOAD_PROGRESS suchen

Das funktioniert nur dort, wo Request-Bodys oder WAF-Ereignisse protokolliert werden, etwa in ModSecurity-Audit-Logs (Pfad je nach Setup) oder in einer vorgeschalteten WAF:

Bash

sudo zgrep -Ein \
  'PHP_SESSION_UPLOAD_PROGRESS' \
  /var/log/nginx/* \
  /var/log/apache2/* \
  2>/dev/null

Ein Treffer ist ein Anlass zur näheren Untersuchung, kein Beweis. Ein fehlender Treffer ist keine Entwarnung, denn bei nicht geloggtem Body kann der Begriff schlicht nicht vorkommen.

SCHRITT 3

PHP- und Webserver- Fehlerlogs prüfen

Beide Schwachstellen betreffen interne Abläufe in PHP. Deshalb können Fehler rund um die Verarbeitung einer Anfrage Hinweise liefern, zum Beispiel:

Auffällige Häufungen von Speicherfehlern und Meldungen über Speichererschöpfung
Ungewöhnliche Abstürze oder Segmentation Faults
Neustarts von PHP-FPM-Workern
Wiederholte HTTP-500-Antworten
Ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies (Hinweis von Wiz)
Zeitlich auffällige Kombinationen aus HTTP-Anfragen und PHP-Fehlern

Solche Ereignisse sind nicht automatisch ein Angriff. Speicherfehler können auch durch reguläre Last, fehlerhafte Anwendungen oder zu knapp konfigurierte Ressourcen entstehen. Umgekehrt weist Datadog darauf hin, dass erfolgreiche Ausnutzung den Worker nicht zwingend zum Absturz bringt. Fehlende Fehlermeldungen sind deshalb keine Entwarnung.

📜

Systemmeldungen durchsuchen

Auf Systemen mit systemd lassen sich die vergangenen Tage so untersuchen. Den Zeitraum bitte an den tatsächlichen Untersuchungszeitraum anpassen:

Bash

sudo journalctl \
  --since "2026-10-17 00:00:00" \
  --until "2026-10-22 23:59:59" \
  | grep -Ei \
  'php|php-fpm|out of memory|memory exhausted|segfault|fatal error'

📁

Eigene Logdateien nicht vergessen

PHP kann Fehler auch in eigene Dateien schreiben. Auf Debian und Ubuntu liegen die Logs von PHP-FPM meist unter /var/log/php-fpm.log (zum Beispiel /var/log/php8.4-fpm.log), bei Apache mit mod_php landen PHP-Fehler im Apache-Error-Log, etwa /var/log/apache2/error.log.

Der genaue Speicherort hängt von der Konfiguration (error_log) ab und sollte pro System geprüft werden.

Worauf kommt es bei der Auswertung an?

Ein einzelner PHP-Fehler ist noch kein Nachweis einer Kompromittierung. Verdächtiger wäre eine zeitliche Abfolge aus (1) einer ungewöhnlichen POST-Anfrage, (2) einem auffälligen PHP-Fehler, (3) dem Start eines bislang nicht beobachteten Prozesses und (4) einer unerwarteten Dateiänderung oder ausgehenden Netzwerkverbindung. Eine solche Kette ist ein Ansatzpunkt für eine Incident-Response-Untersuchung und sollte anhand der vorhandenen Daten verifiziert werden.

SCHRITT 4

Prüfen, ob PHP ungewöhnliche Prozesse gestartet hat

Eine erfolgreiche Remote-Code-Ausführung kann dazu führen, dass ein PHP-Prozess weitere Programme startet. Deshalb lohnt sich ein Blick auf die Prozesshierarchie. Auch die Erkennungsansätze etwa von Elastic setzen genau hier an: Auffällig sind Shells, Skript-Interpreter oder Download-Werkzeuge (curl, wget), die von PHP-FPM oder einem Webserver-Prozess gestartet werden, sowie Programme, die aus /tmp, /dev/shm oder dem Webroot laufen. Aufklärungsbefehle wie id, whoami oder uname -a unter dem Webserver-Benutzer sind ebenfalls ein Warnsignal. Sie können in legitimen Anwendungen vorkommen und müssen im Kontext des Dienstes bewertet werden.

Bash

ps -eo pid,ppid,user,lstart,args --forest

Achte auf unerwartete Kindprozesse von PHP-FPM oder Apache, Prozesse unter dem Webserver-Benutzer, die nicht zum Betrieb gehören, unbekannte Skripte oder ausführbare Dateien, ungewöhnliche Prozessketten und Prozesse, deren Startzeit zu verdächtigen HTTP-Anfragen passt.

Der Befehl zeigt nur eine Momentaufnahme: Bereits beendete Prozesse erscheinen nicht mehr. Wer vor dem Angriff keine Prozessaktivitäten protokolliert hat, kann einen beendeten Prozess normalerweise nicht allein durch eine nachträgliche Abfrage rekonstruieren. Hilfreicher sind historische Daten aus Prozessüberwachung, Audit-Protokollierung oder einem Endpoint-Detection-System, sofern sie schon vor dem Vorfall aktiv waren.

SCHRITT 5

Webverzeichnisse auf unerwartete Änderungen prüfen

Wenn ein Angreifer Code ausführen konnte, könnte er Dateien verändert oder zusätzliche Skripte abgelegt haben. Untersucht werden sollten insbesondere Webroots und Upload-Verzeichnisse, Verzeichnisse mit PHP-Skripten, temporäre Verzeichnisse, vom Webserver beschreibbare Verzeichnisse sowie Konfigurationsdateien und geplante Aufgaben. Dabei sind reguläre Änderungen durch Deployments, CMS-Updates, Uploads und Wartung von unbekannten Änderungen zu unterscheiden.

📄

Kürzlich veränderte Dateien

Für ein Webverzeichnis unter /var/www lassen sich Skripte suchen, die seit dem 17. Oktober geändert wurden. Das ist genauer als ein relativer Zeitraum wie -mtime -7, der mit jedem Tag verrutscht:

Bash

sudo find /var/www -type f \
  \( -name '*.php' -o -name '*.phtml' \) \
  -newermt '2026-10-17' -ls

⏰

Geplante Aufgaben

Neue Cron-Einträge können auf Persistenz hinweisen:

Bash

ls -la /etc/cron.d /var/spool/cron/crontabs

Besonders prüfenswert sind unbekannte PHP-Dateien, unerwartete Änderungen an vorhandenen Skripten sowie neue Dateien in Verzeichnissen, in denen normalerweise keine ausführbaren Skripte liegen. Eine große Trefferliste ist bei aktiv betriebenen Websites normal, vergleiche sie deshalb mit bekannten Deployments, Paketupdates und Backups.

Was dieser Dateicheck nicht leisten kann

Ein Angreifer kann Dateien verändern, Zeitstempel beeinflussen oder Code an vorhandene Dateien anhängen. Umgekehrt erzeugen normale Updates viele legitime Änderungen. Der Befehl ist deshalb nur eine erste Bestandsaufnahme. Belastbarer sind bekannte Sollzustände, Versionskontrolle, vertrauenswürdige Backups oder Integritätsprüfungen.

SCHRITT 6

Ausgehende Netzwerkverbindungen untersuchen

Ein kompromittierter Webserver könnte versuchen, weitere Systeme zu erreichen, Daten zu übertragen oder zusätzliche Dateien abzurufen. Deshalb sollte geprüft werden, ob PHP-Prozesse oder andere Prozesse unter dem Webserver-Benutzer ungewöhnliche ausgehende Verbindungen aufbauen.

Bash

sudo ss -tpn

Der Befehl zeigt aktuelle TCP-Verbindungen und, soweit verfügbar, die zugehörigen Prozesse. Auch hier gilt: Es ist nur der aktuelle Zustand, eine bereits beendete Verbindung lässt sich damit nicht nachweisen. Für eine rückwirkende Untersuchung sind vorhandene Firewall-, DNS-, Proxy-, NetFlow- oder EDR-Protokolle wesentlich wertvoller. Ein Webserver kann außerdem durch reguläre API-Aufrufe, Updates oder externe Dienste legitime Verbindungen aufbauen, auffällige Verbindungen müssen deshalb im Zusammenhang mit Prozessen und dem jeweiligen Dienst bewertet werden.

ZEITRAUM

Den Zeitraum vor dem Patch nicht vergessen

Wer am 21. Oktober oder später aktualisiert hat, sollte bei einer rückwirkenden Untersuchung nicht nur die Zeit nach dem Update betrachten. Amazon Threat Intelligence hat einen Ausnutzungsversuch bereits am 17. Oktober 2026 beobachtet und empfiehlt, Untersuchungen ab diesem Datum zu beginnen. Je nach Systemhistorie kann ein sinnvoller erster Prüfzeitraum deshalb bis zum 17. Oktober zurückreichen, bei konkreten Hinweisen auch weiter. Angreifer könnten eine Schwachstelle außerdem schon vor der öffentlichen Bekanntgabe gekannt haben.

Eine sinnvolle Zeitleiste umfasst:

den Zeitraum vor der öffentlichen Veröffentlichung,
den Tag der Veröffentlichung und der Verfügbarkeit von Exploits,
den Zeitpunkt der eigenen Aktualisierung,
die Zeit nach dem Update, falls weiterhin verdächtige Aktivitäten auftreten.

Die Grenzen sind klar: Wenn Logs bereits rotiert wurden, Request-Bodys nicht protokolliert wurden oder keine Prozessüberwachung existierte, kann die rückwirkende Prüfung unvollständig bleiben.

VERDACHT

Was tun bei einem konkreten Verdacht?

Wenn mehrere Indikatoren zusammenpassen, sollte die Untersuchung nicht bei einzelnen Shell-Befehlen enden.

Beweise sichern

Webserver-, PHP-, System-, Firewall- und Sicherheitslogs sichern. Zeitstempel, betroffene Systeme und auffällige Ereignisse dokumentieren. Vorschnelle Bereinigungen vermeiden, sie können Beweise zerstören.

System bewerten und isolieren

Ist eine erfolgreiche Kompromittierung wahrscheinlich, das System nach einem geeigneten Incident-Response-Verfahren isolieren und dabei die Auswirkungen auf produktive Dienste berücksichtigen.

Nicht nur nach Schadsoftware suchen

Ein Angreifer muss keine dauerhafte Datei hinterlassen. Auch Prozesse, Benutzerkonten, SSH-Zugänge, geplante Aufgaben, Dienste, Konfigurationsänderungen und ausgehende Verbindungen gehören in die Untersuchung.

Zugangsdaten und Geheimnisse bewerten

Bei bestätigter oder stark vermuteter Kompromittierung prüfen, welche Zugangsdaten, Tokens oder API-Schlüssel das System erreichen konnte. Je nach Befund ist eine Rotation nötig.

Wiederherstellung nicht mit Patchen verwechseln

Ein Sicherheitsupdate behebt die bekannte Schwachstelle. Bei bestätigter Kompromittierung müssen zusätzlich unerwünschte Änderungen und Persistenzmechanismen beseitigt werden. In schwerwiegenden Fällen kann ein Neuaufbau aus einem vertrauenswürdigen Zustand sicherer sein, als nur verdächtige Dateien zu löschen.

GRENZEN

Warum es keine einfache Entwarnung gibt

Die beschriebenen Prüfungen liefern Hinweise, aber keine universelle Garantie. Angriffsspuren können in Webserver-Logs fehlen, weil der Request-Body nicht protokolliert wurde. Laut Wiz laufen die Schwachstellen unterhalb der Anwendungsebene, Anwendungslogs zeigen deshalb oft wenig. Prozessinformationen gehen verloren, wenn keine historischen Daten aufgezeichnet wurden, und Dateien können verändert oder entfernt worden sein, bevor die Untersuchung beginnt.

Umgekehrt können legitime Uploads, PHP-Fehler und reguläre Deployments einzelne Indikatoren auslösen, ohne dass ein Angriff stattgefunden hat. Die beste Bewertung entsteht aus mehreren unabhängigen Datenquellen: HTTP-Zugriffen, PHP-Fehlern, Prozessaktivitäten, Dateiänderungen, Netzwerkdaten und bekannten Änderungen am System.

Liegen konkrete Hinweise auf eine Kompromittierung vor, ist eine strukturierte Incident-Response-Untersuchung sinnvoller als der Versuch, mit einem einzelnen Befehl Sicherheit zu beweisen.

BEI RDDZ

Was wir bei RDDZ empfehlen

Wir haben unsere Systeme am 21. Oktober 2026 um 18:00 Uhr gepatcht. Das war der entscheidende Schritt, um die bekannten Schwachstellen in den aktualisierten Umgebungen zu beheben. Eine rückwirkende Prüfung auf frühere Ausnutzung ist davon getrennt zu betrachten.

Wir empfehlen Betreibern deshalb, nicht nur die installierten PHP-Versionen zu kontrollieren, sondern auch die vor dem Update verfügbaren Protokolle und Systeminformationen zu prüfen. Bei öffentlich erreichbaren Systemen sollten insbesondere ungewöhnliche HTTP-Anfragen, auffällige PHP-Fehler, unerwartete Prozesse und unbekannte Dateiänderungen untersucht werden.

Ein erfolgreiches Update ist notwendig. Eine belastbare Aussage über eine mögliche frühere Kompromittierung erfordert jedoch eine separate Untersuchung.

FAZIT

Patchen ist der Anfang, nicht die gesamte Untersuchung

PHP2Shell zeigt, wie schnell eine kritische Schwachstelle in einer weit verbreiteten Laufzeitumgebung zu einem praktischen Sicherheitsproblem werden kann. Die verfügbaren Updates sollten unverzüglich installiert werden. Zusätzlich lohnt sich eine rückwirkende Prüfung, insbesondere wenn Systeme vor dem Patch öffentlich erreichbar waren und relevante Logs noch vorhanden sind.

Webserver- und PHP-Logs, Prozessaktivitäten, Dateisystemänderungen und ausgehende Netzwerkverbindungen liefern zusammen mögliche Hinweise auf einen Angriff. Keine dieser Quellen reicht für sich allein aus, um eine Kompromittierung sicher nachzuweisen oder auszuschließen. Wer verdächtige Aktivitäten findet, sollte die Hinweise sichern, zeitlich korrelieren und bei konkretem Verdacht eine strukturierte Incident-Response-Untersuchung durchführen.

QUELLEN

Weiterführende Quellen

Verdacht auf einen Angriff oder Hilfe bei der Prüfung?

Logs, Prozesse und Dateien sauber auswerten ist Aufwand. Sprechen Sie uns an, wir unterstützen bei Prüfung, Absicherung und Betrieb.

Der Beitrag PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab erschien zuerst auf RDDZ.

PHP2Shell: Kritische PHP-Sicherheitslücken gefährden Websites und Server

dennis_rddz — Wed, 21 Oct 2026 15:55:39 +0000

SICHERHEIT · PHP · UPDATE 22.10.2026

PHP2Shell: Kritische PHP-Sicherheitslücken gefährden Websites und Server

Zwei kritische Sicherheitslücken im PHP-Kern sorgen für Alarm: PHP2Shell, geführt als CVE-2026-109618 und CVE-2026-109619. Unter bestimmten Voraussetzungen können Angreifer aus der Ferne und ohne Anmeldung Code auf einem verwundbaren System ausführen. Betroffen sind PHP-Versionen ab 5.4, also auch viele ältere Installationen.

PHP2SHELL · 2 CVES

● Updates seit 21.10.2026

9,2

CVSS 4.0, kritisch

Ohne Login

Remote-Codeausführung

ab 5.4

Betroffene Versionen

PHP 8.5 ✓ 8.5.12

PHP 8.4 ✓ 8.4.27

PHP 8.3 ✓ 8.3.36

PHP 8.2 ✓ 8.2.35

PHP 8.1 und älter ● kein Upstream-Fix

Entscheidend: korrigierte Version installieren, PHP-Prozesse neu starten und prüfen, was tatsächlich läuft.

✓ Korrigierte PHP-Versionen seit 21. Oktober 2026

✓ Betroffen: mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed

✓ Kein vollständiger Schutz ohne Update

✓ Mit Praxisbefehlen und Übergangsmaßnahmen

UPDATE 22.10.2026

Neue Erkenntnisse zur Angriffslage

Seit unserer ursprünglichen Veröffentlichung liegen weitere technische Informationen zu PHP2Shell vor. Die Sicherheitslücken CVE-2026-109618 und CVE-2026-109619 sind inzwischen genauer dokumentiert. Außerdem haben Sicherheitsforscher und Sicherheitsorganisationen ihre Einschätzungen zur möglichen Ausnutzung veröffentlicht.

Die wichtigste Nachricht bleibt: Die PHP-Projektseite stellt korrigierte Versionen bereit, und betroffene Systeme sollten aktualisiert werden. Darüber hinaus sollten Betreiber prüfen, ob ihre Systeme bereits vor der Aktualisierung verdächtige Aktivitäten gezeigt haben.

Was ist inzwischen über mögliche Angriffe bekannt?

Sicherheitsforscher haben die Schwachstellen technisch untersucht, und es sind Berichte zu Exploit-Ansätzen im Umlauf. Das PHP-Projekt erklärte laut Tenable allerdings, in den ihm bekannten Proof-of-Concepts zum Zeitpunkt der Veröffentlichung keine funktionsfähigen Exploits gefunden zu haben. Angeblicher Exploit-Code im Netz sollte nicht unbesehen ausgeführt werden, er kann selbst Schadsoftware enthalten.

Zu tatsächlichen Angriffen unterscheiden sich die Berichte: Amazon Threat Intelligence meldet erste Angriffsversuche gegen sein Honeypot-Netz bereits am 17. Oktober 2026, also rund vier Tage vor der Veröffentlichung, und weitere Versuche am 21. Oktober von offenbar mehreren Akteuren. watchTowr berichtet von aktiven Ausnutzungsversuchen, Cloudflare von Angriffsverkehr gegen Kundensysteme. Ob die Versuche bei echten Systemen erfolgreich gewesen wären, ist nach Angaben von Amazon offen. Ein bestätigter erfolgreicher Angriff auf ein konkretes produktives System ist uns nicht bekannt.

Ein öffentlich verfügbarer Exploit, ein erfolgreicher Test im Labor und ein bestätigter Angriff auf ein produktives System sind drei unterschiedliche Dinge. Für Betreiber bedeutet das: Die Gefahr sollte nicht unterschätzt werden. Aus den bisherigen Meldungen lässt sich aber auch nicht ableiten, dass jeder verwundbare Server tatsächlich angegriffen wurde.

🔧

Warum die verwendete PHP-Umgebung wichtig ist

Die Sicherheitslücken betreffen die PHP-Laufzeit selbst und nicht nur ein bestimmtes Content-Management-System oder Plugin. Deshalb reicht es nicht, ausschließlich WordPress, TYPO3 oder eine andere Anwendung zu aktualisieren.

Laut dem PHP-Projekt sind unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed relevant. Das PHP-Team stuft insbesondere Apache-Konfigurationen mit mod_php als risikoreich ein: Ein präparierter Request kann dort die Schwachstelle auslösen, bevor der eigentliche Anwendungscode ausgeführt wird.

Auch PHP-Runtimes, die in Containern, Verwaltungsoberflächen oder Drittanbieterprodukten gebündelt sind, müssen separat berücksichtigt werden. Ein aktualisiertes PHP-Paket auf dem Host bedeutet nicht automatisch, dass jede mitgelieferte Runtime ebenfalls korrigiert ist.

📦

Neuer Stand bei den Distributionen

Seit der ersten Veröffentlichung sind weitere Korrekturen erschienen. Laut den Herstellerseiten (Stand 22.10.2026):

Debian 12 Bookworm: 8.2.35-1~deb12u1 (DLA-4848-1)
Debian 13 Trixie: 8.4.27-1~deb13u1 (DSA-6574-1)
Ubuntu 22.04 LTS und 24.04 LTS: korrigierte Pakete (USN-8948-1 und USN-8948-2)
Debian Unstable/Testing: zum Prüfzeitpunkt noch nicht korrigiert

Details stehen im Abschnitt „Korrigierte Versionen“ weiter unten.

Gepatcht bedeutet nicht automatisch, dass es vorher keinen Angriff gab

Wir haben unsere Systeme am 21. Oktober 2026 um 18:00 Uhr auf den korrigierten Stand gebracht. Damit haben wir die notwendigen Aktualisierungen zeitnah nach Veröffentlichung der Sicherheitskorrekturen umgesetzt.

Ein Patch schließt die bekannte Schwachstelle in der aktualisierten Runtime. Er kann jedoch nicht rückwirkend ausschließen, dass ein System vor dem Update bereits angegriffen wurde oder dass ein Angreifer zuvor Dateien, Konten oder andere Zugänge verändert hat. Amazon empfiehlt deshalb, Untersuchungen nicht erst ab dem Tag der Veröffentlichung zu beginnen, sondern ab dem 17. Oktober 2026, dem frühesten bekannten Angriffsversuch.

Bei einem konkreten Verdacht sind zusätzlich die verfügbaren Webserver- und PHP-Logs, Prozessaktivitäten und Dateiänderungen zu untersuchen. Auffälligkeiten müssen zeitlich eingeordnet und mit regulären Deployments sowie Wartungsarbeiten abgeglichen werden. Umgekehrt gilt auch: Wenn keine verdächtigen Einträge gefunden werden, ist das allein noch kein Beweis dafür, dass es keinen Angriff gab.

Zum Zeitpunkt dieser Aktualisierung liegen uns keine Erkenntnisse vor, die wir als Beleg für eine erfolgreiche Ausnutzung auf unseren Systemen veröffentlichen könnten. Das ist ausdrücklich keine allgemeine Garantie, dass eine frühere Ausnutzung allein durch das Einspielen eines Updates ausgeschlossen wäre.

Was Administratoren jetzt zusätzlich prüfen sollten

Neben dem Update der PHP-Runtime empfehlen wir, die eigene Umgebung systematisch zu kontrollieren:

Alle PHP-Runtimes erfassen: Dazu gehören auch alternative PHP-Versionen, PHP-FPM-Pools, Container und in Drittanbieterprodukten gebündelte Laufzeiten.
Laufende Version kontrollieren: Prüfen, ob die korrigierte Version tatsächlich von den Webanwendungen verwendet wird und ob betroffene Prozesse nach dem Update neu gestartet wurden.
Webserver- und PHP-Logs prüfen: Auffällige Requests, ungewöhnliche Fehlerhäufungen und zeitlich zusammenhängende Ereignisse können Ansatzpunkte für eine Untersuchung liefern. Einzelne HTTP-Fehler sind für sich genommen kein Beweis für einen Angriff.
Prozesse und Dateien kontrollieren: Ungewöhnliche Kindprozesse von PHP oder dem Webserver, unerwartete Skripte im Webverzeichnis, neue geplante Aufgaben oder unbekannte Dienste sollten untersucht werden.
Bei konkretem Verdacht Beweise sichern: Logs und relevante Systeminformationen sollten gesichert werden, bevor Bereinigungsmaßnahmen Spuren verändern. Bei belastbaren Hinweisen sollte das betroffene System nach einem geeigneten Incident-Response-Verfahren isoliert und untersucht werden.

Ausführliche Anleitung: Wie du Logs, Prozesse, Dateien und Netzwerkverbindungen prüfst, welche Befehle helfen und wo die Grenzen liegen, zeigen wir in unserem Folgebeitrag PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab.

Es gibt keine einzelne Logzeile und keinen einfachen Test, der zuverlässig beweist, dass PHP2Shell ausgenutzt wurde oder nicht. Die Bewertung muss mehrere Datenquellen und den konkreten Aufbau des Systems berücksichtigen.

Fazit des Updates

PHP2Shell bleibt eine kritische Sicherheitsmeldung, die eine schnelle Aktualisierung und eine sorgfältige Prüfung der betroffenen Umgebungen erfordert. Die korrigierten PHP-Versionen sind verfügbar; zusätzlich sollten Betreiber mögliche frühere Angriffe nicht allein deshalb ausschließen, weil das Update inzwischen installiert ist.

Wir unterscheiden dabei bewusst zwischen der Behebung der bekannten Schwachstelle und der separaten Frage, ob es vor dem Update Hinweise auf eine Ausnutzung gab.

EINORDNUNG

Was ist passiert?

Besonders brisant: Die Schwachstellen liegen im PHP-Laufzeitsystem selbst, nicht in einem einzelnen Plugin oder einer einzelnen Website. Damit können Webserver, Content-Management-Systeme und Anwendungen betroffen sein, bei denen PHP im Hintergrund läuft.

📅

20. Oktober 2026: Vorankündigung

Das PHP-Projekt kündigt ein außerplanmäßiges Sicherheitsupdate für zwei kritische Schwachstellen an. Zuvor waren Hinweise auf die Lücken vorzeitig öffentlich aufgetaucht, die Veröffentlichung wurde deshalb vorgezogen.

✅

21. Oktober 2026: Details und Updates

Das PHP-Projekt veröffentlicht die Details und die korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Schweregrad und Ausnutzung

Das PHP-Projekt bewertet beide Schwachstellen mit CVSS 4.0 9,2 (kritisch). Auch CERT-EU und das BSI nennen 9,2. Die Bewertung weist darauf hin, dass für einen Angriff weder eine Anmeldung noch eine Interaktion eines Nutzers nötig ist.

Zur Ausnutzung hat sich die Lage seit der Veröffentlichung weiterentwickelt. Die aktuellen Erkenntnisse fassen wir im Update vom 22. Oktober 2026 weiter oben zusammen.

Der Name PHP2Shell ist ein griffiger Begriff aus der Sicherheitsbranche, den das PHP-Projekt selbst nicht verwendet. Technisch maßgeblich sind die beiden CVE-Nummern.

DIE SCHWACHSTELLEN

Zwei Fehler im PHP-Kern

💥

CVE-2026-109618: Speichermangel

Wenn PHP während der Vorbereitung eines Requests nicht genug Speicher hat, kann der Request abgebrochen werden, obwohl interne Daten noch nicht vollständig initialisiert sind. Die anschließende Bereinigung behandelt diese Daten dann, als wären sie gültig. Das kann zu einer Speicherbeschädigung und im Ergebnis zu Codeausführung führen.

Das PHP-Projekt hat die Ausnutzung ohne Anmeldung über HTTP gegen mod_php mit Standardeinstellungen bestätigt.

🔄

CVE-2026-109619: veralteter Zustand

Interner Zustand eines Requests kann erhalten bleiben, obwohl der zugehörige Speicher bereits freigegeben wurde. Eine spätere Anfrage desselben Workers kann diesen veralteten Zustand verwenden, bevor er zurückgesetzt wird.

Mögliche Folgen sind Codeausführung mit den Rechten des Webserver-Prozesses und das Auslesen von Speicherinhalten, etwa Zugangsdaten oder Tokens aus anderen Requests.

Die genauen Voraussetzungen unterscheiden sich, deshalb muss nicht jede Installation auf identische Weise betroffen sein. Besonders hoch ist das Risiko laut PHP-Projekt bei Apache mit mod_php. Aber auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed müssen überprüft werden.

BETROFFENE VERSIONEN

Sind wirklich 20 Jahre PHP betroffen?

Der mögliche Versionsbereich reicht sehr weit zurück. Wiz und Sansec nennen PHP-Versionen ab 5.4 bis einschließlich 8.5.11 als betroffen. CERT-EU sprach in seiner Meldung allgemein von PHP ab Version 5. Das umfasst einen Zeitraum von etwa zwei Jahrzehnten.

Das heißt nicht, dass jede jemals veröffentlichte PHP-Version heute noch läuft oder auf gleiche Weise aktualisiert werden kann. Wichtig ist die Unterscheidung zwischen betroffen, noch unterstützt und bereits korrigiert:

Für die unterstützten Zweige PHP 8.2 bis 8.5 hat das PHP-Projekt Updates veröffentlicht. PHP 8.2 wird nur noch bis zum 31. Dezember 2026 mit Sicherheitsupdates versorgt.
Für PHP 8.1 und älter gibt es vom PHP-Projekt keine regulären Updates. Für 7.4, 8.0 und 8.1 hat das Sicherheitsteam allerdings minimale Quellcode-Backports bereitgestellt, gedacht für Nutzer, die PHP selbst bauen und keinen LTS-Anbieter haben.
Einige Linux-Distributionen und LTS-Anbieter liefern eigene Korrekturen. Ob eine konkrete Installation abgesichert ist, muss anhand des Paketstands und des Anbieters geprüft werden.

Gerade bei älteren Websites, gewachsenen Kundenprojekten und Anwendungen, die seit Jahren unverändert laufen, lohnt sich deshalb ein genauer Blick auf die eingesetzte PHP-Version.

KORRIGIERTE VERSIONEN

Welche PHP-Versionen schließen die Lücken?

Das PHP-Projekt hat am 21. Oktober 2026 diese Versionen veröffentlicht. Sie beheben CVE-2026-109618 und CVE-2026-109619:

PHP-Zweig	Korrigierte Version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Wer PHP selbst kompiliert oder über eigene Runtime-Images bereitstellt, muss sicherstellen, dass die korrigierte Version tatsächlich in das laufende System übernommen wird. Das gilt auch für Container, deren Image neu gebaut und ausgerollt werden muss.

🌀

Debian: Korrigierte Pakete verfügbar

Bei Debian kann die Korrektur in einem eigenen Paket stecken, dessen Versionsnummer von der Upstream-Version abweicht. Laut Debian Security Tracker (Stand 22.10.2026) gilt:

Debian 13 Trixie: PHP 8.4 ist mit 8.4.27-1~deb13u1 korrigiert (DSA-6574-1)
Debian 12 Bookworm: PHP 8.2 ist mit 8.2.35-1~deb12u1 korrigiert (DLA-4848-1)
Debian Unstable/Testing: PHP 8.4 war zum Prüfzeitpunkt noch nicht korrigiert

Der Stand kann sich ändern. Maßgeblich ist der Debian Security Tracker.

💡

Ubuntu: Korrekturen für unterstützte Releases

Ubuntu stuft CVE-2026-109618 mit der Priorität „Critical“ ein und hat am 21. Oktober 2026 die Sicherheitshinweise USN-8948-1 und USN-8948-2 veröffentlicht. Laut Ubuntu Security (Stand 22.10.2026) gibt es Korrekturen unter anderem für:

Ubuntu 22.04 LTS: PHP 8.1 mit 8.1.2-1ubuntu2.28
Ubuntu 24.04 LTS: PHP 8.3 mit 8.3.6-0ubuntu0.24.04.13
Ältere Releases (20.04 und früher): nur über Ubuntu Pro (ESM) bzw. Legacy Support

Maßgeblich ist die Seite Ubuntu Security.

📦

Drittanbieter-Repositories

Das ehrenamtlich gepflegte Repository rpms.remirepo.net wird zum Release keine Updates haben. Das PHP-Projekt empfiehlt in solchen Fällen Distributionspakete oder einen Build aus dem Quellcode.

Wer PHP über ein Drittanbieter-Repository, ein Hosting-Panel oder ein fertiges Image bezieht, sollte beim jeweiligen Anbieter den Stand erfragen.

BETROFFENE ANWENDUNGEN

Welche Websites und Anwendungen können betroffen sein?

PHP steckt in zahlreichen Content-Management-Systemen, Webanwendungen und Diensten. Auch wenn die Anwendung selbst aktuell ist, kann eine verwundbare PHP-Laufzeit ein Risiko darstellen. Dazu können beispielsweise gehören:

WordPress-Websites und deren Backend
Drupal-, Joomla- und TYPO3-Installationen
Nextcloud- und ownCloud-Umgebungen
MediaWiki und DokuWiki
Shopsysteme und individuell entwickelte PHP-Anwendungen
PHP-basierte Dienste in Docker-Containern
Weitere Webanwendungen, die PHP-FPM, mod_php oder eine andere betroffene Laufzeit verwenden

Die Liste ist nicht vollständig. Entscheidend ist, welche PHP-Version eine Anwendung tatsächlich verwendet und wie sie bereitgestellt wird. Ein Update des CMS allein reicht nicht, solange der PHP-Prozess eine verwundbare Version ausführt. Bei Containern muss zusätzlich das Image aktualisiert und die Anwendung damit neu bereitgestellt werden.

MASSNAHMEN

Was Betreiber jetzt tun sollten

Die Sicherheitsmeldungen empfehlen, betroffene Installationen unverzüglich zu aktualisieren. Ist das nicht sofort möglich, sollten öffentlich erreichbare Anwendungen bis zur Korrektur möglichst vom Netz genommen oder in ihrer Erreichbarkeit eingeschränkt werden.

Alle PHP-Installationen erfassen

Nicht nur der Hauptwebserver zählt. Auch zusätzliche PHP-FPM-Pools, alternative PHP-Versionen, Container, Verwaltungsoberflächen, Hosting-Panels und ältere Kundenanwendungen müssen berücksichtigt werden.

Tatsächlich verwendete Version prüfen

Die PHP-Version auf der Kommandozeile muss nicht der Version entsprechen, die eine Website über PHP-FPM oder Apache nutzt. Maßgeblich ist die Runtime, die den Webanfragen zugeordnet ist.

Sicherheitsupdate einspielen

Für unterstützte Upstream-Zweige stehen die oben genannten Releases bereit. Bei distributionsverwalteten Installationen die Updates des jeweiligen Anbieters verwenden.

Prozesse und Container neu starten

Ein installiertes Paket bedeutet nicht, dass alle laufenden Prozesse die korrigierte Version nutzen. Je nach Bereitstellung müssen PHP-FPM, Apache oder Container neu gestartet bzw. neu ausgerollt werden.

Ergebnis kontrollieren

Nach der Aktualisierung prüfen, welche Version tatsächlich läuft. Bei mehreren Hosts oder getrennten Umgebungen darf die Prüfung nicht auf einem einzelnen System enden.

Veraltete Versionen gesondert behandeln

Bei PHP 8.1 oder älter klären, ob ein bestätigter Backport des Anbieters verfügbar ist. Ist das nicht der Fall, eine Migration auf einen unterstützten Zweig einplanen.

PRAXIS

Praxisbefehle: Welche PHP-Version läuft wirklich?

Die Befehle sind Beispiele für Debian/Ubuntu-Systeme mit Paketinstallation. Bitte an die eigene Umgebung anpassen (PHP-Version, Dienstnamen) und Neustarts nur nach Wartungsplanung durchführen.

🔍

Installierte Versionen finden

Zeigt die CLI-Version und alle installierten PHP-Pakete. Die CLI-Version sagt noch nichts über die Webumgebung:

Bash

php -v
dpkg -l | grep -E '^ii\s+php'
ls /usr/sbin/php-fpm* 2>/dev/null

🖥

Laufende Webprozesse prüfen

Zeigt, welche PHP-Prozesse tatsächlich laufen, und ob sie noch das alte Binary nutzen. Steht hinter dem Pfad „(deleted)“, läuft der Prozess noch mit der Version vor dem Update:

Bash

ps aux | grep -E 'php-fpm|apache2|httpd' | grep -v grep
ls -l /proc/$(pgrep -o php-fpm)/exe
apache2ctl -M 2>/dev/null | grep -i php

🔄

Update einspielen und Dienste neu starten

Beispiel für PHP 8.4 mit PHP-FPM. Dienstnamen je nach Version und Setup anpassen:

Bash

apt update
apt list --upgradable 2>/dev/null | grep -i php
apt full-upgrade

# Dienste neu starten (nur nach Wartungsplanung):
systemctl restart php8.4-fpm
systemctl restart apache2   # bzw. nginx

# Prozesse mit veralteten Bibliotheken anzeigen:
needrestart

📦

Container prüfen

Zeigt, welche Container laufen und welche PHP-Version darin verwendet wird. Ein reines Update im Host reicht nicht, das Image muss neu gebaut und der Container neu gestartet werden:

Bash

docker ps --format '{{.Names}}  {{.Image}}'
docker exec  php -v

ÜBERGANGSMASSNAHMEN

Wenn ein Update nicht sofort möglich ist

Das PHP-Projekt stellt klar: Es gibt keinen vollständigen Schutz außer dem Update. Die folgenden Punkte verringern höchstens die Angriffsfläche und ersetzen die Aktualisierung nicht. Datadog weist zudem darauf hin, dass die Einstellung session.upload_progress.enabled=0 gegen CVE-2026-109618 nicht schützt. Maßnahmen sollten vor dem Einsatz geprüft werden, weil sie Nebenwirkungen haben können.

Für CVE-2026-109619

session.upload_progress.enabled=0 in php.ini, im FPM-Pool oder in der Serverkonfiguration setzen und alle Worker neu starten. ini_set() und .user.ini genügen dafür nicht.
Bei PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen und die Worker neu starten. Das blockiert nur einen bestätigten Pfad.

Für CVE-2026-109618

Anfragegrößen begrenzen, etwa post_max_size und upload_max_filesize, sowie auf dem Webserver oder Proxy die Zahl der Felder, Multipart-Teile und Header.
Das PHP-Projekt nennt außerdem memory_limit=-1 (vorzugsweise per php_admin_value) in Kombination mit einer Container- oder cgroup-Begrenzung, die nur den betroffenen Worker beendet. RLIMIT_AS und RLIMIT_DATA sollten nicht verwendet werden, weil sie den verwundbaren Fehlerfall auslösen können.

Zusätzlich

Nicht patchbare Anwendungen vom Internet trennen oder hinter VPN bzw. eine Web Application Firewall stellen. Einige Anbieter wie Cloudflare haben erste WAF-Regeln für bekannte Angriffswege bereitgestellt.

ERKENNUNG

Woran man einen Angriff erkennen könnte

Die Lücken liegen unterhalb der Anwendungsebene, Anwendungslogs zeigen deshalb oft wenig. Hinweise können laut Wiz und Huntress sein:

Ungewöhnliche Multipart-Anfragen, auf die Fehlermeldungen zum Speicherlimit folgen
Wiederholte HTTP-500-Antworten und ungewöhnlicher Neustart-Wechsel bei PHP-Workern
Ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies
Formular-Uploads (POST-Requests), die die Zeichenfolge PHP_SESSION_UPLOAD_PROGRESS enthalten (Hinweis von Amazon Threat Intelligence)
PHP-Worker oder Webserver-Prozesse, die Shells, Interpreter oder Download-Werkzeuge starten
Neue Dateien im Webroot, unerwartete Cron-Jobs oder neue Benutzerkonten

Bei einem Verdacht: System isolieren, Web- und PHP-Logs sichern und auf Webshells prüfen. Die Auswertung sollte nicht allein auf einem erfolgreichen Update beruhen, weil eine Kompromittierung schon vorher erfolgt sein kann.

BEI RDDZ

Was wir bei RDDZ unternommen haben

Wir haben unsere Systeme am 21. Oktober 2026 um 18:00 Uhr auf den korrigierten Stand gebracht.

Dabei betrachten wir nicht nur die offensichtlichen Webanwendungen, sondern auch die darunterliegenden Laufzeitumgebungen. PHP kann direkt auf einem Host, in einer getrennten Runtime oder innerhalb eines Containers installiert sein. Eine einzelne Aktualisierung deckt deshalb nicht automatisch jede Anwendung ab.

Das Einspielen der Korrektur ersetzt nicht die Frage, ob es vor dem Update Hinweise auf eine Ausnutzung gab. Dazu mehr im Update weiter oben. Bei produktiven Systemen prüfen wir nach Updates außerdem den ordnungsgemäßen Betrieb der Anwendungen.

FAZIT

Jetzt aktualisieren, nicht auf den Wartungstermin warten

PHP2Shell ist kein gewöhnliches Update-Thema. Die beiden kritischen Schwachstellen CVE-2026-109618 und CVE-2026-109619 können unter bestimmten Voraussetzungen eine Codeausführung ohne Anmeldung ermöglichen. Der große Versionsbereich und der Einsatz von PHP in unzähligen Webanwendungen machen eine systematische Prüfung wichtig.

Die korrigierten Versionen stehen bereit. Betreiber sollten ihre PHP-Runtimes und Anwendungen unverzüglich prüfen, passende Updates installieren und sicherstellen, dass die korrigierte Version tatsächlich läuft. Bei alten oder nicht mehr unterstützten Installationen muss zusätzlich geklärt werden, ob eine belastbare Sicherheitskorrektur verfügbar ist, oder eine Migration auf einen unterstützten Zweig anstehen.

QUELLEN

Weiterführende Quellen

PHP-Server und Webseiten sicher betreiben?

PHP-Versionen, Updates und Neustarts nicht allein im Blick behalten? Sprechen Sie uns an, wir unterstützen bei Betrieb, Wartung und Absicherung.

Der Beitrag PHP2Shell: Kritische PHP-Sicherheitslücken gefährden Websites und Server erschien zuerst auf RDDZ.

PwnEscape (CVE-2026-99999): Wenn eine virtuelle Maschine den Linux-Host gefährden kann

dennis_rddz — Tue, 20 Oct 2026 14:29:20 +0000

SICHERHEIT · LINUX-KERNEL · STAND 20.10.2026

PwnEscape (CVE-2026-99999): Wenn eine virtuelle Maschine den Linux-Host gefährden kann

Eine Sicherheitslücke im Linux-Kernel sorgt derzeit für Aufmerksamkeit: PwnEscape, geführt unter CVE-2026-99999, kann unter bestimmten Voraussetzungen dazu genutzt werden, aus einer virtuellen Maschine auf den zugrunde liegenden Host zuzugreifen. Betroffen sein können damit ausgerechnet Systeme, deren Aufgabe es ist, voneinander getrennte Umgebungen bereitzustellen.

PWNESCAPE · CVE-2026-99999

● CVE seit 15.10.2026

9,3

CVSS 3, kritisch

IPv4

Linux-Kernel

Gast → Host

KVM, virtio

Proxmox VE ✓ Kernel 7.0.14-24

Debian ✓ Fix für 12 und 13

Ubuntu ● Status prüfen

Entscheidend: korrigierten Host-Kernel installieren, neu starten und prüfen, ob er läuft.

✓ CVE veröffentlicht am 15. Oktober 2026

✓ Proxmox-Fix seit 16. Oktober 2026

✓ Korrigierte Debian-Kernel für 12 und 13

✓ Ubuntu: Status direkt prüfen

✓ Mit Praxisbefehlen für die Host-Prüfung

EINORDNUNG

Eine ernst zu nehmende Meldung für Virtualisierungshosts

Für Betreiber virtualisierter Server ist das eine ernst zu nehmende Meldung. Entscheidend ist allerdings nicht allein die Schwere der Schwachstelle, sondern auch, wie schnell die verfügbaren Korrekturen eingespielt werden.

Proxmox hat bereits einen korrigierten Kernel bereitgestellt. Auch Debian führt behobene Kernelpakete. Bei Ubuntu ist der Status der betroffenen Pakete gesondert zu prüfen.

Was steckt hinter PwnEscape?

PwnEscape betrifft die Verarbeitung von IPv4-Netzwerkpaketen im Linux-Kernel. Vereinfacht gesagt kann eine fehlerhafte Prüfung von Metadaten zur Prüfsummenberechnung dazu führen, dass der Kernel beim Verarbeiten eines Pakets Speicher beschädigt.

Das Problem ist deshalb besonders relevant, weil Netzwerkpakete auch innerhalb virtualisierter Umgebungen verarbeitet werden. Unter den entsprechenden Voraussetzungen kann ein Angreifer aus einer virtuellen Maschine heraus versuchen, die Sicherheitsgrenze zum Host zu überwinden. Die Proxmox-Sicherheitsmeldung beschreibt den Angriffsweg über den virtio-Netzwerkstack, die Forscher von PWNAI Research zeigen ihn in einem eigenen KVM-Testaufbau.

Die möglichen Folgen reichen von einem Absturz des Systems über das Offenlegen von Speicherinhalten bis hin zur Ausführung von Code mit weitreichenden Rechten auf dem Host. Der konkrete Erfolg eines Angriffs hängt allerdings von den jeweiligen technischen Voraussetzungen und der betroffenen Umgebung ab. Die Veröffentlichung bedeutet nicht, dass jede virtuelle Maschine auf jedem Linux-Host automatisch kompromittiert werden kann.

Die Schwachstelle wurde am 15. Oktober 2026 als CVE-2026-99999 veröffentlicht. In der CVSS-Version 3 wird sie mit einem Schweregrad von 9,3 von 10 – kritisch bewertet. Hersteller können für ihre jeweiligen Produkte zu abweichenden Bewertungen kommen, weil sie unterschiedliche Rahmenbedingungen berücksichtigen.

Technische Hintergründe finden sich in der Linux-Kernel-Sicherheitsmeldung und in der Analyse der Sicherheitsforscher.

⚖

Kritisch bewertet, aber nicht überall gleich

Der CVSS-Wert liegt bei 9,3. Ubuntu führt die CVE dennoch mit der Priorität „Medium“. Das zeigt, wie unterschiedlich Hersteller die Lücke für ihre Pakete einstufen.

🛡

Korrektur als Zusatzschutz

Der Upstream-Fix prüft checksum_start, bevor die Prüfsumme berechnet wird. Debian und Ubuntu beschreiben ihn als zusätzliche Schutzmaßnahme (Defense in Depth). Eine umfassendere Validierung beim Empfang ist laut den Angaben noch in Arbeit.

🔍

Keine Ausnutzung bei Anbietern behauptet

Die Forscher behaupten ausdrücklich keine Ausnutzung bei Produktionsanbietern. Ihre Angriffe zeigen sie in eigenen Testaufbauten.

VIRTUALISIERUNG

Warum die Lücke für Virtualisierung besonders relevant ist

Bei einem virtualisierten Server laufen mehrere voneinander getrennte Systeme auf derselben physischen Hardware. Der Hypervisor und der Host-Kernel übernehmen dabei eine zentrale Rolle: Sie stellen die Ressourcen bereit und setzen die Trennung zwischen den virtuellen Maschinen und dem Host durch. Genau diese Trennung ist bei einer möglichen Guest-to-Host-Schwachstelle der entscheidende Punkt.

Kann ein Angreifer aus einer Gast-VM heraus eine Schwachstelle im Host-Kernel ausnutzen, betrifft das nicht mehr nur das einzelne Gastsystem. Im ungünstigsten Fall könnte auch die darunterliegende Infrastruktur gefährdet sein. Je nach Umgebung wären damit weitere virtuelle Maschinen auf demselben Host betroffen.

Das macht PwnEscape für Betreiber von Virtualisierungsplattformen und für alle relevant, die eigene virtuelle Server betreiben. Die Sicherheitslücke ist jedoch kein Beleg dafür, dass sämtliche KVM-Systeme oder jede Proxmox-Installation gleichermaßen angreifbar sind. Entscheidend sind unter anderem der eingesetzte Kernel, der Patchstand und die konkreten Bedingungen der Umgebung.

DISTRIBUTIONEN

Proxmox, Debian und Ubuntu im Überblick

📦

Proxmox VE: Der korrigierte Kernel war schnell verfügbar

Für Betreiber von Proxmox VE gibt es bereits eine konkrete Korrektur. In der offiziellen Proxmox-Community wurde die Sicherheitsmeldung PSA-2026-00068-1 zu PwnEscape am 16. Oktober 2026 veröffentlicht.

Der Fix ist im Paket proxmox-kernel-7.0.14-24-pve sowie in der signierten Variante proxmox-kernel-7.0.14-24-pve-signed enthalten. Laut Proxmox-Team war das Paket zunächst im Repository pve-no-subscription verfügbar und sollte anschließend auch im Enterprise-Repository bereitgestellt werden. Ein Nutzer im Forum bestätigt es inzwischen auch dort.

Die CVE wurde am 15. Oktober offiziell veröffentlicht. Damit reagierte Proxmox sehr schnell und stellte die korrigierte Kernel-Version bereits kurz darauf bereit.

Wichtig ist dabei die Unterscheidung zwischen einem verfügbaren Update und einem tatsächlich aktualisierten Host: Ein Administrator muss sicherstellen, dass das passende Paket installiert ist und der Host anschließend mit dem korrigierten Kernel läuft. Ein bloßes Aktualisieren von Paketen garantiert nicht in jedem Fall, dass der neue Kernel bereits aktiv ist.

Ältere Installationen: Laut Proxmox-Team ist 7.0.14 die einzige aktuell unterstützte Kernel-Serie. Für Kernel-Serien, deren Support ausgelaufen ist, gibt es keine Updates. Das betrifft beispielsweise den Kernel 6.8 von Proxmox VE 8. Wer solche Hosts betreibt, sollte ein Upgrade auf eine unterstützte Version einplanen.

GPU-Treiber: Im Forum berichtet ein Nutzer, dass der NVIDIA-Treiber 615.78.08 auf dem Kernel 7.0.14-24-pve nicht kompiliert. Wer Treiber per DKMS einsetzt, sollte das Update vorher auf einem Testsystem prüfen.

Die offizielle Diskussion und die Angaben des Proxmox-Teams finden sich im Proxmox-Supportforum zur Sicherheitslücke.

🌀

Debian: Korrigierte Kernelpakete sind ausgewiesen

Debian ist für viele Server eine wichtige Grundlage – auch im Umfeld von Virtualisierung und Hosting. Der Debian Security Tracker weist für CVE-2026-99999 korrigierte Kernelpakete für mehrere Veröffentlichungszweige aus:

Debian 12 Bookworm: 6.1.190-1 im Security-Repository
Debian 13 Trixie: 6.12.113-1 im Security-Repository
Debian Testing beziehungsweise Unstable: korrigierte Pakete auf Basis von 7.2.11-1

Diese Angaben beziehen sich auf die vom Debian Security Tracker ausgewiesenen Paketstände. Bei Debian sollten Administratoren nicht einfach die Versionsnummer des unveränderten Linux-Kernels mit der installierten Paketversion vergleichen: Distributionen integrieren Sicherheitskorrekturen häufig in ihre eigenen Pakete und pflegen dafür entsprechende Paketversionen.

Die maßgebliche Anlaufstelle ist der Debian Security Tracker für CVE-2026-99999.

💡

Ubuntu: Den Status der eigenen Kernelpakete prüfen

Auch Ubuntu führt CVE-2026-99999 in seiner Sicherheitsdatenbank. Bei der Recherche am 20. Oktober 2026 war der Status für die dort aufgeführten Ubuntu-Versionen allerdings noch als „Needs evaluation“ angegeben.

Das ist kein Grund, die Meldung zu ignorieren. Es bedeutet vielmehr, dass sich aus diesem Eintrag zu diesem Zeitpunkt noch keine pauschale Aussage ableiten ließ, wonach für alle betroffenen Ubuntu-Versionen bereits ein korrigiertes Paket bereitsteht.

Wer Ubuntu auf einem Virtualisierungshost oder Server einsetzt, sollte deshalb den aktuellen Status der eigenen Version und des verwendeten Kernelpakets direkt bei Ubuntu kontrollieren. Dabei ist auch zu berücksichtigen, dass sich der Status nach Veröffentlichung einer Sicherheitsmeldung noch ändern kann.

Die offizielle Übersicht findet sich unter Ubuntu Security: CVE-2026-99999.

MASSNAHMEN

Was Administratoren jetzt tun sollten

Unabhängig von der verwendeten Distribution empfiehlt sich ein strukturierter Blick auf die eigenen Systeme. Dabei sollte vor allem der Host im Mittelpunkt stehen – nicht nur die virtuellen Maschinen.

Virtualisierungshosts inventarisieren

Zunächst sollte klar sein, welche physischen Systeme Linux als Host-Kernel verwenden und welche Virtualisierungsplattform dort läuft. Dazu gehören beispielsweise Proxmox VE und andere KVM-basierte Umgebungen.

Den Patchstand der Distribution prüfen

Maßgeblich sind die offiziellen Sicherheitsmeldungen und Paketversionen des jeweiligen Herstellers. Ein Vergleich allein anhand der Upstream-Kernelnummer reicht nicht immer aus, weil Distributionen Sicherheitskorrekturen zurückportieren können.

Korrigierte Pakete installieren

Sobald ein passendes Update für die eigene Distribution verfügbar ist, sollte es nach den üblichen Wartungs- und Freigabeprozessen eingespielt werden. Bei produktiven Hosts sind mögliche Auswirkungen auf laufende virtuelle Maschinen und die notwendige Wartungsplanung zu berücksichtigen.

Sicherstellen, dass der neue Kernel aktiv ist

Kernelupdates benötigen häufig einen Neustart, bevor der korrigierte Kernel tatsächlich läuft. Nach der Aktualisierung sollte deshalb kontrolliert werden, welcher Kernel aktiv ist und ob das System den erwarteten Patchstand erreicht hat.

Nicht nur die Gäste aktualisieren

Updates innerhalb einer virtuellen Maschine ersetzen nicht das Update des Host-Kernels. Die Sicherheitsgrenze, um die es bei PwnEscape geht, liegt zwischen Gast und Host. Deshalb muss die Korrektur auf dem betroffenen Host-System wirksam sein.

PRAXIS

Praxisbefehle: Welcher Kernel läuft auf dem Host?

Die folgenden Befehle sind Beispiele für die Prüfung. Bitte vor der Ausführung an die eigene Umgebung anpassen und produktive Hosts nur nach Wartungsplanung neu starten.

🔍

Laufenden Kernel prüfen

Zeigt, welcher Kernel tatsächlich läuft – unabhängig davon, was installiert ist:

Bash

uname -r
uname -v

Bei Debian enthält uname -v die Debian-Paketversion (z. B. 6.1.190-1) und lässt sich direkt mit dem Security Tracker vergleichen.

🖥

Proxmox VE

Installierte Kernel-Pakete prüfen, aktualisieren und nach dem Neustart kontrollieren:

Bash

pveversion -v | grep -i proxmox-kernel
apt update
apt full-upgrade
# Neustart nur nach Wartungsplanung:
# reboot

# Nach dem Neustart: sollte 7.0.14-24-pve zeigen
uname -r

Welches Repository genutzt wird (pve-no-subscription oder Enterprise), bestimmt, wann das Paket verfügbar ist.

💻

Debian und Ubuntu

Verfügbare Kernel-Updates anzeigen, einspielen und installierte Kernel auflisten:

Bash

apt update
apt list --upgradable 2>/dev/null | grep -i linux-image
apt full-upgrade
apt list --installed 'linux-image*'

# Falls installiert: prüft, ob ein Neustart wegen des Kernels nötig ist
needrestart -k

Bei Ubuntu zusätzlich den Status auf der Ubuntu-Sicherheitsseite kontrollieren, bevor man von einem verfügbaren Fix ausgeht.

🔄

Cluster: VMs vor dem Neustart verschieben

In einem Proxmox-Cluster lassen sich laufende VMs per Live-Migration auf einen bereits gepatchten Node verschieben, bevor der nächste Host neu startet:

Bash

qm migrate   --online

Ob das in der eigenen Umgebung funktioniert, hängt unter anderem von Storage und CPU-Kompatibilität ab. Vorher auf einer unkritischen VM testen.

BEI RDDZ

Was wir bei RDDZ unternommen haben

Sicherheitsmeldungen wie PwnEscape zeigen, warum es bei gemieteten oder selbst betriebenen Servern nicht ausreicht, Updates nur gelegentlich und ohne Blick auf ihre Bedeutung einzuspielen.

Wir haben unsere Host-Systeme im Zusammenhang mit dieser Schwachstelle überprüft und die verfügbare Kernel-Korrektur zeitnah nach der Veröffentlichung eingespielt.

Für Kunden ist dabei besonders wichtig, dass Sicherheitsmaßnahmen nicht an der Oberfläche enden. Bei einer Schwachstelle im Host-Kernel muss die zugrunde liegende Virtualisierungsinfrastruktur betrachtet werden – zusätzlich zu den Betriebssystemen und Anwendungen, die innerhalb der virtuellen Maschinen laufen.

Wie bei jeder Sicherheitslücke gilt: Eine zeitnahe Aktualisierung ist ein wesentlicher Schritt, ersetzt aber keine laufende Wartung und Überwachung. Wir behalten relevante Sicherheitsmeldungen deshalb im Blick und setzen notwendige Korrekturen auf unseren Systemen nach Verfügbarkeit und unter Berücksichtigung des jeweiligen Betriebsumfelds um.

FAZIT

Schnelle Updates sind entscheidend

PwnEscape ist ein gutes Beispiel dafür, dass Sicherheitslücken im Linux-Kernel auch die Isolation virtualisierter Systeme betreffen können. Die mögliche Auswirkung ist ernst, sollte aber nicht mit der pauschalen Behauptung verwechselt werden, jede KVM- oder Proxmox-Umgebung sei automatisch kompromittiert.

Die wichtigste Empfehlung für Betreiber eigener Server: Host-Kernel und Sicherheitsmeldungen der jeweiligen Distribution im Blick behalten, Updates zeitnah installieren und anschließend prüfen, ob der korrigierte Kernel tatsächlich aktiv ist. Die Befehle oben helfen dabei.

QUELLEN

Weiterführende Quellen

Eigene Server oder Proxmox-Hosts sicher betreiben?

Patchstand, Kernel-Updates und Wartungsfenster nicht allein im Blick behalten? Sprechen Sie uns an, wir unterstützen bei Betrieb, Wartung und Absicherung.

Der Beitrag PwnEscape (CVE-2026-99999): Wenn eine virtuelle Maschine den Linux-Host gefährden kann erschien zuerst auf RDDZ.

Welches CMS ist das richtige? Worauf es bei der Auswahl wirklich ankommt

dennis_rddz — Tue, 13 Oct 2026 06:20:53 +0000

RDDZ RATGEBER · CMS · WEBDESIGN

Welches CMS ist das richtige? Worauf es bei der Auswahl wirklich ankommt

WordPress, Joomla, individuelle Lösungen oder ein Shop-System – die Auswahl ist groß, und auf den ersten Blick scheint die Entscheidung einfach: Funktionen vergleichen, ein paar Demos ansehen, zuschlagen. In der Praxis zeigt sich schnell, dass es auf mehr ankommt als auf die längste Featureliste.

CMS-AUSWAHL · VON RDDZ

● Aus eigener Projekterfahrung

WordPress

Unser Hauptsystem bei RDDZ

Joomla → WP

Mehrfach erfolgreich migriert

Woo & Magento

Beide Shop-Systeme im Einsatz

FunktionenNur was wirklich gebraucht wird

BedienungWer pflegt die Website später?

BetriebKosten, Wartung, Sicherheit

Aus unserer Erfahrung mit Unternehmenswebsites und Online-Shops.

✓ Funktionsumfang an echten Anforderungen statt an Feature-Listen ausgerichtet

✓ Bedienbarkeit im Redaktionsalltag selbst getestet, nicht nur in der Demo

✓ Shop-Anforderungen mit WooCommerce und Magento abgedeckt

✓ Gesamtkosten über mehrere Jahre statt nur Einstiegspreis betrachtet

✓ Wartung, Updates und Sicherheit von Anfang an mitgeplant

FUNKTIONSUMFANG

Welche Funktionen werden tatsächlich gebraucht?

Mehrsprachigkeit, Benutzerrechte, Formulare, Schnittstellen – viele CMS werben mit einer langen Liste an Möglichkeiten. Die wichtigere Frage lautet: Was davon braucht die Website wirklich?

📋

Anforderungen zuerst festhalten

Für eine klassische Unternehmenswebsite mit Leistungsseiten, Kontaktformular und Newsbereich reicht oft ein überschaubarer Funktionsumfang.

🧩

Nicht jede Funktion per Plugin lösen

Auch bei WordPress gilt: Jede zusätzliche Erweiterung muss zum Projekt passen und lässt sich auf Dauer nicht von allein pflegen.

📋

Redaktionsportale brauchen mehr

Ein großes Portal mit vielen Autoren, Freigaben und komplexen Inhaltsstrukturen stellt ganz andere Anforderungen als eine Unternehmensseite.

🔄

Muss das bestehende CMS ersetzt werden?

Nicht immer. Manchmal reicht eine Überarbeitung der bestehenden Installation. Entscheidend ist, was konkret stört: die Pflege, fehlende Funktionen, die technische Basis – oder soll die Seite ohnehin neu gestaltet werden?

Ein Beispiel aus unserer Praxis

Ein gemeinnütziger Verein kam mit einer in die Jahre gekommenen Joomla-Seite zu uns, die sich kaum noch pflegen ließ. Im Rahmen eines großen Redesigns haben wir ein komplett neues WordPress-Setup realisiert, Inhalte sauber übernommen und die Redaktion danach selbstständig arbeiten lassen können.

ALLTAGSTAUGLICHKEIT

Wer soll später mit der Website arbeiten?

Die Bedienbarkeit wird bei der CMS-Auswahl häufig unterschätzt, entscheidet im Alltag aber darüber, ob Inhalte schnell aktualisiert werden oder jede kleine Änderung Zeit kostet.

✏

Ohne Fachkraft pflegbar

Neue Leistungen, geänderte Kontaktdaten oder aktuelle Meldungen sollten sich unkompliziert einpflegen lassen.

🏗

Aufbau entscheidet mit

Ein System kann grundsätzlich einfach sein und trotzdem kompliziert wirken, wenn der Seitenaufbau unübersichtlich ist oder zu viele Werkzeuge im Einsatz sind.

✅

Typische Aufgaben vorher testen

Einen Beitrag veröffentlichen, ein Bild austauschen, eine Leistungsseite aktualisieren: Klappt das reibungslos, ist das ein gutes Zeichen.

PRAXISBEISPIEL

Vom alten Joomla-Auftritt zum neuen WordPress-Setup

Ein gemeinnütziger Verein, dessen Website seit Jahren auf einer veralteten Joomla-Installation lief, ist ein gutes Beispiel dafür, wann ein Wechsel wirklich sinnvoll ist.

Die alte Seite war technisch veraltet, die Redaktion kam mit dem Backend kaum noch zurecht, und kleine Änderungen landeten regelmäßig bei uns, statt dass der Verein sie selbst hätte erledigen können.

Im Rahmen eines größeren Redesigns haben wir die Seite komplett neu auf WordPress aufgebaut: bestehende Inhalte übernommen, Struktur und Bedienung an den Alltag des Vereins angepasst und ein System übergeben, das die Redaktion seither eigenständig pflegt.

Der Fall zeigt gut, worauf es bei einer Migration ankommt: nicht der reine Systemwechsel steht im Vordergrund, sondern dass die neue Website hinterher leichter zu pflegen ist als die alte.

GESAMTKOSTEN

Was kostet das CMS wirklich?

Ein kostenloses CMS ist nicht automatisch die günstigste Lösung. Der Lizenzpreis ist nur ein Teil der Rechnung.

💵

WordPress ist Open Source

Trotzdem entstehen Kosten, etwa für Premium-Plugins, individuelle Entwicklung, technische Betreuung oder Sicherheitsmaßnahmen.

🛒

Bei Shops kommt mehr hinzu

Zahlungs- und Versandlösungen, Schnittstellen oder spezielle Shop-Funktionen schlagen je nach System unterschiedlich zu Buche.

🔍

Der Pflegeaufwand zählt mit

Eine günstig wirkende Lösung kann teuer werden, wenn Anpassungen kompliziert sind oder ständig externe Unterstützung nötig ist.

Erweiterungen mit Bedacht wählen

Plugins sparen Zeit, solange sie sorgfältig ausgewählt werden. Zu viele Erweiterungen machen eine Website unnötig komplex, müssen aktuell gehalten werden und zueinander passen. Wird eine wichtige Erweiterung nicht mehr gepflegt, entsteht schnell zusätzlicher Aufwand.

ONLINE-SHOPS

Bei Shops gelten andere Anforderungen

WooCommerce für integrierte Inhalte

Baut auf WordPress auf und eignet sich besonders, wenn neben dem Verkauf auch Ratgeber oder andere redaktionelle Inhalte eine Rolle spielen.

Magento für umfangreichere Shops

Kommt bei uns ins Spiel, wenn Sortiment, Geschäftsprozesse und Schnittstellen entsprechend umfangreich sind.

SICHERHEIT & WARTUNG

Mit der Veröffentlichung fängt die Arbeit erst an

CMS, Plugins und andere Komponenten müssen laufend aktualisiert werden. Worauf es dabei ankommt:

Updates zeitnah einspielen

Sicherheitslücken werden regelmäßig bekannt und geschlossen.

Backups prüfen, nicht nur erstellen

Eine Sicherung, die im Ernstfall nicht einspielbar ist, hilft niemandem.

Benutzerrechte sauber verwalten

Jeder Zugang nur mit den Rechten, die tatsächlich gebraucht werden.

Erweiterungen aktuell halten

Veraltete Plugins sind eine der häufigsten Einfallstore.

Zuständigkeit vorab klären

Wer kümmert sich um Updates, Monitoring und Notfälle?

Shops besonders im Blick behalten

Technische Probleme wirken sich hier direkt auf Bestellungen und Umsatz aus.

Notfallplan bereithalten

Ein nachvollziehbarer Ablauf, falls doch einmal etwas schiefgeht.

FAZIT

Das System muss zum Projekt passen

Ob WordPress, Joomla, WooCommerce oder Magento: Kein System ist automatisch für jedes Projekt die beste Wahl. Für viele Unternehmenswebsites ist WordPress eine vielseitige Grundlage, bei Online-Shops können WooCommerce oder spezialisierte Lösungen wie Magento infrage kommen.

Auch ein Wechsel von einem bestehenden CMS sollte gut überlegt sein. Er lohnt sich, wenn er konkrete Probleme löst, so wie bei dem Verein, der von Joomla auf WordPress umgezogen ist – nicht, weil ein System gerade im Trend liegt.

Unser Tipp: Anforderungen zuerst festhalten, dann die infrage kommenden Systeme daran messen. So entsteht eine Entscheidung, die zum Projekt passt, statt eine nach Bauchgefühl oder Featureliste.

FAQ

Häufige Fragen zur CMS-Auswahl

Ist WordPress für jede Website geeignet?

Für viele Unternehmenswebsites ist WordPress eine vielseitige und bewährte Grundlage. Bei sehr großen Redaktionsportalen mit komplexen Freigabeprozessen kann aber auch ein anderes System die bessere Wahl sein.

Lohnt sich ein Wechsel von Joomla zu WordPress?

Das hängt davon ab, was konkret stört. Wenn die Pflege umständlich ist, die technische Basis veraltet ist oder die Website ohnehin neu gestaltet werden soll, kann eine Migration sinnvoll sein – wie bei einem Verein, den wir so von Joomla auf WordPress umgezogen haben.

WooCommerce oder Magento: Was passt besser?

WooCommerce baut auf WordPress auf und eignet sich gut, wenn Verkauf und redaktionelle Inhalte zusammenspielen sollen. Magento kommt eher bei umfangreicheren Shops mit komplexeren Geschäftsprozessen infrage. Welches System passt, hängt vom Einzelfall ab.

Was kostet eine CMS-Website wirklich?

Neben Lizenz- oder Abonnementkosten gehören Einrichtung, Hosting, Erweiterungen, Wartung und der laufende Pflegeaufwand zur Rechnung. Ein niedriger Einstiegspreis sagt wenig über die Gesamtkosten über mehrere Jahre aus.

Wer kümmert sich nach dem Launch um Updates und Sicherheit?

Das sollte vor der CMS-Auswahl geklärt sein, nicht erst beim ersten größeren Update. RDDZ übernimmt auf Wunsch die laufende technische Betreuung, von Updates über Backups bis zur Fehlerbehebung.

QUELLEN

Quellen und Links

Neue Website oder CMS-Wechsel geplant?

Du planst eine neue Website, möchtest dein bestehendes CMS ablösen oder deinen Online-Shop weiterentwickeln? RDDZ unterstützt dich bei der Planung und Umsetzung – von der Auswahl des passenden Systems bis zur technischen Realisierung.

Der Beitrag Welches CMS ist das richtige? Worauf es bei der Auswahl wirklich ankommt erschien zuerst auf RDDZ.

NIS2: Bin ich betroffen? Registrierungspflicht für IT-Dienstleister

dennis_rddz — Sat, 26 Sep 2026 10:34:59 +0000

NIS2 · BSIG · Registrierungspflicht

NIS2: Warum die Registrierungspflicht auch kleinere IT-Dienstleister betreffen kann

Das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz ist am 6. Dezember 2025 in Kraft getreten. Seitdem gilt eine Registrierungspflicht beim BSI – und die betrifft nicht nur große Konzerne. Managed Service Provider, DNS-Anbieter, Cloud- und Rechenzentrumsdienste stehen ausdrücklich im Gesetz, teils unabhängig von der Mitarbeiterzahl.

NIS2-REGISTRIERUNG 2026

● Seit 6.12.2025 in Kraft

19.058

registriert (Stand 31.7.2026)

Mitarbeiter-Schwelle

24 Std.

Erstmeldefrist

6.12.2025Gesetz in Kraft

6.3.2026gesetzliche Frist

31.7.2026BSI-Nachfrist

11.500 → 19.058 registrierte Einrichtungen

✓ Gesetz seit 6.12.2025 in Kraft

✓ MSP, MSSP, Cloud & DNS ausdrücklich genannt

✓ DNS-Anbieter ohne Mitarbeiter-Schwelle

✓ Bußgeld bis zu 10 Mio. € möglich

✓ Registrierung über eigenes BSI-Portal

WAS IST NIS2?

Mehr als nur ein Eintrag im BSI-Portal

Das BSI-Gesetz unterscheidet zwischen besonders wichtigen und wichtigen Einrichtungen und verlangt von beiden weit mehr als eine einmalige Anmeldung.

Risikomanagement

Sicherheitskonzepte, Backup, Zugriffskontrolle, Kryptographie und Lieferkettensicherheit gehören ausdrücklich dazu.

Meldepflichten

Erheblichen Sicherheitsvorfällen folgt ein gestuftes Verfahren: 24 Stunden, 72 Stunden, Abschlussmeldung.

Geschäftsleitung

§ 38 BSIG verpflichtet die Geschäftsleitung persönlich zu Umsetzung, Überwachung und Schulung.

Aufsicht durch das BSI

Registrierung, Auskunftsrechte und Bußgelder bis zu 10 Mio. € stehen ausdrücklich im Gesetz.

Zwei Einrichtungsarten, zwei Schwellenwerte

Wichtige Einrichtungen: ab 50 Mitarbeitern oder mehr als 10 Mio. € Jahresumsatz und Jahresbilanzsumme. Besonders wichtige Einrichtungen: ab 250 Mitarbeitern oder mehr als 50 Mio. € Umsatz und 43 Mio. € Bilanzsumme. § 28 BSIG verweist dafür auf die EU-Empfehlung 2003/361/EG – unter Umständen zählen auch Partner- und verbundene Unternehmen mit.

GRÖSSE IST NICHT ALLES

Digitale Infrastruktur steht ausdrücklich im Gesetz

Anlage 1 BSIG nennt den Sektor „Digitale Infrastruktur“ mit konkreten IT-Leistungen – unabhängig davon, ob dahinter ein Konzern oder ein kleines Systemhaus steht.

◐

Managed Service Provider

Installation, Verwaltung, Betrieb oder Wartung von IKT, Netzwerken und Systemen – vor Ort oder remote. Für klassische MSPs gelten grundsätzlich die normalen Größenschwellen.

▤

DNS-Diensteanbieter

Gilt nach § 28 Abs. 1 Nr. 2 BSIG als besonders wichtige Einrichtung – ohne 50-Mitarbeiter- oder Umsatzschwelle.

✓

Cloud, Rechenzentrum, CDN

Auch Cloud-Computing-Dienste, Rechenzentrumsdienste, CDNs und TLD-Registries stehen ausdrücklich in Anlage 1.

DIE PRAXIS

Registrierung ist nur der erste Schritt

Wer registriert ist, ist damit noch nicht automatisch NIS2-konform – und die Registrierung selbst läuft in zwei Schritten.

Vor der eigentlichen NIS2-Registrierung steht ein eigenständiger Schritt: das Anlegen eines „Mein Unternehmenskonto“ (MUK). Ohne dieses Konto kommt man gar nicht erst zum BSI-Portal.

Das MUK wird über muk.bsi.bund.de angelegt und per ELSTER-Organisationszertifikat authentifiziert. Erst danach ist die NIS2-Registrierung selbst möglich.

1. ELSTER-Organisationszertifikat
2. MUK-Konto anlegen (muk.bsi.bund.de)
3. Login im BSI-Portal zur NIS2-Registrierung
4. Registrierungsdaten eintragen & absenden

Wer die Frist verpasst hat, ist nicht aus der Pflicht: § 33 BSIG erlaubt dem BSI, eine Einrichtung nötigenfalls selbst zu registrieren und Auskünfte zu verlangen. Eine nachträgliche Registrierung sollte deshalb nicht weiter aufgeschoben werden.

BSI-Selbstcheck (unverbindlich):
NIS-2-Betroffenheitsprüfung des BSI

Registrierung:
BSI-Portal – nicht das alte MIP

AKTUELLER STAND

Von 11.500 zu 19.058 Registrierungen

Die Zahlen zur Registrierungsquote haben sich seit dem Fristablauf im März 2026 deutlich weiterentwickelt – und sollten nicht mit dem alten Stand zitiert werden.

6. März 2026

Ablauf der gesetzlichen Drei-Monats-Frist nach § 33 BSIG. Rund 11.500 Einrichtungen waren registriert, bezogen auf die Schätzung von 29.500 rund 38,5 %.

31. Juli 2026

Keine neue gesetzliche Frist, aber eine behördliche Nachfrist des BSI. Bis dahin waren 19.058 Einrichtungen registriert.

August 2026

Die Bundesregierung stellte klar: Sie sieht aktuell keine Registrierungslücke – die 29.500 waren stets nur eine Schätzung, keine belastbare Gesamtzahl.

Woher stammt die Zahl 29.500 überhaupt?

Sie beruht auf einer Schätzung des Statistischen Bundesamts, nicht auf einer Zählung tatsächlich betroffener Einrichtungen. Zusätzlich wurde kurz vor der Sommerpause 2026 eine Änderung an KRITIS-Dachgesetz und BSIG verabschiedet und erst am 28. Juli 2026 im Bundesgesetzblatt Nr. 221 veröffentlicht – was genau sich dadurch an Zählweise oder Zuständigkeit verschoben hat, ist öffentlich noch nicht abschließend aufgearbeitet. Die „39 Prozent“-Schlagzeile vom März 2026 ist damit heute veraltet.

ZWEI EINORDNUNGEN

Kunden und Bußgelder

Was bedeutet das für Kunden eines IT-Dienstleisters?

Wer Server administriert, Backups verwaltet oder Admin-Zugänge besitzt, ist Teil der technischen Lieferkette seiner Kunden. Das macht den Dienstleister nicht automatisch selbst NIS2-pflichtig – ein NIS2-pflichtiger Kunde wird seinen Dienstleister aber genauer prüfen.

Was droht bei Verstößen?

Für die reine Verletzung der Registrierungspflicht sieht § 65 BSIG eine Obergrenze von 500.000 € vor – deutlich niedriger als die bis zu 10 Mio. € (besonders wichtige) bzw. 7 Mio. € (wichtige Einrichtungen), die bei fehlendem Risikomanagement oder versäumten Meldungen drohen können.

CHECKLISTE

Was IT-Dienstleister jetzt prüfen sollten

Die richtige Reihenfolge lautet: Leistung → Einrichtungsart → Sektor → Größenkriterien → Sonderregelungen → Einstufung.

Welche Leistungen erbringen wir?

MSP, MSSP, Cloud, Rechenzentrum, CDN, DNS – oder ein anderer NIS2-Sektor aus Anlage 1/2?

Wie groß ist das Unternehmen?

Mitarbeiterzahl, Umsatz, Bilanzsumme – und ggf. verbundene bzw. Partnerunternehmen nach 2003/361/EG.

Gibt es eine Sonderregel?

DNS-Anbieter, TLD-Registries und Betreiber kritischer Anlagen zählen unabhängig von der Größe.

Sind wir bereits registriert?

MUK-Konto und BSI-Portal – und sind Kontaktdaten sowie IP-Bereiche noch aktuell?

Ist Risikomanagement umgesetzt?

Backup, Patch-Management, MFA und Zugriffskontrolle gehören zum Kern von § 30 BSIG.

Gibt es einen Meldeprozess?

Wer erkennt, bewertet und meldet einen erheblichen Vorfall innerhalb von 24 und 72 Stunden?

Ist die Geschäftsleitung eingebunden?

§ 38 BSIG verlangt Umsetzung, Überwachung und regelmäßige Schulung auf Leitungsebene.

FAZIT

NIS2 beginnt nicht bei 250 Mitarbeitern

Die entscheidende Frage lautet nicht „Sind wir groß genug für NIS2?“, sondern: Welche Leistungen erbringen wir, welchem Sektor und welcher Einrichtungsart sind sie zuzuordnen – und welche Größen- oder Sonderregelungen gelten für uns?

Die gesetzliche Registrierungsfrist vom 6. März 2026 ist vorbei, die Registrierungspflicht selbst besteht aber weiter. Wer als MSP, MSSP, Cloud-, Rechenzentrums- oder DNS-Anbieter arbeitet, sollte die eigene Einordnung jetzt nachholen, statt sich auf die zuletzt entspanntere Tonlage der Bundesregierung zu verlassen.

Hinweis: Dieser Beitrag dient der technischen und organisatorischen Orientierung und ersetzt keine individuelle Rechtsberatung. Maßgeblich sind das aktuelle BSIG, seine Anlagen sowie die konkrete Unternehmensstruktur.

FAQ

Häufige Fragen zur NIS2-Registrierung

Sind wir als kleiner IT-Dienstleister automatisch von NIS2 betroffen?

Nicht automatisch. Für klassische Managed Service Provider gelten grundsätzlich die normalen Größenschwellen aus § 28 BSIG (ab 50 Mitarbeitern bzw. über 10 Mio. € Umsatz/Bilanzsumme). Bestimmte Einrichtungsarten wie DNS-Anbieter sind davon unabhängig betroffen.

Was ist ein Managed Service Provider im Sinne des BSIG?

Ein Anbieter von Leistungen rund um Installation, Verwaltung, Betrieb oder Wartung von IKT-Produkten, Netzwerken, Infrastruktur oder Anwendungen – vor Ort oder aus der Ferne. Die Definition orientiert sich am tatsächlichen Geschäftsmodell, nicht an der Selbstbezeichnung.

Gilt für DNS-Anbieter wirklich keine Mitarbeitergrenze?

Ja. § 28 Abs. 1 Nr. 2 BSIG stuft DNS-Diensteanbieter als besonders wichtige Einrichtung ein, ohne die sonst übliche 50-Mitarbeiter- oder Umsatzschwelle vorauszusetzen.

Wir haben die Frist am 6. März 2026 verpasst – was jetzt?

Die Registrierungspflicht besteht unabhängig von der verpassten Frist weiter. Das BSI kann eine Einrichtung nach § 33 BSIG notfalls selbst registrieren und Auskünfte verlangen. Eine verspätete Registrierung sollte deshalb umgehend nachgeholt werden.

Wie läuft die Registrierung beim BSI technisch ab?

Zweistufig: zuerst ein „Mein Unternehmenskonto“ (MUK) über muk.bsi.bund.de mit ELSTER-Organisationszertifikat anlegen, danach im BSI-Portal die eigentliche NIS2-Registrierung mit Kontaktdaten, Sektor und öffentlichen IP-Adressbereichen durchführen.

Welche Bußgelder drohen bei einer verspäteten Registrierung?

Für die reine Verletzung der Registrierungspflicht sieht § 65 BSIG eine Obergrenze von 500.000 € vor. Für fehlendes Risikomanagement oder versäumte Vorfallmeldungen können dagegen bis zu 10 Mio. € (besonders wichtige Einrichtungen) bzw. 7 Mio. € (wichtige Einrichtungen) fällig werden.

QUELLEN

Quellen und Links

BSI-Gesetz (BSIG) in der seit 6.12.2025 geltenden Fassung, insb. §§ 28, 30, 32, 33, 38, 65
BSI: NIS-2-Betroffenheitsprüfung (automatisierte, unverbindliche Ersteinschätzung)
BSI-Portal zur NIS2-Registrierung sowie muk.bsi.bund.de für das Unternehmenskonto
Bundesregierung: Antwort auf parlamentarische Anfrage, August 2026 (Registrierungsstand 19.058, Einordnung der 29.500-Schätzung)
Bundesgesetzblatt Nr. 221 vom 28. Juli 2026 (Änderung KRITIS-Dachgesetz/BSIG)

NIS2-Einordnung für Ihre IT?

Ob Registrierung, Risikomanagement oder Meldeprozess: Nutzen Sie unsere IT-Leistungen.

Der Beitrag NIS2: Bin ich betroffen? Registrierungspflicht für IT-Dienstleister erschien zuerst auf RDDZ.

US CLOUD Act: Warum „Daten liegen in Deutschland“ nicht die ganze Wahrheit ist

dennis_rddz — Fri, 25 Sep 2026 14:51:12 +0000

Datenschutz · US CLOUD Act · Compliance

US CLOUD Act: Warum „Daten liegen in Deutschland" nicht die ganze Wahrheit ist

Ein Microsoft-365-Tenant kann seine Daten in deutschen Rechenzentren speichern und trotzdem mit einem Anbieter betrieben werden, der US-Recht unterliegt. Im Juni 2025 musste ein Microsoft-Manager vor dem französischen Senat unter Eid einräumen, dass er das nicht ausschließen kann. Wir ordnen ein, was der CLOUD Act tatsächlich regelt, was er nicht regelt, und warum der Speicherort allein die Frage nicht beantwortet.

US CLOUD ACT

● Seit 2018 in Kraft

Speicherort

nicht entscheidend

DE-Abkommen

existiert nicht

DPF

kein CLOUD-Act-Schutz

CLOUD-Act-Abkommen mit DE/EU ✓ existiert nicht

Nur UK und Australien ✓ haben ein Abkommen

Microsoft 365 ✓ laut HBDI konform nutzbar möglich

Selbst-Hosting ✓ reduziert Risiko, kein Freifahrtschein

Serverstandort → US-Jurisdiktion → CLOUD Act → DSGVO/DPF

✓ Microsoft: keine Garantie möglich

✓ § 2713: Speicherort nicht entscheidend

✓ Kein CLOUD-Act-Abkommen mit DE/EU

✓ HBDI: M365 konform nutzbar möglich

✓ DPF ist kein CLOUD-Act-Schutz

EIN SATZ VOR DEM SENAT

Was der CLOUD Act tatsächlich regelt

Am 10. Juni 2025 wurde Anton Carniaux, Director of Public and Legal Affairs bei Microsoft France, vor einer Untersuchungskommission des französischen Senats vereidigt. Die Frage: Kann Microsoft garantieren, dass Daten französischer Bürger niemals aufgrund einer US-Anordnung ohne Zustimmung französischer Behörden herausgegeben werden?

„Non, je ne peux pas le garantir."

Carniaux antwortete mit diesem Satz und ergänzte direkt, ein solcher Fall sei bei europäischen Kunden bislang nicht vorgekommen. Das bedeutet nicht, dass Microsoft europäische Daten an die USA weitergibt, das lässt sich aus dieser Aussage nicht ableiten. Es bedeutet: Microsoft kann nicht garantieren, dass eine rechtmäßige US-Anordnung unter allen Umständen ausgeschlossen werden kann. Genau darum geht es beim CLOUD Act.

Der Clarifying Lawful Overseas Use of Data Act, kurz CLOUD Act, stammt aus 2018. Sein Hintergrund war ein Rechtsstreit zwischen Microsoft und US-Behörden um E-Mails eines Kontos, die auf einem Server in Dublin lagen. Microsoft argumentierte, eine US-Anordnung könne nicht auf außerhalb der USA gespeicherte Daten angewendet werden. Der Fall erreichte den US Supreme Court, noch bevor dieser entscheiden konnte, verabschiedete der Kongress den CLOUD Act, und der Supreme Court erklärte den Rechtsstreit für erledigt.

Der entscheidende Punkt steht heute in 18 U.S.C. § 2713: Ein erfasster Anbieter muss Daten herausgeben, die sich in seiner possession, custody or control befinden, unabhängig davon, ob sie innerhalb oder außerhalb der USA gespeichert sind. Der physische Standort des Servers ist damit nicht automatisch entscheidend.

KEIN AUTOMATISCHER SCHUTZ

Deutschland als Speicherort ist kein Freibrief

Ein einfacher Fall: Ein deutsches Unternehmen nutzt Microsoft 365, Exchange-Postfächer und OneDrive-Daten liegen in einem deutschen Rechenzentrum, SharePoint läuft in einer europäischen Region. Technisch liegen die Daten damit in Europa.

Die entscheidende zusätzliche Frage lautet aber: Wer kontrolliert diese Daten, und welchem Recht unterliegt der Anbieter? Bei einem Anbieter, der dem relevanten US-Rechtsrahmen unterliegt, kann eine US-rechtliche Herausgabeanordnung grundsätzlich auch außerhalb der USA gespeicherte Daten betreffen, sofern die gesetzlichen Voraussetzungen erfüllt sind. § 2713 stellt gerade nicht auf den physischen Speicherort ab.

Das bedeutet nicht, dass jede US-Tochter oder jede europäische Gesellschaft eines US-Konzerns automatisch jeder US-Anordnung folgen muss. Die konkrete US-Gerichtsbarkeit und die tatsächliche Kontrolle über die Daten spielen eine Rolle. Das vom Bundesinnenministerium beauftragte Rechtsgutachten der Universität zu Köln beschäftigt sich ausführlich mit genau diesen Fragen.

Wichtig ist auch, was der CLOUD Act nicht bedeutet: Ein häufiger Irrtum ist, ihn als eine Art dauerhaften Direktzugriff der US-Behörden auf europäische Microsoft-Server zu verstehen. Das besagt das Gesetz nicht. Es schafft gesetzliche Möglichkeiten, von bestimmten Anbietern im Einzelfall die Herausgabe von Daten zu verlangen. Welche rechtliche Maßnahme dafür erforderlich ist, hängt unter anderem von der Art der Daten und der jeweiligen Rechtsgrundlage ab.

DIE WICHTIGSTE EINORDNUNG

§ 2703(h): Ein spezieller Schutzmechanismus – aber nicht für Deutschland

Für bestimmte Herausgabeanordnungen betreffend Kommunikationsinhalte enthält § 2703(h) einen besonderen Mechanismus für Konflikte mit dem Recht bestimmter ausländischer Staaten. Danach kann ein Anbieter beantragen, eine Anordnung zu ändern oder aufzuheben, wenn die Herausgabe gegen das Recht einer „qualifying foreign government“ verstoßen würde.

Die entscheidende Einschränkung

Als „qualifying foreign government“ gilt nach § 2703(h) nur ein Staat, mit dem die USA ein Executive Agreement nach § 2523 abgeschlossen haben und dessen Rechtsordnung weitere gesetzliche Voraussetzungen erfüllt. Aktuell nennt das US-Justizministerium zwei solche CLOUD-Act-Abkommen: mit dem Vereinigten Königreich (unterzeichnet 2019) und mit Australien (unterzeichnet 2021, in Kraft seit 2024).

Ein entsprechendes Abkommen mit Deutschland oder einem EU-Mitgliedstaat besteht derzeit nicht. Die EU und die USA verhandeln zwar seit Jahren über grenzüberschreitenden Zugang zu elektronischen Beweismitteln, das ist aber nicht dasselbe wie ein in Kraft befindliches CLOUD-Act-Executive-Agreement.

Für deutsche Unternehmen bedeutet das: Der spezielle gesetzliche Konfliktmechanismus nach § 2703(h) steht ihnen mangels eines entsprechenden Abkommens derzeit nicht zur Verfügung. Das bedeutet nicht, dass ein Anbieter keinerlei andere rechtliche Einwendungen gegen eine US-Anordnung haben kann, das Kölner Gutachten bewertet die Rechtsschutzmöglichkeiten europäischer Unternehmen insgesamt aber als eingeschränkt.

Das ist kein theoretisches Detail: Der CLOUD Act sieht diesen Mechanismus zwar vor, Deutschland gehört aber derzeit nicht zu den Staaten mit einem entsprechenden Abkommen.

ZWEI WEITERE BAUSTEINE

Benachrichtigung und das Kölner Gutachten

Muss der Kunde von einem Zugriff erfahren?

Es stimmt nicht, dass US-Recht grundsätzlich jede Information verbietet. Es gibt aber Möglichkeiten, eine Benachrichtigung zu verzögern oder einem Anbieter zu untersagen, andere Personen zu informieren, § 2705 regelt entsprechende Verfahren. Für einen Kunden bedeutet das: Eine Benachrichtigung kann eingeschränkt oder verzögert sein, das ist etwas anderes als die pauschale Aussage „der Kunde erfährt nie etwas“.

Das Kölner Gutachten: Serverstandort ist nur ein Teil der Betrachtung

Das Rechtsgutachten der Universität zu Köln, im Auftrag des damaligen Bundesministeriums des Innern und für Heimat, wurde am 21. März 2025 vorgelegt und untersucht die US-Rechtslage zum weltweiten Datenzugriff bei Cloud-Diensten. Die Kurzfassung: US-Sicherheitsbehörden verfügen über weitreichende Herausgabe- und Zugriffsrechte, das betrifft nicht nur Daten auf US-Servern, unter bestimmten Voraussetzungen auch ausländische Server und Cloud-Anbieter, nicht immer ist dafür ein klassischer gerichtlicher Durchsuchungsbeschluss erforderlich.

Gleichzeitig ist das Gutachten keine Aussage darüber, dass jede solche Herausgabe nach deutschem oder europäischem Recht zulässig wäre. US-Recht und EU-Recht stehen nicht in einer Hierarchie: Ein US-Anbieter kann nach US-Recht zur Herausgabe verpflichtet und gleichzeitig nach europäischem Recht mit Datenschutzanforderungen konfrontiert sein. Genau daraus entsteht der mögliche Konflikt zwischen zwei Rechtsordnungen.

ZWEI VERSCHIEDENE FRAGEN

CLOUD Act, DSGVO und das Data Privacy Framework

Der CLOUD Act beantwortet eine Frage des US-Rechts: Kann ein Anbieter zur Herausgabe verpflichtet werden? Die DSGVO beantwortet eine andere: Unter welchen Voraussetzungen dürfen personenbezogene Daten in Drittländer übermittelt werden? Das eine hebt das andere nicht automatisch auf.

Die Europäische Kommission hat im Juli 2023 das EU-US Data Privacy Framework (DPF) als Angemessenheitsmechanismus beschlossen, er ist weiterhin in Kraft. Das Gericht der EU wies eine Klage dagegen am 3. September 2025 ab, ein Rechtsmittel (C-703/25 P, Latombe/Kommission) ist im September 2026 weiter anhängig. Am 31. Juli 2026 bat die EDSA-Vorsitzende Anu Talus die Kommission zusätzlich um eine Bewertung, ob das US-Urteil Trump v. Slaughter vom 29. Juni 2026 Auswirkungen auf die Unabhängigkeit der Federal Trade Commission (FTC) hat, die für das DPF zentral ist.

Der wichtigste Satz zur Einordnung: Das Data Privacy Framework ist kein Schutzmechanismus gegen den CLOUD Act. Es regelt die datenschutzrechtliche Zulässigkeit bestimmter Übermittlungen in die USA, es verhindert nicht, dass ein US-Anbieter einer rechtmäßigen US-Anordnung unterliegt. DPF und CLOUD Act beantworten unterschiedliche Fragen und lösen sich gegenseitig nicht auf.

DIE ANDERE SEITE

HBDI und DSK: nicht nur Warnungen

Microsoft 365 kann datenschutzkonform eingesetzt werden

Der Hessische Beauftragte für Datenschutz und Informationsfreiheit (HBDI) veröffentlichte im November 2025 einen 137-seitigen Bericht zu Microsoft 365 und kam zu dem Ergebnis: Microsoft 365 kann datenschutzkonform genutzt werden. Er hatte zuvor mit Microsoft sieben frühere Kritikpunkte der Datenschutzkonferenz am Microsoft-Datenschutznachtrag untersucht. Der HBDI kommt in seinem Bericht zu dem Ergebnis, dass personenbezogene Daten inzwischen weitgehend im Europäischen Wirtschaftsraum verarbeitet werden und verbleibende Übermittlungen über Angemessenheitsbeschlüsse beziehungsweise Standardvertragsklauseln abgesichert sind.

Zwei Einschränkungen: Der HBDI hat ausdrücklich keine technische Untersuchung einzelner Microsoft-365-Dienste durchgeführt, er bewertet vertragliche und rechtliche Rahmenbedingungen. Und er trifft damit keine Aussage, dass Microsoft 365 vor einem Zugriff aufgrund US-amerikanischen Rechts geschützt wäre.

DSK: Vorsicht bei „Confidential Cloud Computing"

Die Datenschutzkonferenz verabschiedete am 16. Juni 2025 eine Entschließung zu „Confidential Cloud Computing“ und weist darauf hin, dass der Begriff nicht einheitlich definiert ist. Die Aussage, Daten könnten sogar vor dem Cloud-Betreiber geheim gehalten werden, hängt vom konkreten Angreifermodell ab und greift als pauschales Werbeversprechen zu kurz.

Das Kölner Gutachten weist ergänzend darauf hin, dass technische Maßnahmen wie Verschlüsselung eine US-rechtliche Zugriffsmöglichkeit nicht automatisch ausschließen, relevant ist unter anderem, ob der Anbieter selbst noch Zugriff auf die Daten oder die zur Entschlüsselung erforderlichen Schlüssel hat.

ZUSAMMENGEFASST

Drei Aussagen, die nicht dasselbe bedeuten

Daten liegen in Deutschland	Physischer bzw. vertraglich zugesicherter Speicherort
Daten werden innerhalb der EU/EWR verarbeitet	Regionale Datenverarbeitung bzw. Datenresidenz
Anbieter unterliegt keinem relevanten US-Recht	Frage der rechtlichen Zugriffsmöglichkeit

CHANCEN UND GRENZEN

Warum Selbst-Hosting hier interessant wird

Self-Hosting ist nicht automatisch sicherer, aber es verändert den Rechts- und Kontrollrahmen. Eine Nextcloud auf eigener Hardware in Deutschland ist eine andere Konstellation als OneDrive bei einem US-Hyperscaler.

✓

Was sich ändert

Ein selbst betriebener Mailserver wie mailcow unterscheidet sich grundsätzlich von Exchange Online, bei Vaultwarden kontrolliert der Betreiber die Infrastruktur und Datenablage selbst.

◐

Kein Freifahrtschein

Steht der Server bei einem US-Cloudanbieter, liegen Backups bei einem US-Anbieter, läuft Monitoring über einen US-Dienst, ist die Infrastruktur nicht vollständig aus diesem Rechtsraum herausgelöst.

↻

Die ganze Kette zählt

„Der Anbieter sitzt in Deutschland“ ist genauso wenig eine vollständige Prüfung wie „der Server steht in Deutschland“. Entscheidend sind Betreiber, Zugriff, Backup-Ziel, Subunternehmer und Supportsysteme zusammen.

Die saubere Formulierung: Eine vollständig europäisch betriebene Infrastruktur ohne US-rechtlich relevante Anbieter in der Verarbeitungskette reduziert dieses konkrete CLOUD-Act-Risiko erheblich. Genau deshalb setzen wir bei RDDZ konsequent auf europäische, quelloffene Bausteine: Nextcloud statt SharePoint/OneDrive, mailcow statt Exchange Online, Vaultwarden statt einem US-Passwortmanager, UniFi OS Server statt Cloud-verwaltetem Netzwerk-Controller. Und auch bei vollständig selbst betriebener Infrastruktur bleiben Sicherheitsupdates, Backup, Restore-Tests und Dokumentation Aufgabe des Betreibers. Self-Hosting verschiebt Verantwortung, es hebt sie nicht auf.

CHECKLISTE

Was Unternehmen praktisch mitnehmen sollten

Nicht nur auf den Speicherort schauen

„Die Daten liegen in Deutschland“ beantwortet nicht, wem der Anbieter rechtlich verpflichtet ist.

Die ganze Verarbeitungskette prüfen

Nicht nur die Hauptanwendung: Backup-Ziel, CDN, Monitoring, Support, Mailrelay.

Datensensibilität einordnen

Nicht jede Verarbeitung braucht dieselbe Vorsicht, bei Gesundheitsdaten oder Berufsgeheimnissen lohnt eine strengere Betrachtung.

Bestehendes nicht pauschal verteufeln

Microsoft 365 kann laut HBDI unter den geprüften vertraglichen und rechtlichen Rahmenbedingungen datenschutzkonform genutzt werden.

Bei Selbst-Hosting den Betrieb ernst nehmen

Sonst verschiebt man nur das Risiko, statt es zu senken: Updates, Backups, Zugriffsschutz bleiben Pflicht.

Bei Bedarf fachlich beraten lassen

Gerade bei regulierten Branchen oder besonders sensiblen Daten lohnt eine individuelle Prüfung der eigenen Infrastruktur.

FAZIT

Kein Mythos, aber auch kein Papiertiger

Der CLOUD Act ist kein Mythos und kein automatischer Zugriff, aber auch kein Papiertiger. Microsoft selbst hat unter Eid eingeräumt, eine vollständige Garantie nicht geben zu können, während der spezielle gesetzliche Konfliktmechanismus nach § 2703(h) mangels eines entsprechenden CLOUD-Act-Exekutivabkommens für Deutschland derzeit nicht zur Verfügung steht. Gleichzeitig hält eine deutsche Aufsichtsbehörde Microsoft 365 unter bestimmten Bedingungen für datenschutzkonform nutzbar, und das Data Privacy Framework ist trotz laufender rechtlicher Entwicklung weiterhin gültig.

Für Unternehmen bedeutet das: keine Panik, aber auch keine blinde Beruhigung durch „die Daten liegen doch in Deutschland“. Wer besonders sensible Daten verarbeitet oder das Risiko grundsätzlich nicht eingehen will, findet mit einer konsequent europäischen, selbst gehosteten Infrastruktur den Weg, der dieses spezielle Risiko am wirksamsten reduziert, verbunden mit der eigenen Verantwortung, diese Infrastruktur auch sauber zu betreiben. Mehr zum Zusammenhang mit dem Speicherort selbst: Microsoft 365: Datenstandort Deutschland ändert sich.

FAQ

Häufige Fragen zum US CLOUD Act

Bedeutet der CLOUD Act, dass US-Behörden jederzeit auf europäische Microsoft-Server zugreifen können?

Nein. Der CLOUD Act schafft gesetzliche Möglichkeiten, von bestimmten Anbietern im Einzelfall die Herausgabe konkreter Daten zu verlangen, kein dauerhaftes Zugriffsrecht. Welche Maßnahme nötig ist, hängt von der Art der Daten und der Rechtsgrundlage ab.

Schützt es, wenn meine Daten in Deutschland gespeichert werden?

Es reduziert bestimmte Risiken und erfüllt organisatorische Anforderungen, ist aber kein vollständiger Schutz. § 2713 CLOUD Act stellt nicht auf den physischen Speicherort ab, sondern auf possession, custody or control des Anbieters.

Kann sich ein Anbieter gegen eine US-Anordnung wehren?

Der CLOUD Act sieht mit § 2703(h) einen Mechanismus dafür vor, er gilt aber nur gegenüber Staaten mit einem CLOUD-Act-Executive-Agreement. Das haben aktuell nur Großbritannien und Australien, Deutschland und die EU nicht.

Schützt mich das EU-US Data Privacy Framework vor dem CLOUD Act?

Nein. Das DPF regelt die datenschutzrechtliche Zulässigkeit von Datenübermittlungen in die USA, es verhindert nicht, dass ein US-Anbieter einer rechtmäßigen US-Anordnung nach dem CLOUD Act unterliegt. Beides sind unterschiedliche Rechtsfragen.

Ist Microsoft 365 deshalb nicht DSGVO-konform?

Diese pauschale Aussage lässt sich nicht halten. Der Hessische Beauftragte für Datenschutz kam 2025 zu dem Ergebnis, dass Microsoft 365 unter bestimmten vertraglichen und rechtlichen Bedingungen datenschutzkonform genutzt werden kann, allerdings ohne eigene technische Prüfung einzelner Dienste.

Löst Selbst-Hosting das Problem vollständig?

Es reduziert das konkrete CLOUD-Act-Risiko erheblich, wenn die gesamte Verarbeitungskette ohne US-rechtlich relevante Anbieter auskommt, ist aber kein Freifahrtschein. US-CDN, US-Backup oder US-Monitoring in der Verarbeitungskette können wiederum einen Anbieter einbeziehen, der einem relevanten US-Rechtsrahmen unterliegt, und die eigene Betriebsführung bleibt Pflicht.

QUELLEN

Quellen und Rechtsgrundlagen

18 U.S.C. § 2713, § 2703(h), § 2705 (CLOUD Act / Stored Communications Act)
Sénat français: Anhörung Anton Carniaux (Microsoft France), 10. Juni 2025
Rechtsgutachten der Universität zu Köln im Auftrag des BMI, 21. März 2025
US Department of Justice: CLOUD Act Agreements (UK, Australien)
HBDI: Bericht zu Microsoft 365, November 2025
Datenschutzkonferenz: Entschließung „Confidential Cloud Computing“, 16. Juni 2025
EuG, Urteil vom 3. September 2025; EuGH C-703/25 P (Latombe/Kommission), anhängig
EDSA: Schreiben an die EU-Kommission zu Trump v. Slaughter, 31. Juli 2026

Europäische Infrastruktur statt US-Cloud?

Ob Nextcloud, mailcow oder Vaultwarden: Nutzen Sie unsere IT-Leistungen.

Der Beitrag US CLOUD Act: Warum „Daten liegen in Deutschland“ nicht die ganze Wahrheit ist erschien zuerst auf RDDZ.

Microsoft 365: Datenstandort Deutschland ändert sich

dennis_rddz — Fri, 25 Sep 2026 14:43:51 +0000

Microsoft 365 · Datenschutz · Compliance

Microsoft 365: Datenstandort Deutschland ändert sich

Microsoft ändert 2026 die Regeln für den Datenstandort bestimmter Microsoft-365-Daten. Seit dem 14. September 2026 gibt es für bestimmte Tenants in Deutschland eine neue Einstellung im Admincenter, die entscheidet, ob Daten weiterhin in Deutschland oder regional innerhalb der EU-Datengrenze gespeichert werden. Die Frist ist der 14. Dezember 2026, keine Panikmeldung, aber eine Konfigurations- und Compliance-Frage.

DATENSTANDORT 2026

● Frist 14.12.2026

Sichtbar

seit 14.09.2026

Wirksam

ab 14.12.2026

Standard

Off (EU-weit)

Verlässt die EU? ✓ nein

DSGVO-Pflicht zu „nur Deutschland“? ✓ nein

Rückmigration falls „On“ später ✓ ~6 Monate

Betroffen ✓ Exchange, SharePoint, OneDrive, Teams, Copilot

Deutschland ≠ EU-Datengrenze ≠ „nur“ Deutschland

✓ Neue Einstellung seit 14.09.2026

✓ Frist: 14.12.2026

✓ Standard: Off (EU-weit möglich)

✓ Betrifft DE, FR, NO, SE, CH

✓ Keine DSGVO-Pflicht zu „nur DE“

DIE ÄNDERUNG

Was Microsoft konkret geändert hat

Microsoft nennt die neue Option „Store Microsoft 365 customer data in-country“, zu finden im Admincenter unter Admin → Einstellungen → Organisationseinstellungen → Organisationsprofil → Datenspeicherort → Verpflichtungen.

14.09.2026: sichtbar

Die Einstellung steht seither zur Prüfung bereit. Die bestehende Datenposition soll während dieser rund dreimonatigen Prüfphase nicht verändert werden.

14.12.2026: wirksam

Die hinterlegte Auswahl wird verbindlich. Microsoft weist ausdrücklich darauf hin, dass nicht alle Daten an diesem einen Tag verschoben werden.

Nicht für jeden Tenant

Betroffen sind berechtigte kommerzielle Tenants mit Standardgeografie in Deutschland, Frankreich, Norwegen, Schweden oder der Schweiz. Tenants mit Advanced Data Residency oder Multi-Geo sehen die Einstellung nicht.

ON ODER OFF

Der wichtigste Unterschied

Was bedeutet „On“ und „Off“?

On: Microsoft hält die betroffenen Core-Service-Daten im Ruhezustand in der zugeordneten Länder-Geografie, für einen deutschen Tenant also in Deutschland.

Off (Standard): Microsoft darf diese Daten regional innerhalb der EU-Datengrenze speichern und verschieben. Microsoft formuliert ausdrücklich, dass das Ausschalten die bisherige In-Country-Data-at-Rest-Zusage für diese Dienste entfernt.

WICHTIGE KLARSTELLUNG

EU-Datengrenze bedeutet nicht Deutschland

Die EU Data Boundary ist eine von Microsoft definierte geografische Grenze, sie umfasst die EU- und die EFTA-Staaten. Damit können Daten künftig auch innerhalb verschiedener europäischer Rechenzentrumsstandorte liegen, ohne dass Deutschland weiterhin zwingend der Speicherort sein muss.

◐

Deutschland

Eine konkrete Länder-Geografie: ein einzelnes Land als zugesagter Speicherort.

▤

EU Data Boundary

Eine größere regionale Geografie innerhalb EU und EFTA. Das ist nicht dasselbe wie Deutschland.

✓

Kein neues Konstrukt

Die EU-Datengrenze existiert bereits seit 2023 für Microsoft 365, Azure, Power Platform und Dynamics 365. Sie wird hier nicht verlassen, nur die engere Zusage „nur Deutschland“ steht zur Wahl.

Wichtig: Die Daten bleiben in jedem Fall innerhalb der EU-Datengrenze, unabhängig davon, ob die Einstellung an- oder ausgeschaltet ist. Es geht nicht darum, ob Daten Europa verlassen, sondern nur darum, ob sie ausschließlich in einem Land oder regional innerhalb der EU/EFTA gespeichert werden dürfen.

DIENSTE UND GRENZEN

Betroffene Dienste und die Grenzen der Grenze

Die neue Einstellung gilt nur für die sogenannten Microsoft 365 Core Services.

◐

Betroffen

Exchange Online
SharePoint
OneDrive for Business
Microsoft Teams
Microsoft 365 Copilot / Copilot Chat

✎

Nicht daraus ableiten

„Alle Microsoft-365-Daten liegen ab jetzt in Deutschland“ ist falsch. Genauso falsch: „Alle Daten werden ab Dezember irgendwo in Europa gespeichert.“ Andere Microsoft-Dienste können eigenen Datenresidenz-Regeln unterliegen, ein Blick auf die konkrete Data Location Card lohnt sich immer.

↗

Data at rest ≠ Verarbeitung

Microsoft spricht von Customer Data at rest, also Daten im Ruhezustand. Das ist nicht dasselbe wie „diese Daten werden ausschließlich in Deutschland verarbeitet“.

Auch die EU-Datengrenze ist keine absolute technische Grenze

Microsoft dokumentiert selbst begrenzte Situationen, in denen Daten trotz EU-Datengrenze außerhalb übertragen werden können: Remotezugriff durch Microsoft-Mitarbeiter außerhalb der Grenze, vom Kunden selbst ausgelöste Übertragungen, bestimmte Sicherheits- und Schutzmaßnahmen, begrenzte Replikation von Verzeichnisdaten, bestimmte Netzwerktransits sowie Service-, Plattform- und Resilienzmaßnahmen. Diese Szenarien sind Teil der von Microsoft beschriebenen Bedingungen und über die entsprechenden Vertrags- und Datenschutzmechanismen abgedeckt. Für Administratoren heißt das: EU-Datengrenze bedeutet nicht „kein Byte verlässt jemals Europa“.

DIE ENTSCHEIDENDE FRAGE

Und was bedeutet das für die DSGVO?

Kurz und direkt: Es gibt keine DSGVO-Pflicht zur ausschließlichen Speicherung in Deutschland, weder vorher noch nachher.

Die DSGVO regelt in den Artikeln 44 ff. Übermittlungen personenbezogener Daten in Länder außerhalb der EU und des EWR (sogenannte Drittländer). Datenverkehr zwischen EU-/EWR-Mitgliedstaaten fällt gar nicht unter diese Drittland-Regeln, er ist datenschutzrechtlich innerhalb der Union frei möglich. Eine Speicherung „irgendwo in der EU-Datengrenze“ statt „nur in Deutschland“ berührt diese Vorschriften deshalb grundsätzlich nicht.

Das heißt aber nicht, dass der Speicherort für Datenschutz und Compliance völlig egal ist. Die DSGVO-Konformität eines Microsoft-365-Tenants hängt nicht allein davon ab, ob Daten in Deutschland oder beispielsweise Frankreich liegen. Relevant sind unter anderem: welche personenbezogenen Daten verarbeitet werden, welche Microsoft-Dienste eingesetzt werden, welche Unterauftragsverarbeiter beteiligt sind, welche vertraglichen Grundlagen gelten (Microsoft stellt dafür ein Data Protection Addendum und EU-Standardvertragsklauseln bereit) und welche technischen und organisatorischen Maßnahmen eingesetzt werden.

Ein Fall, in dem es doch relevant wird: Wenn ein Unternehmen gegenüber Kunden, Mitarbeitern oder Geschäftspartnern vertraglich ausdrücklich eine bestimmte, engere Datenresidenz zugesichert hat (zum Beispiel „ausschließlich Deutschland“), kann die Änderung dieser Microsoft-Einstellung diese eigene Zusage berühren, unabhängig von der DSGVO selbst.

FOLGEN UND ALTERNATIVEN

Was passiert, wenn man nichts tut?

Nichts tun bedeutet: Off bleibt aktiv

Bei einem berechtigten Tenant bleibt die Einstellung zunächst deaktiviert. Ab dem 14. Dezember 2026 kann Microsoft bei solchen Tenants mit der regionalen Speicherung beziehungsweise Verschiebung innerhalb der EU-Datengrenze beginnen, nicht zwingend vollständig an diesem einen Tag.

Die Einstellung lässt sich später wieder auf „On“ stellen, Microsoft verpflichtet die Daten dann wieder auf die ursprüngliche Geografie und beginnt mit der Rückmigration. Diese kann laut Microsoft rund sechs Monate dauern. Wer die Länder-Geografie wichtig findet, sollte deshalb vor dem 14. Dezember entscheiden, statt später „einfach zurückzustellen“.

Das ist nicht dasselbe wie Advanced Data Residency

Advanced Data Residency (ADR) ist ein kostenpflichtiges Add-on mit weitergehenden Datenresidenz-Zusagen für bestimmte Dienste und Länder, Deutschland gehört zu den unterstützten Geografien. Tenants mit ADR, ADR for Education oder Multi-Geo sehen die neue „in-country“-Einstellung gar nicht, weil deren Datenresidenz bereits über diese kostenpflichtigen Angebote gesteuert wird.

CHECKLISTE

So prüfst du deinen Microsoft-365-Tenant

Im Admincenter: Admin → Einstellungen → Organisationseinstellungen → Organisationsprofil → Datenspeicherort → Verpflichtungen. Zusätzlich lohnt der Blick auf die Data Location Card, sie unterscheidet zwischen der aktuellen Current Geography und der zugesicherten Committed Geography.

Tenant prüfen

Ist der Tenant betroffen? Ist die Einstellung vorhanden, und steht sie auf On oder Off? Welche Committed Geography wird angezeigt?

Datenschutzvorgaben prüfen

Nicht nur „wo liegt die Datei“, sondern auch: Welche Datenresidenz wurde Kunden, Mitarbeitern oder Geschäftspartnern zugesichert?

Dienste klassifizieren

Nicht jede Microsoft-365-Komponente fällt unter dieselbe Zusage, besonders bei Copilot, Entra ID, Sicherheitsprodukten und Drittanbieter-Integrationen lohnt ein eigener Blick.

Bei strengeren Compliance-Anforderungen prüfen, ob die vorhandene Konfiguration tatsächlich ausreicht, und die Entscheidung vor dem 14. Dezember treffen, nicht erst danach, wegen der rund sechsmonatigen Rückmigration.

RICHTIGSTELLUNG

Was Microsoft damit nicht sagt

Microsoft sagt nicht: „Ab Dezember liegen deutsche Microsoft-365-Daten irgendwo in den USA.“ Die neue Option verschiebt die Datenresidenz von Deutschland auf die EU-Datengrenze, nicht in die USA.

Microsoft sagt auch nicht: „Ab Dezember sind deutsche Microsoft-365-Daten nicht mehr DSGVO-konform.“ Dafür gibt es keine Grundlage.

Ebenso falsch wäre die Annahme: „Die Daten sind garantiert ausschließlich in Deutschland und werden niemals außerhalb Deutschlands verarbeitet.“ Auch das lässt sich aus der Einstellung nicht ableiten, unabhängig von On oder Off.

FAZIT

Eine Konfigurationsfrage, keine Panikmeldung

Wer einen deutschen Microsoft-365-Tenant betreibt und Wert darauf legt, dass die betroffenen Core-Service-Daten weiterhin der deutschen Geografie zugeordnet bleiben, sollte die neue Einstellung im Admincenter vor dem 14. Dezember 2026 prüfen. Wer nichts ändert, bekommt bei einem betroffenen Tenant künftig eine regionale Speicherung innerhalb der EU-Datengrenze, mehr Flexibilität für Microsoft, aber Deutschland ist dann nicht mehr als konkrete Datenresidenz zugesichert.

Deutschland ≠ EU-Datengrenze ≠ ausschließliche Verarbeitung in Deutschland. Für Datenschutz und Compliance entscheidend ist deshalb nicht nur, wo Microsoft die Daten speichert, sondern auch, welche Dienste betroffen sind, welche Verarbeitung stattfindet und welche vertraglichen Zusagen für den konkreten Tenant gelten, unabhängig davon, dass eine DSGVO-Pflicht zu „nur Deutschland“ nie bestanden hat.

FAQ

Häufige Fragen zum Datenstandort

Verlangt die DSGVO, dass Daten ausschließlich in Deutschland gespeichert werden?

Nein. Die DSGVO regelt nur Übermittlungen in Länder außerhalb der EU/des EWR. Datenverkehr zwischen EU-Mitgliedstaaten fällt nicht unter diese Regeln. Eine Speicherung innerhalb der EU-Datengrenze statt nur in Deutschland ist datenschutzrechtlich grundsätzlich unproblematisch.

Werden meine Daten ab Dezember 2026 in die USA verschoben?

Nein. Die neue Einstellung verschiebt die Datenresidenz höchstens von Deutschland auf die EU-Datengrenze (EU und EFTA), nicht in die USA oder andere Drittländer.

Was bedeutet die Einstellung „On“ und „Off“ konkret?

On: Microsoft hält die betroffenen Daten im Ruhezustand in Deutschland. Off (Standard): Microsoft darf sie regional innerhalb der EU-Datengrenze speichern und verschieben.

Welche Dienste sind betroffen?

Nur die Microsoft 365 Core Services: Exchange Online, SharePoint, OneDrive for Business, Microsoft Teams sowie Microsoft 365 Copilot und Copilot Chat. Andere Microsoft-Dienste können eigenen Regeln unterliegen.

Was passiert, wenn ich die Frist verpasse?

Die Einstellung bleibt auf Off, Microsoft kann ab dem 14. Dezember 2026 mit der regionalen Speicherung beginnen. Die Einstellung lässt sich später ändern, die Rückmigration nach Deutschland dauert dann aber laut Microsoft rund sechs Monate.

Warum sehe ich die Einstellung in meinem Tenant gar nicht?

Sie gilt nur für berechtigte kommerzielle Tenants mit Standardgeografie in Deutschland, Frankreich, Norwegen, Schweden oder der Schweiz. Tenants mit Advanced Data Residency oder Multi-Geo sehen sie nicht, weil deren Datenresidenz bereits anders geregelt ist.

QUELLEN

Quellen und Links

Microsoft Learn: Data residency in Microsoft 365 (Committed Geography, Data Location Card)
Microsoft Learn: EU Data Boundary Übersicht und Ausnahmen
Microsoft Message Center: MC1470878 (Store Microsoft 365 customer data in-country)
Microsoft: Product Terms und Data Protection Addendum (DPA)

Microsoft 365 datenschutzkonform betreiben?

Ob Tenant-Prüfung, Datenschutz oder IT-Infrastruktur: Nutzen Sie unsere IT-Leistungen.

Der Beitrag Microsoft 365: Datenstandort Deutschland ändert sich erschien zuerst auf RDDZ.

TLS-Zertifikate 2026: Warum 200 Tage jetzt zum Problem werden

dennis_rddz — Fri, 25 Sep 2026 04:10:00 +0000

Server · TLS · Automatisierung

TLS-Zertifikate 2026: Warum 200 Tage jetzt zum Problem werden

Wer heute noch öffentliche TLS-Zertifikate manuell verlängert, sollte sich langsam nach einer anderen Lösung umsehen. Seit dem 15. März 2026 dürfen öffentlich vertrauenswürdige TLS-Zertifikate nach den neuen Regeln des CA/Browser Forums maximal 200 Tage gültig sein. Ab März 2027 werden daraus 100 Tage, 2029 nur noch 47. Und Let’s Encrypt geht bei den eigenen Profilen sogar noch schneller voran.

TLS-ZERTIFIKATE 2026

● Stufe 1 seit 15.03.2026 aktiv

200 Tage

seit März 2026

100 Tage

ab März 2027

47 Tage

ab März 2029

Interne PKI/Homelab ✓ nicht betroffen

Let’s Encrypt 45 Tage ✓ seit 13.05.2026 testbar

Manuelle Verlängerung ✓ wird zum Dauerjob

Lösung ✓ ACME automatisieren

398 → 200 → 100 → 47 Tage

✓ Stufe 1: 200 Tage seit 15.03.2026

✓ Stufe 2: 100 Tage ab März 2027

✓ Stufe 3: 47 Tage ab März 2029

✓ Let’s Encrypt: 45 Tage schon testbar

✓ Interne CAs nicht betroffen

DER ZEITPLAN

Von 398 auf 200 Tage – und danach weiter

Das CA/Browser Forum hat mit dem Ballot SC081v3 einen festen Zeitplan für die Verkürzung der maximalen Zertifikatslaufzeiten beschlossen, mit großer Mehrheit angenommen, unter anderem von den großen Browser-Anbietern.

bis 14.03.2026

Maximal 398 Tage, der bisherige Standard.

ab 15.03.2026

Maximal 200 Tage. Diese erste Stufe ist bereits aktiv.

ab 15.03.2027

Maximal 100 Tage.

ab 15.03.2029

Maximal 47 Tage, die letzte Stufe.

Das sind Maximalwerte, keine Pflichtwerte

Eine CA darf weiterhin kürzere Zertifikate ausstellen. DigiCert beispielsweise stellt seit Februar 2026 Zertifikate mit maximal 199 Tagen aus, einen Tag weniger als das CA/Browser-Forum-Maximum. Wer heute ein neues öffentliches Zertifikat beantragt, bekommt also nicht mehr automatisch die früher möglichen 398 Tage.

HINTERGRUND

Warum werden die Zertifikate überhaupt kürzer?

Die Verkürzung hat nicht den Grund, dass RSA oder TLS plötzlich unsicher geworden wären. Das CA/Browser Forum nennt mehrere Gründe.

◐

Der Zustand veraltet

Ein Zertifikat beschreibt einen bestimmten Zustand zum Zeitpunkt der Ausstellung, etwa Domainbesitz oder Kontrolle über Systeme. Je länger es gültig bleibt, desto größer die Wahrscheinlichkeit, dass sich dieser Zustand verändert.

▤

Reaktionsfähigkeit der Web-PKI

Stellt eine CA falsch aus, wird ein Schlüssel kompromittiert oder muss ein Verfahren ersetzt werden, ist es hilfreich, wenn alte Zertifikate nicht noch jahrelang gültig bleiben.

✓

Automatisierung als Nebeneffekt

Das Forum nennt die Automatisierung des Zertifikatslebenszyklus ausdrücklich als erwarteten Nebeneffekt: Ausstellung, Austausch und Rotation sollen zuverlässiger automatisiert werden.

DIE EIGENTLICHE HÜRDE

Erneuert ist nicht dasselbe wie übernommen

200 Tage sind noch kein echtes Problem, 47 Tage schon: Aus einer gelegentlichen Wartungsaufgabe wird ein laufender Prozess, gerade wenn ein Server gleichzeitig Zertifikate für www.example.de, mail.example.de, autodiscover.example.de, einen Reverse Proxy und mehrere Kunden-Domains verwendet.

Ein automatisierter Zertifikatsabruf allein reicht nicht. Erneuert Certbot erfolgreich das Zertifikat für mail.example.de, liegt es danach korrekt im Zertifikatsordner. Wenn Postfix oder Dovecot aber weiterhin das alte Zertifikat im Speicher halten, hat sich für den Client zunächst nichts geändert. Nach einer erfolgreichen Erneuerung muss deshalb je nach Software ein Reload oder eine andere Form der Übernahme erfolgen.

Certbot bietet dafür sogenannte deploy-hooks an, die nach einer erfolgreichen Erneuerung automatisch einen Webserver oder Maildienst neu laden. Postfix dokumentiert dafür postfix reload. Erst der komplette Ablauf ist wirklich automatisiert:

ACME → Zertifikat erneuern → Zertifikat installieren → Dienst neu laden → Funktion prüfen

ACME steht für Automatic Certificate Management Environment, das Protokoll, über das ein Client mit einer Zertifizierungsstelle kommuniziert. Let’s Encrypt ist dabei die Zertifizierungsstelle, Certbot ein möglicher Client, oft wird auch beides verwechselt. Certbot ist ausdrücklich für automatisierte Erneuerungen ausgelegt: certbot renew prüft die vorhandenen Zertifikate und erneuert nur, was ansteht, ausgeführt über systemd-Timer oder Cron. Ein sinnvoller Test nach der Einrichtung:

certbot renew --dry-run

BEREITS AKTIV

Let’s Encrypt macht schon vor, was jetzt Standard wird

Für Let’s-Encrypt-Nutzer ist diese Entwicklung eigentlich nichts grundsätzlich Neues, und ein Teil davon läuft schon heute, nicht erst in der Zukunft.

Seit 15.01.2026

Ein optionales Profil mit rund sechs Tagen (160 Stunden) Laufzeit ist allgemein verfügbar, ohne Widerrufsprüfung, nicht als Standard gedacht.

Seit 13.05.2026

Das Opt-in-Profil „tlsserver“ stellt Zertifikate mit 45 Tagen Laufzeit aus. Wer es aktiv anfordert, kann es schon heute nutzen.

10.02.2027 / 16.02.2028

Das Standardprofil „classic“, das die meisten ACME-Clients ohne besondere Einstellung bekommen, wechselt am 10.02.2027 auf 64 Tage und am 16.02.2028 auf 45 Tage.

Bei der Domain-Validierung geht Let’s Encrypt noch weiter

Die Wiederverwendung einer Domain-Validierung sinkt beim Standardprofil von 30 Tagen auf 10 Tage (2027) und dann auf nur noch 7 Stunden (2028), deutlich unter das CA/Browser-Forum-Minimum von 10 Tagen, das dort erst 2029 gilt.

Wenn die Automatisierung einmal funktioniert, spielt es für den Administrator kaum noch eine Rolle, ob ein Zertifikat 200, 90 oder 45 Tage gültig ist. Genau das macht 47 Tage weniger dramatisch, als es klingt.

ZWEI EINORDNUNGEN

Mailserver und interne Zertifikate

Was ändert sich für Mailserver?

Ein öffentliches Zertifikat wird oft gleichzeitig für SMTP, IMAP, Webmail und Autodiscover verwendet. Bei einem einzelnen Webserver reicht meist:

ACME → Zertifikat → nginx reload

Bei einem Mailserver kann daraus schnell werden:

ACME → Zertifikat → Postfix → Dovecot → Webmail → weitere Dienste

Wer bisher einmal im Jahr manuell eine Zertifikatsdatei kopiert hat, sollte diesen Ablauf jetzt sauber durchplanen.

Und was ist mit internen Zertifikaten?

Die neuen Laufzeitvorgaben gelten für Zertifikate, die unter die TLS Baseline Requirements für öffentlich vertrauenswürdige Serverzertifikate fallen, also für Server, die über das Internet erreichbar sind. Eine eigene interne CA ist davon nicht automatisch betroffen: Wer für ein Homelab eine eigene PKI betreibt und deren Root-CA auf den eigenen Geräten verteilt, kann weiterhin eigene Laufzeiten festlegen. Für öffentlich erreichbare Webseiten, Mailserver und andere Dienste mit öffentlich vertrauenswürdigen Zertifikaten sieht es dagegen anders aus.

CHECKLISTE

Was Administratoren jetzt prüfen sollten

Wenn noch irgendwo Zertifikate manuell verlängert werden, würden wir nicht bis 2027 oder 2029 warten. Eine kleine Bestandsaufnahme reicht zunächst:

Welche öffentlichen Zertifikate gibt es?

Nicht nur Webseiten: auch Mailserver, Reverse Proxies, VPN-Portale, Monitoring-Systeme und Webinterfaces.

Wer stellt sie aus?

Let’s Encrypt, DigiCert, Sectigo oder eine andere öffentliche CA?

Wie werden sie erneuert?

ACME, Hosting-Panel, manuell per Datei oder per E-Mail-Erinnerung?

Wie kommt das neue Zertifikat zum Dienst?

Die Ausstellung allein zu automatisieren reicht nicht.

Wird der Dienst neu geladen?

Das sollte fester Teil des automatisierten Ablaufs sein.

Was passiert bei einem Fehler?

Ein fehlgeschlagener ACME-Lauf darf nicht erst auffallen, wenn der Browser ein abgelaufenes Zertifikat meldet.

Gibt es einen Ablauf-Test?

Certbot bietet dafür –dry-run zur Prüfung des späteren Renewal-Ablaufs.

FAZIT

Zertifikate werden zur laufenden Aufgabe – aber nicht für den Administrator

Die 200 Tage sind nicht das eigentliche Problem. Das Problem ist ein manueller Prozess. Seit März 2026 gilt für öffentliche TLS-Zertifikate ein Maximum von 200 Tagen, 2027 werden daraus 100 Tage, 2029 nur noch 47. Auch in aktuellen Diskussionen unter Administratoren zeigt sich ein einheitliches praktisches Problem: Nicht die Ausstellung eines neuen Zertifikats ist die größte Herausforderung, sondern die Systeme, die es anschließend übernehmen müssen, insbesondere die Verteilung an mehrere Dienste und deren Neuladen.

Wer heute noch jedes Zertifikat einzeln bestellt, herunterlädt, auf den Server kopiert und anschließend Dienste neu startet, sollte diesen Ablauf automatisieren. ACME, Certbot, integrierte Lösungen in Reverse Proxies oder Funktionen des Hosting-Panels machen das möglich.

Das Ziel ist nicht, sich einen Termin für die nächste Zertifikatsverlängerung in den Kalender zu schreiben. Das Ziel ist, dass man überhaupt keinen Termin mehr braucht. Wenn die Erneuerung funktioniert, das neue Zertifikat automatisch verteilt wird, die betroffenen Dienste neu laden und ein Monitoring Fehler meldet, spielt die maximale Laufzeit irgendwann keine große Rolle mehr. Dann sind 200 Tage kein Problem. 100 Tage auch nicht. Und 47 Tage ebenfalls nicht.

FAQ

Häufige Fragen zu den neuen Laufzeiten

Ab wann gelten die 200 Tage genau?

Seit dem 15. März 2026. Öffentlich vertrauenswürdige TLS-Zertifikate dürfen seitdem maximal 200 Tage gültig sein, vorher waren es 398 Tage.

Muss ich jetzt sofort auf ACME umstellen?

Vorgeschrieben ist das nicht, man kann weiterhin manuell verlängern. Praktisch wird ACME-Automatisierung aber kaum vermeidbar, sobald mehrere Zertifikate im Spiel sind oder die Laufzeit weiter sinkt.

Betrifft das auch meine interne Homelab-CA?

Nein. Die Vorgaben gelten für öffentlich vertrauenswürdige Zertifikate von Servern, die über das Internet erreichbar sind. Eine eigene, intern verteilte Root-CA kann weiterhin eigene Laufzeiten verwenden.

Bietet Let’s Encrypt schon kürzere Zertifikate an?

Ja. Seit dem 13. Mai 2026 lässt sich ein 45-Tage-Profil aktiv anfordern, seit Januar 2026 sogar ein optionales Profil mit rund sechs Tagen Laufzeit. Der Standard wechselt planmäßig 2027 auf 64 und 2028 auf 45 Tage.

Reicht es, das Zertifikat automatisch zu erneuern?

Nein. Das neue Zertifikat muss anschließend auch beim jeweiligen Dienst ankommen, etwa per Certbot-Deploy-Hook und einem Reload von Webserver oder Mailserver. Ohne diesen Schritt verwendet der Dienst weiter das alte Zertifikat.

Was ist der Unterschied zwischen Zertifikatslaufzeit und Domain-Validation-Reuse?

Die Zertifikatslaufzeit bestimmt, wie lange ein ausgestelltes Zertifikat gültig ist. Die Domain-Validation-Reuse bestimmt, wie lange eine CA eine bereits durchgeführte Domainprüfung für ein neues Zertifikat wiederverwenden darf. Beide Zeiträume sinken nach eigenem Zeitplan.

QUELLEN

Quellen und Links

CA/Browser Forum: Ballot SC081v3 (Zeitplan zur Verkürzung von Zertifikatslaufzeit und Domain-Validation-Reuse)
DigiCert: Umstellung auf 199 Tage maximale Laufzeit seit Februar 2026
Let’s Encrypt: Ankündigung zur Verkürzung der Zertifikatslaufzeiten (Profile tlsserver, shortlived, classic)
Certbot-Dokumentation: deploy-hooks und certbot renew

Zertifikatsverwaltung automatisieren?

Ob ACME-Automatisierung, Mailserver oder Reverse Proxy: Nutzen Sie unsere IT-Leistungen.

Der Beitrag TLS-Zertifikate 2026: Warum 200 Tage jetzt zum Problem werden erschien zuerst auf RDDZ.

Homelab: Die 10 häufigsten Fehler

dennis_rddz — Thu, 24 Sep 2026 15:49:02 +0000

Homelab · Selfhosting · Praxis

Homelab: Die 10 häufigsten Fehler

Ein Homelab fängt meistens klein an: ein alter PC, ein Raspberry Pi, vielleicht ein gebrauchtes NAS. Dann kommt Nextcloud dazu, Home Assistant, ein Reverse Proxy. Und plötzlich ist aus dem Bastelprojekt eine wichtige Infrastruktur geworden. Die häufigsten Homelab-Fehler entstehen dabei nicht durch fehlendes technisches Wissen, sondern durch fehlende Vorbereitung

HOMELAB-FEHLER

● Reddit · Hardwareluxx · ComputerBase

RAID

ist kein Backup

Strom

oft unterschätzt

Restore

selten getestet

Hardware ✓ nach Bedarf, nicht Rabatt

USV ✓ kontrollierter Shutdown

Dienste ✓ nicht blind ins Internet

Backup ✓ nur mit Restore-Test

Keine Statistik, sondern wiederkehrende Muster aus der Community

✓ RAID ≠ Backup

✓ Strom messen statt schätzen

✓ USV mit Shutdown-Logik

✓ Dienste nicht ungeschützt exponieren

✓ Restore tatsächlich testen

WIE DIESE LISTE ENTSTAND

Kein technisches Unwissen, sondern fehlende Vorbereitung

Beim Durchstöbern von Reddit, Hardwareluxx, ComputerBase und dem Proxmox-Forum fallen dabei immer wieder dieselben Probleme auf. Nicht unbedingt, weil den Leuten die Technik fehlt. Viel häufiger passiert es, weil man am Anfang einfach loslegt und sich um Backup, Stromverbrauch oder Dokumentation erst kümmert, wenn das Homelab schon gewachsen ist.

Einordnung

„Die 10 häufigsten“ ist hier keine statistische Rangliste, sondern eine redaktionelle Zusammenfassung wiederkehrender Fehler und Diskussionsthemen aus diesen Communitys. Die genannten Wattwerte sind konkrete Beispiele einzelner Setups, keine Durchschnittswerte für Homelabs.

FEHLER 1–3

Backup, Hardwarekauf und Stromverbrauch

1. RAID wird mit einem Backup verwechselt

Zwei SSDs im RAID 1, vier Festplatten im RAIDZ, dazu vielleicht ZFS mit Snapshots: Damit ist das System redundant, aber noch lange nicht gesichert. RAID schützt vor bestimmten Hardwareausfällen, nicht vor einem versehentlich gelöschten Verzeichnis, Ransomware, einer fehlerhaften Konfiguration oder dem falschen Befehl. Löscht sich eine Datei versehentlich, wirkt sich der Fehler über die Redundanz sogar problemlos auf alle beteiligten Laufwerke aus.

Proxmox selbst rät in der Dokumentation ausdrücklich davon ab, den Proxmox Backup Server direkt auf dem Hypervisor zu installieren: Sicherer sei ein separater physischer Server für die Backups, damit sie bei einem Ausfall des Hypervisors weiter erreichbar bleiben (Proxmox-Dokumentation).

Die einfache Regel: RAID erhöht die Verfügbarkeit. Ein Backup ermöglicht die Wiederherstellung.

2. Erst Hardware kaufen, dann überlegen, was man eigentlich braucht

Ein ausgemusterter Xeon-Server für 100 Euro, 128 GB ECC-RAM, klingt gut. Sechs Monate später hat das Mainboard kaum noch freie Slots, die Netzwerkkarte passt nicht zum Setup, oder der Server verbraucht im Idle mehr Strom als gedacht. Oder man baut bewusst klein und merkt später, dass zwei zusätzliche NVMe-Laufwerke, eine weitere Netzwerkkarte oder mehr RAM sinnvoll wären, das System dafür aber nicht ausgelegt ist.

Vor dem Kauf lohnt sich deshalb eine einfache Liste: Wie viele VMs? Wie viel RAM realistisch? SATA, NVMe oder beides? Wie viele Netzwerkports, ist 10 GbE wirklich nötig? Was soll in ein bis zwei Jahren noch dazukommen? Ein Homelab muss nicht riesig dimensioniert sein, es sollte aber zum geplanten Ausbau passen.

3. Der Stromverbrauch wird unterschätzt

Ein gebrauchter Enterprise-Server ist billig in der Anschaffung, das heißt nicht, dass er billig im Betrieb ist. Ein System mit 100 Watt Dauerverbrauch braucht 100 W × 24 × 365 = 876 kWh im Jahr, bei 0,30 €/kWh also rund 263 Euro, nur für dieses eine Gerät. Bei 150 Watt sind es schon 1.314 kWh beziehungsweise knapp 394 Euro. Dazu kommen NAS, Switch, Access Points, USV und eventuell weitere Server.

In Homelab-Foren werden ähnliche Setups mit deutlich über 100 Watt Dauerverbrauch dokumentiert und teils akribisch durchgerechnet. Gerade bei alten Servern sollte man deshalb nicht nur auf den Anschaffungspreis schauen: Watt messen, statt Watt schätzen. Ein moderner Mini-PC mit niedriger Leistungsaufnahme kann sinnvoller sein als ein ausgemusterter Rackserver.

FEHLER 4–6

USV, offene Dienste und fehlende Dokumentation

Keine USV – bis der Strom einmal weg ist

Ein kurzer Stromausfall ist meist kein Drama. Für einen Server mit mehreren VMs, Datenbanken oder ZFS kann ein harter Stromverlust trotzdem unangenehme Folgen haben, je nach Hardware, Dateisystem und Zeitpunkt der Schreibvorgänge. Das eigentliche Problem ist nicht der Stromausfall selbst, sondern der fehlende kontrollierte Shutdown. Eine USV muss deshalb mehr können als nur Strom liefern: Sie sollte den Ausfall erkennen und dem Server einen sauberen Shutdown ermöglichen, bevor die Batterie leer ist.

Dienste werden einfach ins Internet gestellt

„Ich möchte von unterwegs auf meinen Dienst zugreifen“, also Portweiterleitung im Router, fertig. Das funktioniert technisch, sicherheitsseitig sollte man sich vorher aber fragen, ob der Dienst überhaupt direkt aus dem Internet erreichbar sein muss. Besonders problematisch sind Verwaltungsoberflächen, Datenbanken und NAS-Webinterfaces, die ursprünglich gar nicht für offenen Internetbetrieb gedacht sind. Besser: ein Reverse Proxy oder VPN davor, und alles, was nicht öffentlich sein muss, bleibt intern.

Es gibt keine Dokumentation

Das Homelab wächst leise: ein Container hier, ein VLAN dort, ein geänderter Port. Ein halbes Jahr später weiß man nur noch „irgendwo läuft das“, aber nicht mehr auf welcher VM, mit welcher IP, in welchem VLAN oder wohin das Backup geht. Besonders unangenehm wird das, wenn jemand anderes übernehmen muss oder man selbst nach längerer Zeit etwas repariert. Eine einfache Markdown-Datei mit VMs, VLANs, IP-Adressen und Backup-Zielen reicht am Anfang völlig. Das ist keine Bürokratie, das ist das Gedächtnis für das Homelab.

FEHLER 7–8

Systemlaufwerk und Hypervisorwahl

7. Das Betriebssystem läuft dauerhaft von einem billigen USB-Stick

USB-Boot funktioniert, auch ein Hypervisor lässt sich grundsätzlich von einem USB-Medium betreiben. Die eigentliche Frage ist, ob ein günstiger USB-Stick das richtige dauerhafte Systemlaufwerk für einen Host ist. Bei einem System mit vielen Schreibzugriffen sind Haltbarkeit, Performance und Verhalten bei Verschleiß wichtige Punkte, eine vernünftige SSD ist für einen dauerhaft betriebenen Hypervisor in vielen Fällen die robustere Lösung. Ein USB-Stick ist also nicht grundsätzlich verboten, aber wenn der Host 24/7 läuft und darauf wichtige VMs und Container betrieben werden, lohnt sich die Frage: Warum ausgerechnet das billigste Speichermedium im ganzen Server?

8. Der Hypervisor wird nur nach persönlichem Geschmack ausgewählt

Proxmox, Hyper-V, XCP-ng, VMware, Unraid, Incus – Möglichkeiten gibt es genug. Der Fehler ist nicht, den „falschen“ Hypervisor zu wählen, sondern die Entscheidung ausschließlich danach zu treffen, was gerade interessant aussieht. Ein Homelab besteht nicht nur aus Software, sondern auch aus Hardware-Kompatibilität, Passthrough, Storage, Backups, Dokumentation und vor allem der Community, die einem hilft, wenn etwas nicht funktioniert. Wer beruflich mit Microsoft arbeitet, hat andere Gründe für einen Hypervisor als jemand, der Linux und KVM lernen möchte. Sinnvoll sind deshalb drei Fragen vorab: Was will ich lernen? Was will ich betreiben? Wie viel Hilfe möchte ich bekommen, wenn etwas nicht funktioniert? Gerade die dritte Frage wird beim ersten Homelab gerne vergessen.

FEHLER 9–10

Single Point of Failure und ungetestete Backups

9. Alles läuft auf einem einzigen Server. Ein Server ist nicht automatisch ein Problem, für ein kleines Homelab ist ein einzelner Host sogar völlig vernünftig. Problematisch wird es, wenn alles davon abhängt: Proxmox, DNS, Reverse Proxy, Nextcloud, Storage, Monitoring und Backup auf derselben Maschine. Fällt der Host aus, ist nicht nur eine Anwendung weg, sondern das komplette Homelab. Besonders kritisch sind Basisdienste wie DNS: Laufen DNS und Virtualisierung auf derselben Maschine und die fällt aus, wirken plötzlich auch andere Geräte im Netzwerk „kaputt“. Man muss nicht alles redundant bauen, sollte aber wissen, welcher Ausfall welche anderen Systeme mitnimmt. Auch Proxmox selbst empfiehlt für Backup-Daten einen separaten physischen Server, damit ein Ausfall des Hypervisors nicht gleichzeitig das Backup unzugänglich macht.

10. Das Backup wird nie zurückgespielt. Der vielleicht unterschätzteste Fehler von allen. Der Backup-Job ist grün, die NAS-Platte blinkt, Proxmox meldet „Backup successful“, also alles gut? Nicht unbedingt. Ein Backup ist erst dann wirklich etwas wert, wenn man daraus tatsächlich etwas wiederherstellen kann, eine einzelne Datei, eine VM, im schlimmsten Fall das komplette System. Ein Backup ohne getestete Wiederherstellung reicht nicht aus. Ein sinnvoller Test kann einmal im Quartal eine Testdatei löschen und aus dem Backup wiederherstellen, eine VM testweise zurückspielen und prüfen, ob die Anwendung startet, und bei verschlüsselten Backups die benötigten Schlüssel kontrollieren. Noch besser ist ein echter Restore-Test auf Hardware oder einer VM außerhalb des Produktivsystems.

ZUSÄTZLICH UNTERSCHÄTZT

Updates und Monitoring

Neben den zehn Punkten tauchen in den Diskussionen noch zwei Themen regelmäßig auf. Beides nehmen wir bewusst nicht als eigenen Punkt in die Top 10 auf, weil sie sich gut in die vorhandenen Themen einordnen lassen.

◐

Updates nicht blind automatisieren

Ein Docker-Container ist schnell aktualisiert. Ein Reverse Proxy, eine Firewall, Proxmox oder eine Datenbank sollte dagegen nicht ohne Kontrolle jede neue Version installieren. Vor wichtigen Updates: Backup prüfen, Release Notes lesen, Update durchführen, Dienst testen, Logs kontrollieren.

▤

Monitoring statt Überraschungen

Ein voller Datenträger, eine sterbende SSD oder ein nicht mehr laufendes Backup sollte möglichst vor dem eigentlichen Ausfall auffallen. Schon einfache Checks für SMART, Storage, CPU/RAM, Backup-Jobs, Zertifikate und Erreichbarkeit bringen hier viel.

✓

Beides gehört zusammen

Ein überwachtes System zeigt, wenn ein Update etwas kaputt gemacht hat. Ein kontrolliertes Update-Verfahren verhindert, dass das Monitoring ständig unnötig Alarm schlägt.

DIE GRUNDREGELN

Was ein gutes Homelab eigentlich ausmacht

Ein gutes Homelab muss nicht riesig sein. Es braucht keinen 42-HE-Schrank, kein 10-Gbit-Netzwerk und keine drei Server. Wichtiger sind ein paar Grundregeln:

✓Backup statt nur RAID

✓Stromverbrauch messen statt schätzen

✓USV, wenn die Infrastruktur einen kontrollierten Shutdown braucht

✓Nur notwendige Dienste öffentlich erreichbar machen

✓Dokumentieren, was man baut

✓Hardware nach Bedarf kaufen, nicht nach Rabatt

✓Hypervisor nach Einsatzzweck und Support auswählen

✓Single Points of Failure kennen

✓Backups tatsächlich wiederherstellen

FAZIT

Die meisten Probleme entstehen, weil man einfach loslegt

Die meisten Homelab-Probleme entstehen nicht, weil jemand zu wenig technische Ahnung hat. Sie entstehen, weil man am Anfang einfach loslegt. Das Interessante an den Diskussionen in Reddit, Hardwareluxx, ComputerBase und dem Proxmox-Forum: Die Details unterscheiden sich, aber die Muster sind erstaunlich ähnlich. Stromverbrauch, Backup und Restore, USV, Hardwareplanung, öffentlich erreichbare Dienste und fehlende Dokumentation tauchen immer wieder auf, und vieles davon lässt sich mit etwas Vorbereitung vermeiden.

Ein Homelab darf chaotisch sein. Es darf experimentell sein. Es darf auch mal kaputtgehen. Aber wenn wichtige Daten darauf liegen, sollte zumindest klar sein, wie man es wieder repariert. Entscheidend ist am Ende nicht, wie viele Container man betreiben kann, sondern ob man nach einem Fehler noch weiß, was passiert ist, wie man zurückkommt und wo das Backup liegt.

FAQ

Häufige Fragen zum Homelab

Ist RAID nicht schon ein Backup?

Nein. RAID schützt vor bestimmten Hardwareausfällen, nicht vor versehentlichem Löschen, Ransomware oder Fehlkonfiguration. Ein echtes Backup liegt getrennt vom Produktivsystem und lässt sich tatsächlich wiederherstellen.

Wie viel Strom verbraucht ein typisches Homelab?

Das hängt stark von der Hardware ab. In Foren werden Systeme mit 80 bis über 150 Watt Dauerverbrauch diskutiert. Bei 100 Watt im 24/7-Betrieb sind das rund 876 kWh im Jahr, bei 0,30 €/kWh also etwa 263 Euro, nur für dieses eine Gerät.

Brauche ich für mein Homelab wirklich eine USV?

Nicht zwingend, aber sie schützt vor Datenverlust durch einen harten Stromausfall mitten in einem Schreibvorgang. Wichtig ist, dass die USV einen kontrollierten Shutdown des Servers auslösen kann, nicht nur Strom puffert.

Wie mache ich einen Dienst sicher von unterwegs erreichbar?

Statt einzelne Ports direkt per Portweiterleitung zu öffnen, ist ein Reverse Proxy oder ein VPN-Zugang die sicherere Lösung. Verwaltungsoberflächen und Dienste, die nicht für den offenen Internetbetrieb gedacht sind, sollten intern bleiben.

Welcher Hypervisor ist der richtige für mich?

Das hängt vom Einsatzzweck ab. Entscheidend sind nicht nur persönliche Vorlieben, sondern auch Hardware-Kompatibilität, Community-Unterstützung und wie viel Hilfe verfügbar ist, wenn etwas nicht funktioniert.

Wie teste ich, ob mein Backup wirklich funktioniert?

Regelmäßig eine Testdatei löschen und aus dem Backup wiederherstellen, gelegentlich eine VM testweise zurückspielen und prüfen, ob die Anwendung startet. Bei verschlüsselten Backups zusätzlich kontrollieren, ob die Schlüssel noch verfügbar sind.

QUELLEN

Quellen und Einordnung

Proxmox Backup Server: Installation (Empfehlung zum separaten Host)
Proxmox VE: Backup and Restore
Reddit: r/homelab und r/selfhosted – Diskussionen zu Hypervisoren, Internet-Exposure und USV
Hardwareluxx-Forum: Proxmox-Stammtisch und Stromverbrauch-Diskussionen
ComputerBase-Forum: Diskussionen zu Proxmox, Stromverbrauch, Offsite-Backups und USV

Homelab zu Infrastruktur ausbauen?

Ob Backup-Konzept, Netzwerk oder Server: Nutzen Sie unsere IT-Leistungen.

Der Beitrag Homelab: Die 10 häufigsten Fehler erschien zuerst auf RDDZ.