PHP2Shell: BSI warnt vor kritischen PHP-Lücken, was Matomo-Betreiber jetzt tun sollten

Am 21. Oktober 2026 hat das BSI einen IT-Sicherheitshinweis zu zwei Schwachstellen in PHP veröffentlicht, CVE-2026-109618 und CVE-2026-109619, in Berichten auch „PHP2Shell“ genannt. Beide sind nach CVSS 4.0 mit 9,2 von 10 Punkten bewertet: Angreifer können aus der Ferne Code auf Webservern ausführen, ohne Anmeldung und ohne Zutun eines Nutzers. Das BSI stuft die Lage als „Orange“ ein, die dritte von vier Stufen, das heißt: Maßnahmen müssen unverzüglich ergriffen werden. Matomo ist eine PHP-Anwendung. Wer Matomo selbst betreibt, sollte PHP jetzt aktualisieren.

Was das BSI und PHP melden#

• Betroffen sind alle PHP-Versionen bis mindestens PHP 5, so das BSI unter Berufung auf CERT-EU. PHP selbst nennt alle Installationen, die Webanfragen beantworten: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das größte Risiko sieht PHP bei mod_php. Dort gibt es einen nachgewiesenen Exploit: Eine Anfrage ohne Anmeldung kann den Angriff auslösen, bevor überhaupt Code der Anwendung läuft.
• Die Updates sind da: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 vom 21. Oktober schließen beide Lücken. Linux-Distributionen haben die Patches vorab erhalten und liefern eigene Pakete aus. Eine vollständige Abhilfe ohne Update gibt es laut PHP nicht.
• Ein Matomo-Update hilft nicht: Die Lücken stecken in PHP, nicht in Matomo. Matomo schreibt dazu selbst, dass ein Update von Matomo sie nicht behebt.
• Ältere Versionen: PHP 8.1 und älter bekommen keine regulären Releases mehr. Für 7.4, 8.0 und 8.1 hat das PHP-Team ausnahmsweise Quell-Patches zum Selbstbauen veröffentlicht, manche Distributionen liefern Pakete. PHP 8.2 erhält nur noch bis zum 31. Dezember 2026 Sicherheitsupdates.
• Angriffe: Öffentliche Exploits gibt es inzwischen. Das RUS-CERT der Universität Stuttgart hat einen davon auf einem Testsystem nachvollzogen und meldet, dass Angriffe schon beobachtet wurden. Das BSI konnte Berichte über erste Angriffsversuche am 21. Oktober noch nicht bestätigen, geht aber von einer kurzfristigen Ausnutzung verwundbarer Systeme aus.

Was hinter den beiden Lücken steckt#

CVE-2026-109618, beschädigter Speicher nach Speichermangel. Erreicht PHP beim Verarbeiten einer Anfrage sein Speicherlimit, bricht es mitten in der Arbeit ab. Interne Daten der Anfrage sind dann erst zum Teil angelegt, und das Aufräumen am Ende behandelt sie trotzdem als gültig. Auslösen lässt sich das laut PHP mit präparierten Eingaben, etwa Multipart-Anfragen ohne verwertbare Längenangabe, mit vielen Headern pro Teil oder mit leeren, verschachtelten Datei-Feldern. Datadog Security Labs hat den Speichermangel im Labor (bei einem niedrigen Speicherlimit von 16 MB) auch mit einer gewöhnlichen Formular-Anfrage und einem einzigen, etwa 3,5 MB langen Feldnamen ausgelöst.

CVE-2026-109619, veralteter Zustand zwischen zwei Anfragen. Ein PHP-Prozess bearbeitet nacheinander viele Anfragen. Nach bestimmten Abbrüchen, etwa einem fatalen Fehler, einer Zeitüberschreitung oder Speichermangel, bleibt ein Verweis auf bereits freigegebenen Speicher zurück. Die nächste Anfrage an denselben Prozess kann ihn ausnutzen, laut PHP zum Beispiel über den Upload-Fortschritt von Sessions. Der ist ab Werk aktiv und braucht keinen Aufruf von session_start() durch die Anwendung. PHP hat diesen Weg unter mod_php und PHP-FPM bestätigt.

