Das PHP2Shell-Disaster

Mit PHP2Shell sorgen gleich zwei kritische Sicherheitslücken in PHP weltweit für Aufsehen. Die Schwachstellen ermöglichen unter bestimmten Bedingungen die Ausführung von Schadcode auf betroffenen Webservern. Dieser kurze Blog-Artikel gibt eine Einführung in die Problematik, sammelt weiterführende Links und gibt Auskunft darüber, ob unsere Software-Produkte von dieser Schwachstelle betroffen sind.

Das Wichtigste zuerst

Unsere Software-Lösungen Enbrea, DaVinci, Magellan und Confire Cloud sind alle nicht von der PHP2Shell-Schwachstelle betroffen, da keines dieser Produkte PHP verwendet oder von einer externen PHP-Anwendung abhängig ist. Das gilt auch für unser Ticketsystem.

Lediglich unsere ganz normalen Webseiten (z.B. www.stueber.de) laufen unter PHP. Die entsprechenden PHP-Laufzeitumgebungen wurden von uns bereits am 21.10.2026 aktualsiert.

Was ist ein CVE?

CVE ist eine Abkürzung für Common Vulnerabilities and Exposures (zu deutsch: Bekannte Schwachstellen und Anfälligkeiten). Es handelt sich dabei um eine kuratierte Liste öffentlicher Sicherheitsschwachstellen in IT-Systemen. Ein CVE in Kombination mit einer Nummer kennzeichnet eine bestimmte wohldefinierte Schwachstelle. In unserem Fall sind dies die Schwachstellen CVE-2026-109618 und CVE-2026-109619. CVE-Nummern dienen vor allem der besseren Kommunikation im IT-Umfeld.

Was ist das Problem?

Unter dem Namen PHP2Shell sind zwei kritische Sicherheitslücken bekannt geworden, die es Angreifern unter bestimmten Bedingungen ermöglichen, beliebigen Programmcode auf einem Webserver auszuführen. Ohne Anmeldung, ohne gestohlene Zugangsdaten und im schlimmsten Fall sogar bevor die eigentliche Webanwendung überhaupt gestartet wird.

Die beiden Schwachstellen tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Beide wurden nach dem Bewertungssystem CVSS 4.0 mit 9,2 von 10 Punkten eingestuft und gelten damit als äußerst kritisch.

Interessanterweise steckt die Ursache nicht in einer fehlerhaften Benutzeranmeldung, einer unsicheren Datenbankabfrage oder einem schlecht programmierten WordPress-Plugin. Betroffen ist vielmehr das Innenleben der PHP-Laufzeitumgebung: ihre Speicherverwaltung und Fehlerbehandlung.

Bei CVE-2026-109618 kann PHP in Schwierigkeiten geraten, wenn während der Verarbeitung einer Anfrage das konfigurierte Speicherlimit erreicht wird. Unter bestimmten Umständen bleiben interne Datenstrukturen unvollständig initialisiert zurück. Werden diese später bei der Speicherbereinigung dennoch als gültig behandelt, kann der Speicherinhalt beschädigt werden.

CVE-2026-109619 betrifft dagegen die Lebensdauer interner Zustände. Nach einem schwerwiegenden Fehler können Verweise auf bereits freigegebenen Speicher erhalten bleiben. Wird derselbe PHP-Prozess für eine weitere Anfrage verwendet, kann er auf diese ungültigen Speicherbereiche zugreifen. In der Softwareentwicklung bezeichnet man das als Use-after-free.

Beide Fehler können zur sogenannten Remote Code Execution (RCE) führen: Angreifer können fremden Programmcode auf dem betroffenen Server ausführen, möglicherweise Dateien lesen, Datenbanken angreifen oder weitere Schadsoftware installieren.

Dass die Aufregung so groß ist, liegt an der Verbreitung von PHP. Nach Angaben von W3Techs verwenden rund 70 Prozent aller Webseiten, deren serverseitige Programmiersprache bekannt ist, PHP. Dazu gehören unzählige Installationen von WordPress, Drupal, TYPO3 und anderen Webanwendungen. Eine Schwachstelle in PHP selbst betrifft damit potenziell einen erheblichen Teil der weltweiten Webinfrastruktur.

Was ist zu tun?

Ursprünglich sollten die Sicherheitsupdates am 22. Oktober erscheinen. Nachdem bereits am 20. Oktober Informationen über die Schwachstellen vorzeitig bekannt geworden waren, wurde die Veröffentlichung um einen Tag vorgezogen.

Seit dem 21. Oktober 2026 stehen folgende korrigierte PHP-Versionen bereit:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

Betreiber sollten ihre PHP-Installationen umgehend aktualisieren. Das gilt insbesondere für öffentlich erreichbare Webserver. Bei Linux-Distributionen können die notwendigen Korrekturen auch über Sicherheitspatches der jeweiligen Paketbetreuer bereitgestellt werden, ohne dass sich die ursprüngliche PHP-Versionsnummer entsprechend ändert. Anschließend müssen die betroffenen PHP-Prozesse neu gestartet werden.

PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt selbst keine regulären Sicherheitsupdates mehr. Hier sind eine Migration auf unterstützte Versionen oder entsprechende Sicherheitskorrekturen des Distributors beziehungsweise eines LTS-Anbieters erforderlich.

Temporäre Konfigurationsänderungen können einzelne Angriffswege erschweren, bieten aber keinen vollständigen Schutz. Die PHP-Entwickler betonen deshalb ausdrücklich, dass ein Sicherheitsupdate die einzig verlässliche Lösung ist.

Quellen und weiterführende Informationen:

Das könnte dich auch interessieren:
  1. TLS unter Nginx absichern
  2. Windows Defender manuell aktualisieren
  3. OpenSSH absichern
  4. TLS unter IIS 10 absichern
  5. Public-Key-Kryptographie
Teile diesen Artikel