PHP corrige deux vulnérabilités critiques d’exécution de code à distance sans authentification (CVE-2026-109618, CVE-2026-109619) : [mise à jour pour CVE-2026-115560]

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 CVSS v4.0 9.2, susceptibles de permettre une exécution de code à distance sans authentification. L’équipe de sécurité PHP recommande : « Il n’existe aucune mesure d’atténuation complète ; la mise à jour est la seule option sûre. »

Il s’agit de bogues dans le moteur d’exécution PHP, et non dans un package Composer. Cela change la manière 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, procurez-vous un package rétroporté auprès de votre distribution ou de votre fournisseur LTS, ou procédez à une mise à niveau.

Que s’est-il passé ?

Les heures sont indiquées en UTC.

• 20 octobre : L’équipe de sécurité PHP a publié un avis préalable annonçant une version de sécurité critique prévue le 21 octobre à 14 h 00 UTC. Elle corrige deux vulnérabilités évaluées à CVSS v4.0 9.2. L’équipe se réservait le droit de publier la version plus tôt en cas de fuite d’informations ou d’exploitation 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’alerter les clients sur les mesures à prendre et de signaler les projets surveillés dès que les versions corrigées seraient connues.

• 21 octobre, 14 h 00 UTC : L’avis de sécurité PHP et les quatre versions corrigées sont publiés. En une trentaine de minutes, 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 des avis pour ces distributions au fur et à mesure, par exemple SNYK-UBUNTU2604-PHP85-21373920. La liste à jour se trouve ici : CVE-2026-109618 et CVE-2026-109619.

Mise à jour du 23 octobre : conserver session.upload_progress.enabled=0

Le 23 octobre, le projet PHP a publié un avis informatif pour CVE-2026-115560, une CVE réservée, mais pas encore attribuée. Il décrit un vecteur de contournement partiel de CVE-2026-109619. Le paramètre qui permet de l’éviter, session.upload_progress.enabled=0, figurait déjà parmi les mesures d’atténuation de CVE-2026-109619.

PHP ne se précipite pas pour publier un correctif d’urgence, car les conditions préalables à l’exploitation sont rares et peu susceptibles de s’appliquer à la plupart des déploiements. Une application doit configurer session.serialize_handler sur php_binary or php_serialize, puis le remplacer par php à l’exécution avec ini_set() avant d’appeler session_start(), alors que le suivi de progression des téléversements de session est activé. Les applications qui ne modifient jamais le gestionnaire de sérialisation à l’exécution peuvent laisser cette fonctionnalité activée.

Les vulnérabilités

Les deux vulnérabilités se situent dans le cycle de vie des requêtes du moteur PHP, ce qui les rend exploitables avant l’exécution de tout code applicatif. C’est l’un des facteurs qui les rendent à la fois répandues et dangereuses.

Détails techniques

CVE-2026-109618, exécution de code à distance par corruption due à un manque de mémoire : La gestion d’un manque de mémoire peut interrompre PHP alors que les données internes de la requête ne sont que partiellement initialisées. Lors du nettoyage de la requête, ces données invalides sont alors considérées comme 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 par état global obsolète : Un état interne propre à une requête peut subsister après la libération de la mémoire qui le sous-tend. 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 de processus de longue durée, cela constitue une utilisation après libération entre requêtes.

Ces bogues 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, tout le monde utilise encore des serveurs — et le modèle qui a détecté ces bogues est du même type que ceux dont disposent aujourd’hui les attaquants. C’est le principe à l’origine d’Evo by Snyk : une sécurité pilotée par l’IA pour les applications utilisées par les agents, et pas seulement pour les agents eux-mêmes. La découverte assistée par l’IA explique aussi pourquoi PHP2Shell ne sera pas la dernière faille de ce type, et pourquoi les délais de réponse se comptent désormais en heures.

Qui est concerné ?

Toutes les installations PHP qui traitent des requêtes web sont exposées. Cela inclut PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed, etc. Apache avec mod_php est le plus vulnérable : un exploit a démontré qu’une seule requête sans authentification pouvait déclencher l’attaque avant l’exécution du code applicatif.

Le projet PHP ne fournit plus de mises à jour pour PHP 8.1 et les versions antérieures. Une installation non corrigée de 8.1, 8.0 ou 7.4 est donc vulnérable sans correctif en amont. Compte tenu de la gravité, l’équipe de sécurité PHP a tout de même publié des rétroportages minimaux du code source pour les versions 7.4, 8.0 et 8.1, à l’intention des personnes qui compilent depuis les sources ou ne disposent pas d’un fournisseur LTS.

