FrankenPHP 1.12.3 schließt CVE-2026-45062 — Unicode-Pfad-Splitting wird zum RCE-Pfad

TL;DR — die 90-Sekunden-Zusammenfassung

Was ist CVE-2026-45062?

Ein Unicode-Handling-Fehler in der CGI-Pfad-Splitting-Funktion splitPos() von FrankenPHP. Zwei unabhängige Logikfehler erlauben, dass Pfade mit Unicode-Lookalike-Zeichen (z. B. ﹒php, ．php, .ｐhp, .ⓟⓗⓟ, .𝗽𝗵𝗽) auf .php abgebildet werden — obwohl die Zieldatei keine PHP-Datei ist.

Wie ernst?

Schweregrad hoch, CVSS 8.1. Unauthentisierte Code-Ausführung über das Netzwerk, wenn ein Angreifer eine Datei mit Bypass-Namen im FrankenPHP-Webserver-Verzeichnis ablegen kann. Öffentlicher Exploit-Code im Advisory, vollständige Demonstration mit Docker. CVSS-Vektor: AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:H.

Wer ist betroffen?

FrankenPHP-Versionen v1.11.2 bis v1.12.2 einschließlich. Container-Images dunglas/frankenphp:<tag> in diesem Versionsbereich. PHP-Anwendungen, die FrankenPHP als Anwendungs-Server nutzen — typischerweise TYPO3-, Sylius-, Laravel- und Symfony-Stacks im FrankenPHP-Worker-Modus.

Voraussetzung für einen Angriff

Der Angreifer muss eine Datei mit Unicode-Lookalike-Endung (oder einem Non-ASCII-Byte nach einem Punkt) im FrankenPHP-Webserver-Verzeichnis platzieren können. Typische Wege: Datei-Upload-Endpunkte, gemountete Datei-Speicher, Paket-Spiegel, CMS-Datei-Mounts mit Schreibrechten für nicht-vertrauenswürdige Nutzer.

Patch

FrankenPHP 1.12.3 — heute veröffentlicht. Behebung: Der golang.org/x/text/search-Fallback wurde komplett entfernt; jedes Byte mit Wert ≥ utf8.RuneSelf wird als Nicht-Treffer behandelt.

Was wir bei Moselwal getan haben

Alle TYPO3- und Sylius-Container-Images neu gebaut mit FrankenPHP 1.12.3; der Rollout auf Bestandskunden-Hosts läuft seit dem frühen Nachmittag. Das Neustart-Fenster ist kürzer als bei einem Kernel-Patch — nur der FrankenPHP-Worker startet neu, kein Reboot.

 

Was ist das Problem?

FrankenPHP ist ein moderner PHP-Application-Server, der auf Caddy + Go basiert und PHP-Worker direkt im Server-Prozess läuft. Für klassische PHP-FastCGI-Routen (wo der Pfad nach .php auf ein Skript zeigt und alles danach als PATH_INFO dem Skript weitergegeben wird) gibt es eine Hilfsfunktion splitPos() in cgi.go, die den Splitting-Punkt bestimmt.

Die fehlerhafte Funktion

Die Funktion sucht im Request-Pfad nach der eingestellten Split-Endung (typischerweise .php) und gibt die Position des Splits zurück. Für ASCII-only-Pfade läuft das in einer einfachen byte-weisen Schleife. Sobald ein Byte einen Wert ≥ utf8.RuneSelf hat (also der Start eines Multi-Byte-UTF-8-Zeichens ist), wechselt die Funktion in einen Fallback-Pfad mit golang.org/x/text/search und der Flag search.IgnoreCase. Genau dieser Fallback enthält die zwei Bugs.

Flaw 1 — Stale match-Variable

Wenn der inner-loop in einen Non-ASCII-Byte läuft und der Fallback-Search nichts findet, wird mit break aus der inneren Schleife gesprungen — aber die Variable match wird nicht auf false gesetzt. Der outer-code prüft anschließend if match { return i + splitLen } und liefert eine Position zurück, als ob .php matched worden wäre. Die Datei am tatsächlichen Offset ist aber etwas anderes — z. B. name.¡.txt wird als PHP geroutet.

Flaw 2 — Unicode-IgnoreCase-Folding