In beiden Fällen läuft der Code des Angreifers mit den Rechten des PHP-Prozesses, typischerweise als Benutzer des Webservers. Ein Update der Anwendung behebt das nicht, denn der Fehler liegt in PHP selbst.

Warum Matomo auf eigenem Server besonders gefordert ist#

Viele Webanwendungen lassen sich hinter einem VPN oder einer IP-Freigabe verstecken, und das BSI empfiehlt, den Zugriff auf Webanwendungen so restriktiv wie möglich zu gestalten. Bei Matomo geht das nur für die Oberfläche. Der Tracking-Endpunkt matomo.php muss für jeden Besucher jeder gemessenen Website erreichbar sein, ohne Anmeldung und aus dem ganzen Internet, sonst kommt kein Tracking an. Genau solche Anfragen ohne Anmeldung nutzen die neuen Lücken aus, und sie landen im selben PHP wie die Oberfläche.

Dazu kommt, was auf einem Matomo-Server liegt: die Rohdaten aller Besuche, die Zugangsdaten zur Datenbank in der config.ini.php, API-Token und der Tracking-Code, also matomo.js und die Container des Tag Managers, den alle gemessenen Websites laden. Wer den Server übernimmt, kann diesen Code verändern und so Schadcode auf sämtlichen Websites ausspielen.

Hätten SELinux, AppArmor oder eine WAF geschützt?#

Kurz gesagt: Keines dieser Werkzeuge hätte die Lücken geschlossen. Gut eingerichtet hätten sie aber das Auslösen erschwert oder den Schaden danach begrenzt. Das BSI empfiehlt in der aktualisierten Fassung seines Hinweises ausdrücklich, SELinux und AppArmor auf Linux-Servern, wo möglich, einzusetzen, um die Folgen solcher Lücken zu begrenzen. Webanwendungen zusätzlich mit einer WAF abzusichern, rät es ohnehin.

SELinux und AppArmor#

Beide schränken ein, was ein Prozess auf dem Server darf, unabhängig von den Dateirechten. Die Ausnutzung selbst verhindern sie nicht, denn der Fehler passiert im PHP-Prozess, der ja laufen darf. Die Forscher von Wiz, die an der Entdeckung beteiligt waren, schreiben dazu: Solche Richtlinien können die Folgen begrenzen, sie verhindern aber weder jede Ausnutzung noch das Auslesen von Speicher.

Was sie gut eingestellt begrenzen:

• Fremde Programme starten, etwa eine Shell oder Werkzeuge zum Nachladen von Schadcode, je nach Profil.
• Verbindungen nach außen: Ist unter SELinux der Schalter httpd_can_network_connect aus, können Webserver-Skripte keine Verbindungen zu fremden Servern aufbauen. Manche Matomo-Server schalten ihn allerdings ein, etwa für Updates der Geodatenbank.
• Sich festsetzen und weiterziehen: Cronjobs anlegen, SSH-Schlüssel hinterlegen, Dateien außerhalb von Matomo lesen oder schreiben, andere Dienste auf dem Server angreifen.

Was bleibt, ist alles, was der PHP-Prozess für Matomo ohnehin darf, also genau das, was oben als besonders wertvoll beschrieben ist: Datenbank-Zugang, Rohdaten und der Tracking-Code. Matomo erneuert die matomo.js, wenn Plugins Tracking-Code beisteuern, und legt die Container des Tag Managers im Ordner js/ ab, beides muss PHP also schreiben dürfen. Daten kann ein Angreifer zudem über die Antwort auf seine eigene Anfrage abziehen, ganz ohne Verbindung nach außen.

