PHP veröffentlichte am 21. Oktober 2026 Notfallkorrekturen für CVE-2026-109618 und CVE-2026-109619. Beide kritischen Speicherfehler haben einen CVSS-v4.0-Wert von 9.2. Sie ermöglichen unauthentifizierte Remotecodeausführung auf PHP-Installationen, die Webanfragen verarbeiten. Dazu zählen PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Bei mod_php ist das Risiko besonders hoch, weil der Exploit vor dem Start des Anwendungscodes greift.

<agent_config>
  <localfile>
    <log_format>full_command</log_format>
    <command>ps -u www-data -o comm=,args= 2>/dev/null | grep -Ev '^(php-fpm|php-fpm[0-9.]+|apache2|htcacheclean|nginx) ' | grep -Ev 'front/cron\.php' || true</command>
    <alias>web-children</alias>
    <frequency>60</frequency>
  </localfile>
  <syscheck>
    <directories realtime="yes" check_all="yes" restrict=".php$|.php5$|.php7$|.phtml$|.phar$|.inc$">/var/www</directories>
    <ignore type="sregex">/cache/|/_cache/|/sessions/|/_sessions/|/_tmp/|/_log/|/wp-content/upgrade/</ignore>
  </syscheck>
</agent_config>

Die korrigierten PHP-Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Linux-Distributionen stellten am selben Tag eigene Pakete bereit. Für PHP 8.1 und ältere Versionen gibt es keine offizielle Korrektur. Bereits laufende Worker müssen nach dem Update trotzdem neu gestartet werden, darunter php-fpm und der Webserver.

Der unabhängige Community-Beitrag beschreibt drei lokale Wazuh-Regeln und eine Agentengruppe für die Zeit zwischen Veröffentlichung und vollständigem Patch-Einsatz. Der Aufbau wurde in einer Produktionsumgebung getestet. Den Exploit selbst kann er nicht zuverlässig erkennen, weil beide Schwachstellen vor der Anwendung arbeiten und keine verlässliche Spur in den Anwendungslogs hinterlassen. Stattdessen überwacht der Ansatz Prozesse, die vom Webbenutzer gestartet werden, sowie danach angelegte oder veränderte PHP-Dateien. Er soll jede Remotecodeausführung auf einem PHP-Webserver abdecken, nicht nur diese beiden CVEs.

Am 21. Oktober führte Wazuh CTI noch keines der beiden CVEs. Die Vulnerability Detection hätte betroffene Agents deshalb nicht gemeldet. NVD hatte beide Einträge an diesem Tag veröffentlicht. Ubuntu führte USN-8948 für php8.3 in Version 8.3.6-0ubuntu0.24.04.13 auf Ubuntu 24.04. Debian verwies für trixie und bookworm auf DSA-6574-1 und DLA-4848-1. Bullseye mit PHP 7.4 blieb ohne Fix. In CISA KEV war keines der beiden CVEs aufgeführt. Bestätigte Indicators of Compromise gab es nicht, allerdings kursierte ein ungeprüfter Proof of Concept, der Schadsoftware enthalten könnte.

Für den Wazuh-Aufbau kommen nur PHP-Server in eine Agentengruppe wie web_php. Zentrale Befehle müssen mit logcollector.remote_commands=1 erlaubt werden, anschließend ist der Agent neu zu starten. Die Gruppenkonfiguration fragt alle 60 Sekunden Prozesse des Benutzers www-data ab. Sie filtert normale Prozesse von php-fpm, Apache, htcacheclean und nginx sowie im Beispiel den Job front/cron.php heraus. Die File Integrity Monitoring-Funktion überwacht /var/www in Echtzeit auf Dateien mit den Endungen .php, .php5, .php7, .phtml, .phar und .inc. Cache-, Session-, temporäre und Log-Verzeichnisse sowie WordPress-Upgrade-Verzeichnisse werden ausgeschlossen.

Pfade und Benutzerkonten müssen an die Umgebung angepasst werden. Debian und Ubuntu verwenden häufig www-data, RHEL-Derivate dagegen apache oder nginx. Legitime Jobs unter dem Webkonto müssen aus dem Prozessfilter herausgenommen werden. Anwendungen können PHP außerhalb von /var/www ausliefern, etwa das Zabbix-Frontend unter /usr/share/zabbix. Wazuh folgt bei dieser Überwachung keinen symbolischen Links, daher muss das Zielverzeichnis direkt überwacht werden.

Die lokalen Regeln verwenden die deploymentspezifischen IDs 100972, 100973 und 100976. Neue IDs sollten aus dem freien lokalen Bereich 100000 bis 120000 stammen. Regel 100972 mit Level 12 sucht in der Ausgabe web-children nach Shells, Download-Werkzeugen, Netzwerkprogrammen, Skriptlaufzeiten und ähnlichen Befehlen. Sie ordnet die Aktivität den MITRE-ATT&CK-IDs T1190, T1059.004 und T1505.003 zu. Regel 100973 mit Level 12 meldet eine neue PHP-Datei unter /var/www und verwendet T1505.003. Regel 100976 mit Level 8 meldet eine geänderte Datei dieser Typen. Die Verantwortlichen sollen prüfen, ob ein Update die Änderung erklärt.

