Kurz gesagt
- PHP: zwei kritische Lücken – Update auf 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35.
- GitLab (self-managed): maximal kritisch (CVSS 10) – sofort patchen, kein Workaround.
- Betroffen ist fast jede Website (PHP) und jede eigene GitLab-Instanz.
- Jetzt: updaten, Backups prüfen, 2FA aktivieren, beim Hoster nachfragen.
Hinweis: Dieser Artikel ist ein praktischer Überblick, keine IT-Sicherheitsberatung. Für die konkrete Umsetzung sind dein Hoster, deine Web-Agentur oder ein IT-Dienstleister die richtige Adresse. Stand der Angaben: 22. Oktober 2026.
Was ist passiert?
Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, einen Tag später folgte GitLab mit einem Notfall-Update für eine Lücke der höchsten Schwere. Beide Male geht es um sogenannte Remote Code Execution (RCE): Im schlimmsten Fall kann ein Angreifer aus der Ferne eigenen Code auf dem Server ausführen – also die Kontrolle übernehmen. Weil PHP und GitLab extrem weit verbreitet sind, betrifft das sehr viele Betriebe, oft ohne dass sie es wissen.
Die PHP-Lücken – betrifft fast jede Website
PHP ist die Technik hinter einem riesigen Teil des Webs – von WordPress über Onlineshops bis zu vielen Formular-, Buchungs- und Mitglieder-Tools. Die beiden Lücken (CVE-2026-109618 und CVE-2026-109619, jeweils CVSS 9.2) betreffen folgende Versionen:
- PHP 8.5 vor 8.5.12
- PHP 8.4 vor 8.4.27
- PHP 8.3 vor 8.3.36
- PHP 8.2 vor 8.2.35
- PHP 8.1 und älter: keine Updates mehr (Ende der Unterstützung) – hier ist ein Umstieg überfällig.
Die Fix-Versionen stehen seit 21. Oktober bereit. Heikel: Es kursieren bereits erste öffentliche „Proof of Concepts", was Angriffe wahrscheinlicher macht. Provisorische Tricks (an PHP-Einstellungen herumschrauben) machen die Installation laut Sicherheitsbehörden nicht sicher – nur das Update hilft, danach Webserver bzw. PHP neu starten.
Die GitLab-Lücke – wenn du selbst hostest
Betreibst du eine eigene GitLab-Instanz (self-managed, z. B. für deinen Code oder deine Projekte)? Dann ist CVE-2026-110264 ein Fall für sofortiges Handeln: Die Lücke ist mit CVSS 10.0 maximal kritisch und erlaubt Codeausführung ohne Login. Betroffen sind praktisch alle Versionen seit 2014. Die gepatchten Versionen sind u. a. 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13 (für ältere Linien). Einen Workaround gibt es nicht – nur das Update schützt. Wer GitLab nicht selbst hostet, sondern GitLab.com nutzt, ist bereits abgesichert.
Bin ich betroffen?
Als Faustregel: Wenn du eine eigene Website hast, läuft sie mit hoher Wahrscheinlichkeit auf PHP – dann ja. Wenn du eine eigene GitLab-Instanz betreibst, ebenfalls ja. Nutzt du nur Managed-Hosting oder einen Cloud-Dienst, kümmert sich oft der Anbieter um die Updates – aber verlass dich nicht blind darauf, sondern frag kurz nach.
Was du jetzt tun musst
Die konkrete To-do-Liste:
- Hoster/Agentur fragen – oder selbst updaten: Läuft meine Website schon auf der gepatchten PHP-Version?
- CMS & Plugins aktualisieren (WordPress, Shop-System und Erweiterungen) – oft kommen hier parallel Updates.
- Backups prüfen: aktuell, vollständig und im Ernstfall auch wiederherstellbar?
- Zwei-Faktor-Authentifizierung überall aktivieren, wo es sie gibt.
- Eigene GitLab-Instanz? Sofort auf die gepatchte Version upgraden (Wartungsfenster einplanen).
Warum regelmäßige Updates kein Luxus sind
Der wichtigste Punkt zum Mitnehmen: Die allermeisten erfolgreichen Angriffe nutzen nicht geheime neue Tricks, sondern bekannte, längst gepatchte Lücken auf Systemen, die niemand aktualisiert hat. Wer eine einfache Update-Routine hat – oder einen Wartungsvertrag mit einer Agentur – ist schon besser geschützt als die meisten. Sicherheit ist kein einmaliges Projekt, sondern ein bisschen laufende Pflege.
Was heißt das für dich?
Kurz: jetzt prüfen und updaten, nicht nächste Woche. PHP auf die aktuelle Fix-Version, eigene GitLab-Instanz sofort patchen, Backups und 2FA checken – und falls du dich nicht selbst darum kümmerst, heute noch deinen Hoster oder deine Agentur anstupsen. Zehn Minuten Nachfragen können dir sehr viel Ärger ersparen.
Häufige Fragen
Betrifft mich die PHP-Sicherheitslücke?
Sehr wahrscheinlich, wenn du eine eigene Website oder Web-Anwendung betreibst – denn ein großer Teil des Webs läuft auf PHP (etwa WordPress, Shops, viele Buchungs- und Formular-Tools). Betroffen sind die PHP-Versionen 8.5 vor 8.5.12, 8.4 vor 8.4.27, 8.3 vor 8.3.36 und 8.2 vor 8.2.35 sowie alle älteren, nicht mehr unterstützten Versionen. Bei Managed-Hosting kümmert sich oft der Anbieter – nachfragen schadet aber nie.
Auf welche PHP-Version muss ich aktualisieren?
Auf eine der am 21. Oktober 2026 veröffentlichten Fix-Versionen: PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 (je nach eingesetzter Hauptversion). Wer noch PHP 8.1 oder älter nutzt, bekommt vom PHP-Projekt keine Updates mehr und sollte dringend auf eine aktuelle Version wechseln. Nach dem Update muss der Webserver bzw. PHP-Dienst neu gestartet werden.
Was muss ich bei GitLab tun?
Wenn du GitLab selbst hostest (self-managed), solltest du sofort auf die gepatchte Version deiner Release-Linie aktualisieren – etwa 19.5.1, 19.4.3, 19.3.6 oder 18.11.13. Die Lücke (CVE-2026-110264) ist mit CVSS 10.0 maximal kritisch und erlaubt Codeausführung ohne Login. Es gibt keinen Workaround, nur das Update hilft. GitLab.com-Nutzer sind bereits abgesichert.
Was kann ich grundsätzlich für mehr Sicherheit tun?
Halte Software laufend aktuell (Betriebssystem, PHP, CMS, Plugins), mach regelmäßige und getestete Backups, aktiviere überall Zwei-Faktor-Authentifizierung und kläre mit deinem Hoster oder deiner Web-Agentur, wer für Updates zuständig ist. Die meisten erfolgreichen Angriffe nutzen bekannte, längst gepatchte Lücken aus – wer zügig aktualisiert, ist schon gut geschützt.
Weiterlesen: Datenschutz, EU & US-Alternativen · Tools & Apps aus Österreich · Barrierefreiheit im Onlineshop