Vulnérabilités critiques PHP
L'essentiel de votre hack'tu cybersécurité
- Deux vulnérabilités critiques affectant le cœur de PHP permettent potentiellement à un attaquant distant non authentifié d’exécuter du code sur un serveur exposé. Les correctifs sont disponibles : les organisations doivent identifier leurs installations PHP, appliquer les versions corrigées et redémarrer les services concernés sans attendre.
PHP2Shell : deux vulnérabilités critiques permettent une exécution de code à distance
PHP vient de publier des correctifs pour deux vulnérabilités critiques affectant le cœur du langage de programmation : les CVE-2026-109618 et CVE-2026-109619. Surnommées PHP2Shell par plusieurs chercheurs, ces vulnérabilités peuvent permettre une exécution de code à distance sans authentification, notamment sur des serveurs PHP exposés à Internet.
Les versions corrigées sont disponibles dès maintenant. Il est recommandé à tous les utilisateurs de mettre à jour leurs installations immédiatement : le risque est considéré comme particulièrement élevé pour les environnements Apache mod_php, pour lesquels une exploitation avant l’exécution du code applicatif a été démontrée par les chercheurs.
Consulter l’avis officiel de PHP
Quelles sont les versions corrigées ?
Les versions suivantes intègrent les correctifs de sécurité :
Branche PHP | Version corrigée |
PHP 8.5 | 8.5.12 |
PHP 8.4 | 8.4.27 |
PHP 8.3 | 8.3.36 |
PHP 8.2 | 8.2.35 |
Les installations en PHP 8.1 et versions antérieures ne bénéficient plus du support de sécurité standard du projet PHP. Des correctifs peuvent toutefois être proposés par certains éditeurs, distributions Linux ou fournisseurs de support long terme. À défaut, une migration vers une branche supportée doit être planifiée rapidement.
PHP 8.2 reste corrigé dans cette publication, mais cette branche doit atteindre sa fin de vie le 31 décembre 2026. Une mise à niveau vers une version plus récente est donc à prévoir.
Les avis de sécurité publiés par PHP attribuent à ces vulnérabilités un score CVSS v4.0 de 9,2, correspondant à un niveau de criticité critique.
Advisory CVE-2026-109618 · Advisory CVE-2026-109619
Pourquoi cette alerte est-elle particulièrement importante ?
PHP est utilisé par un très grand nombre de sites web, de portails métiers et d’applications exposées sur Internet. Le risque ne concerne pas uniquement un framework ou un CMS particulier : toute application fonctionnant sur un moteur PHP vulnérable peut être exposée.
Des environnements WordPress, Drupal et Joomla ont notamment été utilisés dans des scénarios de démonstration. La mise à jour du CMS ne suffit pas nécessairement : c’est bien le runtime PHP sous-jacent qui doit être identifié et corrigé.
Selon le rapport du CERT Orange Cyberdefense fourni dans le cadre de cette analyse, des tentatives d’exploitation ont été observées après la divulgation des détails techniques. La disponibilité de preuves de concept publiques et la présence de plusieurs millions de services PHP exposés pourraient accélérer les campagnes d’attaque dans les prochains jours.
Les conséquences potentielles comprennent notamment :
- l’exécution de commandes avec les privilèges du processus web ;
- l’installation de logiciels malveillants ou de webshells ;
- l’accès à des secrets présents en mémoire, tels que des mots de passe, jetons ou clés d’API ;
- la modification du contenu des applications ;
- l’accès aux données traitées par le serveur ;
- un rebond vers d’autres composants du système d’information.
Quelles actions mener immédiatement ?
Les organisations concernées doivent traiter cette alerte comme une opération de remédiation prioritaire.
1. Identifier toutes les installations PHP exposées
L’inventaire doit couvrir les serveurs Internet, les environnements cloud, les conteneurs, les plateformes d’hébergement et les installations utilisées par des applications métiers. Il est important d’identifier :
- la version exacte de PHP ;
- le mode d’exécution utilisé :
mod_php, PHP-FPM, CGI, FrankenPHP ou LiteSpeed ; - les serveurs Apache et les applications accessibles depuis Internet ;
- les branches PHP en fin de vie ;
- les éventuelles installations non référencées dans l’inventaire central.
2. Mettre à jour vers une version corrigée
PHP recommande de migrer vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, selon la compatibilité de l’application et de la distribution utilisée.
Après la mise à jour, il faut également redémarrer les composants qui chargent le moteur PHP, notamment :
- Apache ;
- PHP-FPM ;
- les workers PHP persistants ;
- les conteneurs ou services concernés.
Mettre à jour uniquement WordPress, Drupal, Joomla ou une autre application ne corrige pas le moteur PHP lui-même.
3. Traiter les versions anciennes
Pour PHP 8.1 et les branches plus anciennes, il convient de vérifier la disponibilité d’un correctif rétroporté auprès de la distribution Linux, de l’éditeur ou du fournisseur de support. Si aucun correctif fiable n’est disponible, la migration vers une version supportée doit être accélérée.
4. Renforcer temporairement les contrôles
PHP documente plusieurs mesures de réduction d’exposition pour les organisations qui ne peuvent pas mettre à jour immédiatement. Elles peuvent notamment porter sur la limitation des requêtes multipart, la désactivation de certains chemins liés au suivi des téléversements et le contrôle des paramètres de mémoire et de taille des requêtes.
Ces mesures sont temporaires et incomplètes. Selon PHP, la mise à jour constitue la seule remédiation complète. Elles ne doivent donc pas retarder l’installation des versions corrigées.
5. Rechercher les signes d’exploitation
Les équipes de sécurité doivent examiner les journaux web, Apache, PHP-FPM, les systèmes de détection et les événements liés aux processus afin d’identifier :
- des requêtes anormalement volumineuses ou répétées ;
- des erreurs fatales inhabituelles ;
- des redémarrages fréquents de workers ;
- des créations ou modifications inattendues de fichiers ;
- des processus fils lancés par les services web ;
- des connexions sortantes inhabituelles depuis les serveurs PHP ;
- des accès suspects à des fichiers de configuration ou à des secrets.
Une absence d’alerte visible ne permet pas d’exclure une compromission. Les investigations doivent tenir compte de la rétention des journaux et de la visibilité disponible sur les serveurs concernés.
Le rôle de la threat intelligence face à cette vulnérabilité
Dans ce type de crise, la vitesse de réaction dépend autant de la disponibilité du correctif que de la capacité à identifier rapidement les actifs concernés, les tentatives d’exploitation et les éventuels signaux de compromission.
Le CERT Orange Cyberdefense peut accompagner les organisations dans :
- l’évaluation de leur exposition ;
- la priorisation des actifs vulnérables ;
- la qualification des versions et configurations PHP ;
- la recherche proactive d’indices de compromission ;
- la surveillance des campagnes d’exploitation ;
- la coordination entre équipes infrastructure, applicatives et sécurité ;
- la mise en place de mesures de détection et de réponse.
Conclusion : Les vulnérabilités CVE-2026-109618 et CVE-2026-109619 réunissent plusieurs facteurs de risque : une exposition potentiellement large, un impact de type exécution de code à distance, des preuves de concept disponibles et des signes de tentatives d’exploitation. Les organisations doivent prioriser l’inventaire des installations PHP exposées, l’application des versions corrigées et la vérification des journaux de sécurité. En cas de doute sur l’exposition ou sur les signes d’une compromission, une analyse spécialisée doit être engagée sans attendre.
Besoin d'aide pour évaluer votre exposition PHP ? : Le CERT Orange Cyberdefense peut vous aider à identifier les environnements concernés, prioriser les actions de remédiation et rechercher d’éventuels signes de compromission. Contactez nos équipes : cert-contact.ocd@orange.com
FAQ
Ces vulnérabilités concernent-elles uniquement WordPress ?
Non. Elles affectent le moteur PHP lui-même. WordPress, Drupal, Joomla et d’autres applications peuvent être exposés lorsqu’ils s’exécutent sur une version vulnérable de PHP.
La mise à jour de mon CMS suffit-elle ?
Non. Il faut mettre à jour le runtime PHP et redémarrer les services concernés. La mise à jour du CMS ne corrige pas automatiquement le moteur PHP installé sur le serveur.
PHP-FPM est-il concerné ?
PHP indique que toutes les installations PHP qui servent des requêtes web doivent être évaluées, y compris PHP-FPM. Le niveau d’exposition dépend notamment de la configuration, du serveur frontal et des chemins d’exécution utilisés.
Existe-t-il une mesure temporaire suffisante ?
Non. PHP précise que les mesures de réduction d’exposition ne constituent pas une remédiation complète. L’installation d’une version corrigée reste la seule solution définitive.
Les versions PHP 8.2 et antérieures sont-elles supportées ?
PHP 8.2 reçoit encore le correctif en version 8.2.35, mais cette branche doit arriver en fin de vie le 31 décembre 2026. Les versions 8.1 et antérieures ne sont plus couvertes par le support de sécurité standard de PHP.