# Failles PHP php2shell : ce que les sites vidéo doivent savoir

**Source:** https://vodlix.com/fr/blog/php2shell-php-vulnerability-october-2026  
**Summary:** php2shell expliqué aux entreprises vidéo : les deux failles PHP corrigées le 21 octobre 2026, les versions à installer et comment Vodlix a protégé ses clients.  
**Published:** 2026-11-02  
**Publisher:** Vodlix

---

## Key takeaways

Le 21 octobre 2026, PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger php2shell, deux failles critiques qui peuvent permettre à un attaquant non authentifié d'exécuter du code sur un serveur PHP. Vodlix a appliqué le correctif avant que les failles ne soient publiques, et ses clients n'ont eu rien à faire.

- Si une partie de votre activité vidéo fait tourner PHP sur vos propres serveurs ou chez votre hébergeur, passez dès maintenant à une version corrigée, ou demandez à votre hébergeur de le faire.
- PHP 8.1 et les versions antérieures ne sont plus prises en charge : ces sites ont besoin d'une montée de version, pas seulement d'un correctif.
- Lisez les avis de votre hébergeur et de vos fournisseurs : AWS a publié le bulletin 2026-143-AWS le 21 octobre 2026.
- Sur une plateforme managée, le fournisseur applique ce type de mises à jour pour vous ; chez Vodlix, seul le middleware utilise PHP, et il a été corrigé.

Le 21 octobre 2026, le projet PHP a publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ces versions corrigent deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, le duo connu sous le nom de php2shell. Dans certaines conditions, elles permettent à un attaquant non authentifié d'exécuter du code sur un serveur qui fait tourner PHP. La [PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) le dit sans détour : si vous utilisez PHP, mettez à jour maintenant.

Vodlix a corrigé ses systèmes avant que les failles ne soient rendues publiques. Les clients Vodlix n'ont eu rien à faire.

Un correctif ne protège personne tant qu'il n'est pas installé sur votre serveur. Pour une entreprise vidéo, c'est à cela que se résume php2shell.

## Qu'est-ce que php2shell ? {#qu-est-ce-que-php2shell}

php2shell désigne deux failles d'exécution de code à distance liées dans PHP, CVE-2026-109618 et CVE-2026-109619. Toutes deux se situent dans la gestion de la mémoire et le traitement des erreurs, des parties de PHP que presque chaque requête sollicite. Les avis de sécurité du projet PHP les classent comme critiques, et les versions corrigées sont sorties le 21 octobre 2026.

La PHP Foundation et les avis du projet PHP désignent les failles par leurs numéros CVE ; utilisez donc ces numéros pour chercher dans les avis de vos fournisseurs et hébergeurs.

### CVE-2026-109618 : corruption de mémoire quand PHP manque de mémoire {#cve-2026-109618-corruption-de-mémoire-quand-php-manque-de-mémoire}

Si une requête atteignait la memory\_limit de PHP exactement au mauvais moment, PHP pouvait laisser derrière lui des données internes partiellement initialisées et les traiter ensuite comme valides. Sur Apache avec mod\_php, une requête non authentifiée peut déclencher ce comportement avant même l'exécution du code applicatif, et la PHP Foundation indique qu'une exécution de code à distance complète a été démontrée avec les réglages par défaut. L'exécution de code à distance a aussi été confirmée sur PHP-FPM via des chemins de code applicatif.

### CVE-2026-109619 : état résiduel hérité d'une requête précédente {#cve-2026-109619-état-résiduel-hérité-d-une-requête-précédente}

Une erreur fatale survenant au mauvais moment pouvait laisser un état interne pointant vers une mémoire appartenant à une requête précédente. Une requête ultérieure sur le même worker pouvait alors utiliser cette mémoire libérée. Selon la PHP Foundation, le rapporteur a démontré une exécution de code à distance contre une application réelle sur Apache avec mod\_php.

## Quelles versions de PHP corrigent la vulnérabilité php2shell ? {#quelles-versions-de-php-corrigent-la-vulnérabilité-php2shell}

Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, toutes publiées le 21 octobre 2026. Toute version antérieure de ces quatre branches est affectée, selon l'[avis du projet PHP pour CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w). Si vous utilisez PHP 8.1 ou une version plus ancienne, il n'existe aucun correctif pour votre branche.

| Votre branche PHP | Affectée | Mettre à jour vers |
| --- | --- | --- |
| 8.5 | En dessous de 8.5.12 | 8.5.12 |
| 8.4 | En dessous de 8.4.27 | 8.4.27 |
| 8.3 | En dessous de 8.3.36 | 8.3.36 |
| 8.2 | En dessous de 8.2.35 | 8.2.35 |
| 8.1 et antérieures | Plus prises en charge | Une branche prise en charge, comme 8.5.12 |

