NexTool Solutions

Zwei kritische Schwachstellen in PHP selbst, PHP2Shell genannt (CVE-2026-109618 und CVE-2026-109619), ermöglichen die Ausführung von Code auf dem Server mit Anfragen ohne Login, noch bevor irgendein Code der Anwendung läuft. Sie betreffen jede PHP-Installation, die Webanfragen bedient, und GLPI läuft auf PHP. Die Korrektur steckt in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35, veröffentlicht am 21. Oktober 2026. Dieser Leitfaden erklärt, was hinter den Schwachstellen steckt, warum GLPI in der Schusslinie steht, wie Sie herausfinden, wo Sie PHP im Einsatz haben, wie Sie in jedem Szenario korrigieren, wie Sie erkennen, ob bereits jemand eingedrungen ist, und was danach zu tun ist.

Dieser Leitfaden stützt sich auf die öffentlichen Informationen, die am 22. Oktober 2026 verfügbar waren. Sicherheitshinweise ändern sich schnell: Prüfen Sie vor dem Handeln auch den Hinweis Ihres Anbieters oder Ihrer Distribution.

Update: Am 23. Oktober 2026 hat PHP eine dritte Schwachstelle bekannt gegeben, CVE-2026-115560, für die es noch keine Korrektur gibt. Lesen Sie, was sich ändert und welche Konfiguration schützt.

Zusammenfassung für alle, die fünf Minuten haben

Update vom 23.10.: eine dritte Schwachstelle, CVE-2026-115560

Am 23. Oktober hat ein Hinweis des PHP-Projekts eine dritte Schwachstelle zur Remote-Codeausführung bekannt gemacht, CVE-2026-115560, die mit der Funktion für den Upload-Fortschritt von Sitzungen (session upload progress) zusammenhängt. Sie unterscheidet sich von den beiden PHP2Shell-Schwachstellen, und die Versionen vom 21. und 22. Oktober beheben sie nicht. Die Korrektur kommt mit der nächsten regulären PHP-Version, für die es noch kein Datum gibt, und der vollständige Hinweis erscheint zusammen mit ihr.

Der Angriffsweg ist deutlich enger als bei PHP2Shell. Er existiert nur, wenn drei Bedingungen zusammentreffen:

1. die php.ini setzt session.serialize_handler auf php_binary oder php_serialize;
2. die Anwendung ändert diesen Wert zur Laufzeit mit ini_set() auf php, bevor sie die Sitzung öffnet;
3. der Upload-Fortschritt der Sitzung ist eingeschaltet, was der Standard von PHP ist.

GLPI nimmt diese Änderung nicht vor. Wir haben den Code von GLPI 10, 11 und 12 geprüft: Er ändert den serialize_handler nicht und nutzt den Upload-Fortschritt der Sitzung nicht. Ein Server, auf dem nur GLPI mit der Standardkonfiguration von PHP läuft, ist über diesen Weg nicht angreifbar. Das Risiko entsteht, wenn dasselbe PHP andere Anwendungen bedient, etwa eine Website, einen Shop oder ein Altsystem, welches Sie nicht prüfen können.

Dennoch lautet die Empfehlung, die Funktion jetzt abzuschalten. PHP selbst hatte dies bereits am 21. Oktober als Eindämmungsmaßnahme für CVE-2026-109619 vorgeschlagen, und GLPI verliert dadurch nichts:

session.upload_progress.enabled = Off

Tragen Sie die Zeile in die php.ini des PHP ein, welches das Web bedient, oder in den Pool von PHP-FPM (php_admin_flag[session.upload_progress.enabled] = off), und starten Sie PHP-FPM oder Apache neu. Eine Konfiguration im Code mit ini_set() oder in einer .user.ini-Datei schützt nicht. Wo die Datei im jeweiligen Szenario liegt:

Verwenden Sie zur Prüfung auf dem Server PHP-FPM und nicht das Kommandozeilen-PHP, welches eine andere Datei liest:

sudo php-fpm8.3 -i | grep session.upload_progress.enabled
grep -rn upload_progress /etc/php/8.3/fpm/

Das erwartete Ergebnis ist Off. Wenn ein Pool die Zeile mit on enthält, hat sie Vorrang vor der php.ini.

