PHP2Shell: Ist meine Website von der PHP-Lücke betroffen?
· Lesezeit ca. 17 Min.
Die kurze Antwort
Läuft Ihre Website mit WordPress, Joomla, TYPO3, einem WooCommerce-Shop oder einem anderen System auf PHP, ist sie betroffen, bis Ihr Hoster PHP auf eine korrigierte Fassung gebracht hat. Installieren müssen Sie dafür meistens nichts selbst. Was Sie jetzt tun sollten: Ihren Hoster oder Ihre Agentur schriftlich fragen, ob das Update eingespielt ist. Einen fertigen Text dafür finden Sie weiter unten.
Stand: 22. Oktober 2026, 02:50 Uhr. Die Lage ändert sich in diesen Stunden laufend; alle Quellen stehen am Ende des Beitrags.
Am Nachmittag des 21. Oktober 2026 hat das Entwicklerteam von PHP zwei Sicherheitslücken öffentlich gemacht und gleichzeitig die Korrekturen veröffentlicht. Das Bundesamt für Cybersicherheit BACS hat am selben Tag gewarnt und empfiehlt, betroffene Systeme «unverzüglich» zu aktualisieren. Laut einem Bericht von 20 Minuten und der Deutschen Presse-Agentur haben erste Kommunen, Behörden, Universitäten und Spitäler ihre Online-Angebote vorsorglich vom Netz genommen, darunter, so die Überschrift des Berichts, die Berliner Charité und die Stadt Mainz. Und in der Schweiz hat der Hoster cyon am Nachmittag alle seine Webhostings abgeschaltet, zum Schutz der Websites seiner Kundschaft.
Die meisten Berichte erklären, dass es gefährlich ist. Dieser Beitrag erklärt, was genau kaputt ist und woran Sie erkennen, ob Ihre Website betroffen ist. Weiter unten bekommen Sie einen fertigen Text für Ihren Hoster. Fachwissen brauchen Sie dafür keines.
Was ist PHP, und warum hängt so viel daran?
Eine Website besteht aus zwei Teilen. Den einen sehen Sie: Texte, Bilder, das Kontaktformular. Den anderen nicht: Auf dem Server läuft ein Programm, das bei jedem Aufruf die Seite zusammensetzt, Formulare entgegennimmt, Bestellungen speichert und das Passwort beim Anmelden prüft. Dieses Programm ist bei sehr vielen Websites in PHP geschrieben.
Man kann es sich wie ein Restaurant vorstellen. Die Website ist der Gastraum, PHP ist die Küche. Die Gäste sehen die Küche nie, aber ohne sie kommt nichts auf den Tisch. WordPress, mit dem sehr viele Firmenwebsites gebaut sind, ist ein PHP-Programm. Joomla, Drupal, TYPO3, Contao und Shops wie WooCommerce, Shopware oder PrestaShop ebenfalls.
Laut dem Statistikdienst W3Techs wird PHP auf 69,3 % aller Websites eingesetzt, deren Serversprache sich erkennen lässt (weltweit, Stand 21. Oktober 2026). Darum trifft diese Lücke einen grossen Teil des Internets auf einmal, quer durch alle Branchen.
Was genau ist kaputt?
Es sind zwei verschiedene Fehler, beide im Kern von PHP selbst. Sie haben die offiziellen Kennungen CVE-2026-109618 und CVE-2026-109619. Der Name «PHP2Shell» stammt aus der Berichterstattung: Laut dem deutschen Bundesamt für Sicherheit in der Informationstechnik (BSI) soll er die Ähnlichkeit mit «Log4Shell» aufzeigen, einer schweren Lücke im Protokollierungsbaustein Apache Log4j, die im Dezember 2021 bekannt wurde. «Shell» steht für die Befehlszeile eines Servers. Wer dort Befehle eingeben kann, hat den Server in der Hand.
Fehler 1 · CVE-2026-109618
Der halb geschriebene Bestellzettel
Geht PHP mitten in einer Anfrage der Arbeitsspeicher aus, bricht es ab, während die Daten dieser Anfrage erst halb vorbereitet sind. Beim Aufräumen danach kann PHP diese halbfertigen Daten so behandeln, als wären sie vollständig. Im Restaurant hiesse das: Die Küche kocht nach einem Zettel, den der Kellner nur halb ausgefüllt hat. Laut BACS kann das zu Speicherbeschädigungen führen und einem Angreifer erlauben, eigenen Schadcode ausführen zu lassen.
Fehler 2 · CVE-2026-109619
Das Hotelzimmer, das nicht geputzt wurde
Ein Server bedient viele Anfragen hintereinander mit denselben Arbeitsprozessen. Normalerweise wird zwischen zwei Anfragen alles weggeräumt. Durch den zweiten Fehler kann etwas aus einer früheren Anfrage liegen bleiben, obwohl der Platz dafür schon freigegeben ist. Eine spätere Anfrage kann es benutzen, bevor aufgeräumt wird. Das ist, wie wenn in einem Hotelzimmer der vorige Gast etwas für den nächsten liegen lässt. Laut BACS kann das bei einer späteren Anfrage die Ausführung von Schadcode ermöglichen.
Gefährlich macht beide Fehler dasselbe: Nach der Einstufung des BSI braucht ein Angreifer dafür weder ein Benutzerkonto noch eine Handlung von jemandem auf Ihrer Seite. Am höchsten ist das Risiko laut der offiziellen Sicherheitsmeldung von PHP bei Servern mit mod_php, einer verbreiteten Art, PHP direkt im Webserver Apache zu betreiben. Dort wurde ein Angriff gezeigt, bei dem eine Anfrage ohne Anmeldung genügt und der greift, bevor das eigentliche Programm der Website überhaupt startet. Läuft WordPress auf einem solchen Server, kommt der Angriff also an, bevor WordPress ein einziges Plugin geladen hat.
01 Die Einstufung in Zahlen
Wie ernst ist es? 9,2 von 10 Punkten, bei beiden Lücken
So bewerten das BACS und das BSI die zwei Fehler auf der international üblichen Schweregrad-Skala CVSS (Fassung 4.0). Das BACS nennt beide «kritisch», die höchste Stufe dieser Skala.
| Frage | Antwort | Quelle |
|---|---|---|
| Braucht ein Angreifer ein Passwort? | Nein, und auch keine Mithilfe auf Ihrer Seite | BSI, aus der CVSS-Bewertung abgeleitet |
| Wurde schon angegriffen? | Laut BSI waren noch keine bestätigten Ausnutzungen bekannt, wohl aber unbestätigte Berichte über existierende Angriffsprogramme | BSI, Warnung Version 1.1 |
| Seit wann gibt es die Fehler? | Laut den Forschenden von Wiz seit Jahrzehnten im Code | Help Net Security |
| Wer war an der Entdeckung beteiligt? | Wiz und Calif, zusammen mit OpenAI | BSI |
| Gibt es eine Korrektur? | Ja, seit dem 21. Oktober 2026, für PHP 8.2 bis 8.5 | php.net, BACS |
Das war der Stand der BSI-Warnung (Version 1.1) vom 21. Oktober 2026, abgerufen am selben Abend. Solche Angaben ändern sich bei Lücken dieser Art oft innert Stunden, darum steht hier keine Entwarnung.
Eine Einzelheit erklärt, warum Fachleute so nervös sind. Laut den Forschenden von Wiz, zitiert von der Fachpublikation Help Net Security, steckten die Fehler seit Jahrzehnten in PHP. Sie auszunutzen verlangte aber eine so lange Kette von Schritten, dass es für Menschen allein kaum machbar war. Erst moderne KI-Modelle hätten diese Hürde deutlich gesenkt. Was bisher als theoretisch galt, ist damit ein praktischer Angriff geworden. Und was einmal gezeigt ist, wird oft schnell nachgebaut und automatisiert. Dann lassen Angreifer Programme eine Website nach der anderen abklopfen, ohne sich dafür zu interessieren, wem sie gehört.
Ist meine Website betroffen?
Das hängt an zwei Fragen: Läuft Ihre Website auf PHP, und wer ist für den Server zuständig?
Sehr wahrscheinlich betroffen
WordPress, Joomla, TYPO3, Shops auf PHP
Ihre Website läuft mit einem dieser Systeme bei einem Hoster, oft eingerichtet von einer Agentur. Hier muss der Hoster PHP aktualisieren. Sie selbst sind gefordert, nachzufragen, und, falls Ihre Website eine alte PHP-Fassung benutzt, eine Umstellung zu veranlassen.
Beim Anbieter klären
Baukästen wie Wix, Jimdo oder Shopify
Hier läuft die gesamte Technik beim Anbieter. Sie können dort nichts selbst aktualisieren und müssen es auch nicht. Ob und wie der Anbieter betroffen war, beantwortet nur er selbst, meist auf seiner Statusseite.
Oft vergessen
Alles andere mit PHP im Hintergrund
Das BACS weist ausdrücklich darauf hin: PHP kann auch Teil von Verwaltungsoberflächen, internen Fachanwendungen, Hosting-Plattformen, Containern oder fertigen Geräten sein, und die Betreiber wissen nicht immer, dass PHP darin läuft. Fragen Sie bei Ihren Software-Lieferanten nach.
So finden Sie Ihre PHP-Fassung heraus
Bei WordPress: Melden Sie sich an und öffnen Sie Werkzeuge, dann Website-Zustand, dann den Reiter Bericht. Im Abschnitt Server steht die PHP-Version. Bei anderen Systemen: im Kundenbereich Ihres Hosters, meist unter einem Punkt wie «PHP-Einstellungen» oder «PHP-Version». Vergleichen Sie die Nummer mit dieser Tabelle:
| Ihre PHP-Linie | Korrigiert ab | Was das heisst |
|---|---|---|
| 8.5 | 8.5.12 | Update durch den Hoster |
| 8.4 | 8.4.27 | Update durch den Hoster |
| 8.3 | 8.3.36 | Update durch den Hoster |
| 8.2 | 8.2.35 | Update durch den Hoster |
| 8.1 und älter | keine offizielle Fassung mehr | Umstellung auf 8.3 oder neuer veranlassen, oder beim Hoster eine bestätigte Notkorrektur verlangen |
Zwei Einschränkungen gehören dazu. Erstens: Manche Linux-Distributionen und Anbieter spielen die Korrektur in ihre bisherige Paketversion ein, ohne dass sich die Nummer ändert. Das BACS schreibt dazu, eine unveränderte PHP-Hauptversion bedeute deshalb nicht automatisch, dass der Patch fehlt. Eine alte Nummer ist also ein Grund zum Nachfragen, kein Beweis. Zweitens: Für PHP 8.1 und älter liefert das PHP-Projekt keine Updates mehr. Es hat wegen der Schwere zwar kleine Notkorrekturen für 7.4, 8.0 und 8.1 bereitgestellt, aber nur als Quelltext für Fachleute, die PHP selbst übersetzen und installieren. Ob Ihr Hoster sie einsetzt, müssen Sie erfragen. Und wer ohnehin umstellt: PHP 8.2 bekommt laut php.net nur noch bis zum 31. Dezember 2026 Sicherheitsupdates. Darum lohnt der Schritt auf 8.3 oder neuer.
Wie viele Websites auf so alten Fassungen laufen, zeigt wieder W3Techs: Von den Websites mit PHP benutzen weltweit 27,0 % noch Version 7 und 7,7 % Version 5 (Stand 21. Oktober 2026). Für keine dieser Fassungen gibt es vom PHP-Projekt noch reguläre Updates. Diese Websites hatten schon vor dem 21. Oktober ein Problem; jetzt ist es dringend.
02 Fünf Schritte, in dieser Reihenfolge
Was Sie jetzt tun sollten
Zuständigkeit klären
Wer betreibt den Server Ihrer Website? Meist steht es auf der Hosting-Rechnung.
Schriftlich nachfragen
Lassen Sie sich die Korrektur bestätigen, wie es das BACS empfiehlt. Den Mustertext finden Sie unten.
Alte PHP-Fassung ersetzen
Läuft Ihre Website auf 8.1 oder älter, lassen Sie sie auf 8.3 oder neuer umstellen. Vorher braucht es eine vollständige Sicherung, denn alte Erweiterungen laufen auf neuem PHP nicht immer.
Nach Spuren schauen lassen
Ein Update beseitigt keinen Einbruch, der vorher schon passiert ist. Fremde Administratorkonten, unbekannte Dateien, Weiterleitungen auf fremde Seiten sind Warnzeichen.
Danach weiter pflegen
WordPress, Plugins und Theme aktuell halten. Gegen PHP2Shell hilft das nicht, gegen viele andere Lücken schon.
Mustertext für Ihren Hoster oder Ihre Agentur
Kopieren Sie diesen Text in eine Mail und setzen Sie Ihre Website-Adresse ein. Er ist so formuliert, dass die Antwort eindeutig ausfallen muss:
Guten Tag. Meine Website [Adresse] läuft auf Ihren Servern. Wegen der PHP-Sicherheitslücken CVE-2026-109618 und CVE-2026-109619 («PHP2Shell») bitte ich um eine kurze schriftliche Bestätigung: Ist für meine Website bereits PHP 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 im Einsatz, oder ein Paket, das Sie ausdrücklich als behoben ausweisen? Wurden die PHP-Dienste danach neu gestartet? Und falls meine Website noch PHP 8.1 oder älter benutzt: Was schlagen Sie vor? Besten Dank.
Mustertext zum freien Gebrauch, Stand 21. Oktober 2026
Die Frage nach dem Neustart ist kein Detail. Das BACS weist darauf hin, dass laufende PHP-Prozesse nach dem Update neu gestartet werden müssen. Ein Update, das installiert, aber noch nicht aktiv ist, schützt nicht.
Was nicht hilft
Einige Ratschläge, die jetzt kursieren, beruhigen, ohne zu schützen:
- WordPress und Plugins aktualisieren. Wichtig, aber nicht gegen diese Lücke. Sie sitzt in PHP, eine Ebene darunter, und der bei mod_php gezeigte Angriff greift, bevor WordPress läuft.
- Ein Sicherheits-Plugin installieren. Nach unserer Einschätzung aus demselben Grund: Ein Plugin startet erst, wenn PHP schon arbeitet.
- Sich allein auf eine vorgeschaltete Schutzwand (Web Application Firewall) verlassen. Laut Cloudflare-Technikchef Dane Knecht, zitiert von Help Net Security, sind bei Cloudflare für Websites hinter dem Dienst bereits erste Filterregeln gegen die bekannten Angriffswege aktiv. Das BACS schreibt aber ausdrücklich, eine solche Firewall allein genüge nicht.
- Fehlermeldungen ausblenden. Laut php.net hilft es nicht, Fehlermeldungen zu verstecken; der Fehler passiert trotzdem.
- Abwarten, weil die eigene Firma «zu klein» ist. Automatische Angriffe fragen in der Regel nicht nach der Grösse einer Firma. Sie suchen Server, die noch nicht aktualisiert sind.
Und wenn Ihre Website gerade offline ist?
Dann kann das Absicht sein und kein Angriff: Mehrere Hoster und Einrichtungen haben ihre Seiten vorsorglich vom Netz genommen. Der Schweizer Hoster cyon zum Beispiel hat am 21. Oktober um 15:45 Uhr seine Webhostings und Server vorsorglich vom Netz genommen. Auf seiner Statusseite meldete er in der Nacht, die angepassten PHP-Fassungen seines Betriebssystemherstellers hätten sich verzögert; seit 02:49 Uhr spielt er sie nach und nach ein, und auf den ersten Servern sind die Lücken geschlossen. Der E-Mail-Verkehr lief dort weiter.
Ein solcher Unterbruch ist ärgerlich. Er passt aber zu dem, was das BACS für den Fall rät, dass ein Update nicht sofort möglich ist: prüfen, ob eine vorübergehende Trennung vom Internet nötig ist. Ein paar Stunden offline sind billiger als ein Server, den ein Fremder steuert. Schauen Sie auf der Statusseite Ihres Hosters nach, bevor Sie etwas an der Website ändern.
Was bedeutet das für Besucherinnen und Besucher?
Als Besucherin oder Besucher einer Website können Sie die Lücke weder schliessen noch auslösen. Das Risiko für Sie ist indirekt: Eine übernommene Website kann zum Beispiel Eingaben mitlesen oder auf eine gefälschte Zahlungsseite weiterleiten. Darum in den nächsten Tagen etwas wacher sein als sonst:
- Wenn eine bekannte Website plötzlich ungewohnte Angaben verlangt, etwa Kartendaten an einer Stelle, wo es sie bisher nicht brauchte: abbrechen und beim Anbieter telefonisch nachfragen.
- Seien Sie vorsichtig bei Mails, die sich auf «die PHP-Lücke» oder ein angebliches Datenleck berufen und zu einer Anmeldung auffordern: Betrüger nutzen Schlagzeilen gern als Aufhänger. Melden Sie sich nur über die Adresse an, die Sie selbst eintippen.
- Für jede Website ein eigenes Passwort. Dann bleibt der Schaden bei einer Seite, falls dort doch etwas abfliesst.
Für Fachleute: die Übergangsmassnahmen
Wer seinen Server selbst betreibt und nicht sofort aktualisieren kann, findet in der Sicherheitsmeldung von php.net Massnahmen, die einzelne Angriffswege verengen. php.net und das BACS betonen beide, dass sie eine Installation nicht sicher machen. Kurz zusammengefasst:
Gegen CVE-2026-109619 (Zustand zwischen Anfragen)
session.upload_progress.enabled=0 in php.ini, im FPM-Pool oder in der Serverkonfiguration setzen, also an einer Stelle, die vor dem Einlesen der Anfrage wirkt, und alle Worker neu starten. ini_set() und .user.ini reichen laut php.net nicht. Auf PHP 8.5 zusätzlich fatal_error_backtraces=0. Ungültige oder veraltete Einstellungen entfernen, die je Anfrage Warnungen erzeugen.
Gegen CVE-2026-109618 (Speichermangel)
post_max_size niedrig halten: 8M ohne Datei-Uploads, 32M mit, upload_max_filesize darunter. Grenzen für Anfragegrösse, Felder und Multipart-Teile möglichst schon am Webserver oder Proxy durchsetzen. php.net nennt auch memory_limit=-1; das entfernt die steuerbare Speichergrenze, laut php.net kann ein Speicherfehler den verwundbaren Pfad aber trotzdem erreichen. Ohne Grenze kann zudem ein entgleistes Skript den ganzen Speicher belegen. RLIMIT_AS oder RLIMIT_DATA sind ausdrücklich kein Ersatz.
Welche Umgebungen sind betroffen?
Laut php.net alle PHP-Installationen, die Webanfragen bedienen: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Team bei mod_php. Linux-Distributionen und Anbieter mit Langzeitpflege haben die Korrekturen vorab erhalten; dort zählt die Paketversion des Anbieters, nicht nur die PHP-Nummer.
Häufige Fragen
Muss ich meine Website jetzt abschalten?
Solange Ihr Hoster das Update nicht bestätigt hat, ist die Frage berechtigt. Das BACS rät, eine vorübergehende Trennung vom Internet zu prüfen, wenn ein Update nicht sofort möglich ist, vor allem bei kritischen Anwendungen. Bestätigt der Hoster, dass PHP aktualisiert und neu gestartet ist, ist das der eigentliche Schutz. Bei einem Shop mit Kundendaten oder einem Portal mit Anmeldung würden wir diese Frage ernster nehmen als bei einer reinen Informationsseite.
Woran merke ich, ob meine Website schon angegriffen wurde?
Oft gar nicht von aussen. Verdächtig sind neue Administratorkonten, die niemand angelegt hat, Dateien mit seltsamen Namen im Upload-Ordner, Weiterleitungen auf fremde Seiten oder Warnungen von Google in der Search Console. Das BACS empfiehlt, Protokolle und Systeme auf ungewöhnliche Anfragen, Abstürze, veränderte Dateien und unerwartete Prozesse zu prüfen. Das ist Arbeit für Ihren Hoster oder Ihre Agentur.
Ist das dasselbe wie Log4Shell?
Nein. Log4Shell betraf den Protokollierungsbaustein Apache Log4j und wurde im Dezember 2021 bekannt (Eintrag CVE-2021-44228 der US-Schwachstellendatenbank NVD). Laut BSI soll der Name PHP2Shell die Ähnlichkeit aufzeigen; worin sie liegt, schreibt das BSI nicht. Naheliegend ist unsere Lesart: Beide Male trifft es einen weit verbreiteten Baustein, und ein Angreifer kann ohne Anmeldung eigenen Code ausführen lassen.
Mein Hoster antwortet nicht. Was jetzt?
Schauen Sie zuerst auf seine Statusseite; in solchen Nächten informieren viele dort statt per Mail. Kommt bis am nächsten Tag weder eine Antwort noch eine Statusmeldung, ist das an sich schon eine Information darüber, wie der Anbieter mit Ihrer Website umgeht. Was bei einem Wechsel anfällt, steht in unserem Beitrag Die Agentur wechseln: was bei der Übergabe Ihrer Website wirklich anfällt.
Können Sie testen, ob meine Website angreifbar ist?
Einen Angriffsversuch auf eine Website machen wir nicht, auch nicht zur Probe. Was wir ohne jeden Eingriff sagen können: mit welchem System Ihre Website läuft, ob sie eine alte PHP-Fassung verrät, und wen Sie fragen müssen.
Was sich von aussen nicht sagen lässt
Von aussen lässt sich nicht verlässlich sagen, ob ein bestimmter Server geschützt ist. Viele Server verraten ihre PHP-Fassung gar nicht, und selbst eine sichtbare alte Nummer kann eine eingespielte Korrektur verbergen. Die verbindliche Antwort hat nur, wer den Server betreibt. Darum führt jeder Weg in diesem Beitrag zur selben Stelle: Fragen Sie nach, und lassen Sie es sich schriftlich geben.
Sie wissen nicht, wer bei Ihrer Website für PHP zuständig ist?
Schicken Sie uns die Adresse Ihrer Website. Wir sagen Ihnen in einem kostenlosen Erstgespräch, mit welchem System sie läuft und wen Sie fragen müssen.
Quellen
- Bundesamt für Cybersicherheit BACS, «Kritische Schwachstellen in PHP: Sicherheitsupdates sofort einspielen», veröffentlicht am 21.10.2026: CVSS 9.2 «kritisch» für beide Lücken, korrigierte Fassungen, Hinweis auf zurückübertragene Korrekturen, Empfehlungen zu Neustart, Bestätigung durch den Hoster, Spurensuche, Trennung vom Internet und Web Application Firewall. Gelesen am 21.10.2026.
- The PHP Group, «Security advisory: Critical remote code execution vulnerabilities, update now», 21.10.2026: betroffene Umgebungen, technische Beschreibung beider Fehler, Angriff vor dem Start des Anwendungscodes, keine Updates mehr für 8.1 und älter, Notkorrekturen für 7.4 bis 8.1, Übergangsmassnahmen; dazu die Seite «Supported Versions» (Sicherheitsupdates für 8.2 bis 31.12.2026). Gelesen am 21.10.2026.
- Bundesamt für Sicherheit in der Informationstechnik (BSI), Deutschland, «PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit», Version 1.1, 21.10.2026: CVSS 9.2, keine Anmeldung und keine Nutzerinteraktion nötig, Name in Anlehnung an Log4Shell, Stand der Ausnutzung, Beteiligung von Wiz, Calif und OpenAI an der Entdeckung. Gelesen am 21.10.2026.
- W3Techs, «Usage statistics of PHP for websites»: 69,3 % der Websites mit bekannter Serversprache, Verteilung auf Version 8 (65,2 %), 7 (27,0 %) und 5 (7,7 %). Weltweite Erhebung, Stand 21.10.2026, gelesen am selben Tag.
- Help Net Security, «PHP2Shell: Critical PHP vulnerabilities patched, update now!», Mirko Zorz, 21.10.2026: Aussagen der Forschenden von Wiz zum Alter der Fehler und zur Rolle von KI-Modellen, Filterregeln von Cloudflare gegen die bekannten Angriffswege. Gelesen am 21.10.2026.
- cyon, Statusmeldung «Information zu potenziellen PHP-Sicherheitslücken», Meldungen vom 21.10.2026: Abschaltung um 15:45 Uhr, erwartete Pakete gegen 22 Uhr, E-Mail weiter in Betrieb. Gelesen am 21.10.2026 um 19:55 Uhr, erneut um 20:15 Uhr und am 22.10.2026 um 02:53 Uhr (Meldung von 02:49 Uhr).
- 20 Minuten, «PHP-Sicherheitslücke: Charité und Stadt Mainz nehmen Webseiten vom Netz», Alessia Rambaldi und Deutsche Presse-Agentur, 21.10.2026: vorsorgliche Abschaltungen bei Kommunen, Behörden, Universitäten und Spitälern; Charité und Stadt Mainz nennt die Überschrift. Gelesen am 21.10.2026.
- National Vulnerability Database (NVD), CVE-2021-44228: Lücke in Apache Log4j, veröffentlicht am 10.12.2021. Über die Schnittstelle der NVD gelesen am 21.10.2026.
Weiterlesen: Was Sie an einer WordPress-Website selbst ändern können und was Sie besser abgeben, steht im Beitrag Website selber pflegen.
Dieser Beitrag beschreibt den Stand vom 22. Oktober 2026, 02:50 Uhr. Bei einer Lücke dieser Grösse kommen in den ersten Tagen laufend neue Erkenntnisse dazu, etwa zu bestätigten Angriffen oder zu weiteren betroffenen Produkten. Massgebend sind dann die aktuellen Meldungen des BACS und Ihres Hosters.