En bref : FrankenPHP est un serveur d'applications fondé sur Caddy, qui intègre PHP dans son propre programme. Pour la sécurité FrankenPHP après PHP2Shell, cela signifie que ce ne sont pas les paquets PHP de la distribution qui comptent, mais la version de PHP dans le binaire FrankenPHP ou l'image de conteneur. Construisez ou récupérez une version avec un PHP corrigé et redémarrez tous les workers.
Pourquoi FrankenPHP se corrige différemment
Dans les installations classiques, la distribution fournit PHP sous forme de paquet, et une mise à jour remplace les fichiers. FrankenPHP, en revanche, contient PHP comme bibliothèque intégrée. Qui utilise le binaire officiel ou une image de conteneur construite dessus reçoit PHP avec. Un apt upgrade sur l'hôte n'y change rien.
PHP2Shell regroupe CVE-2026-109618 et CVE-2026-109619, chacune CVSS v4.0 9.2. Le projet PHP cite expressément FrankenPHP parmi les modes d'exécution concernés. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ce qui est décisif, c'est donc la version de PHP avec laquelle votre FrankenPHP a été compilé.
Mode worker et PHP2Shell
FrankenPHP peut exploiter les applications en mode worker. L'application est alors chargée une seule fois et traite ensuite de nombreuses requêtes successives dans le même processus. Cela apporte de la vitesse, mais allonge la durée de vie de chaque processus.
CVE-2026-109619 décrit un état interne d'une requête qui peut subsister après la libération de la mémoire ; une requête ultérieure dans le même worker peut l'utiliser avant qu'il soit réinitialisé. En mode worker, l'interaction de nombreuses requêtes dans un seul processus est le cas normal. Ce n'est pas une raison de renoncer au mode worker, mais une raison claire d'appliquer mises à jour et redémarrages avec un soin particulier. Les détails techniques figurent sous CVE-2026-109619.
Sécurité FrankenPHP : vérifier la version
Vérifiez la version de PHP intégrée directement dans le système en service. Les commandes suivantes se contentent de lire ; les noms de services et de conteneurs sont des exemples.
# Binaire installé
frankenphp version
# Dans le conteneur en service (nom du conteneur à titre d'exemple)
docker exec app frankenphp version
docker exec app php -v
# Quelle image tourne réellement ? (le digest indique l'état exact)
docker inspect --format '{{.Image}} {{.Config.Image}}' app
Notez la version de PHP issue de la sortie. Si elle est antérieure aux versions corrigées, le système est vulnérable. Vérifiez toujours le conteneur en service, pas seulement la dernière image construite, car une nouvelle image ne prend effet qu'après le remplacement des conteneurs.
Installer la mise à jour et redémarrer tous les workers
La forme de la mise à jour dépend de votre installation :
- Binaire sur l'hôte : installer une nouvelle version de FrankenPHP avec une version de PHP corrigée, redémarrer le service.
- Conteneur : récupérer l'image de base avec une version de PHP corrigée, reconstruire sa propre image sans cache pour la couche de base, remplacer le conteneur.
- Compilé soi-même : reconstruire avec la version de PHP corrigée, regénérer toutes les extensions avec la même version.
# Exemple d'installation sur l'hôte comme service systemd
systemctl restart frankenphp
# Exemple Docker Compose : reconstruire sans cache et remplacer le conteneur
docker compose build --pull --no-cache
docker compose up -d --force-recreate
Vérifiez ensuite à nouveau la version de PHP dans le conteneur en service et l'heure de démarrage des processus. En mode worker, chaque worker doit avoir été redémarré. Avec Kubernetes, des étapes supplémentaires s'appliquent, décrites sous Corriger PHP dans Kubernetes, et pour les conteneurs en général sous Corriger PHP dans des conteneurs Docker.
Une balise comme latest ou une version majeure dans le nom de l'image ne garantit pas que vous avez l'état le plus récent. Récupérez activement à nouveau l'image de base et vérifiez ensuite la version de PHP dans le conteneur en service.
Mesures transitoires et durcissement
Si la mise à jour ne peut pas être effectuée immédiatement, php.net recommande des mesures transitoires qui n'offrent pas de protection complète. Avec FrankenPHP, définissez les valeurs dans le php.ini que charge FrankenPHP ou via les paramètres PHP de la configuration Caddy, et non avec ini_set() dans l'application.
; php.ini dans le conteneur ou sur l'hôte
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Avec une fonction d'envoi de fichiers, php.net indique post_max_size = 32M. Sur PHP 8.5, fatal_error_backtraces=0 s'y ajoute. La limite de mémoire relève du niveau du conteneur, par exemple via la limite de mémoire du conteneur, et non de RLIMIT_AS ou RLIMIT_DATA. Après chaque modification, redémarrez tous les workers.
Pour l'exploitation durable, il vaut la peine de référencer les images avec un digest fixe, de les reconstruire régulièrement de façon automatisée et d'intégrer un scanner d'images dans la chaîne de build. Un correctif ne supprime en outre pas les logiciels malveillants introduits auparavant. Conservez les journaux à partir du 20 octobre 2026 ; pour les conteneurs, cela signifie les sauvegarder avant de les remplacer.
Qui utilise FrankenPHP comme binaire construit statiquement doit savoir qu'outre PHP, toutes les extensions y sont aussi intégrées de façon fixe. Une mise à jour signifie donc toujours remplacer le binaire entier. Après le remplacement, vérifiez la version et la liste des extensions chargées pour vous assurer que tout est disponible comme avant, et testez l'application avant d'abandonner l'ancien état. Dans les environnements de conteneurs, il est recommandé de marquer chaque image avec la date de build. Vous pouvez ainsi retracer à tout moment quel état a tourné quand et, en cas de doute, revenir en arrière de façon ciblée sans retomber sur un état vulnérable. Consignez dans votre documentation la correspondance entre image, version de PHP et moment.
Comment PHP SOS aide-t-il concrètement ?
- Nous vérifions quelle version de PHP se trouve réellement dans vos binaires FrankenPHP et vos conteneurs en service.
- Via le service de correctifs PHP, nous reconstruisons les images, remplaçons les conteneurs et redémarrons tous les workers, avec justificatif.
- Nous sauvegardons les journaux avant le remplacement et examinons l'application à la recherche de traces.
- Pour l'exploitation durable, nous mettons en place des reconstructions automatisées et des contrôles d'images dans le cadre du durcissement de serveur.
Questions fréquentes
Une mise à jour apt ou dnf aide-t-elle avec FrankenPHP ?
Seulement si FrankenPHP lui-même provient de ces sources de paquets et a été compilé avec le PHP corrigé. Souvent, PHP est intégré de façon fixe dans le binaire FrankenPHP ou dans l'image de conteneur. Vous devez alors mettre à jour le binaire ou l'image.
Pourquoi le mode worker est-il particulièrement important avec PHP2Shell ?
En mode worker, l'application reste en mémoire et traite de nombreuses requêtes successives dans le même processus. CVE-2026-109619 concerne précisément l'état interne qui peut subsister entre des requêtes dans le même worker. Un redémarrage de tous les workers après la mise à jour est donc obligatoire.
Comment vérifier quelle version de PHP se trouve dans FrankenPHP ?
Le binaire FrankenPHP affiche la version de PHP intégrée lorsqu'on appelle sa version. Dans un conteneur, vous pouvez exécuter la commande via docker exec. Veillez à vérifier la version dans le conteneur réellement en service, et non dans l'image qui vient d'être construite.
Existe-t-il des mesures transitoires propres à FrankenPHP ?
Les indications générales de php.net s'appliquent. Vous définissez les valeurs dans le php.ini que charge FrankenPHP ou dans la configuration PHP du fichier Caddy, et non avec ini_set() dans l'application. Redémarrez ensuite tous les workers.