Tipp: Diese Konfiguration ersetzt nicht die Aktualisierung gegen die Schwachstellen vom 21. Oktober. Sie schließt nur die neue Schwachstelle, bis die Korrektur erscheint. Wenn PHP die nächste Version veröffentlicht, aktualisieren Sie erneut.

Was passiert ist

Das PHP-Projekt hat Sicherheitskorrekturen für zwei Schwachstellen zur Remote-Codeausführung im Kern der Sprache veröffentlicht. Im offiziellen Changelog erscheinen die Korrekturen als „Avoid state corruption via bailout“ (GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp). Sicherheitsquellen nennen einen Wert von 9,2 auf der Skala CVSS 4.0, was sie in den kritischen Bereich einordnet. Manche Quellen nennen 9,8 auf der Skala CVSS 3.1 der NVD.

Vereinfacht gesagt:

• CVE-2026-109618: Ein Speichermangel kann PHP mitten in einer Anfrage unterbrechen, während interne Daten nur teilweise initialisiert sind. Bei der Bereinigung der Anfrage behandelt PHP diese ungültigen Daten dann als gültig.
• CVE-2026-109619: Ein interner Zustand einer Anfrage kann weiterbestehen, nachdem sein Speicher freigegeben wurde. Die nächste Anfrage, die vom selben Prozess bedient wird, kann diesen Zustand verwenden, bevor er neu initialisiert wird.

Beide Fälle sind Probleme der Speicherverwaltung innerhalb des Interpreters, und genau dies macht sie so schwerwiegend. Laut den veröffentlichten Analysen kann eine einzige Anfrage ohne Authentifizierung den Angriff auslösen, bevor irgendein Code der Anwendung läuft. Anders gesagt: Die Anmeldeseite von GLPI, die Profilberechtigungen und die Regeln der Anwendung werden gar nicht erst abgefragt.

Welche Installationen angreifbar sind

Alle Arten, PHP für das Web zu betreiben, werden in den Hinweisen genannt: PHP-FPM (am häufigsten mit Nginx und mit modernem Apache), Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Die Analysen nennen mod_php als Szenario mit dem höchsten Risiko.

Das Kommandozeilen-PHP (CLI), welches die automatischen Aktionen von GLPI über den Cron ausführt, bedient keine Webanfragen. Es hat meist dieselbe Version und wird zusammen aktualisiert.

Nicht nur GLPI

Die Schwachstelle liegt in PHP, nicht in einer Anwendung. Deshalb ist jedes PHP-System, welches Webanfragen bedient, angreifbar, und die Korrektur ist für alle dieselbe: PHP aktualisieren und den Dienst neu starten. Ein Update von WordPress, GLPI oder einem Plugin löst nichts.

Die Warnung blieb nicht auf IT-Fachleute beschränkt: Mercado Pago etwa forderte Händler, die WooCommerce, PrestaShop und Adobe Commerce (Magento) nutzen, auf, das PHP ihrer Shops zu prüfen.

In der Praxis betreut, wer GLPI betreut, fast immer auch andere Server mit PHP: die Firmenwebsite, Intranet, das Monitoring, das Altsystem, welches niemand abgeschaltet hat. Wer nur GLPI korrigiert, lässt die Tür auf dem Server nebenan offen. In Schritt 1 zeigen wir, wie Sie mit dem Inventar von GLPI selbst alle diese Server finden.

Wird die Schwachstelle bereits ausgenutzt?

Die Quellen gehen auseinander, was an der Empfehlung nichts ändert:

• Amazon: Laut Help Net Security hat das Threat-Intelligence-Team von Amazon am 17. Oktober, vier Tage vor der öffentlichen Bekanntgabe, einen Ausnutzungsversuch in seinem Honeypot-Netz (MadPot) registriert.
• watchTowr: In seinen häufig gestellten Fragen zu PHP2Shell teilte watchTowr am 21. Oktober mit, eine Ausnutzung der Schwachstellen in seinem Honeypot-Netz beobachtet zu haben.
• CISA (US-Behörde für Cybersicherheit): In ihrer Warnung vom 21. Oktober erklärte sie, bis zu diesem Zeitpunkt keine Ausnutzung beobachtet zu haben, forderte aber ein sofortiges Update. Wer nicht aktualisieren kann, solle PHP-Systeme bis zur Korrektur vom Netz nehmen. Das britische NCSC gab dieselbe Empfehlung.

