PHP publie les correctifs de deux failles critiques (CVSS 9,2) : 8.5.12, 8.4.27, 8.3.36, 8.2.35. Qui est concerné, mesures transitoires et marche à suivre.
Le projet PHP a publié le 21 octobre 2026 les versions qui corrigent deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur l'échelle CVSS v4.0. Selon les annonces du projet, elles peuvent permettre une exécution de code à distance sans authentification. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. La mise à jour est la seule protection complète : mettez-la en œuvre sans attendre.
La première faille, CVE-2026-109618, tient à la gestion d'un manque de mémoire : PHP peut être interrompu alors que les données internes d'une requête ne sont qu'en partie initialisées, et le nettoyage de la requête les traite ensuite comme valides. La seconde, CVE-2026-109619, concerne un état interne propre à une requête qui survit à la libération de sa mémoire : une requête suivante, traitée par le même processus, peut l'utiliser avant que son initialisation normale ne le remette à zéro.
Le projet indique que toutes les installations PHP qui servent des requêtes web sont concernées, qu'il s'agisse de PHP-FPM, d'Apache avec mod_php, de php-cgi, de FrankenPHP ou de LiteSpeed. Le risque est jugé le plus élevé avec mod_php, pour lequel le projet dit avoir démontré qu'une requête non authentifiée peut déclencher l'attaque avant l'exécution de tout code applicatif. Les distributions et les éditeurs à support long ont reçu les correctifs en avance : vérifiez donc d'abord les mises à jour de votre système ou de votre hébergeur.
Les versions 8.1 et antérieures ne reçoivent plus de mises à jour du projet PHP. Des correctifs sous forme de code source sont toutefois fournis pour les branches 7.4, 8.0 et 8.1, que les distributions peuvent reprendre. Si votre site tourne sur l'une de ces versions, demandez à votre hébergeur ou à votre distribution si le correctif est appliqué, et planifiez une migration vers une branche maintenue.
Le projet précise qu'il n'existe aucune mesure de contournement complète. À titre transitoire seulement, il cite pour la première faille de fixer memory_limit à -1, de préférence d'une façon que les applications ne peuvent pas modifier, et de limiter post_max_size à 8M, ou 32M si des envois de fichiers sont nécessaires, sans remplacer ces réglages par RLIMIT_AS ou RLIMIT_DATA. Pour la seconde, il cite de désactiver session.upload_progress.enabled et, sous PHP 8.5, de désactiver fatal_error_backtraces, puis de redémarrer tous les processus PHP.
Avant toute mise à jour, vérifiez qu'une sauvegarde récente du site et de sa base de données existe et qu'elle peut être restaurée. Après la mise à jour, jetez un œil aux journaux du serveur et à la liste des comptes administrateurs du site : un compte inconnu ou une activité inhabituelle doit être signalé sans tarder.
Notre recommandation : mettez à jour PHP dès maintenant, redémarrez PHP-FPM ou Apache, puis contrôlez la version réellement servie par le web, qui peut différer de celle de la ligne de commande. Si un tiers héberge votre site, demandez-lui la date de mise à jour. TICLIC accompagne ses clients dans cette vérification. Voir nos services de cybersécurité.
Sources : annonces PHP du 21 octobre 2026, ChangeLog PHP 8, Help Net Security.