search.New(language.Und, search.IgnoreCase) macht Unicode-Equivalence-Matching mit Kompatibilitäts-Dekomposition und Case-Folding. Das geht weit über das hinaus, wofür der umgebende Code gebaut ist. Viele Code-Points falten auf ASCII ., p, h:

• ﹒ (small full stop) → .
• ． (fullwidth full stop) → .
• ｐ (fullwidth p) → p
• ⓟⓗⓟ (circled php) → php
• 𝗽𝗵𝗽 (mathematical sans-serif bold php) → php
• 𝓅𝒽𝓅 (mathematical script php) → php

Ergebnis: eine Datei namens shell﹒php wird als shell.php erkannt und an PHP zur Ausführung gegeben. Der Datei-Inhalt darf beliebig sein — PHP interpretiert ihn als Code.

Was den PoC scharf macht

Das Advisory liefert einen kompletten Standalone-Reproducer plus eine end-to-end-Demo mit Docker, drei Caddy-Routen und drei Dateien mit Bypass-Namen. Eine einzelne curl-Anfrage mit URL-Encoded Unicode-Pfad reicht aus, um poc-match-unset.¡. oder poc-search-norm.𝗽𝗵𝗽 als PHP auszuführen. Keine Authentifizierung, kein interaktiver Schritt.

Wer ist betroffen?

Praktisch jedes FrankenPHP-Deployment in der betroffenen Versionsspanne, das eine der drei Vor­dnungen erfüllt — unabhängig vom Betriebsmodus.

Versionsspanne

• Betroffen: FrankenPHP v1.11.2 bis einschließlich v1.12.2. Das umfasst praktisch jedes Release zwischen Sommer 2025 und gestern.
• Nicht betroffen: Versionen ≤ v1.11.1 (der Fehler wurde mit der Pfad-Splitting-Refaktorierung in 1.11.2 eingeführt) und v1.12.3 (heutiger Patch).

Betriebsmodi — nicht nur Docker

FrankenPHP läuft in mehreren Varianten, alle gleichermaßen betroffen:

• Container-Imagesdunglas/frankenphp:<tag> in der genannten Versionsspanne, plus :latest-Tags, die in diesem Zeitraum gezogen wurden — das ist der populärste Verbreitungsweg.
• Eigenständige Binär-Installation (statisches FrankenPHP-Binär aus den GitHub-Releases, typischerweise unter /usr/local/bin/frankenphp), oft als systemd-Service oder direkt aus einer Shell.
• Go-Module-Embedding — FrankenPHP als Bibliothek in einem eigenen Go-Binär eingebettet (github.com/dunglas/frankenphp als Dependency). Hier hängt die Version von der eigenen go.mod-Spezifikation ab.
• Komplexere Plattform-Pakete — NixOS-Module, Debian-/Ubuntu-Drittanbieter-Pakete, eigene RPM-Builds. Hier muss die Paket-Quelle die FrankenPHP-Version dokumentieren.

Drei Risikoprofile

1. Profil A — Datei-Upload-Endpunkte mit Schreibrechten auf das Webserver-Verzeichnis: CMS mit Datei-Upload-Modulen (TYPO3 sys_file, Sylius media), Avatar-Uploads, Anhang-Manager. Direkt exponiert; Patch ist Notfall.
2. Profil B — Externer Datei-Speicher mit öffentlicher Auslieferung aus dem Webserver-Verzeichnis: S3-/MinIO-Buckets, die unter /uploads/ oder vergleichbar gemountet sind. Mittelbar exponiert; Patch innerhalb 24 h.
3. Profil C — Reine Read-Only-Webserver-Verzeichnisse ohne nutzergesteuerte Dateiablage: Statische TYPO3-Frontends, Sylius-Storefronts ohne Datei-Upload. Niedrig exponiert; Patch im nächsten regulären Wartungsfenster.

Warum der Fehler persönlich relevant ist

FrankenPHP ist die Standard-Wahl für moderne TYPO3-, Sylius-, Laravel- und Symfony-Deployments im Worker-Modus — in Containern wie in bare-metal-Setups. Wer im letzten Jahr ein FrankenPHP-Binär aus den GitHub-Releases gezogen oder ein Container-Image dunglas/frankenphp:* verwendet hat, ist mit hoher Wahrscheinlichkeit in der betroffenen Version. Auch ein frankenphp version-Aufruf auf der bare-metal-Installation klärt das in einer Sekunde.