Wenn bereits Versuche registriert wurden, sogar vor der Bekanntgabe, und eine Regierungswarnung dazu auffordert, abzuschalten, was nicht korrigiert werden kann, liegen zwischen „möglich“ und „passiert gerade“ meist nur Tage. Behandeln Sie die Lage als Notfall.

Warum GLPI in der Schusslinie steht

GLPI ist eine klassische PHP-Anwendung: Webserver, PHP und Datenbank. Jede Anfrage an GLPI läuft durch PHP, auch jene, die vor dem Login eintreffen. Und GLPI hat meist mehr offene Türen ins Internet, als man denkt:

Da der Angriff stattfindet, bevor der Code von GLPI läuft, dient jede dieser URLs als Tür. Es spielt keine Rolle, ob die API einen Token verlangt oder das Portal einen Login: Die bösartige Anfrage wird gar nicht erst geprüft.

Und was hinter dieser Tür liegt, ist sensibel. Der GLPI-Server hält den Zugang zur Datenbank mit allen Tickets, Anhängen, Benutzerdaten und dem Inventar des Unternehmens. Im Ordner config liegen das Datenbankpasswort und der Schlüssel, der die in GLPI gespeicherten Passwörter schützt (E-Mail-Empfänger, LDAP, SMTP). Wer Code auf dem Server ausführt, hat all dies in Reichweite.

Drei häufige Fallen

• Ein Update von GLPI aktualisiert nicht PHP. Wer gerade auf GLPI 12 umgestiegen ist, ist nicht automatisch geschützt: GLPI 12 verlangt PHP 8.3, funktioniert aber auch mit einer 8.3 aus der Zeit vor der Korrektur.
• Die Versionsnummer kann täuschen. Ubuntu spielt die Korrektur meist ins Paket ein und behält die Nummer bei (24.04 zeigt auch aktualisiert 8.3.6). Debian macht es manchmal genauso und springt manchmal auf die neue Version. Eine „alte“ Nummer beweist nicht, dass der Server angreifbar ist, und ein neues Paket beweist nicht, dass der Dienst neu gestartet wurde. Diesmal hat Debian die Nummer erhöht (8.4.27 in Debian 13 und 8.2.35 in Debian 12): Dort weist eine alte Nummer auf ein Paket ohne Korrektur hin.
• PHP 8.1 mit GLPI 10 ist die riskanteste Kombination: PHP ohne offizielle korrigierte Version und GLPI ohne Support. Siehe den Abschnitt zu PHP 8.1 weiter unten.

Schritt 1: Finden Sie heraus, wo Sie PHP im Einsatz haben

Die CISA beginnt ihre Empfehlung genau hier: alle Systeme mit PHP inventarisieren. GLPI ist nur eines davon. Häufig tauchen auch die Firmenwebsite, Intranet, Zabbix, phpMyAdmin, Moodle und das alte Ticketsystem auf, welches niemand abgeschaltet hat.

Nutzen Sie GLPI selbst dafür

Wenn Sie den GLPI Agent verwenden, weiß das Software-Inventar bereits, wo PHP installiert ist:

1. Gehen Sie zu Assets > Software (in manchen Übersetzungen Programme) und suchen Sie nach php.
2. Öffnen Sie je nach Distribution Einträge wie php8.3-fpm, php8.3-common, libapache2-mod-php8.3 oder php-fpm.
3. Sehen Sie im Reiter der Installationen nach, auf welchen Computern die jeweilige Version installiert ist.

Die vom Agenten angezeigte Version ist die des Pakets, mit dem Suffix der Distribution (zum Beispiel 8.3.6-0ubuntu0.24.04.x). Genau diese müssen Sie mit dem Sicherheitshinweis der Distribution vergleichen. Das Inventar sieht weder PHP in Docker-Containern noch entpacktes PHP unter Windows oder in XAMPP.

Prüfen Sie das PHP, welches GLPI bedient

