Sécurité
Des vulnérabilités critiques de PHP imposent une mise à jour urgente
Cet article a été traduit à l'aide d'outils de traduction automatique. Voir la version originale
PHP a publié aujourd'hui les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent deux vulnérabilités critiques : avec une simple requête web, quelqu'un sans identifiants peut exécuter du code sur votre serveur. Si vous utilisez PHP en production, il est extrêmement urgent de mettre à jour aujourd'hui.
Si vous avez souscrit la maintenance chez Nebux, comme toujours, vous n'avez rien à faire : tout est déjà à jour.
Ce qui se passe
Les vulnérabilités CVE-2026-109618 et CVE-2026-109619 ont été publiées aujourd'hui. L'équipe de sécurité de PHP leur attribue à toutes deux un score de 9,2 sur 10 selon CVSS 4.0, la norme que nous, experts en cybersécurité, utilisons pour évaluer les risques.
Elles touchent toute installation de PHP qui répond à des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est le plus élevé avec mod_php, pour lequel une attaque a déjà été démontrée.
Les détails ont fuité hier, avant la date prévue, et PHP a avancé la publication d'un jour.
Si vous ne pouvez pas encore mettre à jour
PHP propose ces mesures en attendant. Elles ne protègent pas complètement : seule la mise à jour le fait.
Pour CVE-2026-109618, fixez ces valeurs là où l'application ne peut pas les modifier, par exemple avec php_admin_value dans le pool FPM ou dans la configuration d'Apache :
memory_limit = -1
post_max_size = 8M ; 32M si vous devez envoyer des fichiers
Ne limitez pas la mémoire avec RLIMIT_AS ni RLIMIT_DATA, car ils provoquent précisément l'erreur que l'on veut éviter.
Pour CVE-2026-109619 :
session.upload_progress.enabled = 0
fatal_error_backtraces = 0 ; uniquement en PHP 8.5
Redémarrez ensuite tous les processus PHP. Les modifier avec ini_set() ou un .user.ini ne suffit pas.
Si vous utilisez PHP 8.1 ou une version antérieure
Les développeurs ne publient plus de correctifs pour ces versions. Leur équipe de sécurité a préparé des corrections pour les versions 8.1, 8.0 et 7.4, mais il vous faudrait les compiler vous-même pour les appliquer. Le plus sûr est de passer à une version prise en charge, en gardant à l'esprit que la prise en charge de la 8.2 prend fin le 31 décembre 2026. Vous pouvez vérifier jusqu'à quand votre version est prise en charge sur endoflife.date.
Si vous êtes client de Nebux
Tous nos clients utilisaient des versions de PHP prises en charge, parce que nous faisons nos devoirs à temps : ils ont donc pu appliquer le correctif immédiatement. Dès l'annonce, notre équipe a préparé un plan de mise à jour et, quand PHP a publié les correctifs, nous avons mis à jour tous les services. Comme l'image OCI officielle de PHP (pour Docker, Podman, etc.) n'était pas encore publiée, nous en avons créé une provisoire avec le correctif. Trois heures après la publication, tous les services étaient à jour (et nous parlons de dizaines !). Le tout sans coût supplémentaire : c'est inclus dans le forfait mensuel.
La maintenance est pensée pour prendre soin de ce que vous avez en place et que tout continue de fonctionner, avec les mises à jour, les vulnérabilités et l'usure du quotidien. Et surtout, pour que dans des cas comme celui-ci la mise à jour soit simple, sans migrations précipitées et, bien sûr, sans aucun impact sur la production. Et pas seulement pour PHP : tous les logiciels sont tenus à jour.
C'est un forfait mensuel fixe, selon le volume et la complexité de votre infrastructure. Si vous souhaitez que nous nous occupions de la vôtre, parlez-nous-en.