En bref : la faille de sécurité Laravel que beaucoup de développeurs recherchent actuellement est PHP2Shell et se trouve dans PHP lui-même. Une mise à jour de Laravel ne la comble pas. Comptent un PHP corrigé, le redémarrage de tous les processus, workers de file d'attente et Octane compris, ainsi qu'un contrôle de .env, storage et public.
Ce que PHP2Shell signifie pour les applications Laravel
Laravel est le socle de nombreux développements spécifiques : portails clients, outils internes, systèmes de réservation, API pour applications. Les failles PHP CVE-2026-109618 et CVE-2026-109619 permettent, selon l'équipe PHP, d'exécuter du code malveillant à distance sans authentification. La propreté du code Laravel n'y change rien.
Sont concernés les modes d'exploitation PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Laravel Octane peut utiliser FrankenPHP comme serveur ; PHP se trouve alors dans le programme FrankenPHP ou dans l'image de conteneur et est mis à jour avec lui. Ce qu'il en est pour FrankenPHP est décrit dans Sécuriser FrankenPHP.
Faille de sécurité Laravel : vérifier la version de PHP et les processus
En ligne de commande, php artisan about affiche la version de PHP, la version de Laravel et des réglages importants comme l'environnement et le mode debug. C'est toutefois la version du PHP CLI. Les requêtes web sont traitées par PHP-FPM ou Octane, et il peut s'agir d'une autre version. En cas de doute, faites confirmer par l'exploitant quel état de paquets fonctionne sur toutes les voies.
Les versions corrigées en amont sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35, les backports peuvent porter des numéros plus anciens. Les versions de PHP prises en charge par votre version de Laravel se vérifient dans la configuration requise de la documentation sur laravel.com.
Après la mise à jour vient la partie que l'on oublie le plus souvent avec Laravel : les processus de longue durée.
# Afficher les versions et la configuration
php artisan about
# Demander aux workers de file d'attente de se terminer après la tâche en cours
php artisan queue:restart
# Arrêter Horizon pour que le gestionnaire de processus le redémarre
php artisan horizon:terminate
Les workers ne redémarrent ensuite que si un gestionnaire de processus comme Supervisor ou systemd les surveille. Les serveurs Octane et les conteneurs doivent être entièrement redémarrés ou redéployés avec une nouvelle image. Pour les configurations en conteneurs, voir Corriger PHP dans les conteneurs Docker.
Où les applications Laravel sont vulnérables
| Emplacement | Contenu | Point de contrôle |
|---|---|---|
.env |
APP_KEY, base de données, e-mail, clés API |
ne doit jamais être accessible via le web |
bootstrap/cache/config.php |
configuration mise en cache avec secrets | droits, date de modification |
public/ |
Racine web avec index.php |
fichiers PHP supplémentaires |
storage/app/public |
Uploads, accessibles via public/storage |
aucun fichier PHP |
storage/logs/ |
laravel.log, souvent avec des données de requêtes |
sauvegarder, non public |
vendor/ |
Paquets Composer | composer audit, comparaison avec composer.lock |
Le dossier storage/app/public est accessible via un lien symbolique sous public/storage. Un fichier PHP déposé là peut, selon la configuration du serveur, être exécuté directement. Bloquez cela au niveau du serveur web.
APP_DEBUG doit être sur false en production. Une page d'erreur avec sortie de débogage peut montrer des variables d'environnement, des chemins et des parties du code, et facilite le travail de tout attaquant.
Interfaces d'administration et paquets comme risque
Les applications Laravel n'ont pas d'interface d'administration uniforme. Ce sont souvent des espaces propres ou des paquets comme Filament ou Nova. Vérifiez qui a des droits d'admin, si la connexion comporte un second facteur et si les routes d'administration doivent être accessibles de l'extérieur. Les jetons API, par exemple de Sanctum ou de Passport, devraient eux aussi être révoqués et réémis en cas de soupçon.
Vérifiez en outre si des outils de développement sont accessibles en production, comme les barres de débogage, Telescope ou des routes de test. Ils montrent souvent des requêtes, des interrogations et la configuration, et doivent être placés derrière une connexion ou retirés complètement de l'environnement de production.
Les paquets Composer sont le second grand bloc. Chaque dépendance apporte son propre code, et les paquets sans maintenance bloquent ensuite les mises à niveau de PHP. composer audit montre les failles connues, mais ne remplace pas un contrôle du code propre.
Ce qu'une mise à jour de Laravel peut faire et ne peut pas faire
Une mise à jour de Laravel ou de paquets individuels comble des défauts connus de ce code. Elle ne corrige pas PHP, ne redémarre pas de workers, ne renouvelle pas un APP_KEY qui a fuité et ne supprime aucun fichier de storage ou de public. Savoir si quelque chose s'est produit avant le correctif ne se clarifie que par le contrôle des journaux, des fichiers et de la base de données.
Pour les équipes disposant d'un pipeline de déploiement : la mise à jour de PHP doit aussi aller dans l'environnement de build et dans les images de base, sinon le prochain déploiement ramène de nouveau une ancienne version. Vérifiez en outre si des environnements de staging ou de revue sont accessibles publiquement. Ils tournent souvent avec APP_DEBUG=true et de vraies données et sont facilement oubliés lors des mises à jour de sécurité.
Comment PHP SOS aide-t-il concrètement ?
- Nous contrôlons le PHP web, CLI et workers de votre application Laravel et accompagnons le redémarrage ordonné de tous les processus.
- Nous sauvegardons les journaux à partir du 20/10/2026, la base de données et l'état du code et le comparons à votre dépôt.
- Nous contrôlons
.env, le cache de configuration,storage,public, les comptes admin et les jetons API. - Pour un contrôle plus approfondi du code propre, nous mettons en relation avec des partenaires spécialisés pour un audit de sécurité ou un test d'intrusion.
Questions fréquentes
Dois-je mettre à jour Laravel à cause de PHP2Shell ?
Une mise à jour de Laravel ne comble pas PHP2Shell, car la faille se trouve dans l'interpréteur PHP. Gardez néanmoins Laravel à jour. Pour PHP2Shell, il vous faut un PHP corrigé et le redémarrage de tous les processus PHP, workers compris.
Pourquoi un redémarrage de PHP-FPM ne suffit-il souvent pas avec Laravel ?
Les workers de file d'attente, Horizon, Octane et le scheduler s'exécutent comme processus PHP distincts en ligne de commande. Ils chargent PHP une seule fois au démarrage et continuent ensuite de travailler avec l'ancienne version en mémoire jusqu'à leur redémarrage.
Que faire si le fichier .env a pu fuiter ?
Vous devriez alors renouveler APP_KEY, le mot de passe de la base de données et toutes les clés des services externes. Notez qu'un nouvel APP_KEY met fin aux sessions existantes et rend illisibles les données chiffrées avec l'ancienne clé ; planifiez-le avec vos développeurs.