Das Kommandozeilen-PHP kann sich von dem unterscheiden, welches die Website bedient. So sehen Sie, worauf es ankommt:

• In GLPI: Unter Einstellungen > Allgemein > System zeigt der Abschnitt zum Server die PHP-Version, die GLPI verwendet.
• Auf dem Server: Prüfen Sie, welcher Dienst läuft und welche Version er verwendet.

php -v
systemctl list-units --type=service | grep -Ei 'php|apache|httpd'
sudo php-fpm8.3 -v

Ersetzen Sie 8.3 durch die Version, die in der Liste der Dienste erscheint. Unter Red Hat und Derivaten verwenden Sie sudo php-fpm -v.

Schritt 2: Aktualisieren Sie je nach Szenario

Ubuntu und Debian mit dem PHP der Distribution

Die Distributionen erhalten die Korrekturen vor der öffentlichen Bekanntgabe und veröffentlichen die Pakete in ihren Sicherheitshinweisen (bei Ubuntu USN-8948-1 vom 21.10.; bei Debian DSA-6574-1 und DLA-4848-1). Bei Ubuntu ändert sich die Hauptnummer nicht; prüfen Sie anhand des Pakets:

sudo apt-get update
apt-cache policy php8.3-fpm
sudo apt-get install --only-upgrade 'php8.3*'
zcat /usr/share/doc/php8.3-common/changelog.Debian.gz | grep -E 'CVE-2026-10961[89]'

Der letzte Befehl liest den Changelog des installierten Pakets und sollte CVE-2026-109618 und CVE-2026-109619 anzeigen. Wenn die automatischen Sicherheitsupdates eingeschaltet sind, ist Ihr Paket möglicherweise bereits angekommen; dennoch verwendet der Dienst den neuen Code erst nach einem Neustart.

Referenzversionen nach Distribution:

PHP aus Drittanbieter-Repositorys (ondrej/php, sury.org) oder Hosting-Panel

Diese Pakete tragen die Nummer der offiziellen Version (zum Beispiel 8.3.36-1+ubuntu24.04.1+deb.sury.org+1 unter Ubuntu), sodass die Prüfung direkt möglich ist. Die automatischen Updates der Distribution decken diese Repositorys normalerweise nicht ab, und dasselbe gilt für Panels, die PHP von sury installieren, wie CloudPanel:

sudo apt update && sudo apt upgrade
php -v

Verwenden Sie in Panels wie cPanel, Plesk oder aaPanel die PHP-Aktualisierung des Panels selbst und prüfen Sie die Version jeder Website.

Red Hat, Rocky, AlmaLinux und Oracle Linux

sudo dnf check-update 'php*'
sudo dnf update 'php*'
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'

Beim PHP von Red Hat selbst (AppStream-Module) ändert sich die Nummer ebenfalls nicht: Maßgeblich ist der Changelog. Kommt PHP aus dem Remi-Repository, trifft das Update mit der Nummer der offiziellen Version ein (8.2 bis 8.5, unter RHEL 8, 9 und 10): Prüfen Sie mit php -v. Am Tag der Bekanntgabe hatte Remi die Pakete noch nicht, und die Mirrors waren überlastet: Wenn dnf das Update nicht anbietet, führen Sie sudo dnf upgrade --refresh 'php*' aus, welches den Cache ignoriert, und versuchen Sie es einige Minuten später erneut. Bei Remi im SCL-Modus heißt der Dienst zum Beispiel php83-php-fpm.

Docker

Der Container aktualisiert sich nicht selbst, und ein Neustart des alten Containers tauscht PHP nicht aus. Sie müssen ein neues Image herunterladen und den Container neu erstellen. Sichern Sie vorher die Datenbank und stellen Sie sicher, dass der Dateiordner, der Ordner config und die Datenbank auf Volumes liegen (docker inspect <container> --format '{{json .Mounts}}'); andernfalls löscht die Neuerstellung des Containers die Daten. Verwendet Ihr Image den Tag latest, kann der Pull eine andere GLPI-Version mitbringen: Legen Sie den Tag fest. Benennen Sie in docker compose den GLPI-Dienst (in den folgenden Befehlen glpi): Ohne Namen lädt pull zusätzlich ein Image der Datenbank herunter, und mit mariadb:latest kann dabei eine höhere Datenbankversion mitkommen.