Auswirkungen

Vollständige Code-Ausführung im FrankenPHP-Prozess

Sobald der Angreifer eine Datei mit Bypass-Namen im Web-Root platziert hat, ergibt eine einzelne HTTP-Anfrage Code-Ausführung im FrankenPHP-Prozess. Das ist nicht nur Read-Access — PHP interpretiert den Dateiinhalt mit allen Privilegien, die der FrankenPHP-Prozess hat. Bei den meisten Container-Setups läuft FrankenPHP als www-data oder nobody, aber mit Zugriff auf:

• die TYPO3-/Sylius-Datenbank-Credentials in der .env-Datei
• Session-Tokens und CSRF-Schlüssel aus dem Cache
• Composer-Mirror-Tokens, GitHub-Tokens, API-Keys für Drittanbieter (Mailer, Payment, etc.)
• Schreibrechte auf den gesamten typo3temp/- bzw. var/cache/-Bereich

Container-Escape ist nicht trivial, aber auch nicht ausgeschlossen

Der Bug selbst gibt nur Code-Ausführung im PHP-Kontext. Ein Container-Escape bräuchte einen zusätzlichen Kernel- oder Container-Runtime-Bug. Aber das Zeitfenster zwischen dem ersten Angriff und dem Cleanup ist meist groß genug, dass der Angreifer Persistenz, Datenexfiltration und Lateral Movement durchziehen kann — alles im PHP-Kontext.

Logging schlägt schwach an

Die Bypass-Anfragen sehen für ein klassisches Apache-/Caddy-Access-Log aus wie ganz normale Requests auf existierende Dateien — mit dem Unterschied, dass der Pfad einige Non-ASCII-Bytes enthält. Wer keine spezifische Detection-Regel für Unicode-Lookalike-Pfade hat (siehe unten), sieht in den Logs nichts Auffälliges.

Klassen-Vergleich

Strukturell ist der Bug eine direkte Variante von CVE-2026-24895, die das FrankenPHP-Projekt im März 2026 bereits einmal geschlossen hat — selbe Datei, selber CGI-Path-Splitting-Mechanismus, anderer Bypass-Vektor (damals direktes Path-Confusion, jetzt Unicode-IgnoreCase-Folding). Das deutet darauf hin, dass die Schicht weiter unter externer Audit steht und weitere Befunde möglich sind.

Mitigation und Sofortmaßnahmen

Quick-Start — Container-Image-Update

Der saubere Weg ist FrankenPHP 1.12.3. Für typische Docker-/Compose-Setups:

# 1. Image neu ziehen (FrankenPHP 1.12.3 als Basis)
docker pull dunglas/frankenphp:1.12.3-php8.4-bookworm

# 2. Container-Service neu bauen und starten
docker compose build --pull app
docker compose up -d app

# 3. Verifikation
docker exec <container> frankenphp version
# erwartet: FrankenPHP v1.12.3

Für Custom-Container-Builds mit FrankenPHP als Composer/Go-Dependency:

go get github.com/dunglas/frankenphp@v1.12.3
go mod tidy
# Image neu bauen und ausrollen

Wenn ein sofortiges Image-Update nicht möglich ist

Temporäre Caddy-Side-Mitigation über ein Path-Rewrite, das jeden Request mit Non-ASCII-Bytes im Pfad ablehnt. In der Caddyfile:

:80 {
    @nonascii path_regexp [^\x00-\x7F]
    respond @nonascii 400
    
    root * /app/public
    php_server
}

Das blockiert auch legitime Pfade mit Umlauten oder Akzentzeichen, ist also nur eine Notbremse — nicht eine dauerhafte Lösung. Mit dem 1.12.3-Patch entfällt diese Mitigation.

Vor dem Patch: Upload-Verzeichnisse prüfen

Auch nach dem Image-Update sollten Sie prüfen, ob im Upload-Verzeichnis schon Dateien mit Bypass-Namen liegen. Ein vergiftetes Upload-Verzeichnis bleibt nach dem Patch ungefährlich (die Bypass-Files werden nicht mehr als PHP geroutet) — aber das ist ein Hinweis darauf, dass ein Angriff bereits erfolgt ist:

# Suche nach Dateien mit Non-ASCII-Bytes im Namen im Upload-Verzeichnis
find /var/www/uploads -name '*[\x80-\xff]*php*' -type f
find /var/www/uploads -name '*[\x80-\xff]*' -type f | head -50