Eine Voraussetzung wird oft übersehen: Die Werkzeuge müssen aktiv sein und den PHP-Prozess wirklich einschränken. Unter Red Hat Enterprise Linux und verwandten Systemen ist SELinux ab Werk aktiv und schränkt den Webserver ein, wie weit, hängt von Richtlinie und Schaltern ab. Unter Debian und Ubuntu läuft zwar AppArmor, für PHP-FPM und Apache ist ab Werk aber kein Profil aktiv. Eines für PHP-FPM gibt es nur im optionalen Paket apparmor-profiles, und ohne aktives Profil schränkt AppArmor PHP nicht ein.

WAF und Request-Limits#

Eine Web Application Firewall prüft Anfragen, bevor sie PHP erreichen. Das BSI schreibt, eine WAF könne eine Ausnutzung verhindern oder erschweren, sofern sie passende Erkennungsregeln hat. Solche Regeln gab es schnell: Cloudflare hat sie nach eigenen Angaben ab dem 21. Oktober, 3:02 Uhr UTC, für alle Tarife ausgerollt, also Stunden vor der Veröffentlichung, und beobachtet, wie Angreifer ihre Anfragen abwandeln, um die Regeln zu umgehen. AWS hat seine verwalteten Regeln für PHP erweitert und nennt eine eigene Regel gegen Anfragen mit PHP_SESSION_UPLOAD_PROGRESS und Session-ID. Das BSI nennt außerdem Bunny Shield. Cloudflare und AWS betonen beide, dass die Regeln das Update nicht ersetzen, vollständigen Schutz bieten laut BSI nur das Patchen oder die Trennung vom Internet.

Unabhängig von fertigen Regeln empfiehlt PHP, am Webserver oder Proxy Grenzen zu setzen: für die Größe der Anfragen, die Zahl der Eingabefelder, der Multipart-Teile und der Header sowie die Verschachtelungstiefe, auch für Anfragen ohne Längenangabe. Multipart-Anfragen sollen ganz gesperrt werden, wo die Anwendung sie nicht braucht.

Für Matomo heißt das konkret:

• Der Tracking-Endpunkt braucht kein Multipart. Der JavaScript-Tracker sendet GET oder POST als gewöhnliches Formular, Bulk-Tracking sendet JSON. Datei-Uploads gibt es in Matomo nur in der Oberfläche, etwa für Plugins oder das eigene Logo. Für die Tracking-Endpunkte (matomo.php, piwik.php und den Ordner js/) lassen sich Multipart-Anfragen deshalb sperren, besser noch für alle Anfragen außer den Upload-Aktionen der Oberfläche. Weil der Fehler greift, bevor Matomo läuft, muss die Sperre jede öffentlich erreichbare PHP-Datei abdecken.
• Das allein reicht nicht. Der Speichermangel lässt sich auch mit gewöhnlichen Formular-Anfragen auslösen. Setzen Sie deshalb zusätzlich eine enge Größengrenze für Anfragen und eine Grenze für die Länge von Feldnamen.
• Den Upload-Fortschritt abschalten: Mit session.upload_progress.enabled=0 in der php.ini oder im FPM-Pool, danach alle Worker neu starten. Matomo selbst nutzt diese Funktion nicht.

Gesunde Systemhärtung#

Eine WAF kann neue Varianten übersehen, Request-Limits decken nur bekannte Wege ab, SELinux und AppArmor schützen nicht, was Matomo ohnehin beschreiben darf. Zusammen aber machen sie einen Angriff schwerer, begrenzen, was er anrichtet, und machen ihn sichtbar. Deshalb gehören SELinux oder AppArmor mit aktivem Profil, Request-Limits, eine WAF vor dem Tracking-Endpunkt, ein eigener Benutzer für PHP mit möglichst wenigen Schreibrechten und ein Monitoring, das Veränderungen bemerkt, zu einer gesunden Systemhärtung, eingerichtet, bevor die nächste Lücke bekannt wird.

Was Sie jetzt tun sollten#