docker compose pull glpi
docker compose build --pull glpi
docker compose up -d glpi
docker exec <container-do-glpi> php -v

Wenn Sie das offizielle Image glpi/glpi verwenden, wurde es bereits mit korrigiertem PHP veröffentlicht: Am 22.10. enthielten alle Tags (latest, 12.0.0, 11.0.11, 10.0.28 und die Nightlys) PHP 8.5.12, sodass ein Pull genügt. Es verwendet Apache mit mod_php, das Szenario mit dem höchsten Risiko – ein Grund mehr, nicht zu zögern. Wenn Ihr Image auf einem offiziellen PHP-Image basiert (zum Beispiel php:8.3-fpm oder php:8.3-apache), erschienen die korrigierten Tags im Laufe des 21.10. und die von FrankenPHP in der Nacht zum 22.10. (UTC); ein Pull vor diesem Zeitpunkt hat die angreifbare Version geholt. Zwei Vorsichtsmaßnahmen: apt upgrade im Dockerfile aktualisiert das PHP dieser Images nicht, da es separat kompiliert wird; und ein gleitender Tag kann mehr als PHP mitbringen (auch der Webserver des Images kann die Version wechseln). Sichern Sie vor der Neuerstellung das aktuelle Image, um zurückkehren zu können: docker tag "$(docker inspect --format '{{.Image}}' <container-do-glpi>)" glpi-antes-do-patch.

Windows (IIS, XAMPP, WampServer)

Laden Sie die korrigierte Version Ihrer Versionslinie von der offiziellen Website für PHP unter Windows herunter und ersetzen Sie den PHP-Ordner, wobei Sie Ihre php.ini behalten. Fertige Pakete wie XAMPP veröffentlichen die neue Version oft mit Verzögerung; warten Sie nicht darauf. Starten Sie anschließend IIS oder Apache neu.

Schritt 3: Neu starten und prüfen

Das Paket zu aktualisieren genügt nicht. Die Prozesse, die bereits liefen, behalten den alten Code im Speicher, bis sie neu gestartet werden:

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

Unter Red Hat und Derivaten heißen die Dienste meist php-fpm und httpd. Nach dem Neustart:

1. Öffnen Sie in GLPI Einstellungen > Allgemein > System und prüfen Sie die PHP-Version.
2. Führen Sie php -v auf dem Server aus und prüfen Sie auch PHP-FPM (sudo php-fpm8.3 -v).
3. Mit PHP von sury, Remi, aus einem offiziellen Docker-Image oder unter Windows sollte GLPI die korrigierte Version anzeigen. Zeigt es die alte, läuft noch ein alter Prozess oder ein zweites PHP ist installiert.
4. Mit dem PHP der Distribution ändert sich die Nummer möglicherweise nicht. Prüfen Sie Ihr Paket (dpkg -l 'php8.3*' oder rpm -q php-fpm) und ob der Dienst nach der Installation neu gestartet wurde: systemctl status php8.3-fpm zeigt die Uhrzeit bei „active since“. Unter Ubuntu listet sudo needrestart -r l auf, was noch mit altem Code läuft; unter Red Hat sudo dnf needs-restarting -s.

Testen Sie GLPI, bevor Sie die Sache abschließen

Ein PHP-Update bricht GLPI selten, aber es gilt die Regel jeder Änderung in der Produktion: Wenn möglich, spielen Sie es zuerst auf einer Testkopie ein und erstellen Sie in jedem Fall vorher ein Backup. Prüfen Sie nach dem Update in wenigen Minuten die Abläufe, die nicht stillstehen dürfen:

1. Login, auch über LDAP oder Single Sign-On (SSO), falls Sie es nutzen.
2. Ticketerstellung über das Self-Service-Portal und per Formular.
3. E-Mail-Empfänger: Senden Sie eine Test-E-Mail und prüfen Sie, ob daraus ein Ticket wird.
4. Benachrichtigungen: Prüfen Sie, ob GLPI weiterhin E-Mails versendet.
5. Automatische Aktionen: Prüfen Sie unter Einstellungen > Automatische Aktionen, ob die Aufgaben weiterhin laufen.
6. API und Integrationen: Inventar der Agenten, Chatbots, ERP und Automatisierungen, die GLPI aufrufen.
7. Plugins: Öffnen Sie die Seiten der Plugins, die Ihr Team am häufigsten nutzt.