Ce que vous devez faire 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. Notez que la version 8.2 arrive en fin de vie le 31 décembre 2026. Si vous l’utilisez, profitez-en pour planifier la mise à niveau vers la version suivante.

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 packages mis à jour plutôt que d’attendre une compilation à partir des sources. Une version corrigée d’une distribution peut conserver un numéro de version plus ancien : consultez également l’avis ou le niveau de correctif de la distribution.

3. Vérifiez ce qui est réellement en cours d’exécution. Contrôlez 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 répertorie des mesures d’atténuation qui réduisent l’exposition à certains vecteurs sans rendre une installation sûre : définir memory_limit=-1 à un niveau que les applications ne peuvent pas remplacer, utiliser une valeur faible pour post_max_size, définir session.upload_progress.enabled=0 puis redémarrer chaque processus de traitement et, sur la version 8.5, définir fatal_error_backtraces=0. Consultez l’avis correspondant pour connaître les limites de chaque mesure.

5. Que vous ayez effectué la mise à jour ou non, laissez le paramètre session.upload_progress.enabled=0 activé jusqu’à la prochaine version de correction régulière si votre application modifie session.serialize_handler à l’exécution. Consultez la mise à jour ci-dessus pour en savoir plus.

6. Si vous utilisez PHP 8.1 ou une version antérieure, passez à une version prise en charge ou procurez-vous un package rétroporté auprès de votre distribution ou de votre fournisseur LTS. Les rétroportages du code source publiés par PHP pour les versions 7.4, 8.0 et 8.1 sont une solution de dernier recours pour les équipes qui compilent depuis les sources.

Côté open source

L’équipe de sécurité PHP a prévenu l’écosystème un jour à l’avance, en indiquant une heure précise, le niveau de gravité et en ne communiquant aucun détail sur l’exploitation. Elle a transmis les correctifs aux distributions Linux en amont afin qu’elles puissent publier des packages corrigés en même temps que la version source. Elle a publié des rétroportages pour les versions non prises en charge (7.4, 8.0, 8.1). Elle a informé les utilisateurs d’un dépôt bénévole populaire (rpms.remirepo.net) qu’il ne serait pas mis à jour dès le premier jour, et leur a indiqué quoi faire à la place. Enfin, ses conseils d’atténuation expliquent avec une grande transparence ce que chaque paramètre ne protège pas.

Voilà à quoi ressemble une divulgation coordonnée bien menée par un projet géré par des bénévoles. C’est aussi ce qui nous a permis, chez Snyk, de publier les avis avant la sortie et de les compléter peu après : un calendrier rendu public permet à tous les acteurs en aval de se préparer.

Fonctionnement de Snyk SCA

Snyk Open Source analyse les déclarations de votre application dans les fichiers manifeste ou de compilation, 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 package 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

Repérez votre surface d’attaque PHP avec Snyk API & Web

Avant de pouvoir appliquer un correctif, vous devez établir la liste des éléments concernés. L’onglet Discovery de Snyk API & Web répertorie les ressources trouvées sur vos domaines et identifie leur pile technologique. Ouvrez Discovery, définissez le filtre Tech sur PHP : vous verrez 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 dernière détection. Vous pourrez ensuite les analyser ou les ajouter comme cibles.

Le même filtre Tech est disponible dans la liste Targets. Vous pouvez donc également filtrer de la même manière les applications que vous avez ajoutées.

Cela ne vous indique pas la version de PHP. En revanche, vous savez où chercher, ce qui constitue une étape cruciale vers la remédiation.

Testez la vulnérabilité avec Snyk API & Web

Snyk API & Web vous permet d’analyser vos applications et API pour détecter si elles sont vulnérables à PHP2Shell.

Une analyse avec un profil complet teste désormais la vulnérabilité PHP2Shell. Vous pouvez également créer un profil d’analyse personnalisé qui cible exclusivement PHP2Shell, afin de vérifier rapidement si vos applications sont vulnérables ou si la remédiation a déjà été effectuée.

Ce que nous faisons

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

• Un avis supplémentaire a été publié pour CVE-2026-115560. Il sera mis à jour au fur et à mesure de la publication de nouvelles informations et du correctif.

• Nous importons les avis des distributions au fur et à mesure de leur publication. Ceux d’Ubuntu et de Red Hat sont disponibles dès maintenant.

• Un rapport Zero Day lié à cet événement est disponible pour les projets analysés avec les méthodes Unmanaged et Container.

Comme toujours, l’équipe de recherche en sécurité de Snyk suit cette divulgation et mettra à jour les avis à mesure que de nouvelles informations seront disponibles. Pour toute question, 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 dès maintenant (21 octobre 2026)

• Avis informatif PHP : progression des téléversements de session (23 octobre 2026)

• Avis Snyk Unmanaged pour CVE-2026-109618

• Avis Snyk Unmanaged pour CVE-2026-109619

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

• Documentation Snyk Open Source

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