1. Die richtige Version prüfen: php -v auf der Kommandozeile kann eine andere Version zeigen als die, mit der PHP-FPM oder Apache laufen. In Matomo steht die Version unter Administration › Diagnose › Systemprüfung. Distributionen patchen oft per Backport, dann zählt der Sicherheitshinweis der Distribution, nicht die Versionsnummer.
2. Aktualisieren: über die Paketverwaltung, das Hosting-Panel oder neu gebaute Container-Images.
3. Dienste neu starten: PHP-FPM und Apache laufen bis zum Neustart mit der alten Version weiter. Prüfen Sie danach auch das PHP, mit dem der Cronjob für die Archivierung läuft.
4. Nicht sofort möglich? Die Workarounds aus dem PHP-Hinweis ersetzen kein Update. Das BSI rät dann, eine vorübergehende Trennung vom Internet zu erwägen. Geht auch das nicht, sollten mindestens alle Workarounds umgesetzt werden, nur zusammen erschweren sie eine Ausnutzung maßgeblich. Bei Matomo kostet eine Trennung die Tracking-Daten dieser Zeit, ist aber besser als ein übernommener Server.
5. Auf Spuren prüfen: Unter Systemprüfung › Dateiintegrität meldet Matomo unerwartete Dateien. Kontrollieren Sie außerdem Hauptadministratoren, neue API-Token, Cronjobs, neue PHP-Dateien im Web-Verzeichnis sowie Änderungen an matomo.js und den Containern im Ordner js/.
6. Alte PHP-Versionen ablösen: PHP 8.1 und älter bekommen keine Updates mehr, PHP 8.2 nur noch bis Jahresende. Prüfen Sie vor dem Wechsel, ob Matomo und Ihre Plugins mit der neuen Version laufen. Matomo 6 verlangt mindestens PHP 8.1. Wählen Sie beim Wechsel aber eine Version, die noch Sicherheitsupdates bekommt, also PHP 8.3 oder neuer, mehr dazu in unserer Upgrade-Checkliste für Matomo 6.
7. Härtung nachziehen: Richten Sie die Schutzschichten aus dem Abschnitt oben ein, damit die nächste Lücke weniger anrichten kann.

Eine ausführlichere Anleitung für Matomo-Server finden Sie bei unserer Schwestermarke sonora: PHP2Shell: Matomo-Server jetzt aktualisieren.

So halten wir es bei unseren Kunden#

Bei den Matomo-Instanzen, die wir selbst hosten, gehört genau das zu unserer Arbeit: Sicherheitsupdates für PHP, Matomo und den Server spielen wir ein, ohne dass Sie etwas tun müssen. Wie schnell, richtet sich nach dem Schweregrad, kritische Lücken wie diese schließen wir sofort. Mehr dazu auf der Seite zum Matomo-Hosting.

Wenn Matomo auf Ihren eigenen Servern läuft, übernehmen wir das im SLA-Betrieb. Die Baseline sieht genau die Bausteine vor, die bei PHP2Shell zählen:

• Sicherheitsupdates: kritische innerhalb von 2 Werktagen nach Veröffentlichung, auf Wunsch nach Ihrem Freigabeprozess mit eigener Testinstanz. Wie alle Werte der Baseline lässt sich auch diese Frist vertraglich anpassen.
• Systemhärtung: ein Härtungsprofil für Betriebssystem, Netz und Matomo zum Start, jährlich überprüft und auf Wunsch nach den Vorgaben Ihrer Informationssicherheit. Werkzeuge wie SELinux oder AppArmor, Request-Limits und eine WAF können Bausteine eines solchen Profils sein, abgestimmt auf Ihre Infrastruktur.
• Monitoring rund um die Uhr für Tracking, Oberfläche, Archivierung und Datenbank, bei kritischen Störungen eine Reaktion innerhalb von 4 Stunden, werktags von 8 bis 18 Uhr.
• Pentests: jährlich extern, mit Bericht und nachverfolgten Maßnahmen.
• Nachweise: ein monatlicher Betriebsbericht für Revision, Informationssicherheit und Datenschutz.

So muss bei der nächsten Lücke niemand erst herausfinden, welche PHP-Version wo läuft und wer zuständig ist.