PHP corrige deux vulnérabilités RCE critiques exploitables sans authentification (CVE-2026-109618, CVE-2026-109619) : mettez à jour dès maintenant

Le mercredi 21 octobre 2026 à 14 h 00 UTC, le projet PHP a publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux vulnérabilités critiques, toutes deux notées 9,2 selon CVSS v4.0, qui peuvent permettre l’exécution de code à distance sans authentification. L’équipe de sécurité PHP conseille : « Il n’existe aucune mesure d’atténuation complète ; la mise à jour est la seule option sûre. »

Il s’agit de bugs dans l’environnement d’exécution PHP, et non dans un paquet Composer. Cela change la façon de les détecter et de les corriger, comme nous l’expliquons ci-dessous.

En bref Si vous utilisez PHP pour traiter des requêtes web (PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed), passez dès aujourd’hui à la version 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Si vous utilisez la version 8.1 ou une version antérieure, obtenez un paquet corrigé rétroporté auprès de votre distribution ou de votre fournisseur LTS, ou effectuez une mise à niveau.

Que s’est-il passé ?

Toutes les heures sont indiquées en UTC.

• 20 octobre : L’équipe de sécurité PHP a publié un avis préliminaire annonçant une mise à jour de sécurité critique prévue le 21 octobre à 14 h 00 UTC. Elle corrige deux vulnérabilités notées 9,2 selon CVSS v4.0. L’équipe se réservait le droit de publier plus tôt si des détails venaient à fuiter ou si une exploitation était observée dans la nature.

• 21 octobre, avant 14 h 00 UTC : Snyk a publié des avis pour les deux CVE, SNYK-UNMANAGED-PHP-21347795 (CVE-2026-109618) et SNYK-UNMANAGED-PHP-21347796 (CVE-2026-109619), afin d’informer ses clients des mesures à prendre et de signaler les vulnérabilités dans les projets surveillés dès la publication des versions corrigées.

• 21 octobre, 14 h 00 UTC : L’avis de sécurité PHP et les quatre versions corrigées sont publiés. Environ 30 minutes plus tard, les avis de Snyk sont mis à jour avec tous les détails pertinents, notamment les plages de versions affectées et les versions corrigées.

• À partir du 21 octobre : Les distributions Linux, qui avaient reçu les correctifs à l’avance, commencent à publier leurs propres avis. Snyk publie les avis correspondants au fur et à mesure, par exemple SNYK-UBUNTU2604-PHP85-21373920. La liste complète est disponible pour CVE-2026-109618 et CVE-2026-109619.

Les deux vulnérabilités

Toutes deux se trouvent dans le cycle de traitement des requêtes du moteur PHP et peuvent donc être exploitées avant l’exécution du code de l’application. C’est l’une des raisons pour lesquelles ces vulnérabilités sont à la fois répandues et dangereuses.

Détails techniques

CVE-2026-109618, exécution de code à distance par corruption liée à une mémoire insuffisante : La gestion d’une mémoire insuffisante peut interrompre PHP alors que les données internes de la requête ne sont que partiellement initialisées. Le nettoyage de la requête traite alors ces données invalides comme si elles étaient valides. Un attaquant capable de pousser un processus de traitement jusqu’à sa limite mémoire au moyen d’une requête malveillante peut déclencher cette interruption.

CVE-2026-109619, exécution de code à distance à partir d’un état global obsolète : Un état interne propre à une requête peut persister après la libération de la mémoire qui le contenait. Une requête ultérieure traitée par le même processus peut utiliser cet état obsolète avant que l’initialisation normale ne le réinitialise. Dans un modèle où les processus de traitement sont de longue durée, il s’agit d’une utilisation après libération entre requêtes.

Ces bugs ont été découverts avec l’aide de l’IA dans un environnement d’exécution utilisé en production depuis trois décennies. À l’ère des LLM et des agents, les serveurs restent une cible, et le modèle qui a découvert ces vulnérabilités est du même type que ceux auxquels les attaquants ont désormais accès. C’est le principe à l’origine d’Evo by Snyk : une sécurité pilotée par l’IA pour les applications exécutées par les agents, et pas seulement pour les agents eux-mêmes.

Qui est concerné ?

Toutes les installations PHP qui traitent des requêtes web sont à risque. Cela concerne PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed, etc. Apache avec mod_php est le plus vulnérable : un exploit démontré montre qu’une seule requête sans authentification peut déclencher l’attaque avant même l’exécution du code de l’application.

Le projet PHP ne fournit plus de mises à jour pour PHP 8.1 et les versions antérieures. Par conséquent, les installations non corrigées de la version 8.1, 8.0 ou 7.4 sont vulnérables et ne disposent d’aucun correctif en amont. Compte tenu de la gravité, l’équipe de sécurité PHP a tout de même publié des correctifs sources minimaux rétroportés pour les versions 7.4, 8.0 et 8.1, à l’intention des personnes qui compilent à partir des sources ou qui ne disposent pas d’un fournisseur LTS.

Mesures à prendre dès maintenant

1. Mettez à jour. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. À noter que la prise en charge de la version 8.2 prend fin le 31 décembre 2026. Si vous l’utilisez, c’est aussi le moment de planifier la prochaine mise à niveau.

