Wer ist für Sicherheitsupdates auf meinem Server zuständig?

Du. Bei Servern mit vollen Administrationsrechten bist du für Sicherheit und Updates des Betriebssystems und deiner Software selbst verantwortlich, so steht es in Artikel 5, Absatz 2 unserer AGB. Wir sichern Rechenzentrum, Netzwerk, Hostsysteme und unsere eigenen Dienste.

Schickt Prepaid-Hoster Rundmails bei neuen Sicherheitslücken?

Nein, nicht zu einzelnen CVEs. Es erscheinen täglich Hunderte, und wir wissen nicht, welche Software auf deinem Server läuft. Betrifft eine Lücke unsere eigenen Systeme, veröffentlichen wir eine Meldung auf der Statusseite .

Wo erfahre ich von neuen Sicherheitslücken?

Am besten über die Sicherheitsmeldungen deiner Distribution, die CISA-Liste ausgenutzter Lücken und die Seiten der Hersteller deiner Software. Die Links stehen gesammelt in diesem Artikel.

Wie spiele ich Sicherheitsupdates automatisch ein?

Auf Debian und Ubuntu mit dem Paket unattended-upgrades . Kernel-Updates greifen erst nach einem Neustart.

Was mache ich, wenn mein Server kompromittiert wurde?

Melde dich per Ticket. Laut AGB Artikel 5, Absatz 7 ist bei einem kompromittierten System eine Neuinstallation nötig, eine Datensicherung durch uns ist nur auf Bitte und gegen Aufwand möglich. Eigene Backups sind deshalb wichtig.

Sicherheitslücken auf deinem Server: Wer macht was und wo findest du Updates?

Kurz gesagt: Wir halten unsere Infrastruktur sicher. Die Software auf deinem Server hältst du selbst aktuell. Wir schicken dir keine Rundmail zu jeder neuen Sicherheitslücke, deshalb zeigen wir dir hier, wo du dich selbst zuverlässig informierst und woher du Updates bekommst.

Wer ist wofür zuständig?

Bereich	Wir	Du
Rechenzentrum, Netzwerk, DDoS-Schutz	ja	nein
Hostsysteme (Virtualisierung, Hardware)	ja	nein
Vionity, API, unsere eigenen Dienste	ja	nein
Betriebssystem im Server inklusive Kernel	nein	ja
Webserver, PHP, Node.js, Datenbanken	nein	ja
Anwendungen und Pakete (WordPress, Laravel, Docker-Images …)	nein	ja
Zugangsdaten, SSH-Keys, Firewall	nein	ja
Eigene Backups deiner Daten	nein	ja

Das steht auch in unseren AGB: Wenn du einen Server mit vollen Administrationsrechten buchst, trägst du die Verantwortung für dessen Sicherheit und Verwaltung. Dazu gehört, Sicherheitsupdates regelmäßig einzuspielen und bekannte Schwachstellen umgehend zu schließen (Artikel 5, Absatz 2). Ist ein Server kompromittiert, ist laut Artikel 5, Absatz 7 eine Neuinstallation nötig. Das willst du vermeiden, und mit gepflegten Updates ist es meistens vermeidbar.

Warum es keine Rundmail pro Sicherheitslücke gibt

Die Menge: Nach Angaben von vuln.today erscheinen über 200 neue CVE-Einträge pro Tag. Würden wir jede relevante Meldung an alle Kunden schicken, gäbe es mehrere Mails pro Woche. Die wirklich wichtigen gingen darin unter.
Wir sehen nicht, was auf deinem Server läuft: Bei dir läuft vielleicht nur nginx und PHP, beim nächsten Kunden Node.js, Docker oder Mailcow. Eine Mail an alle wäre für die meisten irrelevant.
Wir sind ein kleines Team: Wir investieren unsere Zeit in das, was nur wir können: unsere Infrastruktur patchen, Störungen beheben und deine Tickets beantworten.