Vor einem Neustart sollte die Konfiguration mit GET /cluster/configuration/validation oder wazuh-analysisd -t geprüft werden. Die Verzeichnisse in den Regeln müssen zu den Pfaden in agent.conf passen. Fünf Details führen laut Beitrag besonders häufig zu Problemen. Das Attribut restrict und das Ignore-Muster mit sregex sind keine PCRE-Ausdrücke. Gruppierte Muster können deshalb still scheitern; Alternativen müssen mit | getrennt werden. $(agent.name) wird in einer Regelbeschreibung nicht ersetzt. Der erste Scan erstellt die Baseline, daher lösen Dateien, die vorher angelegt wurden, keinen Alarm aus. Ohne aktivierte Remote-Befehle ignoriert der Agent den Gruppenbefehl. In unprivilegierten LXC-Containern funktioniert Echtzeit-FIM über inotify, auditd jedoch nicht. Für execve-Auditing auf dem Host muss die gemappte UID verwendet werden, etwa 100033 statt 33.

Alarme 100972 und 100973 sollten zunächst als möglicher Sicherheitsvorfall gelten. In full_log ist zu prüfen, welcher Prozess mit welchen Argumenten lief. Relevante Muster sind etwa curl mit Weiterleitung an bash, /dev/tcp, nc -e und mkfifo. Ein unbekannter Prozess sollte über WAF oder Firewall isoliert werden. Vor einem Neustart sind Webserver- und PHP-Logs, ps -ef, ss -tnp sowie ein Snapshot der VM oder des Containers zu sichern. Die Suche nach Persistenz umfasst neue PHP-Dateien, die Crontab des Webbenutzers, neue Konten und SSH-Schlüssel. Ein bestätigter Einbruch sollte der zuständigen nationalen Cybersicherheitsbehörde gemeldet werden.

Bei einer neuen PHP-Datei sollte der Anwendungsverantwortliche bestätigen, ob ein Update sie erzeugt hat. Falls nicht, sollte die Datei auf eval, base64_decode, system, shell_exec und eine Ausführung über $_POST geprüft werden. Sie sollte dabei nicht im Browser geöffnet werden. Erwartbare Fehlalarme sind Cronjobs der Anwendung unter dem Webkonto, PHP mail(), das sh -c sendmail aufruft, sowie CMS- und Plugin-Updates mit zahlreichen Alarmen der Regel 100976.

Für die Prüfung muss group_config_status = synced anzeigen, dass die Gruppenkonfiguration synchronisiert ist. Außerdem muss ossec.log die Echtzeitüberwachung des Zielverzeichnisses bestätigen. In logtest sollte ein Ereignis mit log_format = full_command und location = web-children die Regel 100972 auslösen, wenn es eine Shell enthält. Eine leere Prozessliste sollte dagegen bei Level 0 bleiben. Für einen Ende-zu-Ende-Test kann ein harmloser Befehl unter dem Webkonto länger als das 60-Sekunden-Intervall laufen. Zusätzlich wird eine leere .php-Datei im Webroot angelegt. Danach sind Dashboard, E-Mail oder SOAR auf den Eingang der Alarme zu prüfen und die Testzeit zu dokumentieren.

Die Prozessabfrage erfolgt nur einmal pro Minute. Befehle, die innerhalb weniger Sekunden enden, können daher unentdeckt bleiben. Für eine umfassendere Abdeckung ist auditd auf dem Host erforderlich. Unter IIS entsprechen w3wp.exe oder php-cgi.exe, die cmd.exe oder powershell.exe starten, dem relevanten Signal. Dafür werden Sysmon oder Windows-Ereignis 4688 mit aktivierter Kommandozeilenprotokollierung benötigt.

Patchen und Neustarten bleiben die wichtigsten Maßnahmen. Ein neu installiertes Paket repariert bereits laufende Worker nicht. Für PHP 7.4 bis 8.1, wo kein offizieller Fix verfügbar ist, sollten betroffene Dienste aus dem Internet genommen werden. Als teilweise Gegenmaßnahmen nennt der Beitrag session.upload_progress.enabled=0 und memory_limit=-1 über php_admin_*-Einstellungen. Zusätzlich empfiehlt er, WAF-Routing und SNI-Filter zu prüfen. Eine Anfrage mit dem SNI einer öffentlichen Website und dem Host-Header einer internen Website kann sonst die interne Website erreichen. Anfragen aus externen Netzen für nicht öffentliche Namen sollten am WAF blockiert werden.

Als Quellen werden das PHP News Archive 2026, das GitHub-Advisory GHSA-w8hw-w9fx-j79w zu CVE-2026-109618, die Ubuntu-Seite zu CVE-2026-109618, der Debian Security Tracker sowie Reaktionsberichte von Huntress und Tenable genannt. Die Regeln sind ein unabhängiger Community-Beitrag. Wazuh Inc. hat sie weder geprüft noch validiert oder freigegeben. Sie gehören nicht zum offiziellen Wazuh-Regelwerk und müssen vor dem Einsatz in der Produktion in der eigenen Umgebung getestet werden.