Vulnerabilites critiques dans le coeur de PHP — PHP2Shell

Le Centre de Reponse aux Incidents de Securite Informatique (CIRT.cm) alerte les organisations camerounaises sur la divulgation, le 21 octobre 2026, de plusieurs vulnerabilites critiques affectant le moteur du langage PHP. Regroupees sous le nom de code PHP2Shell, ces failles permettent a un attaquant non authentifie d’executer du code arbitraire sur un serveur web, quelle que soit l’application qui y tourne.

Le detail qui rend cette alerte exceptionnelle tient en une phrase : PHP alimente environ 70 % des sites web dans le monde, dont WordPress, Drupal, Joomla et MediaWiki — l’infrastructure qui fait tourner Wikipedia. Toutes les versions publiees depuis PHP 5.4 sont touchees. Autrement dit, une faille dans le moteur concerne des millions de serveurs independamment de la qualite du code applicatif qu’ils hebergent. Un simple programme affichant « Bonjour le monde » est vulnerable s’il tourne sur une version non corrigee.

Les vulnerabilites ont ete decouvertes par les equipes de recherche de Wiz, avec l’appui de modeles d’intelligence artificielle de derniere generation. Elles dormaient dans la base de code depuis plus de dix ans. Ce qui a change, c’est le cout de l’exploitation : la ou un chercheur humain devait enchainer plusieurs bugs et adapter un exploit a chaque configuration memoire, un modele d’IA le fait aujourd’hui en quelques heures. C’est le point de bascule que les analystes redoutaient.


Vulnerabilites identifiees

CVE Score CVSS Nature de la faille Impact
CVE-2026-109618 9.8 — Critique Use-after-free dans le deserialiseur de progression d’upload. Une erreur de memoire insuffisante (OOM) interrompt le traitement et laisse l’etat interne de PHP corrompu. Divulgation de la memoire du processus (mots de passe, jetons, cles API, certificats) et execution de code a distance sans authentification.
CVE-2026-109619 9.8 — Critique Use-after-free sur l’etat global conserve entre les requetes. Un worker reutilise un pointeur vers une memoire deja liberee, combine a une confusion de type dans OPcache. Corruption de la memoire partagee et execution de code a distance sans authentification.

Versions corrigees : PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les branches 8.1 et inferieures ne recoivent plus de correctifs de securite et doivent etre abandonnees.


Pourquoi cette faille differe des precedentes

Les chercheurs ont construit un script unique, baptise php2shell, capable d’executer du code a distance sur des deployments WordPress, Drupal et Joomla a jour, en utilisant leurs images de conteneurs officielles les plus recentes. Ce n’est pas une faille dans WordPress ou dans Drupal : c’est le moteur commun sous-jacent qui est en cause.

Un second scenario, plus discret mais tout aussi grave, permet de lire la memoire du processus PHP sans meme executer de code. Dans un environnement mutualise — un hebergement partageant un meme worker entre plusieurs sites — cela signifie qu’un attaquant peut recuperer les identifiants de connexion, les cles d’API ou les certificats d’un autre client heberge sur la meme machine. C’est le meme mecanisme que Heartbleed en 2014, applique a PHP.

Une difficulte supplementaire pour les equipes de defense : ces attaques s’executent sous la couche applicative. Les journaux de l’application peuvent ne conserver presque aucune trace exploitable. Les chercheurs recommandent donc de surveiller particulierement les requetes multipart inhabituelles suivies d’erreurs de limite memoire ou de reponses HTTP 500 repetees.


Menaces actives

  • PHP2Shell — Chaine d’exploitation complete publiee, avec demonstrations video sur WordPress, Drupal et Joomla. Le code n’est pas encore largement distribue mais la publication des details techniques ouvre la voie a des adaptations rapides.
  • Divulgation memoire a l’echelle — Technique d’extraction de secrets depuis la memoire des workers PHP, sans authentification. Risque majeur pour les hebergeurs mutualises et les plateformes multi-tenant.
  • Variantes non identifiees — Les deux CVE ne couvrent que quatre instances exploitables d’un meme defaut architectural. Les chercheurs signalent l’existence d’autres variantes suivies et probablement non suivies dans la base de code.

Ce qu’il faut retenir

Il ne s’agit pas d’une faille dans un plugin, un theme ou un module. C’est le moteur qui execute le code de votre site qui est atteignable. La correction fournie par l’equipe PHP traite le defaut a sa racine et elimine l’ensemble des variantes connues. Pour les organisations camerounaises qui hebergent leurs services sur des mutualisees ou des plateformes non maitrisees, la verification de la version PHP aupres du prestataire devient une priorite immediate.

Pour celles qui ne peuvent pas appliquer le correctif sans delai, les grands fournisseurs de cloud et de CDN — Cloudflare, AWS, Microsoft, Google, Akamai, Fastly, Imperva, Vercel, Automattic — ont mis en place des regles de protection. Ces mesures d’attenuation ne remplacent pas la mise a jour.


Operations ciblant l’Afrique

Aucune campagne specifiquement dirigee contre le Cameroun ou l’Afrique de l’Ouest n’a ete rapporte a ce stade, la divulgation datant de moins de vingt-quatre heures. La nature de la faille rend toutefois le continent particulierement expose : le parc web africain repose massivement sur PHP, souvent via WordPress, et une part importante des sites institutionnels et commerciaux est hebergee sur des offres mutualisees ou la version du moteur n’est ni connue ni maitrisee par le proprietaire du site. Un scan de masse sur les adresses africaines est le scenario le plus probable dans les prochains jours. Le CIRT.cm maintient sa veille et diffusera une mise a jour si des indicateurs de compromission sont identifies sur le territoire.


Actions recommandees

  1. Identifier la version PHP de chaque serveur web et application exposee. Toute version inferieure a 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 doit etre consideree comme vulnerable.
  2. Appliquer les correctifs vers PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 sans attendre le cycle de maintenance habituel.
  3. Migrer hors des branches 8.1 et anterieures, qui ne recoivent plus de mises a jour de securite.
  4. Interroger votre hebergeur sur la version du moteur PHP utilisee et sur son calendrier de mise a jour si vous etes sur une offre mutualisee.
  5. Activer les regles de protection proposees par votre fournisseur de CDN ou de pare-feu applicatif pour les applications qui ne peuvent pas etre corrigees immediatement.
  6. Surveiller les requetes multipart inhabituelles suivies d’erreurs de limite memoire, de redemarrages de workers ou de series de reponses HTTP 500.
  7. Renouveler par precaution les secrets applicatifs (cles d’API, jetons d’acces, identifiants de base de donnees) des services qui ont ete exposes sur un serveur PHP non corrige, la divulgation memoire permettant leur extraction.
  8. Signaler tout incident a incidents@cirt.antic.cm ou au numero vert 8202.

Sources : NVD NIST, avis de securite php-src GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp, Wiz Research, Openwall oss-security, CISA KEV.
Reference CIRT : CIRT-AL-2026-10-21-2

By CIRT-CM

Leave a Reply

Your email address will not be published. Required fields are marked *