Das heißt nicht, dass uns die Lage egal ist. Wir beobachten sie jeden Tag und spielen Fixes für unsere eigenen Systeme nach Priorität ein. Betrifft eine Lücke unsere Systeme oder Dienste, veröffentlichen wir dazu eine eigene Meldung auf der Statusseite. Dort stehen auch Wartungen und Störungen. Bei Lagen, die viele Kunden betreffen, verlinken wir dort Einordnung und Fixes.

Beispiele aus Oktober 2026

So sieht eine Häufung kritischer Lücken in der Praxis aus. Stand der Angaben: 30.10.2026.

PHP2Shell (CVE-2026-109618 und CVE-2026-109619): Remote Code Execution in PHP selbst. Fixes gibt es in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Ältere Zweige bekommen von php.net keine regulären Releases, hier brauchst du die Backports deiner Distribution oder ein Upgrade. Eine Einordnung findest du auf php2shell.de.
Brotli (CVE-2026-111497): Speicherfehler im Brotli-Decoder, der in Node.js, Python-Paketen (Brotli, brotlicffi), .NET und anderen Programmen steckt. Die US-Behörde CISA führt die Lücke als aktiv ausgenutzt. Fixes: Node.js 22.23.4, 24.22.1 und 26.12.1, Python Brotli 1.2.1 und brotlicffi 1.2.1.0.
Linux-Kernel (CVE-2026-98432, CVSS 9.8): Use-after-free im IPv4-TCP-Stack. Der Fix steckt seit Mitte Oktober in den Upstream-Kerneln. Ubuntu hatte Stand 30.10.2026 noch keinen gepatchten Kernel veröffentlicht, andere Distributionen liefern teils schon Updates. Eine Ausnutzung in freier Wildbahn ist bisher nicht bestätigt.
UEFI/PXE (CVE-2026-97631): betrifft nur Dedicated Server und nur während eines PXE-Boots. Laufende Server sind nicht betroffen. Hinweise zu Neustarts stehen in der Status-Meldung.

Node.js im Detail: Node.js ist auf Servern weit verbreitet, oft als Hintergrunddienst, Build-Werkzeug oder im Docker-Image. Prüfe mit node -v, welche Version läuft, und aktualisiere auf mindestens 22.23.4, 24.22.1 oder 26.12.1. Wer noch Node.js 20.x oder eine andere ausgelaufene Version einsetzt, bekommt keinen Fix und muss auf eine unterstützte Version wechseln. Je nach Installationsweg (Distributionspaket, nvm, Docker-Image) läuft das Update anders. Docker-Images musst du neu bauen, ein apt upgrade auf dem Host ändert sie nicht. Starte Dienste nach dem Update neu, zum Beispiel pm2 oder systemd.

So bleibst du informiert

Fünf Minuten Einrichtung reichen für einen soliden Grundschutz.

1. Automatische Sicherheitsupdates aktivieren (Debian und Ubuntu)

apt update
apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Das spielt Sicherheitsupdates der Distribution automatisch ein. Kernel-Updates greifen erst nach einem Neustart. Auf Ubuntu zeigt die Datei /var/run/reboot-required, dass einer nötig ist. Mehr dazu findest du in Mein Linux Server hat Updates! Was jetzt?.

2. Die Sicherheitsmeldungen deiner Distribution abonnieren

Dort erscheint der Fix für Pakete wie Kernel, OpenSSH, nginx oder PHP aus den Distributions-Repositories. Die Links stehen in der Tabelle weiter unten.

3. Allgemeine Feeds für kritische Lücken

cve.now: freier Feed für CVE-, GHSA- und OSV-Abfragen, auch mit Abfrage exakter Paketversionen
CISA Known Exploited Vulnerabilities: Lücken, die nachweislich ausgenutzt werden, mit Abo für Updates. Hier solltest du am schnellsten reagieren.
BSI Warn- und Informationsdienst (CERT-Bund): deutschsprachige Kurzinformationen, per E-Mail abonnierbar
OSV und die GitHub Advisory Database: Lücken nach Paket und Version, praktisch für Python, Node.js und PHP-Pakete
vuln.today: Watchlist nach Hersteller oder Produkt

