PHP2Shell : ce que vous pouvez faire dès maintenant

Deux vulnérabilités critiques de PHP, surnommées PHP2Shell (CVE-2026-109618 et CVE-2026-109619), permettent à un attaquant d'exécuter du code sur un serveur web sans authentification. PHP obtient une note de 9,2 sur 10 pour ces vulnérabilités et des correctifs seront déployés le 21 octobre 2026 à 14h00 UTC. Des informations ont fuité la veille et des attaques ont déjà été signalées.

Si votre site utilise PHP, voici ce que vous pouvez faire dès aujourd'hui, de la solution définitive aux solutions temporaires. Pour plus d'informations techniques et un calendrier en temps réel, consultez la documentation. Avis de Sansec.

1. Mettez à jour PHP dès que possible.

La mise à jour de PHP est la seule véritable solution. Tout le reste dans cet article ne fait que réduire les risques en attendant.

• Versions corrigées attendues : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ces numéros proviennent de chercheurs en sécurité et de systèmes de suivi des distributions Linux ; PHP lui-même ne les confirme qu’avec la publication.
• Versions antérieures (8.1, 8.0, 7.x, 5.x) Ces systèmes sont en fin de vie et ne bénéficient d'aucune mise à jour officielle. Si vous utilisez l'un d'eux, prévoyez une mise à niveau dès maintenant et appliquez les solutions de contournement décrites ci-dessous.
• Vérifiez que votre paquet contient bien le correctif. Le numéro de version seul peut être trompeur, car les distributions intègrent souvent des correctifs a posteriori. Recherchez le numéro CVE dans le journal des modifications, par exemple avec Journal des modifications d'apt pour php8.3-cli (Debian/Ubuntu) ou rpm -q --changelog php (RHEL/Alma/Rocky).
• Redémarrez PHP après la mise à jour. (Par exemple systemctl restart php8.3-fpm), sinon l'ancien code continue de s'exécuter.
• Sur hébergement mutualisé, Demandez à votre hébergeur quand il déploiera la version corrigée de PHP.

2. Désactiver la progression du téléchargement de la session

Les premières analyses pointent du doigt la fonctionnalité de suivi de la progression des chargements de fichiers de PHP, activée par défaut et déclenchée lors du chargement d'un fichier. La désactiver et activer le mode de session stricte réduit les risques. Cependant, cela ne corrige pas la vulnérabilité, et les chercheurs en sécurité préviennent que cette solution pourrait ne bloquer qu'un seul des deux bugs.

Ajoutez ceci à php.ini, .user.ini ou les paramètres PHP de votre hébergeur :

session.upload_progress.enabled = Désactivé session.use_strict_mode = 1

Si vous utilisez PHP-FPM, vous pouvez également le configurer par pool :

php_admin_flag[session.upload_progress.enabled] = désactivé

Rechargez PHP ensuite. Très peu de sites utilisent des barres de progression de chargement basées sur cette fonctionnalité, donc cette modification ne provoque que rarement des dysfonctionnements.

3. Bloquer les téléchargements sur le serveur web (nginx)

Les vecteurs d'attaque connus exploitent les requêtes multipart, le format utilisé par les navigateurs pour le chargement de fichiers. Bloquer ces requêtes au niveau du serveur web les empêche d'atteindre PHP. Sansec recommande cette mesure à titre temporaire.

Ajoutez ceci à l'intérieur de votre serveur { } bloc, à l'extérieur de n'importe quel emplacement:

if ($http_content_type ~* "multipart/form-data") { rewrite ^ /__upload_blocked last; } location = /__upload_blocked { internal; default_type text/plain; return 403 "Le téléchargement est actuellement indisponible en raison d'un bug important. Il sera bientôt rétabli.\n"; }

Les visiteurs qui tentent de télécharger un fichier reçoivent désormais un message clair au lieu d'une simple page d'erreur. interne ligne signifie que personne ne peut ouvrir /__upload_bloqué directement, et vos autres pages d'erreur restent inchangées.

Tester et recharger :

nginx -t && nginx -s reload curl -i -F "x=1" https://yoursite.example/ curl -i -F "x=1" https://yoursite.example/some/subpage

Les deux boucle Les tests devraient renvoyer 403 avec le message. Si une sous-page se charge toujours, vérifiez que le si se trouve directement dans serveur { } et pas à l'intérieur d'un emplacement, et que vous avez modifié le serveur Ce bloc sert effectivement à l'affichage du site. Une requête de page normale, sans téléchargement, devrait toujours fonctionner.

4. Bloquer les téléchargements sur le serveur web (Apache / .htaccess)

Sur Apache 2.4, ajoutez ceci à la .htaccess dans le répertoire racine de votre document. Cela fonctionne n'importe où dans le fichier, y compris au-dessus ou en dessous des règles de votre CMS :

Erreur 403 : " Le chargement est actuellement impossible en raison d'un bug important. Ce service sera bientôt rétabli. " Accès refusé.

Apache refuse la requête avant même l'exécution des règles de réécriture, ce qui garantit que toutes les URL sont couvertes, et pas seulement la page d'accueil. Une version basée sur Réécrire la règle [F] Il est facile de se tromper : placé en dessous des règles d’un CMS, il bloque uniquement la page d’accueil tandis que les sous-pages atteignent toujours PHP.

• Utilisez le .htaccess Apache effectue en réalité la lecture pour votre site. Pour Magento 2, il s'agit souvent de celui-ci dans pub/.
• Un sous-dossier avec son propre .htaccess, comme une deuxième installation WordPress, peut nécessiter le même bloc.
• Une erreur 500 après l'enregistrement signifie généralement que votre hébergeur n'autorise pas ces directives. .htaccess. Demandez-leur de l'autoriser ou d'ajouter la règle dans la configuration du serveur.

Testez la page d'accueil et au moins une sous-page. Les deux devraient renvoyer une réponse. 403 avec le message :

curl -i -F "x=1" https://yoursite.example/ curl -i -F "x=1" https://yoursite.example/some/subpage

Si une sous-page renvoie toujours la page elle-même, le blocage n'est pas effectif pour cette URL.

À quoi s'attendre et quand y remédier

Le blocage du serveur web empêche toutes les requêtes multipart, et pas seulement les chargements de fichiers. Ces fonctionnalités cesseront de fonctionner jusqu'à ce que vous le supprimiez :

• Téléchargements de fichiers et d'images, y compris dans votre zone d'administration ou votre CMS
• Certains formulaires ordinaires, tels que les formulaires de contact ou de modification de produits, sont soumis en plusieurs parties.
• Les chargements en arrière-plan en JavaScript peuvent afficher une erreur générique au lieu de votre message.

Les paramètres PHP de l'étape 2 causent rarement des problèmes et peuvent être conservés. Supprimez le blocage du serveur web une fois PHP mis à jour et après avoir confirmé la correction dans le journal des modifications de votre paquet. Rechargez ensuite nginx ou Apache et effectuez un test de chargement.

Pour en savoir plus

• Vulnérabilités critiques d'exécution de code à distance (RCE) en PHP : CVE-2026-109618 et CVE-2026-109619 (Sansec) : avis, mesures d'atténuation et chronologie en direct
• Prochaine mise à jour critique de sécurité PHP (Annonce PHP)
• Alerte de sécurité majeure : PHP vulnérable à une exécution de code à distance critique (Patchstack)
• PHP2Shell : ce qui vous protège réellement avant le correctif (The Hacker News)

Dernière mise à jour : 21 octobre 2026