--- title: "PHP2Shell: von verwundbaren PHP-Versionen zu einem prüfbaren Pull Request mit Harbyn | Harbyn" description: "Ein öffentlicher Harbyn-Scan, von den PHP2Shell-Funden bis zu einem echten Update-PR: exakte Versions-Pins, flexible Tags und die Entscheidungen, die beim Review bleiben." canonical: "https://harbyn.com/de/blog/php2shell-production-runtime" last-updated: 2026-10-22 --- # PHP2Shell: von verwundbaren PHP-Versionen zu einem prüfbaren Pull Request mit Harbyn Veröffentlicht am 22. Oktober 2026 von Harbyn. Schlagwörter: php, security, php2shell, developer-tools. Wenn ein kritisches PHP-Update erscheint, ist die Ankündigung erst der Anfang. Die nächste Frage betrifft Ihr Projekt: Wo ist die betroffene Version festgelegt, und was muss sich ändern? PHP2Shell lieferte dafür ein konkretes Beispiel. Wir haben Harbyn auf ein öffentliches Demo-Repository angesetzt, das PHP-Versionen auf mehrere Arten festlegt. Der Scan meldete sechs Funde in elf Dateien, und Harbyn öffnete einen Pull Request, der zwei exakte Versions-Pins aktualisiert. Sie können die [Ausführung des Scans](https://github.com/harbyn/php2shell-demo/actions/runs/39718957930) und den [tatsächlichen Pull Request](https://github.com/harbyn/php2shell-demo/pull/1) ansehen. Hier steht, was passiert ist und wie Sie denselben Ablauf in Ihrem eigenen Repository ausprobieren. ## Was bei PHP2Shell passiert ist Am 21. Oktober 2026 veröffentlichte PHP Korrekturen für zwei kritische Sicherheitslücken, CVE-2026-109618 und CVE-2026-109619, die Codeausführung aus der Ferne ohne Authentifizierung ermöglichen können. Die korrigierten Versionen sind **8.2.35, 8.3.36, 8.4.27 und 8.5.12**. Siehe die [offizielle Sicherheitsmeldung von PHP](https://www.php.net/archive/2026.php#2026-10-21-5). Für ein Entwicklungsteam heißt das, die im Repository verteilten PHP-Angaben zu finden. Die Laufzeit kann in einem Dockerfile festgelegt, in Compose referenziert, in einem Workflow konfiguriert oder in den Composer-Einstellungen abgebildet sein. Diese Angaben bedeuten nicht alle dasselbe, also sollten sie auch nicht alle dieselbe Änderung bekommen. ## Die Demo: sechs Funde, ein prüfbarer PR Unser [Demo-Repository](https://github.com/harbyn/php2shell-demo) ist eine kleine, fiktive PHP-Anwendung, die für diese Demonstration erstellt wurde. Es enthält exakte Versions-Pins, flexible Versionen, eine Composer-Anforderung und ein PHP-8.1-Image. Mit Harbyn hat die GitHub Action elf Dateien gescannt und sechs Zeilen gemeldet, die Aufmerksamkeit brauchen. Danach öffnete Harbyn einen PR für die unterstützten Updates. So entsteht ein nachvollziehbarer Weg von der Sicherheitsmeldung zu den Angaben im Repository und zu den vorgeschlagenen Änderungen. Der Beleg steht im Ausführungsprotokoll und im Diff, nicht in einem illustrierenden Terminal-Screenshot. ## Warum die Funde zu unterschiedlichen Schritten führten Die sechs Funde waren nicht sechs gleiche Korrekturen: | Angabe in der Demo | Was zu tun ist | | --- | --- | | Zwei exakte PHP-Versions-Pins | Auf das korrigierte Patch-Release desselben PHP-Zweigs aktualisieren. | | Zwei flexible Versionen | Die betroffene Umgebung neu bauen oder aktualisieren und die tatsächlich genutzte Laufzeit prüfen. | | Eine PHP-Anforderung in Composer | Kompatibilitätsanforderungen getrennt vom installierten Interpreter prüfen. | | Ein PHP-8.1-Image | Den Wechsel auf einen unterstützten Zweig bewerten, einschließlich der Kompatibilität der Anwendung. | Ein flexibler Tag wie `php:8.3-fpm` kann unverändert bleiben, während noch ein älteres Image läuft. Im Dockerfile gibt es dann womöglich keine Versionsangabe zu ersetzen; die Arbeit liegt darin, ein korrigiertes Image zu beziehen und auszurollen. Ältere PHP-Zweige brauchen ebenfalls eine eigene Entscheidung. Der Wechsel einer Anwendung von PHP 8.1 auf einen unterstützten Zweig kann die Kompatibilität betreffen. Pakete von Distributionen oder mit erweitertem Support können die Korrekturen per Backport enthalten, prüfen Sie also die Sicherheitsmeldung der Pakete, die Sie tatsächlich nutzen. Die [PHP-Meldung](https://www.php.net/archive/2026.php#2026-10-21-5) geht auf diese Optionen ein. ## Im Pull Request Der [erzeugte PR](https://github.com/harbyn/php2shell-demo/pull/1) enthält zwei gezielte Änderungen. Im `Dockerfile` aktualisiert er das PHP-Basis-Image: ```diff -FROM php:8.3.35-fpm +FROM php:8.3.36-fpm ``` In `composer.json` aktualisiert er `config.platform.php`: ```diff - "php": "8.3.35" + "php": "8.3.36" ``` Die zweite Änderung braucht eine Erklärung. Die Plattform-Einstellung von Composer sagt der Abhängigkeitsauflösung, welche PHP-Version sie annehmen soll. Sie installiert oder aktualisiert PHP nicht. Wird sie zusammen mit dem Dockerfile aktualisiert, passt diese Annahme zur vorgesehenen Laufzeit. Siehe [die Composer-Dokumentation zu Plattform-Abhängigkeiten](https://getcomposer.org/doc/articles/composer-platform-dependencies.md). Der PR bündelt die vorgeschlagenen Änderungen für das Review. Danach baut das Team noch das aktualisierte Image, rollt es aus, ersetzt alte Instanzen und prüft die Laufzeit, die tatsächlich Anfragen beantwortet. Erst so erreicht die Änderung im Repository die Anwendung. ## Harbyn im eigenen Repository ausprobieren Führen Sie im Verzeichnis Ihres Repositorys aus: ```sh npx harbyn scan ``` Der Scanner läuft lokal, lädt den signierten Änderungs-Feed von Harbyn und prüft die unterstützten Angaben, ohne Ihren Quellcode hochzuladen. Prüfen Sie die gemeldeten Dateien, Zeilen und Quellen. Wie Sie den PR-Ablauf einrichten, steht in der [Harbyn-Dokumentation](https://harbyn.com/docs). PHP2Shell ist ein Beispiel für das Problem, bei dem Harbyn Entwicklern hilft: Eine externe Änderung wird für eine bestimmte Zeile in einem Repository relevant. Harbyn verbindet diese Änderung mit dem Code und bereitet, wo es eine unterstützte Korrektur gibt, das Update für das Review vor. [Scannen Sie Ihr Projekt](https://harbyn.com), oder sehen Sie sich zuerst den [öffentlichen PHP2Shell-PR](https://github.com/harbyn/php2shell-demo/pull/1) an.