4. Abhängigkeiten deiner Projekte prüfen

Viele Lücken stecken nicht im Betriebssystem, sondern in Paketen deiner Anwendung. Diese Befehle prüfen gegen bekannte Advisories:

pip-audit # Python
npm audit # Node.js
composer audit # PHP

5. Vor größeren Updates absichern

Lege vor dem Update einen Snapshot im Cloud Manager an (2 pro Server, automatisch gelöscht nach 48 Stunden) und kümmere dich um eigene Backups. Laut AGB Artikel 6, Absatz 4 sind regelmäßige Backups auf eigenen, externen Speichermedien deine Aufgabe.

Quellen für die gängigsten Programme

Die Tabelle zeigt, wo die Hersteller Sicherheitsmeldungen veröffentlichen und woher du Updates bekommst. Meist reicht das Paketsystem deiner Distribution. Die Herstellerseiten beantworten die Frage, ob dich eine Lücke betrifft und welche Version du brauchst.

Programm	Sicherheitsmeldungen	Updates
Ubuntu	Security Notices, CVE-Tracker	`apt update && apt upgrade`
Debian	Security Tracker, Debian Security	`apt update && apt upgrade`
Linux-Kernel	über den Tracker deiner Distribution	Kernel-Paket installieren, danach neu starten
PHP	php.net News und Security, GitHub Security Advisories php-src	Paketquelle deiner Distribution oder php.net/downloads
Node.js	Vulnerability-Blog, Mailingliste nodejs-sec	nodejs.org/en/download, auf unterstützte Versionen achten
Python-Pakete	osv.dev, `pip-audit`	`pip install -U <paket>`
nginx	nginx.org Security Advisories	Distribution oder nginx.org-Pakete
Apache httpd	Vulnerabilities 2.4	Distribution
MariaDB	Fixed CVEs	Distribution oder MariaDB-Repository
MySQL	Oracle Critical Patch Updates	Distribution oder MySQL-Repository
PostgreSQL	Security Information, Liste pgsql-announce	immer das neueste Minor-Release einspielen
WordPress	WordPress News, Kategorie Security	Dashboard, Aktualisierungen; Plugins und Themes nicht vergessen
Nextcloud	nextcloud/security-advisories	integrierter Updater oder Paketquelle
Laravel und Composer-Pakete	Packagist Advisories zu laravel/framework, `composer audit`	`composer update`
Docker	Docker Security Announcements	Paketquelle von Docker, Images regelmäßig neu bauen
OpenSSH	openssh.com/security.html	Distribution
Windows Server	Microsoft Security Update Guide	Windows Update

Die Liste ist ein Startpunkt und nicht vollständig. Setze für alles, was du betreibst, mindestens eine Quelle auf deine Beobachtungsliste.

Häufige Stolpersteine

Kernel-Update eingespielt, aber nicht neu gestartet: Der alte Kernel läuft weiter, bis du den Server neu startest. Prüfe mit uname -r die laufende Version.
Docker-Images nicht neu gebaut: Updates auf dem Host ändern nichts an Software, die im Image steckt.
Ausgelaufene Versionen: Für Zweige wie Node.js 20.x oder PHP 8.1 gibt es keine regulären Fixes mehr. Hier hilft nur ein Upgrade oder ein Backport deiner Distribution.
Abhängigkeiten vergessen: Auch wenn das System aktuell ist, können Pakete deiner Anwendung veraltet sein. pip-audit, npm audit und composer audit zeigen das.

Weitere Anleitungen

Schreib uns ein Ticket, wenn du nicht weißt, ob du betroffen bist oder wie du ein Update einspielst. Die Verwaltung deines Servers übernehmen wir nicht, das bleibt dein Part. Fragen kannst du auch in unserer Discord-Community stellen.