Failles critiques dans PHP (PHP2Shell) : la marche à suivre pour sécuriser vos infrastructures

Chez AXOPEN, en tant qu'experts du développement, on sait que la sécurité n'attend pas. Le 21 octobre dernier, dès l’annonce de la faille PH2Shell, nous nous sommes très vite mobilisés pour sécuriser les projets de nos clients. Maintenant que le rush est passé, faisons le point étape par étape, avec des commandes et un script que vous pouvez appliquer immédiatement sur vos projets

PHP2Shell : Comprendre ce qui s'est passé

Le projet PHP a publié un avis de sécurité concernant deux vulnérabilités critiques, toutes deux notées 9,2 sur l'échelle CVSS (Common Vulnerability Scoring System) v4.0 :

• CVE-2026-109618 : une exécution de code à distance liée à la corruption de la mémoire lors d'une erreur de mémoire insuffisante.
• CVE-2026-109619 : une exécution de code à distance liée à un état interne obsolète, réutilisé par une requête suivante dans le même processus.

Ces failles se situent dans le moteur de PHP, pas dans un framework (Symfony, Laravel) ou un CMS. D'après les éditeurs de sécurité, elles ont été identifiées avec l'aide d'outils d'intelligence artificielle, puis corrigées en coordination avec la PHPLangage de programmation s’exécutant côté serveur et permettant la création dynamique de pages web ou d'APIs. Foundation. Leurs détails ayant fuité avant la date prévue, la publication a été avancée, et des tentatives d'exploitation ont été observées. L'agence américaine CISA recommande une mise à jour immédiate.

Les versions corrigées sont :

Note : le projet PHP précise qu'il n'existe pas de solution de contournement complète. Seule la mise à jour règle le problème.

Quelles versions sont concernées par la faille PHP ?

Selon l'avis officiel, toutes les installations de PHP qui servent des requêtes web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé avec mod_php. Si PHP ne sert que des commandes en ligne (tâches planifiées, workers), l'exposition directe est moindre, mais mettez-le à jour dans la foulée.

Pour connaître la version exacte utilisée par votre conteneur :

docker compose exec php php -v

Les versions PHP 8.1 et antérieures ne reçoivent plus de correctifs du projet. Seuls certains fournisseurs de support à long terme proposent des correctifs rétroportés : contactez le vôtre, ou migrez vers une version maintenue.

PHP2Shell : la marche à suivre pour sécuriser vos infrastructures

Mettre à jour avec Docker

Étape 1 : reconstruire l'image

Si votre Dockerfile part d'une image officielle comme php:8.4-fpm, il faut forcer le téléchargement de la dernière version de l'image PHP et ignorer le cache :

docker compose build --pull --no-cache php
docker compose up -d php

Étape 2 : vérifier le résultat

docker compose exec php php -v

La sortie doit afficher une version égale ou supérieure à celles du tableau (par exemple PHP 8.4.27). Si ce n'est pas le cas, vérifiez que le tag de votre image pointe bien vers la dernière version, ou fixez-le explicitement (par exemple php:8.4.27-fpm).

Attention : si vous utilisez les paquets de votre distribution Linux, la version affichée peut rester inchangée malgré le correctif, car les éditeurs rétroportent souvent les corrections. Consultez alors le journal des changements du paquet.

Automatiser la vérification

La magie : plutôt que de vérifier à la main, faites bloquer votre pipeline si la version de PHP est trop ancienne. Créez le fichier bin/check-php-security.php :

<?php

// Versions minimales corrigées (avis de sécurité du 21 octobre 2026)
const PATCHED_VERSIONS = [
    '8.5' => '8.5.12',
    '8.4' => '8.4.27',
    '8.3' => '8.3.36',
    '8.2' => '8.2.35',
];

$branch = PHP_MAJOR_VERSION . '.' . PHP_MINOR_VERSION;

if (!isset(PATCHED_VERSIONS[$branch])) {
    fwrite(STDERR, sprintf(
        "PHP %s : branche non maintenue. Vérifiez le correctif auprès de votre fournisseur ou migrez.\n",
        PHP_VERSION
    ));
    exit(1);
}

if (version_compare(PHP_VERSION, PATCHED_VERSIONS[$branch], '<')) {
    fwrite(STDERR, sprintf(
        "PHP %s vulnérable : mettez à jour vers %s ou supérieur.\n",
        PHP_VERSION,
        PATCHED_VERSIONS[$branch]
    ));
    exit(1);
}

echo sprintf("PHP %s : version corrigée.\n", PHP_VERSION);

Testez-le en local :

docker compose exec php php bin/check-php-security.php

Puis ajoutez un job à votre pipeline, ici au format GitLab CI. Il doit s'exécuter dans l'image de votre application, et non dans une image générique :

check-php-security:
  stage: test
  image: mon-registre/mon-app:$CI_COMMIT_SHA
  script:
    - php bin/check-php-security.php

Le script renvoie un code d'erreur si la version est vulnérable : le déploiement s'arrête avant d'atteindre la production.

Faille PHP : que faire si on ne peut pas déployer le correctif complet rapidement ?

Le projet PHP liste des mesures qui réduisent l'exposition à certains chemins d'attaque, sans rendre l'installation sûre. À appliquer dans la configuration du serveur (php.ini ou pool PHP-FPM), et non avec ini_set() :

; php.ini : puis redémarrer tous les processus PHP
session.upload_progress.enabled = 0
; PHP 8.5 uniquement
fatal_error_backtraces = 0

; Pool PHP-FPM : valeurs non modifiables par les applications
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M

Avec memory_limit illimité, limitez les ressources au niveau du conteneur pour éviter qu'un processus n'épuise la machine. Si votre application a besoin d'envois de fichiers, l'avis recommande une limite post_max_size de 32 Mo plutôt que 8 Mo.

PHP2Shell : un rappel de l'importance des mises à jour !

Cet incident montre que la sécurité ne s'arrête pas au code de votre application : le moteur qui l'exécute compte autant.

Envie de passer au niveau supérieur ? Profitez de cette mise à jour pour planifier la migration de vos projets vers PHP 8.4 ou 8.5, et ajoutez dès maintenant le script de vérification à votre pipeline ! Et si vous avez besoin d’aide, n’hésitez pas à nous contacter.