Am Dienstag, dem 20. Oktober 2026, kündigte das PHP-Projekt ein Sicherheitsupdate an. Die neuen Versionen folgten in dieser Woche, und zwei Nummern trugen die Bewertung 9,2 von 10. In den vergangenen Tagen kamen noch zwei andere Meldungen dazu, die für Betreiber von Websites relevant sind. Sie finden alle drei hier, die PHP-Lücke zuerst.
1. Die PHP-Lücke, die unter dem Namen „PHP2Shell“ läuft
Was ist passiert?
PHP ist die Programmiersprache, auf der WordPress, Joomla, Shopware und viele weitere Systeme laufen. In PHP selbst stecken zwei Fehler im Umgang mit dem Arbeitsspeicher. Sie haben die Nummern CVE-2026-109618 und CVE-2026-109619. Beide ermöglichen laut den Hinweisen des PHP-Projekts, dass ein Angreifer ohne Anmeldung eigenen Code auf dem Server ausführt (Fachbegriff RCE). Beide sind mit CVSS 4.0 jeweils mit 9,2 bewertet, das ist die Stufe „kritisch“. Die Plugin-Nummern weiter unten nutzen dagegen CVSS 3.1. Die Zahlen beider Versionen lassen sich nicht direkt miteinander vergleichen.
Der Name „PHP2Shell“ steht weder bei php.net noch in den Sicherheitshinweisen auf GitHub. Er stammt aus der Berichterstattung. Gemeint sind die beiden Nummern oben.
Technisch laufen die Fehler so ab.
- Bei CVE-2026-109618 bricht PHP bei Speichermangel ab, während der Speicher für die laufende Anfrage erst halb vorbereitet ist. Das Aufräumen danach arbeitet mit ungültigen Daten weiter.
- Bei CVE-2026-109619 bleibt der Zustand einer Anfrage im Arbeitsprozess liegen und zeigt auf bereits freigegebenen Speicher. Eine spätere Anfrage im selben Prozess greift darauf zu.
Für 109618 muss ein Angreifer den Speicherfehler zum passenden Zeitpunkt auslösen, etwa mit besonders gebauten Upload-Anfragen. Wie zuverlässig das klappt, hängt laut Quelle von der Server-Einrichtung ab. Eine Entwarnung ist das nicht.
Wer ist betroffen?
Betroffen sind alle Installationen, die Web-Anfragen beantworten. Die Lücke liegt nicht in WordPress und nicht in einem Plugin, sondern eine Ebene darunter. Ein Sicherheits-Plugin in WordPress ist deshalb kein Ersatz für das PHP-Update.
Wie hoch das Risiko ist, hängt davon ab, wie PHP auf dem Server eingebunden ist. Bei mod_php ist laut den Quellen eine vollständige Ausführung von fremdem Code über das Internet nachgewiesen. Für PHP-FPM bestätigen die Quellen die Anfälligkeit für 109619 und halten sie für 109618 nach Quellcodeanalyse für gegeben. Bei FrankenPHP und LSAPI ist eine Betroffenheit wahrscheinlich bzw. unter Bedingungen möglich. Als Betreiber einer normalen Firmenwebsite müssen Sie das nicht selbst auseinanderhalten. Es zeigt aber, warum die Antwort „bei uns läuft doch FPM“ keine Entwarnung ist.
Das BSI führt die Lücke unter WID-SEC-2026-4055. Dort stehen auch Produkte, die PHP mitbringen, zum Beispiel Checkmk, Matomo und cPanel. Wer solche Software betreibt, braucht zusätzlich deren eigene Updates.
Die Fix-Versionen
Der Fehler ist in diesen Ständen behoben, und in allen neueren.
| PHP-Reihe | Fix-Version |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Für 7.4, 8.0 und 8.1 gibt es keine neuen Versionen mehr. Das PHP-Projekt hat dort nur kleine Korrekturen am Quellcode als eigene Zweige bereitgestellt, die ein Hoster oder ein Linux-Anbieter selbst einbauen muss. Distributionen und Anbieter mit Langzeit-Support haben die Patches vorab bekommen. Deshalb kann auf Ihrer Seite eine alte Nummer stehen und die Lücke trotzdem geschlossen sein. Ob das so ist, klärt nur Ihr Hoster.
Was Sie als Betreiber tun
Laut php.net ist das Update die einzige vollständige Lösung. Die genannten Zwischenlösungen schützen nur teilweise, zum Beispiel session.upload_progress.enabled auf 0 zu stellen und die Prozesse neu zu starten. Setzen Sie solche Einstellungen nicht auf eigene Faust, sondern lassen Sie sie von Ihrem Dienstleister prüfen. Eine falsch gesetzte Sperre kann Formulare und Bild-Uploads lahmlegen.
Schreiben Sie Ihrem Hoster und stellen Sie drei Fragen.
- Welche PHP-Version läuft für meinen Tarif, und ist sie mindestens 8.2.35, 8.3.36, 8.4.27 oder 8.5.12?
- Ist bei 8.1 oder älter der Fix per Backport eingespielt, oder kann ich auf 8.3 oder 8.4 umstellen?
- Bis wann ist das erledigt?
Vor einer Umstellung gehören eine Sicherung und ein kurzer Test der Seite dazu, weil sehr alte Plugins und Themes auf neuem PHP nicht immer laufen.
So lief es bei uns
Ein Blick auf unsere eigene Seite. Bis der Patch da war, haben wir auf den Webspaces, die wir betreuen, eine vorübergehende Notsperre in den Konfigurationsdateien (.htaccess) eingerichtet. Unser Hoster hat den Patch kurz nach Veröffentlichung eingespielt. Wir haben die Version danach nachgemessen, und expertomundi.de lief auf PHP 8.4.27. Danach haben wir die Notsperre auf allen betroffenen Konfigurationsdateien wieder zurückgebaut.
Der kostenlose Selbsttest
Sie müssen nicht erst Menüs durchklicken. Unter expertomundi.de/php-check geben Sie Ihre Domain ein und sehen das Ergebnis als Ampel.
Der Selbsttest ist für die Domain Ihrer eigenen Website gedacht. Er ruft die Startseite einmal auf und wertet nur die Kopfzeilen der Antwort aus, also die Angaben, die ein Server ohnehin an jeden Besucher schickt. Das Ergebnis ist eine Momentaufnahme und keine Sicherheitsbescheinigung. Ein grünes Ergebnis gilt nur für diese eine Lücke. Einbruchsspuren prüft der Test nicht. Nennt der Server seine Version nicht, bleibt das Ergebnis offen, und das ist keine Entwarnung. Dann hilft im WordPress-Menü Werkzeuge, Website-Zustand, Info, Server, oder Ihr Hoster.
Zum Datenschutz beim Selbsttest. Die geprüfte Domain wird nicht im Klartext in unserer Datenbank gespeichert, sondern nur als Prüfwert (Hash), und den nur 10 Minuten lang. Im Webserver-Protokoll stehen wie bei jedem Seitenaufruf die aufgerufene Adresse und die IP-Adresse. Dazu kommt ein anonymer Tageszähler ohne Domain und ohne IP-Adresse. Er ist eine Obergrenze und keine Besucherzahl. Die Einzelheiten stehen in Ziffer 19 unserer Datenschutzerklärung.
Update 28.10.2026: Die US-Behörde CISA hat beide PHP-Lücken, CVE-2026-109618 und CVE-2026-109619, am 26.10.2026 in ihren Katalog „Known Exploited Vulnerabilities“ (KEV) aufgenommen, in dem nach ihrer Einschätzung bereits ausgenutzte Lücken stehen; US-Bundesbehörden müssen sie bis zum 29.10.2026 beheben. Für Sie gilt diese Frist nicht, doch fragen Sie Ihren Hoster jetzt, ob der PHP-Fix eingespielt ist.
2. Acht widerrufene Zertifikats-Zwischenstellen bei eMudhra
Das Schloss neben der Adresse im Browser zeigt, dass die Verbindung per HTTPS gesichert ist. Dahinter steht eine Kette aus Zertifikaten, die Zertifizierungsstellen ausstellen (englisch CA). Die Kette besteht aus einer Wurzel und mehreren Zwischenstellen, den Intermediate-CAs.
Bei der indischen Zertifizierungsstelle eMudhra (Marke emSign) ist ein Fehler passiert. Acht Zwischenstellen aus einer Serie vom 30. April 2025 nutzen Schlüssel, deren geheimer Anteil so klein ist, dass er sich leicht erraten lässt. eMudhra nennt als Ursache einen Fehler im Skript zur Schlüsselerzeugung. Dabei wurde versehentlich ein zweites, schwaches Schlüsselpaar verwendet. Am 18. Oktober 2026 hat eMudhra alle acht widerrufen, mit dem Grund „caCompromise“. Betroffen sind sechs Stellen für Website-Zertifikate (EV, OV und DV, jeweils in den Serien G3B für eMudhra BV und G3C für eMudhra Inc) und zwei Stellen für Code-Signing.
Mozilla hat darauf reagiert.
- Die sechs Website-Stellen stehen auf Mozillas Sperrliste OneCRL. Der erste Eintrag kam am 17. Oktober, weitere folgten am 21. Oktober.
- Die Wurzel „emSign ECC Root CA G3“ (laut Beschreibung im Bug-Eintrag) wird aus Mozillas Zertifikatsspeicher NSS entfernt, Zielversion NSS 3.132. Firefox hat das Update am 20. Oktober bekommen.
- Die Wurzel „emSign Root CA G1“ ist laut Bug-Eintrag nicht betroffen.
- Chrome ist laut einem Kommentar im Bug-Eintrag für den 27. Oktober vorgesehen (Chrome Root Store v43).
Wie andere Browser und Betriebssysteme reagieren, ist in unseren Quellen nicht belegt. Deshalb stützen wir uns hier allein auf die Angaben bei Mozilla.
Was Sie als Betreiber prüfen
Die Prüfung dauert eine Minute. Klicken Sie im Browser auf das Schloss neben der Adresse Ihrer Website, öffnen Sie das Zertifikat und suchen Sie nach dem Aussteller. Steht dort eMudhra oder emSign, fragen Sie Ihren Zertifikatsanbieter oder Hoster, ob Ihr Zertifikat von einer der acht Zwischenstellen oder von der entfernten Wurzel stammt und ersetzt werden muss. Steht dort ein anderer Aussteller, ist es unwahrscheinlich, dass Sie betroffen sind. Schauen Sie zur Sicherheit im Zertifikatsfenster auch den Zertifizierungspfad an und fragen Sie im Zweifel Ihren Anbieter. Die Meldung betrifft außerdem Zertifikate für Code-Signing, die hier nicht gemeint sind.
3. WordPress-Plugins, sechs Nummern mit sehr unterschiedlichem Risiko
Bei vier der sechs Nummern braucht der Angreifer kein Konto bei Ihnen, bei zwei schon. Das ist die wichtigste Trennlinie. Alle sechs Plugin-Lücken sind am 15. Oktober 2026 in der US-Datenbank NVD erschienen. Die Bewertungen stammen vom Melder (CNA), die NVD hat noch keine eigene vorgenommen. Sie folgen CVSS 3.1, die PHP-Nummern oben CVSS 4.0, deshalb sind die Zahlen nicht direkt vergleichbar.
Ohne Anmeldung
User Rights Access Manager, CVE-2026-109145 (Bewertung 9,8 von 10)
Über eine AJAX-Anfrage kann sich ein Fremder registrieren, und das neue Konto bekommt eine Kopie der Administratorrolle (Schwachstellentyp CWE-269). Betroffen sind Versionen bis 1.1.3. Es gibt keinen Fix. Das Plugin ist auf wordpress.org seit dem 7. März 2024 wegen eines Sicherheitsproblems geschlossen. Es hilft nur die Deinstallation. Prüfen Sie unter Plugins, ob es bei Ihnen noch installiert ist, und schauen Sie in der Benutzerliste nach Konten, die Sie nicht kennen.
Zwei Plugins für Zahlungen, drei Nummern
Beide Lücken betreffen Rückmeldungen des Zahlungsdienstes (Callbacks). Mit ihnen teilt ein Zahlungsdienst Ihrem Shop mit, dass bezahlt wurde. Die Plugins prüften die Echtheit dieser Meldung nicht richtig (Schwachstellentyp CWE-345). Ein Fremder kann also Zahlungsmeldungen erfinden. Bewertung jeweils 5,3 von 10.
- Cardinity Payment Gateway for WooCommerce, CVE-2026-103324. Das geheime Prüfwort ist standardmäßig leer. Betroffen sind Versionen vor 3.4.2, behoben in 3.4.2. Aktuell ist 3.4.3.
- Rede Itaú for WooCommerce, CVE-2026-92428 und CVE-2026-92429. Ohne Echtheitsprüfung kann der Status beliebiger Bestellungen geändert werden, auch bezahlter. Zusätzlich lassen sich unbezahlte Bestellungen als bezahlt markieren. Betroffen sind Versionen vor 5.5.3, behoben in 5.5.3 vom 9. Oktober 2026. Welche Änderung der Version 5.5.3 genau zu welcher der beiden Nummern gehört, geht aus dem Änderungsprotokoll nicht klar hervor.
Für Shop-Betreiber heißt das ganz praktisch, dass eine Ware als bezahlt gelten kann, obwohl kein Geld ankam. Prüfen Sie Ihre Plugin-Liste und aktualisieren Sie.
Mit Anmeldung
Hier braucht der Angreifer erst ein Konto auf Ihrer Seite. Die nötige Rolle (Abonnent bzw. Mitarbeiter) steht jeweils unten. Prüfen Sie unter Einstellungen, Allgemein, ob sich Fremde selbst registrieren können, und welche Rolle sie dann erhalten.
Email Customizer for WooCommerce (Pro) von ThemeHigh, CVE-2026-81534 (8,8 von 10)
Über die Funktion zum Test-E-Mail-Versand lässt sich Code einschleusen (Typ CWE-74). Die NVD nennt als Voraussetzung ein Konto ab der Rolle Abonnent. Ob die Lücke behoben ist und in welcher Version, konnten wir nicht belegen. Das Änderungsprotokoll der Version 3.9.6 vom 14. September 2026 nennt sie nicht. Das heißt nicht, dass sie offen ist, es heißt nur, dass wir es nicht wissen. Fragen Sie beim Hersteller nach, wenn Sie das Plugin einsetzen.
Elementor Website Builder, CVE-2026-11905 (4,3 von 10)
Private, Entwurfs- und geplante Inhalte samt Passwörtern können offengelegt werden (Typ CWE-862, fehlende Rechteprüfung). Voraussetzung ist ein Konto ab der Rolle Mitarbeiter. Betroffen sind Versionen bis einschließlich 4.2.3, behoben in 4.2.4 vom 31. August 2026. Aktuell ist 4.3.5. Wer Elementor regelmäßig aktualisiert, ist längst darüber.
Was in dieser Woche nicht zu klären war, ob zu den sechs Nummern bereits Angriffe laufen. Dazu enthalten die Quellen nichts.
Wenn Sie das nicht selbst prüfen möchten
Die Prüfung der PHP-Version Ihrer Website ist bei uns kostenlos und unverbindlich. Wenn Sie darüber hinaus Plugin-Liste und Benutzerkonten ansehen lassen möchten, brauchen wir vorab einen schriftlichen Auftrag und eine Vereinbarung zur Auftragsverarbeitung. Umfang und Kosten besprechen wir vorher mit Ihnen. Schreiben Sie an mpeter@expertomundi.de.
Quellen
Stand der Recherche 22.10.2026, CISA-Eintrag Stand 28.10.2026.
PHP (CVE-2026-109618 und CVE-2026-109619)
- GitHub Security Advisory GHSA-w8hw-w9fx-j79w
- GitHub Security Advisory GHSA-6wmf-4rv5-p3rp
- PHP-Projekt, Archiv 2026, Meldung vom 21.10.2026
- BSI, WID-SEC-2026-4055
- CISA, Known Exploited Vulnerabilities Catalog (Version 2026.10.27, Abruf 28.10.2026)
eMudhra
- Mozilla Bugzilla, Bug 2083449
- Mozilla Bugzilla, Bug 2084101, Entfernung der Wurzel emSign ECC Root CA G3 aus NSS
- Mozilla OneCRL
WordPress-Plugins (NVD, alle Einträge vom 15.10.2026)
- CVE-2026-109145
- CVE-2026-81534
- CVE-2026-11905
- CVE-2026-103324
- CVE-2026-92428
- CVE-2026-92429
- User Rights Access Manager auf wordpress.org
- Elementor auf wordpress.org, Version 4.2.4
- Cardinity Payment Gateway auf wordpress.org
- Rede Itaú for WooCommerce auf wordpress.org
- ThemeHigh, Änderungsprotokoll Email Customizer
Eigene Seite