Und wenn ein Update jetzt nicht möglich ist?

• Nehmen Sie GLPI bis zur Korrektur aus dem Internet. Erlauben Sie den Zugriff nur über interne Netze oder per VPN. Wenn das Self-Service-Portal offen bleiben muss, ist es die oberste Priorität des Updates und kein Grund, es aufzuschieben.
• Beschränken Sie, was offen bleiben muss, vor PHP. Setzen Sie die Beschränkung in der Firewall oder im Webserver um (allow/deny in Nginx, Require ip in Apache), niemals in den Optionen von GLPI selbst, die erst nach PHP greifen. Und bedenken Sie: Nur Inventar und API zu beschränken hilft wenig, wenn die Anmeldeseite offen bleibt.
• Schalten Sie den Upload-Fortschritt der Sitzung ab (session.upload_progress.enabled = Off), wie von PHP empfohlen. Dies schließt CVE-2026-115560 und verringert die Angriffsfläche für CVE-2026-109619, ersetzt aber nicht die Aktualisierung.
• Nutzen Sie eine Web Application Firewall (WAF) als Überbrückung. Cloudflare hat erste Regeln für die bekannten Angriffsvektoren veröffentlicht. Dies hilft, korrigiert aber nicht: AWS selbst hat darauf hingewiesen, dass keine Konfigurationsänderung eine vollständige Abhilfe darstellt. Die Regeln gelten auch im kostenlosen Plan von Cloudflare.
• Erhöhen Sie die Wachsamkeit. Achten Sie auf PHP-Prozesse, die eine Shell öffnen oder Dateien herunterladen – genau dieses Signal sollen Sie laut CISA überwachen.

Schritt 4: Prüfen Sie, ob bereits jemand eingedrungen ist

Zunächst eine Entwarnung: Eine angreifbare Version betrieben zu haben, beweist nicht, dass es einen Einbruch oder ein Datenleck gab. Es ist nur der Anlass, genauer hinzusehen. Der älteste registrierte Versuch stammt vom 17. Oktober. Wenn Ihr GLPI in diesem Zeitraum mit angreifbarem PHP erreichbar war, lohnt sich nach der Korrektur eine kurze Prüfung. Keiner dieser Befehle verändert etwas.

PHP-Dateien, wo keine sein sollten. Der Datenordner von GLPI enthält Anhänge, Bilder und temporäre Dateien; dort sollten keine .php-Dateien entstehen, mit Ausnahme des Caches (_cache) und der Klassen, die von Plugins wie Zusätzliche Felder (Fields) und GenericObject in files/_plugins/fields und files/_plugins/genericobject erzeugt werden. Diese erscheinen im Ergebnis und sind zu erwarten, wenn die Daten zu Änderungen passen, die Sie selbst vorgenommen haben:

sudo find /var/lib/glpi/files /var/www/glpi/files -name '*.php' -not -path '*/_cache/*' 2>/dev/null
sudo find /var/www/glpi -type f -name '*.php' -newerct '2026-10-15' -not -path '*/files/_cache/*' 2>/dev/null

Die zweite Suche verwendet das Änderungsdatum der Datei im System (ctime), welches ein Angreifer nicht mit touch verschleiern kann. Passen Sie die Pfade an Ihre Installation an. Dateien von Plugins und von GLPI, die Sie im Zeitraum selbst aktualisiert haben, sind zu erwarten; bedenklich ist, woran sich niemand erinnert, es dort abgelegt zu haben.

Prozesse und Verbindungen des Webserver-Benutzers:

ps -eo user,pid,ppid,lstart,cmd | grep -E '^(www-data|apache|nginx)' | grep -Ev 'php-fpm|apache2|httpd|nginx'
sudo ss -tnp | grep -E 'php|apache|httpd|"(sh|bash|dash|nc|ncat|perl|python[0-9.]*)"'
sudo crontab -u www-data -l

