Matomo 5.14.2 ist da, aber die eigentliche Lücke steckt in PHP

Am 22. Oktober 2026 hat Matomo die Version 5.14.2 veröffentlicht, laut Changelog ein Patch-Release mit einem wichtigen Sicherheitshinweis. Anlass sind die beiden PHP-Lücken CVE-2026-109618 und CVE-2026-109619, auch „PHP2Shell“ genannt, die PHP einen Tag zuvor geschlossen hat. Matomo stellt selbst klar: Ein Update von Matomo allein schließt diese Lücken nicht. 5.14.2 warnt nur, wenn Ihr Server eine betroffene PHP-Version meldet. Wer Matomo selbst hostet, und das ist einer der großen Vorteile von Matomo, ist damit auch für alles darunter verantwortlich.

Was in 5.14.2 steckt#

Das Update enthält neben der neuen Versionsnummer genau zwei Änderungen, ein Datenbank-Update gibt es nicht:

• Eine Warnung bei betroffenem PHP: Matomo vergleicht die PHP-Version des Servers mit den korrigierten Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Liegt sie darunter oder läuft noch PHP 8.1 oder älter, sehen alle angemeldeten Nutzer die Meldung „Urgent PHP security update required“. Man kann sie schließen, beim nächsten Seitenaufruf ist sie wieder da. Eine deutsche Übersetzung gibt es noch nicht, die Meldung erscheint auf Englisch.
• Eine neue Liste vertrauenswürdiger Zertifizierungsstellen: Matomo bringt für ausgehende HTTPS-Verbindungen über cURL eine eigene Liste mit, das Paket composer/ca-bundle. Diese Verbindungen nutzt Matomo etwa für den Marketplace, die Suche nach Updates und Downloads. Version 1.6.0 vom 20. Oktober entfernt drei Wurzelzertifikate von emSign, eines davon ausdrücklich, weil es kompromittierte Zwischenzertifikate des Anbieters eMudhra gegengezeichnet hatte. Mit PHP2Shell hat das nichts zu tun.

Für Matomo 6 kamen beide Änderungen mit der Beta 7 vom selben Tag, neben weiteren Korrekturen. Aktuell ist dort der Release Candidate 1 vom 30. Oktober. Der eingebaute Updater bietet 5.14.2 an, starten muss das Update ein Hauptadministrator.

Warum die Warnung nicht immer stimmt#

Matomo prüft nur die Versionsnummer. Viele Linux-Distributionen spielen Sicherheitskorrekturen aber als Backport ein und lassen die Versionsnummer dabei unverändert:

• Ubuntu führt die Lücken zum Beispiel in PHP 8.3.6 von Ubuntu 24.04 als behoben, sobald das aktuelle Paket installiert ist. Matomo warnt trotzdem.
• Debian hat die neuen Versionen selbst ausgeliefert, 8.2.35 in Bookworm und 8.4.27 in Trixie. Dort stimmt die Warnung.
• PHP 8.1 und älter meldet Matomo immer als betroffen, auch wenn die Distribution sie gepatcht hat (etwa PHP 8.1.2 in Ubuntu 22.04) oder sie mit den Quell-Patches des PHP-Teams nachgebaut wurden.

Die Meldung bittet deshalb ausdrücklich darum, zu prüfen, ob die Sicherheitskorrekturen Ihrer Distribution eingespielt sind. Maßgeblich ist deren Sicherheitshinweis, nicht die Versionsnummer. Damit sich die Warnung nach dieser Prüfung abschalten lässt, hat Matomo eine Einstellung entwickelt: disabled_notifications[] = PhpSecurityAdvisory_2026_10_21 im Abschnitt [General] der config.ini.php. Sie steckt in Matomo 6 ab der Beta 9 und ist für Matomo 5.14.3 vorgesehen, in 5.14.2 noch nicht.

Umgekehrt sagt die Warnung nur etwas über das PHP, mit dem die Matomo-Oberfläche läuft. Läuft der Tracking-Endpunkt in einem anderen PHP-Pool oder auf einem anderen Server, müssen Sie diesen selbst prüfen.

Selbst hosten heißt: der ganze Stapel#

Matomo auf eigenen Servern zu betreiben, ist ein starkes Argument: Die Daten bleiben bei Ihnen, und Sie bestimmen, was mit ihnen passiert. Dazu gehört aber, jede Schicht aktuell zu halten, nicht nur Matomo selbst. Eine Checkliste:

1. Matomo und Plugins: Updates zeitnah einspielen, vorher ein Backup ziehen und den Changelog lesen. Plugins aus dem Marketplace oder von Drittanbietern gehören dazu.
2. PHP: Eine Version nutzen, die noch Sicherheitsupdates bekommt. PHP 8.2 erhält sie nur noch bis zum 31. Dezember 2026, PHP 8.3 bis Ende 2027, PHP 8.4 bis Ende 2028 und PHP 8.5 bis Ende 2029. Nach einem Update PHP-FPM oder Apache neu starten und prüfen, mit welcher Version Webserver und Archivierungs-Cronjob tatsächlich laufen. Was bei PHP2Shell konkret zu tun ist, steht in unserem Beitrag PHP2Shell: was Matomo-Betreiber jetzt tun sollten.
3. Webserver und TLS: Apache oder nginx über die Distribution aktuell halten, Zertifikate automatisch erneuern lassen und nur aktuelle TLS-Versionen anbieten.
4. Betriebssystem: Sicherheitsupdates der Distribution regelmäßig einspielen, wo möglich automatisch, und nach Kernel-Updates neu starten.
5. Informiert bleiben: Sicherheitshinweise Ihrer Distribution, die Warnungen des BSI und den Changelog von Matomo verfolgen. Wer erst reagiert, wenn Matomo warnt, ist spät dran: Die Warnung kam einen Tag nach dem PHP-Update, und auch sie wirkt erst, wenn 5.14.2 eingespielt ist.
6. Härten: SELinux oder AppArmor, Grenzen für Anfragen und eine WAF begrenzen den Schaden, wenn eine Lücke schneller ausgenutzt wird, als Sie patchen können. Mehr dazu ebenfalls im PHP2Shell-Beitrag.

Wie wir mit PHP2Shell umgegangen sind#

Für alle Server, die wir betreuen, also die Matomo-Instanzen, die wir selbst hosten, und die Server unserer SLA-Kunden, lief der 21. Oktober so:

1. Sofort nach der Warnung, noch vor den Patches:
   • Den Upload-Fortschritt von Sessions abgeschaltet (session.upload_progress.enabled=0), einen der Angriffswege, die PHP selbst nennt.
   • Die Firewall angepasst.
   • Eine Überwachung aufgeschaltet, die abgestürzte PHP-Prozesse sofort meldet. Speichermangel und fatale Fehler gehören zu den Wegen, über die sich die Lücken auslösen lassen, abgestürzte Prozesse sind also ein frühes Warnsignal.
   • Bestimmte Funktionen in PHP deaktiviert, die einem Angreifer nach einem Einbruch helfen würden.
2. Um 14 Uhr UTC, also 16 Uhr deutscher Zeit: Mit dem Erscheinen der Patches haben wir die PHP-Versionen direkt aktualisiert.

Die Sofortmaßnahmen ersetzen kein Update, das sagt auch PHP selbst. Sie haben aber die Stunden bis zum Patch überbrückt und die Angriffsfläche bis dahin verkleinert. Genau dafür gibt es Hosting und SLA-Betrieb: Jemand verfolgt die Lage, kennt Ihre Server und handelt, ohne dass Sie sich darum kümmern müssen. Auch die Server unserer SLA-Kunden waren damit am Tag der Veröffentlichung gepatcht, deutlich vor der vertraglichen Frist. Zugesagt sind im SLA die vereinbarten Fristen.

Ein fester Prozess statt Patchen auf Zuruf#

Haben Sie einen festen Prozess für PHP-Updates, oder patchen Sie erst, wenn Matomo warnt? PHP2Shell hat gezeigt, wie knapp die Zeit ist: Die Patches kamen am 21. Oktober um 16 Uhr, und das BSI hielt eine breite Ausnutzung schon wenige Stunden später für wahrscheinlich. Wer dann erst einen Zuständigen suchen muss, verliert Zeit.

Wenn Sie das nicht selbst übernehmen möchten, gibt es zwei Wege:

• Matomo-Hosting: Bei den Instanzen, die wir selbst hosten, spielen wir Sicherheitsupdates für PHP, Matomo und den Server ein, je nach Schweregrad, kritische sofort. Mehr auf der Seite zum Matomo-Hosting.
• SLA-Betrieb auf Ihrer Infrastruktur: Die Baseline sieht kritische Sicherheitsupdates innerhalb von 2 Werktagen nach Veröffentlichung vor, dazu Härtung und Monitoring rund um die Uhr, alle Werte vertraglich anpassbar. Mehr auf der Seite zum SLA-Betrieb.

Und wenn Sie einen guten Prozess gefunden haben: Schreiben Sie uns, wie Sie das lösen.