2. Vérifiez auprès de votre fournisseur. Les distributions Linux et les fournisseurs LTS ont reçu les correctifs avant leur publication. Installez leurs paquets mis à jour plutôt que d’attendre une compilation à partir des sources. Une version corrigée fournie par une distribution peut conserver un numéro de version antérieur. Consultez donc également son avis ou le niveau de correctif.

3. Vérifiez ce qui est réellement exécuté. Vérifiez la version de PHP sur chaque hôte et dans chaque image (php -v ou la balise de l’image). Les résultats d’analyse ne suffisent pas à confirmer qu’une installation est corrigée.

4. Si vous ne pouvez pas effectuer la mise à jour aujourd’hui, PHP indique des mesures qui réduisent l’exposition à certaines voies d’attaque, sans pour autant sécuriser l’installation : définissez memory_limit=-1 là où les applications ne peuvent pas remplacer ce paramètre, utilisez une valeur faible pour post_max_size, définissez session.upload_progress.enabled=0 puis redémarrez tous les processus de traitement et, pour la version 8.5, définissez fatal_error_backtraces=0. Consultez l’avis correspondant pour connaître les réserves associées à chaque mesure.

5. Si vous utilisez PHP 8.1 ou une version antérieure, passez à une version prise en charge ou obtenez un paquet corrigé rétroporté auprès de votre distribution ou de votre fournisseur LTS. Les correctifs sources rétroportés par PHP pour les versions 7.4, 8.0 et 8.1 constituent une solution de dernier recours pour les équipes qui compilent à partir des sources.

L’écosystème open source

L’équipe de sécurité PHP a averti l’écosystème un jour à l’avance, en précisant l’heure de publication et le niveau de gravité, sans communiquer de détails sur l’exploitation. Elle a partagé les correctifs en amont avec les distributions Linux pour qu’elles puissent publier des paquets corrigés en même temps que la version source. Elle a publié des correctifs rétroportés pour les versions qui ne sont plus prises en charge (7.4, 8.0, 8.1). Elle a prévenu les utilisateurs d’un dépôt très populaire géré par des bénévoles (rpms.remirepo.net) qu’il ne serait pas mis à jour le premier jour et leur a indiqué la marche à suivre. Enfin, ses conseils d’atténuation expliquent avec beaucoup de transparence ce que chaque paramètre ne permet pas de prévenir.

Voilà à quoi ressemble une divulgation coordonnée bien menée par un projet géré par des bénévoles. C’est aussi pourquoi Snyk a pu publier ses avis avant la mise à jour et les compléter peu après : un calendrier de publication annoncé permet à tous les acteurs en aval de se préparer.

Comportement de Snyk SCA

Snyk Open Source analyse les déclarations de votre application dans les fichiers manifestes ou de build, comme composer.json et composer.lock. L’interpréteur PHP n’est pas une dépendance déclarée. Il est installé par un Dockerfile, un paquet de distribution, une image de plateforme ou manuellement. Une contrainte « php » : « >=8.2 » dans composer.json indique les versions acceptées par l’application, mais pas précisément la version déployée.

Comment la plateforme Snyk vous aide à repérer les instances PHP exposées

Identifiez votre surface d’attaque PHP avec Snyk API & Web

Avant de pouvoir corriger le problème, vous devez savoir où chercher. L’onglet Discovery de Snyk API & Web répertorie les actifs détectés sur vos domaines et identifie leur pile technologique. Ouvrez Discovery, définissez le filtre Tech sur PHP : vous obtiendrez la liste de tous les hôtes et points de terminaison détectés où PHP a été identifié, avec leur niveau de risque, leur score et la date de leur dernière détection. Vous pourrez alors les analyser ou les ajouter comme cibles.

Le même filtre Tech est également disponible dans la liste Targets. Vous pouvez ainsi filtrer de la même manière les applications que vous avez ajoutées pour ne conserver que celles utilisant PHP.

Cela ne vous indique pas la version de PHP. En revanche, vous savez où chercher, une étape essentielle pour remédier au problème.

Nos actions

• Les avis concernant les deux CVE ont été publiés avant la sortie de PHP prévue à 14 h 00 UTC, puis mis à jour avec les versions affectées et les détails des correctifs dans les 30 minutes environ qui ont suivi.

• Les avis des distributions sont importés au fur et à mesure de leur publication par les distributions Linux. Ceux d’Ubuntu et de Red Hat sont disponibles dès maintenant.

• Un rapport Zero Day sur cet événement est disponible pour les projets Unmanaged et Container.

Comme toujours, l’équipe de recherche en sécurité de Snyk suit cette divulgation et mettra à jour les avis au fil des nouvelles informations. Si vous avez des questions, contactez votre équipe de compte Snyk ou le Support.

Références

• Avis de sécurité PHP : vulnérabilités critiques d’exécution de code à distance, mettez à jour sans attendre (21 octobre 2026)

• Avis Snyk Unmanaged concernant CVE-2026-109618

• Avis Snyk Unmanaged concernant CVE-2026-109619

• Tous les avis Snyk concernant CVE-2026-109618 et CVE-2026-109619

• Documentation Snyk Open Source

• Documentation sur l’analyse des dépendances C/C++ non gérées de Snyk