Unter Red Hat heißt der Benutzer apache (crontab -u apache -l). Der Webserver-Benutzer sollte weder sh, bash, curl, wget noch nc ausführen und keine geplanten Aufgaben haben, die Sie nicht angelegt haben (die Aufgabe für cron.php von GLPI ist legitim). Seien Sie misstrauisch bei ausgehenden Verbindungen zu IPs, die weder zur Datenbank, zu LDAP, zu SMTP noch zu Ihren Integrationen gehören.

Neue Konten und Plugins in GLPI. Fügen Sie unter Verwaltung > Benutzer die Spalte Erstellungsdatum hinzu (Spaltensymbol), sortieren Sie danach und prüfen Sie, ob seit dem 17. Oktober ein unbekanntes Konto aufgetaucht ist, insbesondere mit dem Profil Super-Admin. Prüfen Sie auch Verwaltung > Profile (Änderungen an Berechtigungen), Einstellungen > Plugins (ein Plugin, welches Sie nicht installiert haben?) und die API-Clients.

Logs des Webservers und von PHP. Spitzen ungewöhnlicher Anfragen von unbekannten IPs, gefolgt von 500-Fehlern, verdienen Aufmerksamkeit, vor allem bei den URLs aus der obigen Tabelle. Im Log von PHP-FPM lohnen auch Folgen von „Allowed memory size exhausted“ und durch ein Signal beendete Prozesse (zum Beispiel „exited on signal 11“) einen Blick.

Wenn Sie Anzeichen eines Einbruchs finden

1. Isolieren Sie den Server vom Netz, ohne ihn auszuschalten, um Beweise zu sichern.
2. Sichern Sie die Logs und eine Kopie der Festplatte, bevor Sie irgendetwas bereinigen.
3. Bauen Sie das System auf einer sauberen Basis neu auf und stellen Sie die Daten aus einem Backup von vor dem Einbruch wieder her, wobei Sie prüfen, was nach diesem Datum neu erfasst werden muss. Nur die gefundene Datei zu entfernen garantiert nicht, dass keine weitere Hintertür geblieben ist.
4. Tauschen Sie alle Geheimnisse aus, die der Server gespeichert hatte – erst nach Isolierung und Neuaufbau. Ist der Angreifer noch in der Umgebung, gelangen die neuen Passwörter zusammen mit den alten in seine Hände. Die Reihenfolge lautet: eindämmen, bereinigen und erst dann austauschen:
5. das Datenbankpasswort, welches in config/config_db.php liegt (oder in /etc/glpi/ bei Paketinstallationen);
6. den Schlüssel glpicrypt.key, der die in GLPI gespeicherten Passwörter schützt: Erzeugen Sie einen neuen mit php bin/console glpi:security:change_key, welches die Daten neu verschlüsselt (die Datei von Hand auszutauschen macht die Geheimnisse unlesbar), und tauschen Sie danach die Passwörter selbst aus: E-Mail-Empfänger, LDAP-Lesekonto, SMTP und Proxy;
7. die Passwörter der lokalen Administratoren von GLPI, weil die Hashes in der Datenbank lagen;
8. die API-Tokens (von Anwendungen und Benutzern) und die OAuth-Secrets;
9. die Zugangsdaten der Integrationen, die GLPI aufruft (ERP, Chatbot, Automatisierungen).
10. Prüfen Sie die Meldepflichten: Wenn auf personenbezogene Daten zugegriffen worden sein könnte, beziehen Sie den Datenschutzbeauftragten (DPO) und die Rechtsabteilung ein. Das brasilianische Datenschutzgesetz LGPD (Art. 48) sieht eine Meldung an die ANPD und an die Betroffenen vor, wenn der Vorfall ein erhebliches Risiko oder einen erheblichen Schaden verursachen kann, und die Verordnung der ANPD legt dafür eine kurze Frist fest.

PHP 8.1 oder älter: Das Problem ist größer