[TechCrunch](https://techcrunch.com/2026/10/21/php-armageddon-openai-googles-wiz-find-ancient-holes-panicking-the-internet/) rapporte que ces failles existent dans toutes les versions de PHP depuis PHP 5, sorti en 2004, et que PHP 8.1 et les versions antérieures ne sont plus prises en charge. Les sites sur ces versions ont plus de travail devant eux qu'une simple mise à jour mineure.

## Qui a découvert les failles, et quand ? {#qui-a-découvert-les-failles-et-quand}

Le chercheur Ryan A, de la société de sécurité Calif, a signalé la première exécution de code à distance à PHP le 11 août 2026, lors d'un audit commencé le 30 juillet 2026. Wiz et OpenAI ont ensuite signalé d'autres vecteurs d'attaque. La cause profonde remonte à un problème de mémoire que l'équipe PHP avait repéré pour la première fois en 2024.

Le récit de la PHP Foundation elle-même établit la chronologie des événements :

1. **2024 :** lors du premier audit de sécurité externe de PHP depuis des années, un développeur principal a trouvé les premiers signes du problème de dépassement de mémoire. Aucun vecteur d'attaque concret n'a été identifié à l'époque, et le correctif est resté en suspens.
2. **30 juillet 2026 :** Calif a commencé un audit de PHP dans le cadre du programme Patch the Planet.
3. **11 août 2026 :** Ryan A, de Calif, a signalé une exécution de code à distance inconditionnelle ayant la même cause profonde. OpenAI a signalé indépendamment la même cause profonde.
4. **24 août 2026 :** Wiz a signalé d'autres vecteurs d'attaque.
5. **18 septembre 2026 :** OpenAI a signalé d'autres vecteurs d'attaque.
6. **21 octobre 2026 :** PHP a publié les versions corrigées.

La Foundation ne cache pas ce retard : elle qualifie le délai écoulé depuis 2024 de « défaillance structurelle » du processus de décision de l'équipe de sécurité et de son manque de ressources, et indique que l'équipe change sa façon de travailler.

## Quelle est la gravité de php2shell, et comment Internet a-t-il réagi ? {#quelle-est-la-gravité-de-php2shell-et-comment-internet-a-t-il-réagi}

C'est grave parce que PHP est partout et que le pire scénario est un attaquant qui exécute du code sur votre serveur. TechCrunch rapporte que PHP fait tourner environ 70 % des sites web, et que la National Security Agency américaine a conseillé de mettre un site hors ligne s'il ne peut pas être corrigé immédiatement.

TechCrunch rapporte aussi que ces failles peuvent permettre aux attaquants d'accéder au système de fichiers d'un serveur ou à une base de données utilisée par l'application web. Au moment de son article du 21 octobre, OpenAI indiquait que les failles avaient été découvertes par des chercheurs avant les attaquants, sans aucun signalement d'exploitation active. La divulgation change la donne, puisque les détails sont désormais publics.

Les fournisseurs cloud ont réagi le jour même. [AWS a publié le bulletin de sécurité 2026-143-AWS](https://aws.amazon.com/security/security-bulletins/2026-143-aws/) le 21 octobre 2026, classé « Important (requires attention) », pour les environnements d'exécution web PHP affectés par les deux CVE.

## Que signifie php2shell pour une plateforme de streaming ou un site vidéo ? {#que-signifie-php2shell-pour-une-plateforme-de-streaming-ou-un-site-vidéo}

Cela signifie vérifier chaque partie de votre activité vidéo qui fonctionne avec PHP, pas seulement le lecteur. Un site de streaming, c'est une boutique, une connexion, un parcours de facturation et souvent un site marketing ou un blog. Si l'un de ces éléments fait tourner PHP sur un serveur que vous ou votre hébergeur gérez, il lui faut une version corrigée.

Ici, la sécurité n'est pas seulement une tâche informatique. C'est un enjeu commercial. Un site vidéo mis hors ligne en attendant un correctif cesse de vendre des abonnements et des locations pendant toute la durée de l'interruption.

WordPress est un cas fréquent. TechCrunch rapporte que WordPress a déclaré que la faille n'est pas propre à WordPress, et que les sites qui l'utilisent doivent corriger leurs serveurs et travailler avec leurs hébergeurs.

L'application des correctifs n'est qu'une couche de protection. Notre guide sur [les essentiels de la sécurité OTT pour votre contenu et vos spectateurs](https://vodlix.com/fr/blog/ott-security-essentials-safeguarding-your-content-and-viewers) couvre les autres, et notre page sur [la sécurité des connexions pour les plateformes de streaming](https://vodlix.com/fr/features/login-security) traite des comptes spectateurs.

## Comment Vodlix a-t-il géré php2shell ? {#comment-vodlix-a-t-il-géré-php2shell}

Vodlix a corrigé ses systèmes contre CVE-2026-109618 et CVE-2026-109619 avant que les failles ne soient rendues publiques le 21 octobre 2026. Chez Vodlix, seul le middleware utilise PHP, et c'est lui qui a été corrigé. Les clients Vodlix n'ont eu aucune action à entreprendre.

Sur une plateforme managée comme Vodlix, les mises à jour de sécurité de ce type sont appliquées pour vous. Si vous souhaitez signaler un problème de sécurité concernant Vodlix, écrivez à security@vodlix.com.

## Que faire si vous gérez vos propres sites PHP ? {#que-faire-si-vous-gérez-vos-propres-sites-php}

Mettez à jour chaque installation PHP que vous gérez vers une version corrigée, ou demandez à votre hébergeur de le faire, et lisez les avis de vos fournisseurs. Si vous ne pouvez pas mettre à jour immédiatement, suivez les recommandations de la NSA rapportées par TechCrunch et mettez le site hors ligne jusqu'à ce que vous le puissiez.

1. **Recensez ce qui fonctionne avec PHP.** Incluez votre site principal, tout site ou blog WordPress, les pages d'atterrissage et les outils d'administration.
2. **Vérifiez chaque version.** Comparez-la avec le tableau ci-dessus.
3. **Mettez à jour ou demandez à votre hébergeur.** Passez à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Chez un hébergeur managé, demandez-lui de confirmer la date de la mise à jour.
4. **Planifiez une montée de version pour les anciennes branches.** PHP 8.1 et les versions antérieures ne sont plus prises en charge : aucun correctif ne viendra pour elles.
5. **Lisez les avis de vos fournisseurs.** Commencez par votre hébergeur et votre fournisseur cloud. AWS en a publié un.
6. **Confirmez que la nouvelle version est bien en service.** Vérifiez à nouveau après la mise à jour, sur chaque serveur.

## Et maintenant ? {#et-maintenant}

Si vous êtes client Vodlix, vous n'avez rien à faire concernant php2shell. Pour toute question, consultez le [centre d'aide Vodlix](https://vodlix.com/fr/help) ou [contactez l'équipe Vodlix](https://vodlix.com/fr/contact).

Si vous envisagez une plateforme managée pour que ce type de mises à jour soit pris en charge à votre place, découvrez les [fonctionnalités de la plateforme Vodlix](https://vodlix.com/fr/features) ou [demandez une démo Vodlix](https://vodlix.com/fr/demo).

## Questions fréquentes

**Q: Qu'est-ce que php2shell ?**

php2shell est le surnom de deux vulnérabilités PHP critiques, CVE-2026-109618 et CVE-2026-109619. Les avis officiels, comme ceux de la PHP Foundation, utilisent les numéros CVE. Il s'agit de deux failles dans la gestion de la mémoire et le traitement des erreurs de PHP qui, dans certaines conditions, permettent à un attaquant non authentifié d'exécuter du code sur un serveur. PHP les a corrigées le 21 octobre 2026.

**Q: Quelles versions de PHP corrigent CVE-2026-109618 et CVE-2026-109619 ?**

PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent les deux vulnérabilités. Elles ont été publiées le 21 octobre 2026. Toute version antérieure des branches 8.5, 8.4, 8.3 et 8.2 est affectée. PHP 8.1 et les versions antérieures ne sont plus prises en charge ; les sites sur ces versions doivent donc passer à une branche prise en charge.

**Q: Les clients Vodlix doivent-ils faire quelque chose concernant php2shell ?**

Non. Chez Vodlix, seul le middleware utilise PHP, et Vodlix l'a corrigé avant que les failles ne soient rendues publiques le 21 octobre 2026. Les clients n'ont eu aucune action à entreprendre. Si vous souhaitez signaler un problème de sécurité concernant Vodlix, vous pouvez écrire à security@vodlix.com.

**Q: WordPress est-il concerné par la vulnérabilité PHP d'octobre 2026 ?**

WordPress fonctionne avec PHP, donc les sites WordPress sont exposés via la version de PHP du serveur. TechCrunch rapporte que WordPress a déclaré que la faille n'est pas propre à WordPress, et que les sites qui l'utilisent doivent corriger leurs serveurs et travailler avec leurs hébergeurs. Mettre à jour WordPress lui-même ne remplace pas la mise à jour de PHP.

**Q: php2shell a-t-il été exploité avant la sortie du correctif ?**

TechCrunch a rapporté le 21 octobre 2026 que, selon OpenAI, les failles avaient été découvertes par des chercheurs avant les attaquants et qu'aucune exploitation active n'avait été signalée à ce moment-là. Maintenant que les détails sont publics, les serveurs non corrigés courent un risque accru, raison pour laquelle la NSA a conseillé de mettre hors ligne les sites qui ne peuvent pas être corrigés.

**Q: Que faire si je ne peux pas mettre à jour PHP immédiatement ?**

TechCrunch rapporte que la National Security Agency américaine a conseillé de mettre hors ligne tout site web qui ne peut pas être corrigé immédiatement, jusqu'à ce qu'il puisse l'être. Demandez à votre hébergeur quand il appliquera PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, et lisez son avis ainsi que celui de votre fournisseur cloud, comme le bulletin AWS 2026-143-AWS.