Treffer hier deuten auf einen versuchten oder erfolgreichen Exploit hin — forensisch dokumentieren, Datei isolieren, Log-Korrelation auf den Upload-Zeitpunkt fahren.

Detection und Prüfung

Drei Lead-Fragen für die schnelle Triage

1. Welche FrankenPHP-Version läuft? Wenn 1.11.2 ≤ x ≤ 1.12.2, dann ist der Host exposed.
2. Gibt es User-Upload- oder File-Storage-Mounts im Web-Root? Wenn ja, sofortiger Patch.
3. Liegen Dateien mit Non-ASCII-Bytes im Upload-Verzeichnis? Wenn ja, forensisch prüfen.

Versions-Prüfung im laufenden Container

docker exec <container> frankenphp version
# Wenn Output 1.11.2 .. 1.12.2 — Patch nötig

Versions-Prüfung aus dem Image-Tag

docker inspect dunglas/frankenphp:<tag> --format '{{.Config.Labels}}' | grep org.opencontainers.image.version

Logs nach Bypass-Patterns durchsuchen

Im Caddy-/Access-Log nach Requests mit Non-ASCII-Bytes im Pfad oder mit URL-Encoded Sequenzen suchen, die auf typische Bypass-Codepoints zeigen:

# Non-ASCII-Bytes im Pfad (häufige Bypass-Anzeiger)
grep -P 'GET [^ ]*%[CDEF][0-9A-F]%[89AB][0-9A-F]' /var/log/caddy/access.log

# Spezifische Bypass-Codepoints in URL-Encoded Form
# %ef%bc%8e = U+FF0E fullwidth full stop
# %ef%b9%92 = U+FE52 small full stop
# %ef%bd%90 = U+FF50 fullwidth p
grep -E '%ef%bc%8e|%ef%b9%92|%ef%bd%90' /var/log/caddy/access.log

# Mathematical-Bold-PHP: %f0%9d%97%bd = U+1D5FD (𝗽)
grep '%f0%9d%97%bd' /var/log/caddy/access.log

Falco-/eBPF-Detection

Eine Falco-Regel kann die auslösende Sequenz erkennen — ein FrankenPHP-Prozess, der eine Datei mit Non-ASCII-Bytes im Pfadnamen opent, ist ein klares Signal:

- rule: frankenphp_nonascii_php_exec
  desc: FrankenPHP opens file with non-ASCII bytes for PHP execution
  condition: >
    spawned_process and
    proc.name = "frankenphp" and
    fd.name contains "\u00" and
    fd.name endswith ".php"
  output: "FrankenPHP CVE-2026-45062 trigger pattern (fd=%fd.name proc=%proc.pid)"
  priority: CRITICAL

Verifikation des Patches

# Im Container, mit dem PoC aus dem Advisory:
curl -i --path-as-is "http://127.0.0.1:8080/poc-search-norm.%F0%9D%97%BD%F0%9D%97%B5%F0%9D%97%BD.anything-after-payload.php/trigger"
# Vor Patch: 200 OK mit PHP-Marker-Output (Bug aktiv)
# Nach Patch: 404 Not Found (Bug geschlossen)

Betreiberempfehlung

Operativer Entscheidungsblock

Empfehlung nach Setup-Typ

Single-Tenant-TYPO3-Hosting ohne Datei-Upload

Niedriges Risikoprofil, aber CVSS 8.1 heißt auch bei niedrigem Profil: Patch innerhalb 72 h. Die Schwelle für „im nächsten regulären Slot“ liegt bei Medium-CVEs (CVSS < 7) und bei abgeklemmten internen Systemen. Eine High-Severity-CVE rechtfertigt diese Verzögerung nicht — zumal der Wechsel auf 1.12.3 ein 1:1-Ersatz ohne Konfigurationsumstellung ist.

TYPO3 mit aktivem Datei-Upload

Hochrisiko. Update innerhalb 24 h. Bis dahin: Upload-Endpunkte temporär deaktivieren oder Non-ASCII-Pfad-Block via Caddy.

Sylius-Storefront mit Avatar-/Asset-Upload