PHP 8.1 und ältere Versionen werden vom PHP-Projekt nicht mehr unterstützt und erhalten daher keine offizielle korrigierte Version. Das PHP-Team selbst hat minimale Korrekturen im Quellcode für 7.4, 8.0 und 8.1 veröffentlicht: Wer PHP selbst kompiliert, kann sie anwenden; alle anderen sind darauf angewiesen, dass ihr Anbieter oder ihre Distribution ein Paket veröffentlicht. PHP 5 und 7.0 bis 7.3 haben überhaupt keine Korrektur (dies betrifft alle, die noch GLPI 9.5 betreiben). Unter Ubuntu 22.04 etwa wird PHP 8.1 von Canonical selbst gepflegt: USN-8948-1 vom 21.10. enthält bereits die Korrektur. Auch sury und das PPA ondrej/php pflegen Pakete von 7.4 bis 8.1; prüfen Sie, ob sie die Korrektur bereits enthalten. Läuft GLPI bei einem Managed Hoster, fordern Sie dort ein Paket mit der Korrektur beider Schwachstellen oder einen vorrangigen Migrationsplan auf eine unterstützte Version mit Termin an.

Wer noch PHP 8.1 betreibt, ist meist auch noch auf GLPI 10, welches mit dem Erscheinen von GLPI 12 den Support verloren hat. GLPI 11 verlangt PHP 8.2 oder neuer, GLPI 12 verlangt 8.3. Wenn dies auf Sie zutrifft, sind die Korrektur dieser Schwachstelle und der Abschied von GLPI 10 zu einem einzigen Projekt geworden: Lesen Sie die Risiken eines Verbleibs auf GLPI 10 und den Fahrplan für die Migration.

Nach der Korrektur: Machen Sie den nächsten Schreck kleiner

• Nehmen Sie vom Netz, was nicht im Internet sein muss. Inventar nur von den IPs der Agenten, API nur von den Servern, die sie nutzen, Administrationsbereich nur über VPN – immer mit der Regel in der Firewall oder im Webserver.
• Verbergen Sie die PHP-Version. Mit expose_php = Off in der php.ini gibt der Server die Version nicht mehr im Antwort-Header preis. Dies verringert automatisierte Scans, schützt aber nicht: Der Angriff hängt nicht davon ab, die Version zu kennen.
• Schalten Sie die automatischen Sicherheitsupdates der Distribution ein und denken Sie daran, dass sie weder Drittanbieter-Repositorys noch Docker-Images abdecken.
• Halten Sie ein getestetes Backup bereit von der Datenbank und vom Dateiordner von GLPI. Die Wiederherstellung ist der Plan B bei jeder kritischen Schwachstelle.
• Behalten Sie die Schwachstellen Ihrer Umgebung im Blick. CVE Scan ist kostenlos: Es prüft die Version von GLPI und PHP, die Sicherheits-Header und die Berechtigungen und zeigt, was zuerst korrigiert werden sollte.

Zeitleiste

Checkliste für heute

1. Alle Server mit PHP auflisten, nicht nur den von GLPI (das Inventar von GLPI hilft dabei).
2. Die Version unter Einstellungen > Allgemein > System und das Paket auf dem Server prüfen.
3. Aktualisieren, beginnend mit allem, was im Internet erreichbar ist.
4. PHP-FPM oder Apache neu starten und erneut prüfen.
5. Wenn ein Update heute nicht möglich ist, vom externen Zugriff trennen.
6. Die Prüfungen auf einen Einbruch durchführen und die Ergebnisse aufbewahren.
7. Inventar, API und Administrationsbereich auf das Nötige beschränken.
8. session.upload_progress.enabled in der php.ini oder im Pool von PHP-FPM abschalten, neu starten und prüfen.

Brauchen Sie Hilfe beim Update des GLPI-Servers oder bei der Überprüfung der Angriffsfläche Ihrer Umgebung? Sprechen Sie mit uns.

Quellen: Sicherheitshinweise von PHP vom 21. und 23.10.2026, Warnung der CISA (21.10.2026), offizieller Changelog von PHP (php.net), Sicherheitsbulletin von AWS, Bericht von Help Net Security über PHP2Shell, FAQ von watchTowr, Hinweis von Ubuntu (USN-8948-1), Security Tracker von Debian und Hinweis von Mercado Pago an Entwickler (21.10.2026). GLPI ist eine eingetragene Marke von Teclib'. NexTool ist nicht mit Teclib' verbunden.