Scanner und KI-Agenten stuufen gepatchte PHP-Server teils falsch als verwundbar ein
Nach der PHP2Shell-Veroeffentlichung mit CVE-2026-109618 und CVE-2026-109619 pruefen viele Nutzer ihre Server mit Scannern oder KI-Agenten. Auf manchen Systemen faellt das Ergebnis falsch aus, in beide Richtungen.
Nach der Veroeffentlichung von PHP2Shell (CVE-2026-109618 und CVE-2026-109619, php.net-Hinweis vom 21. Oktober 2026) haben viele Menschen einen Scanner ausgefuehrt oder einen KI-Agenten gefragt, ob ihre Server gefixt sind. Auf manchen Systemen faellt die Antwort in beide Richtungen falsch aus.
Offenlegung: Wir betreiben php2shell.fyi, einen passiven Checker fuer PHP2Shell.
Das PHP-Projekt hat die Schwachstellen in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 behoben. Einige Distributionen haben den Fix in die Version eingebaut, die sie bereits ausliefern, und dabei die alte Upstream-Versionsnummer beibehalten:
Ein Werkzeug, das nur 8.3.6 liest und sie mit 8.3.36 vergleicht, meldet "verwundbar". Die ProjectDiscovery-Nuclei-Vorlage fuer CVE-2026-109618 tut dies in ihrem Versions-Fallback, und der Assetnote-Scanner macht dasselbe, wenn er kein Absturzsignal sieht. Manche Community-Agent-Skills machen das Gleiche mit sort -V.
Nicht jede Distribution macht das. Debian, Alpine, die RHEL-Module und RHEL 10 liefern die neuen Upstream-Versionsnummern aus, zum Beispiel Debian 13 8.4.27-1~deb13u1.
Der CVE-Eintrag fuer CVE-2026-109618 listet nur die Zwaige 8.2, 8.3, 8.4 und 8.5 als betroffen und markiert jede andere Version als nicht betroffen (cve.org, abgerufen am 23. Oktober 2026). Ein Scanner, der den Eintrag woertlich liest, kann PHP 8.1 und aelter als "nicht betroffen" einstufen.
Sie sind betroffen. Das PHP-Sicherheitsteam hat Quellcode-Fixes fuer 7.4, 8.0 und 8.1 veroeffentlicht, und die Forscher fanden betroffene Versionen bis zurueck zu PHP 5.4 (php2shell.com).
Lies die Paketversion des PHP aus, das die Website ausliefert, nicht nur php -v:
# Debian und Ubuntu dpkg -l 'php*' | grep '^ii' # RHEL, AlmaLinux, Rocky rpm -qa 'php*' # Alpine und Wolfi apk info -v | grep '^php' Enter fullscreen mode Exit fullscreen mode Vergleiche die vollstaendige Version mit dem gefixten Build aus der Mitteilung deines Anbieters. Unter Debian und Ubuntu erledigt dpkg --compare-versions dies korrekt; auf RPM-Systemen vergleiche innerhalb derselben Release und desselben Streams.
Pruefe dann, ob PHP neu gestartet wurde. Ein installiertes Paket veraendert keine PHP-Prozesse, die bereits laufen:
ps -eo pid,lstart,cmd | grep -i '[p]hp' Enter fullscreen mode Exit fullscreen mode Ein PHP-FPM-, Apache- oder LiteSpeed-Prozess, der vor dem Update gestartet wurde, fuehrt weiterhin den alten Code aus.
Sage dem Agenten, welchen Vergleich er verwenden soll. Zum Beispiel: "Vergleiche die vollstaendige Paketversion mit dem gefixten Build des Anbieters. Vergleiche php -v nicht mit Upstream-Versionsnummern. Wenn du eine Version nicht verifizieren kannst, melde sie als unbekannt." Die Agent-Skills von OpenAI (phpcheck-server), Cognition (fix-php-vuln) und Chainguard funktionieren bereits auf diese Weise.
Die gefixten Builds fuer Ubuntu, Debian, RHEL und Alpine, mit den Links der Anbieter, findest du auf php2shell.fyi/linux.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
After the PHP2Shell release (CVE-2026-109618 and CVE-2026-109619, php.net advisory of 21 October 2026 ), many people ran a scanner or asked an AI agent whether their servers are fixed. On some systems, the answer comes back wrong in both directions.
Disclosure: we run php2shell.fyi, a passive checker for PHP2Shell.
The PHP project fixed the flaws in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Some distributions put the fix into the version they already ship and keep the old upstream number:
A tool that reads only 8.3.6 and compares it with 8.3.36 says "vulnerable". The ProjectDiscovery Nuclei template for CVE-2026-109618 does this in its version fallback, and so does the Assetnote scanner when it sees no crash signal. Some community agent skills do the same with sort -V.
Not every distribution does this. Debian, Alpine, the RHEL modules and RHEL 10 ship the new upstream numbers, for example Debian 13 8.4.27-1~deb13u1.
The CVE record for CVE-2026-109618 lists only the 8.2, 8.3, 8.4 and 8.5 branches as affected, and marks every other version as unaffected ( cve.org, checked 23 October 2026). A scanner that reads the record literally can call PHP 8.1 and older "not affected".
They are affected. The PHP security team published source fixes for 7.4, 8.0 and 8.1, and the researchers found affected releases back to PHP 5.4 ( php2shell.com ).
Read the package version of the PHP that serves the site, not only php -v:
# Debian and Ubuntu dpkg -l 'php*' | grep '^ii' # RHEL, AlmaLinux, Rocky rpm -qa 'php*' # Alpine and Wolfi apk info -v | grep '^php' Enter fullscreen mode Exit fullscreen mode Compare the full version with the fixed build in your vendor's notice. On Debian and Ubuntu, dpkg --compare-versions does this correctly; on RPM systems, compare within the same release and stream.
Then check that PHP restarted. An installed package does not change PHP processes that are already running:
ps -eo pid,lstart,cmd | grep -i '[p]hp' Enter fullscreen mode Exit fullscreen mode A PHP-FPM, Apache or LiteSpeed process that started before the update still runs the old code.
Tell it which comparison to use. For example: "Compare the full package version with the vendor's fixed build. Do not compare php -v with upstream numbers. If you cannot verify a version, report it as unknown." The agent skills from OpenAI ( phpcheck-server ), Cognition ( fix-php-vuln ) and Chainguard already work this way.
The fixed builds for Ubuntu, Debian, RHEL and Alpine, with the vendor links, are on php2shell.fyi/linux.