Hochrisiko, weil Avatar-Upload typischerweise ohne strenge Datei-Endung-Prüfung erfolgt. Update innerhalb 24 h, Avatar-Upload-Endpunkt prüfen, ob er Dateinamen mit Non-ASCII-Bytes durchlässt.

Multi-Tenant-Shared-Hosting mit FrankenPHP

Maximalrisiko. Sofortiges Update auf 1.12.3 plus Caddy-Mitigation als gestaffelte Verteidigung. Jeder Mandant kann den FrankenPHP-Worker für alle anderen kompromittieren.

FrankenPHP hinter Reverse-Proxy mit URL-Normalisierung

Mittleres Risiko. Wenn der vorgelagerte Proxy (NGINX, Cloudflare, AWS ALB) Non-ASCII-Pfade ohnehin ablehnt oder normalisiert, sinkt das Risiko — aber innerhalb 72 h trotzdem patchen. Die Proxy-Schicht ist eine zusätzliche Sicherheitsschicht, kein Ersatz.

Bare-Metal-FrankenPHP als systemd-Service

Hier reicht ein Binär-Tausch plus systemctl restart frankenphp; kein Container-Rebuild nötig. Risikoprofil hängt vom Webserver-Verzeichnis ab — Empfehlung folgt den Profilen oben.

Was wir bei Moselwal konkret getan haben

Renovate erkennt FrankenPHP-Releases automatisch

Unsere TYPO3- und Sylius-Container nutzen Renovate als Versions-Wächter. Renovate hat das FrankenPHP-1.12.3-Release nach dem Disclosure automatisch erkannt, einen Merge-Request gegen unsere Image-Definition eröffnet und die CI-Pipeline für den Image-Neubau angestoßen. Der Rollout auf die Bestandskunden-Container läuft im Laufe des Tages — ohne manuellen Build-Trigger.

Prüfung der Upload-Verzeichnisse

Parallel zum Rollout ein Audit-Pass via find /var/www/uploads -name '*[\x80-\xff]*' auf allen Bestandskunden-Hosts. Keine Auffälligkeiten — keine Datei mit Unicode-Bypass-Pattern im Bestand. Plus eine Korrelation der Caddy-Zugriffs-Logs auf Non-ASCII-Pfade in den letzten 30 Tagen, ebenfalls ohne Treffer.

Detektions-Regel ausgerollt

Die Falco-Regel frankenphp_nonascii_php_exec ist auf den Hosts mit aktivem Falco-Agent ausgerollt. Zusätzlich eine Zugriffs-Log-Warnregel für URL-Encoded Bypass-Patterns (%ef%bc%8e, %ef%b9%92, %ef%bd%90, %f0%9d%97%bd und weitere) in unserem Log-Aggregator.

Warum Renovate hier den Unterschied macht

Renovate-getriebene Versions-Aktualisierung heißt: kein „heute Disclosure gelesen, morgen manuell rebuilden“-Loop. Die Pipeline triggert automatisch, sobald die neue FrankenPHP-Version verfügbar ist; CI baut die Container; Deployment-Schritt rollt aus. Bei einer High-Severity-CVE im Worker-Server ist das die richtige Größenordnung von Reaktionszeit — nicht stundenlange Notschicht, aber auch nicht eine Woche reguläres Wartungsfenster.

Fazit

CVE-2026-45062 ist ein klassischer Bug aus der Unicode-Handling-Klasse: eine Hilfsfunktion vertraut einer Library-API, die strenger zu sein scheint, als sie tatsächlich ist — in diesem Fall search.IgnoreCase mit Unicode-Equivalence-Folding statt einfacher ASCII-Case-Folding. Zwei Logikfehler in derselben Funktion, ein Patch in FrankenPHP 1.12.3, ein klar definierter Exploit-Pfad. Wer FrankenPHP zwischen v1.11.2 und v1.12.2 läuft und User-Uploads im Web-Root hat, sollte heute patchen.

Strukturell ist es die zweite CGI-Path-Splitting-CVE in dieser Schicht in zwei Monaten — ein Indikator, dass die Datei cgi.go unter externer Auditierung steht. Wir behandeln das wie die XFRM/ESP-Schicht im Linux-Kernel: nicht als einmaligen Vorfall, sondern als Schicht, die regelmäßig nachpatched werden muss. Image-Pin-Disziplin, automatische Rebuild-Trigger auf FrankenPHP-Releases und Falco-Detection-Regeln machen das beherrschbar.