FrankenPHP 1.13.2 wurde am 21. Oktober 2026 veröffentlicht. Die Docker-Images enthalten nun PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Statische Binärdateien verwenden PHP 8.5.12. Diese Versionen beheben PHP2Shell mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Die beiden kritischen Lücken ermöglichen nicht authentifizierte Remotecodeausführung. Laut Release-Hinweisen gibt es außer dem Upgrade keine vollständige Gegenmaßnahme.

Vier weitere Schwachstellen in FrankenPHP sind geschlossen. Eine als hoch eingestufte Lücke bei der Extraktion eingebetteter Anwendungen wurde als GHSA-6q3j-62j9-f9hh erfasst. Ein lokaler Benutzer konnte ein vorhersehbares Verzeichnis im gemeinsam genutzten temporären Bereich anlegen und den Dienst dadurch zur Ausführung eigenen PHP-Codes bringen. FrankenPHP extrahiert Anwendungen jetzt atomar in ein benutzerspezifisches Verzeichnis. Ein vorhandenes Verzeichnis wird nur wiederverwendet, wenn es dem aktuellen Benutzer gehört.

Wartende Anfragen werden verworfen, sobald der Client die Verbindung trennt. Zuvor konnte ein nicht authentifizierter Client den Thread-Pool auslasten, indem er Anfragen einreihte und die Verbindung schloss. Diese Lücke trägt die Kennung GHSA-fq24-r53r-xcx3.

Selbstreferenzierende PHP-Arrays werden bei der Umwandlung in Go-Werte jetzt abgelehnt. Zuvor konnte ein solches Array, das an `frankenphp_log()` übergeben, von einem Worker-Callback zurückgegeben oder über die Extension-API eingespeist wurde, einen Stack-Überlauf und den Absturz des Prozesses auslösen. Die Kennung lautet GHSA-ccgp-ch9h-533f. Im Worker-Modus werden `error_get_last()` und `libxml_get_errors()` nach jeder Anfrage geleert. Dadurch gelangen keine Teile der Eingabe eines vorherigen Clients oder Serverpfade in die nächste Anfrage. Dieser Fehler ist als GHSA-4gfw-9v29-gp9h dokumentiert.

`frankenphp_log()` und die Konstanten `FRANKENPHP_LOG_LEVEL_*` stehen jetzt auch in `php-cli` zur Verfügung. Die Einträge verwenden das Serverformat und werden nach stderr geschrieben. Bei der CLI-Ausführung wird das Caddyfile nicht geladen, daher gelten dessen Logging-Direktiven dort nicht. Die Extension-Funktion `frankenphp_thread_index()` ist für C-Extensions wie `frankenstate` und `frankenasync` wieder exportiert.

Statische Builds verwenden jetzt static-php-cli v3. Für macOS werden Binärdateien nur noch für Apple Silicon veröffentlicht. Das Asset `frankenphp-mac-x86_64` entfällt deshalb. Auf Intel-Macs muss mit `build-static.sh` aus dem Quellcode gebaut werden. Die `-gnu`-Binärdatei verlangt nun glibc 2.28 oder neuer, statt 2.17.

Statische Builder-Images erhalten `PHP_EXTENSIONS`, `PHP_EXTENSION_LIBS`, `XCADDY_ARGS` und weitere Optionen nun als Umgebungsvariablen für `docker run`. Docker-Build-Argumente werden dafür nicht mehr verwendet. Die Binärdatei landet im eingebundenen Verzeichnis `/output`, und die Standardwerte stehen in `craft.yml`. Die Dokumentation für statische Builds wurde entsprechend angepasst.

Bei aktiviertem `hot_reload` setzt FrankenPHP `opcache.revalidate_freq` nun standardmäßig auf 0. Damit soll verhindert werden, dass nach einer Änderung eine veraltete Seite ausgeliefert wird. Werte aus `php.ini`, `PHP_INI_SCAN_DIR` oder der Direktive `php_ini` haben weiterhin Vorrang. Caddy verarbeitet Thread- und Anfragegrenzen jetzt als Integer. Auf `linux/386`, `linux/arm/v6` und `linux/arm/v7` führen Werte außerhalb des Bereichs zu einem Fehler, statt zu einer negativen Zahl überzulaufen. `max_threads 4294967295` bedeutet daher nicht mehr automatische Skalierung.

Der Header `types.h` für statische Builds heißt jetzt `frankenphp_types.h`, weil ein gleichnamiger libwebp-Header den Build stören konnte. Die Dokumentation beschreibt nun Mercure-Updates aus `php-cli` über den POST-Endpunkt des Hubs. Sie erklärt außerdem, warum die Erkennung von `mercure_publish()` während des Aufwärmens des Caches die Funktion auch im Webserver deaktiviert.

Enthalten ist außerdem eine Korrektur der russischen Übersetzung. Erste Beiträge kamen von @chubakur in #2712 und @zaccesss in #2726. @nickchomey trug in #2717 erstmals bei, @sergehardy in #1926.