Warum diese Seite offline war
Wer in der vergangenen Woche fm-berger.de aufgerufen hat, sah nur eine Wartungsseite mit einem Hinweis auf PHP2Shell. Das war Absicht.
PHP2Shell ist der Name für zwei kritische Sicherheitslücken in PHP (CVE-2026-109618 und CVE-2026-109619), der Programmiersprache, auf der ein großer Teil aller Websites läuft, auch WordPress. Über die Lücken können Angreifer ohne Anmeldung die Kontrolle über einen Server übernehmen. Das Unangenehme daran: Die Details wurden öffentlich, bevor es ein Update gab.
Ich hatte die Wahl zwischen „hoffen, dass es mich nicht trifft“ und „abschalten, bis das Update eingespielt ist“. Ich habe abgeschaltet. Eine Wartungsseite kostet mich wenig, ein gekaperter Server deutlich mehr.
Es blieb nicht bei PHP
In dieselben Tage fielen zwei weitere Sicherheitsupdates für kritische Lücken:
- Oracle hat mit seinem vierteljährlichen Sicherheitsupdate rund 1.200 Lücken quer durch seine Produkte geschlossen, mehrere davon mit der höchsten Gefährdungsstufe. Einen Tag später kam noch ein außerplanmäßiges Notfall-Update für Java hinterher (CVE-2026-91403).
- Node.js, eine weit verbreitete Plattform für Webanwendungen, musste eine kritische Lücke schließen, über die sich Schadcode einschleusen lässt (CVE-2026-111497). Hier reicht es nicht, das Update einzuspielen: Jede laufende Anwendung muss neu gebaut und neu gestartet werden, sonst bleibt sie verwundbar.
Und weil Sicherheitslücken sich nicht nach dem Kalender richten, hatte ein Kunde in derselben Woche noch eine kritische Produktionsstörung. Ein zentrales System stand, die Ursache lag nicht dort, wo sie zuerst vermutet wurde.
Keine dieser Nachrichten war für sich außergewöhnlich. Ungewöhnlich war nur, dass alles gleichzeitig kam. Genau dann zeigt sich, wie es um eine IT-Landschaft tatsächlich steht.
Was das mit Digitaler Souveränität zu tun hat
„Digitale Souveränität“ wird meist als Standortfrage diskutiert: europäische Cloud, deutsches Rechenzentrum. Das ist ein Teil. In einer Woche wie dieser wird aber ein anderer Teil sichtbar, und der ist handfester:
Können Sie selbst entscheiden und handeln, wenn es darauf ankommt?
Konkret heißt das:
- Wissen, was läuft. Wer am Dienstagmorgen nicht in einer Viertelstunde sagen kann, welche Systeme PHP, Node.js oder welche Oracle-Komponente in welcher Version einsetzen, verliert die ersten Stunden mit Suchen statt mit Handeln.
- Updates in Stunden einspielen können, nicht in Wochen. Der Node.js-Fall zeigt es: Ein Patch nützt erst, wenn Images neu gebaut und Dienste neu ausgerollt sind. Mit einer automatisierten, reproduzierbaren Bereitstellung ist das Routine. Ohne sie ist es ein Projekt.
- Auf aktuellen Versionen stehen. Die PHP-Fixes gibt es offiziell nur für 8.2 bis 8.5. Wer noch auf 8.1 oder älter läuft, bekommt vom Projekt selbst keinen Patch mehr und ist auf Backports von Distribution oder Hoster angewiesen, oder bleibt verwundbar. Veraltete Systeme sind nicht nur technische Schuld, sie sind im Ernstfall eine Sackgasse.
- Nicht vom Zeitplan oder Vertrag eines Herstellers abhängen. Oracle liefert Sicherheitsupdates quartalsweise, und den Zugang zu den Patches gibt es nur mit laufendem Supportvertrag. Das ist legitim, aber es ist eine Abhängigkeit, die man bewusst eingehen sollte und nicht nebenbei.
- Das Wissen im eigenen Team haben. Bei der Produktionsstörung hat am Ende nicht ein Werkzeug geholfen, sondern Menschen, die das System verstehen. Wenn dieses Wissen nur bei einem externen Dienstleister liegt, ist man im Ernstfall dessen Verfügbarkeit ausgeliefert.
Ich habe meine Website abschalten können, weil ich sie selbst betreibe und selbst entscheiden konnte. Das ist im Kleinen genau das, worum es im Großen geht.
Modernisierung ist Sicherheitsarbeit
Daraus folgt für mich ein Punkt, der in Modernisierungsdiskussionen oft untergeht: Die Ablösung von Altsystemen, Automatisierung und der Weg zu offenen, gut gepflegten Plattformen sind keine Komfortthemen für ruhige Zeiten. Sie entscheiden darüber, ob eine Woche wie die letzte ein paar Stunden geplante Arbeit bedeutet oder mehrere Tage Ausnahmezustand.
Das gilt auch für die Frage Oracle oder PostgreSQL. Es geht dabei weniger um die Lizenzkosten als darum, wer bestimmt, wann und wie Sie Ihre Systeme absichern können.
In eigener Sache: Es kommt etwas Neues
Diese Website ist in die Jahre gekommen, und sie beschreibt auch nicht mehr ganz, was ich heute mache. Deshalb ist in den letzten Monaten eine neue entstanden, die in den nächsten Tagen online geht.
Der Kern: Ich arbeite an der Schnittstelle von Datenbankbetrieb und Infrastrukturautomatisierung, mit Oracle und PostgreSQL, Linux, Ansible und Kubernetes. Und ich arbeite mit IT-Teams, nicht an ihrer Stelle. Mein Ziel ist, dass Ihr Team seine Systeme selbst beherrscht, unabhängig davon, wer sie ihm verkauft hat. Der Unterschied zu einem Betriebsvertrag ist nicht die Technik, sondern wo das Wissen liegt, wenn ich wieder weg bin.
Quellen:
- PHP2Shell: Help Net Security, Qualys, Unit 42
- Oracle CPU Oktober 2026: Oracle Advisory, Fortra, Java-Notfallupdate: Cybersecurity News
- Node.js: Qualys, Vercel, CSA Singapur
