Liste de contrôle de sécurité PHP : 8 étapes pour détecter et corriger les vulnérabilités

php icon.
Responsable de la section Engineering
Expert certifié
Chaque article publié sur Innowise est rédigé par des auteurs dotés d'une expérience concrète. Ils maîtrisent le sujet au-delà de la théorie et apportent un éclairage issu de projets réels.
7+ ans d'expérience
Expert certifié
7+ ans d'expérience
Herman dirige des départements d'ingénierie et met en place les processus, les structures d'équipe et les normes techniques dont ceux-ci ont besoin pour se développer. Son expertise porte sur les systèmes backend à forte charge, la gestion des livraisons et le leadership en ingénierie.
Expertise
Systèmes à forte charge Architecte de logiciel Bases de données
Parlons-en

Principaux enseignements

  • PHP2Shell nécessite une mise à jour urgente. Le 21 octobre 2026, PHP a corrigé les vulnérabilités CVE-2026-109618 et CVE-2026-109619. Il s’agit dans les deux cas de vulnérabilités critiques d’exécution (CVSS v4.0 : 9,2) pouvant permettre l’exécution de code à distance sans authentification.
  • Vérifiez les versions corrigées. Les premières versions corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les distributions Linux peuvent fournir les mêmes correctifs via des correctifs rétroportés.
  • Donnez la priorité aux environnements d’exécution PHP exposés. Le module mod_php d’Apache présente le risque le plus élevé signalé, mais PHP-FPM et d’autres configurations exposées au Web nécessitent également une attention particulière. Les mises à jour des frameworks et l’audit Composer ne corrigeront pas la vulnérabilité PHP2Shell.
  • Ne vous contentez pas d’appliquer des correctifs à PHP. Utilisez la liste de contrôle en huit étapes pour passer en revue les dépendances, le code des applications, les paramètres du serveur et d’autres failles de sécurité.
  • Vérifiez que le correctif fonctionne en production. Demandez à votre équipe un rapport indiquant quelles versions de PHP sont effectivement en cours d’exécution, quelles charges de travail ont été corrigées et s’il existe des signes d’une compromission antérieure.
Résumé par l'IA

Selon W3Techs, PHP alimente environ 70 % des sites web dont le langage côté serveur est connu. Comme PHP est si répandu, une vulnérabilité dans l’interpréteur peut mettre de nombreux sites en danger, même si leur propre code est sécurisé.

Le 21 octobre 2026, le projet PHP a publié des correctifs d’urgence pour deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, regroupées sous le nom de PHP2Shell. Toutes deux ont obtenu un score de 9,2 selon le CVSS v4.0 et permettent l’exécution de code à distance sans authentification. Ces failles affectent la mémoire interne et la gestion des requêtes de PHP.

Les premiers correctifs ont été publiés dans les versions PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Si votre système utilise l’une des versions concernées, mettez à jour PHP immédiatement et assurez-vous que votre serveur web exécute la version corrigée. Mais le travail ne doit pas s’arrêter là. Pour les équipes qui développent et assurent la maintenance d’applications PHP, notamment les spécialistes du développement InnowisePHP spécialistes du développement, la version d’octobre est également l’occasion de passer en revue les dépendances, le code des applications et les paramètres du serveur.

Dans ce guide, je vais vous présenter huit étapes pour détecter et corriger les vulnérabilités de votre configuration PHP et vérifier que vos correctifs fonctionnent en production.

Analyse d'expert : en quoi PHP2Shell diffère-t-il d'une vulnérabilité CVE liée à une dépendance courante ?

Un paquet Composer vulnérable affecte le code utilisé par votre application. PHP2Shell est différent. Ces deux vulnérabilités se trouvent au sein même de l'interpréteur PHP, et un attaquant peut les exploiter avant Laravel, Symfony ou tout autre framework ne commence même pas à s’exécuter. La mise à jour des plugins CMS ou des dépendances Composer ne corrigera pas PHP, et l’audit Composer ne détectera pas ces vulnérabilités d’exécution.

L’équipe de sécurité PHP identifie Apache mod_php comme la configuration présentant le risque le plus élevé pour la vulnérabilité CVE-2026-109618, avec une attaque démontrée qui fonctionne avant même l’exécution du code de l’application. PHP-FPM, CGI et d’autres configurations de serveurs web sont également concernées, bien que les conditions d’exploitation diffèrent. Des chercheurs ont également démontré l’exploitation de la vulnérabilité CVE-2026-109619 contre PHP-FPM.

Voici ce qui ne fonctionne pas dans chaque cas :

CVECause premièrePourquoi les équipes devraient s'y intéresser
CVE-2026-109618Si PHP vient à manquer de mémoire lors du traitement d'une requête, certaines données internes peuvent se retrouver dans un état invalide. Lorsque PHP nettoie la requête ayant échoué, il peut utiliser ces données.Si PHP vient à manquer de mémoire lors du traitement d'une requête, certaines données internes peuvent se retrouver dans un état invalide. Lorsque PHP nettoie la requête ayant échoué, il peut utiliser ces données.
CVE-2026-109619Un PHP worker peut conserver une référence à de la mémoire qui a été libérée après une requête précédente. Lorsque le worker traite une autre requête, il peut tenter d'utiliser cette ancienne référence.Le problème peut se répercuter d'une requête à l'autre traitées par le même worker. Vérifier chaque requête de l'application ne permettra pas forcément de le détecter.

Ces deux failles peuvent permettre l'exécution de code à distance sans authentification. Le correctif concerne le moteur d'exécution PHP, et non les dépendances de l'application.

Pour une explication technique plus détaillée, vous pouvez consulter les avis de sécurité du projet PHP concernant CVE-2026-109618 et CVE-2026-109619.

D'où proviennent les failles de sécurité de PHP ?

Comme je l’ai mentionné précédemment, la mise à jour de PHP ne résoudra pas le problème d’un paquet Composer vulnérable, et une analyse complète des dépendances ne permettra pas de détecter les problèmes présents dans votre propre code. Lorsque j’examine une application PHP, je m’intéresse à quatre sources de risques de sécurité, chacune ayant ses propres conséquences potentielles.

CatégorieExemplesRisque principal
Environnement d'exécution PHPVersions non mises à jour de PHP, vulnérabilités de l'interpréteur, versions non prises en chargeLes pirates exploitent des failles dans PHP lui-même, quel que soit le niveau de sécurité avec lequel l'application a été développée.
Dépendances de tiersPackages Composer, plugins CMS, frameworksUn code tiers vulnérable expose les applications à des attaques, même lorsque votre propre code est sécurisé
Code de l'applicationInjection SQL, XSS, CSRF, désérialisation non sécurisée, contrôle d'accès défaillantDes failles de codage peuvent permettre à des pirates de voler des données, d'effectuer des actions non autorisées ou de compromettre l'application
Configuration et infrastructureParamètres PHP non sécurisés, fichiers exposés, droits d'accès excessifsDes erreurs de configuration peuvent exposer des informations sensibles ou accorder aux pirates un accès plus étendu que prévu.

Remédiez aux failles de sécurité PHP avant qu'elles ne s'aggravent

Liste de contrôle de sécurité PHP : 8 vérifications indispensables

Passons maintenant en revue les huit contrôles de sécurité que j’effectuerais sur une application PHP existante. Je commencerais par l’environnement d’exécution PHP traitant les requêtes en temps réel, puis j’examinerais le code, les dépendances et la configuration à la recherche de problèmes qu’une simple mise à jour PHP ne suffirait pas à résoudre.

Vérifiez votre version de PHP et les correctifs de sécurité

Commencez par identifier les environnements d’exécution PHP utilisés par vos applications : Apache mod_php, PHP-FPM, php-cgi, FrankenPHP ou LiteSpeed. Tenez compte des pools FPM, des conteneurs, des installations CLI, des workers de file d’attente et des tâches planifiées distincts.

Ne vous fiez pas uniquement à php -v ou php –ini. php -v affiche la version CLI, tandis que php –ini affiche sa configuration. Aucune de ces commandes ne permet de confirmer quel environnement d'exécution PHP traite les requêtes Web.

Comparez l’environnement d’exécution actif et sa configuration avec le avis officiel PHP, y compris les versions concernées et les conditions d’exposition. Le module mod_php d’Apache présente la vulnérabilité PHP2Shell la plus grave qui ait été démontrée, avec notamment une voie d’exploitation avant même l’exécution du code de l’application. La vulnérabilité de PHP-FPM dépend de la configuration et des chemins d’exécution. D’autres SAPI doivent également faire l’objet d’une évaluation, car la SAPI à elle seule ne permet pas de déterminer si un déploiement est sûr.

Les premières versions en amont contenant les deux correctifs étaient :

Branche PHPPremière version corrigée
8.28.2.35
8.38.3.36
8.48.4.27
8.58.5.12

Ces versions sont répertoriées dans les avis de sécurité PHP concernant CVE-2026-109618 et CVE-2026-109619. Vérifiez s'il existe des versions de sécurité plus récentes avant de procéder à la mise à jour.

Vérifier les correctifs PHP sous Linux et dans les conteneurs

Vérifiez l'environnement d'exécution actif. Vérifiez la configuration de votre serveur web pour identifier le module PHP, le pool FPM ou le SAPI intégré qui traite les requêtes. Vérifiez sa version à l’aide de diagnostics à accès restreint, puis supprimez tous les points de terminaison temporaires. N’exposez jamais publiquement phpinfo() ou un point de terminaison de version.

Vérifiez les paquets installés. Sous Ubuntu avec PHP 8.3, ces commandes en lecture seule affichent les paquets installés et les versions disponibles :

dpkg-query -W 'php8.3*'
apt-cache policy php8.3-fpm

Adaptez les noms des paquets en fonction de votre branche PHP et comparez les versions installées avec l’avis de sécurité du fournisseur ou le journal des modifications du paquet. Les éditeurs Linux peuvent rétroporter des correctifs vers des versions plus anciennes de PHP. Par exemple, Ubuntu répertorie ces versions corrigées :

  • Ubuntu 24.04 : 8.3.6-0ubuntu0.24.04.13

  • Ubuntu 22.04 : 8.1.2-1ubuntu2.28

Ces deux versions contiennent les correctifs nécessaires malgré leurs numéros de version inférieurs. Consultez l"avis de sécurité d’Ubuntu.

Appliquez les correctifs et redéployez. Installez les paquets corrigés. Pour les conteneurs, enregistrez le hachage de l’image en cours d’exécution, mettez à jour les images de base PHP vulnérables, recompilez et redéployez les charges de travail concernées, y compris les travailleurs de file d’attente.

Vérifiez le résultat. Redémarrez ou remplacez les PHP workers concernés et assurez-vous que les processus et conteneurs en cours d’exécution utilisent des versions corrigées ou des backports vérifiés par le fournisseur. Enregistrez les versions des paquets, les hachages des images en cours d’exécution, les détails du redémarrage et les résultats de la vérification.

PHP 8.1 et les versions antérieures ne sont plus prises en charge en amont, bien que certains fournisseurs proposent encore des backports de sécurité. Vérifiez si votre version installée est prise en charge et effectuez une mise à niveau si ce n’est pas le cas. Le support de sécurité de PHP 8.2 prend fin le 31 décembre 2026 ; veillez donc à associer tout correctif à court terme à un plan de mise à niveau. Vous trouverez le calendrier complet de prise en charge dans le calendrier de prise en charge de PHP.

Dépendances et cadres d'audit

Commencez par composer.lock. Ce fichier répertorie les versions des paquets dont dépend votre application, y compris celles installées indirectement via d’autres paquets. Exécutez ces deux commandes :

composer audit --locked
composer outdated

composer audit --locked vérifie les versions verrouillées par rapport aux avis de sécurité connus et peut signaler les paquets abandonnés. composer outdated indique les mises à jour disponibles, mais un paquet obsolète n’est pas nécessairement vulnérable. Vérifiez également les avis de Laravel ou de Symfony, en particulier si la version de votre framework n’est plus prise en charge.

Comparez les paquets déployés en production avec les versions figurant dans le fichier lock audité. Conservez les résultats de l’audit et l’inventaire des paquets installés avec vos archives de versions.

Si vous identifiez des paquets vulnérables, mettez-les à jour vers des versions corrigées compatibles et testez les fonctionnalités concernées. Remplacez les bibliothèques qui ne bénéficient plus de correctifs de sécurité. Si des problèmes de compatibilité empêchent la mise à niveau d’un framework, documentez-les ainsi que le travail de migration nécessaire. Ne négligez pas les plugins CMS ou les bibliothèques installées en dehors de Composer.

Un audit Composer sans anomalie ne garantit pas que la vulnérabilité PHP2Shell soit corrigée. L’audit vérifie les paquets Composer, tandis que PHP2Shell nécessite une vérification distincte de l’interpréteur PHP et de ses correctifs. Pour évaluer l’application elle-même, utilisez SAST pour analyser le code source et DAST pour tester l’application en exécution.

Vérification PHP et des configurations du serveur

Vérifiez les paramètres PHP effectivement utilisés par votre serveur web, y compris les modifications apportées au pool PHP-FPM et les extensions chargées. N’oubliez pas que php --ini affiche la configuration CLI, qui peut différer de celle de l’application en production.

En production, commencez par :

display_errors = Off
log_errors = On

Conservez les journaux en dehors des répertoires accessibles au public et limitez leur accès. Supprimez les pages phpinfo() publiques et les points de terminaison de débogage, puis vérifiez le paramètre expose_php, les extensions inutiles et les droits d’accès au système de fichiers.

La désactivation de display_errors réduit la divulgation d’informations, mais ne permet pas d’atténuer la vulnérabilité CVE-2026-109619. Le chemin d’exécution vulnérable peut s’exécuter avant que PHP ne traite le message d’erreur.

Mesures temporaires en cas de retard dans l’application du correctif PHP

Si l’application du correctif doit être reportée, suivez les instructions de l"avis officiel PHP correspondant à votre configuration.

  • CVE-2026-109619 : Désactivez session.upload_progress.enabled et, sous PHP 8.5, définissez fatal_error_backtraces=0. Appliquez ces paramètres avant le traitement des requêtes via la configuration du serveur ou du pool, puis redémarrez les workers concernés. D’autres vecteurs d’exploitation peuvent subsister.

  • CVE-2026-109618 : Appliquez memory_limit=-1 au niveau du serveur ou du pool, puis redémarrez les workers concernés. Cela supprime la faille prévisible liée à la limite de mémoire PHP, mais d’autres défaillances d’allocation restent possibles. Vérifiez les limites des requêtes et les protections de mémoire de l’hôte ou du conteneur afin de réduire les risques de déni de service.

PHP a également publié un avis distinct concernant la vulnérabilité CVE-2026-115560 le 23 octobre. Elle concerne les applications qui basculent session.serialize_handler de php_binary ou php_serialize vers php à l’aide de ini_set() avant session_start(), avec la progression du téléchargement activée. Les installations concernées doivent désactiver l’affichage de la progression du téléchargement en attendant un correctif.

Optez pour un plan de mise à niveau pour les anciennes applications PHP dont dépend votre entreprise

Vérifier la présence d'injections SQL, de XSS et d'exécution de code non sécurisé

Une mauvaise gestion des données saisies par l'utilisateur peut exposer des données sensibles ou permettre à des attaquants d'exécuter du code malveillant. Je vous recommande d'utiliser la révision de code pour identifier les chemins de saisie à risque et le SAST pour signaler les vulnérabilités potentielles. Le DAST autorisé teste l’application en exécution, tandis que les tests d’intrusion permettent de déterminer quelles failles les attaquants pourraient exploiter. Les applications développées via le vibe coding peuvent présenter les mêmes failles et nécessitent les mêmes vérifications.

Injection SQL

Une injection SQL se produit lorsque les données saisies par l'utilisateur modifient la structure d'une requête de base de données. Vérifiez la manière dont votre application construit les requêtes, en particulier dans les formulaires de recherche et les rapports.

Pour séparer les données saisies par l'utilisateur des commandes SQL, utilisez les instructions préparées PDO :

$stmt = $pdo->prepare(
    'SELECT id FROM users WHERE email = :email'
);
$stmt->execute(['email' => $email]);

Les instructions préparées séparent les valeurs des données de la syntaxe SQL, comme le fait l'espace réservé :email dans l'exemple. Cependant, les placeholders ne peuvent pas représenter des noms de tables ou de colonnes. Par exemple, si les utilisateurs peuvent trier un rapport, sélectionnez les colonnes autorisées dans une liste définie dans l’application. Testez les requêtes concernées après avoir effectué les modifications.

Cross-site scripting

Une attaque de type ' cross-site scripting ' (XSS) se produit lorsqu’une application affiche des données non fiables qu’un navigateur peut exécuter en tant que code. Vérifiez les modèles PHP pour vous assurer que les données saisies par l’utilisateur ne sont pas affichées sans échappement approprié, en particulier lorsque l’échappement automatique est désactivé.

Par exemple, si votre application affiche le nom d’un utilisateur sous forme de texte HTML, utilisez htmlspecialchars() pour convertir les caractères spéciaux afin que le navigateur les traite comme du texte :

echo htmlspecialchars(
    $name,
    ENT_QUOTES | ENT_SUBSTITUTE,
    'UTF-8'
);

La protection appropriée dépend de l’endroit où les données apparaissent. JavaScript, les URL et les attributs HTML nécessitent des vérifications et un encodage spécifiques au contexte. Si les utilisateurs peuvent soumettre du HTML formaté, utilisez un sanitiseur HTML pour supprimer les éléments dangereux tout en conservant la mise en forme autorisée.

Code non sécurisé et exécution de commandes

Some PHP functions can execute system commands or PHP code. Check whether untrusted input reaches exec(), shell_exec(), or eval(). Also review dynamic file inclusion and the use of unserialize() with data from untrusted sources.

Where possible, use a PHP API instead of running a shell command. If you need to start an external program, specify the executable and pass its arguments separately. Here’s an example using Symfony Process:

use Symfony\Component\Process\Process;

// Validate $filePath against approved paths first.
$process = new Process([
    '/usr/bin/file',
    '--',
    $filePath
]);
$process->mustRun();

This example uses the file utility to identify a file’s type. Symfony Process passes $filePath as a separate argument rather than inserting it into a shell command string. You still need to validate the path, restrict the service account’s filesystem access, and allow only the operations your application requires.

Deserialization needs a separate check. Avoid passing untrusted data to unserialize(), even with allowed_classes restrictions. Where suitable, use JSON instead and validate the decoded values.

Révision de l'authentification, des sessions et du contrôle d'accès

Commençons par les mots de passe. Ils ne doivent pas être stockés sous une forme lisible. Vérifiez que votre application utilise PHP : les fonctions password_hash() et password_verify(), ou les méthodes équivalentes de votre framework. Recherchez d’anciens codes de hachage qui pourraient ne plus être sécurisés.

Ensuite, vérifiez ce qui se passe lorsqu’un utilisateur se connecte. L’application doit générer un nouvel identifiant de session afin qu’un identifiant obtenu avant la connexion ne puisse pas être réutilisé pour accéder au compte. Vérifiez le paramètre session.use_strict_mode ainsi que les paramètres des cookies tels que Secure, HttpOnly et SameSite. Testez la régénération de l’identifiant de session via votre framework, y compris lorsque plusieurs requêtes arrivent simultanément.

À présent, vérifiez si les utilisateurs peuvent consulter des données qui ne leur appartiennent pas. Créez deux comptes de test, chacun avec sa propre facture. Connectez-vous au premier compte et remplacez, dans une requête, l’identifiant de la facture par celui du deuxième compte. Le serveur doit refuser l’accès à moins que cet utilisateur ne dispose des autorisations nécessaires.

Répétez le test pour la modification des factures, le téléchargement de fichiers et les requêtes API. Vérifiez que les utilisateurs lambda ne peuvent pas accéder aux fonctions d’administration. Le fait d’être connecté ne donne pas automatiquement à quelqu’un l’autorisation d’accéder à tous les enregistrements. Le serveur doit vérifier les autorisations pour chaque requête visant un enregistrement protégé ou un point de terminaison API.

Vérifier la protection CSRF

Une attaque CSRF consiste à piéger le navigateur d'un utilisateur connecté pour qu'il effectue une action qu'il n'a pas autorisée, comme la modification des informations de son compte. Commencez par vérifier les formulaires et les requêtes qui modifient des données, en particulier ceux authentifiés via des cookies de session.

Vérifiez la protection CSRF de votre application Laravel ou Symfony et assurez-vous qu’aucune route n’est exclue. Lorsque la validation par jeton s’applique, testez des requêtes avec des jetons manquants ou non valides. Vérifiez également qu’aucune requête falsifiée provenant d’un autre site web ne puisse modifier les données utilisateur. Vérifiez également le paramètre SameSite sur les cookies de session.

Dans Laravel Blade, @csrf ajoute un champ de jeton masqué à un formulaire :


    @csrf
    

Il existe un détail important dans Laravel 13. Son middleware CSRF vérifie d’abord l’en-tête Sec-Fetch-Site. Une requête de même origine peut être acceptée sans jeton, tandis que les autres requêtes sont soumises par défaut à la validation du jeton. Laravel désactive également la protection CSRF par défaut lors des tests automatisés ; assurez-vous donc qu’elle soit activée lorsque vous testez ces mesures de défense.

Pour les API, la méthode d’authentification a son importance. Une API sans état utilisant des jetons « bearer » dans les en-têtes d’autorisation est généralement exposée à des risques CSRF différents. Mais si votre SPA s’appuie sur des cookies de session, elle a tout de même besoin d’une protection contre les requêtes falsifiées.

Sécurité des transferts et de l'accès aux fichiers

Le téléchargement de fichiers peut constituer un risque de sécurité lorsque des attaquants parviennent à télécharger des fichiers exécutables ou à accéder à des données auxquelles ils ne devraient pas avoir accès. Vérifiez quels types et quelles tailles de fichiers votre application accepte, où les fichiers téléchargés sont stockés et qui peut les télécharger. Testez les routes de téléchargement et de chargement pour détecter les failles de type ' path traversal ', assurez-vous que les fichiers téléchargés ne peuvent pas s’exécuter en tant que PHP, et vérifiez que les fichiers .env, .git et les fichiers de sauvegarde ne sont pas accessibles au public.

Vous trouverez ci-dessous un PHP exemple qui vérifie le type MIME d’un fichier téléchargé et l’enregistre sous un nom généré aléatoirement :

if (($_FILES['file']['error'] ?? null) !== UPLOAD_ERR_OK) {
    throw new RuntimeException('Échec du téléchargement');
}

$tmp = $_FILES['file']['tmp_name'];
$allowed = ['image/jpeg' => 'jpg', 'image/png' => 'png'];
$mime = (new finfo(FILEINFO_MIME_TYPE))->file($tmp);

if (!isset($allowed[$mime])) {
    throw new RuntimeException('Type de fichier non pris en charge');
}

$name = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];
$target = '/var/app/private-uploads/' . $name;

if (!move_uploaded_file($tmp, $target)) {
    throw new RuntimeException('Impossible d'enregistrer le fichier téléchargé');
}

Cet exemple suppose le téléchargement d'un seul fichier et l'existence d'un répertoire privé disposant des droits d'accès appropriés. La fonction move_uploaded_file() de PHP confirme que le fichier source a été téléchargé via le mécanisme HTTP POST de PHP.

La vérification du type MIME ne suffit pas à elle seule à garantir la sécurité des téléchargements. Le code de production doit également inclure des limites de taille de fichier imposées par le serveur, des droits d’accès en lecture et en écriture, ainsi qu’une validation du contenu réel des fichiers. Recodez les images lorsque cela est nécessaire et envisagez une analyse antivirus pour les téléchargements à haut risque. Conservez les fichiers en dehors de la racine du site lorsque cela est possible, restreignez l’accès au système de fichiers et empêchez les fichiers téléchargés de s’exécuter en tant que PHP.

Protéger les données sensibles et les identifiants

Les mots de passe de bases de données, clés API et jetons d'accès exposés peuvent permettre à des pirates d'accéder à votre application ou à vos données sensibles. Vérifiez la présence de ces secrets dans votre code source et l’historique Git. Des outils tels que Gitleaks peuvent vous aider à les repérer. Assurez-vous que les fichiers .env ne sont pas stockés dans Git ni accessibles via le Web. Vérifiez également qui peut accéder aux informations confidentielles dans les pipelines CI/CD, et passez en revue les images de conteneurs et les journaux d’application à la recherche d’informations sensibles.

Conservez les secrets dans un gestionnaire de secrets ou un autre système à accès restreint, plutôt que dans le code de l’application. Limitez les personnes autorisées à les consulter ou à les modifier, et n’accordez à chaque application que les autorisations dont elle a besoin.

Si un identifiant est exposé, révoquez-le ou remplacez-le, puis mettez à jour les services qui l’utilisent. Supprimez les copies exposées, vérifiez si quelqu’un l’a utilisé sans autorisation et empêchez que des secrets n’apparaissent dans les futurs journaux. La suppression d’un secret de votre code ne le désactive pas et ne l’efface pas des anciens commits Git.

Bénéficiez d'une évaluation de sécurité PHP réalisée par des experts

Comment hiérarchiser, déployer et vérifier les correctifs de sécurité PHP

01
Hiérarchiser les vulnérabilités

Donnez la priorité aux systèmes exposés aux attaques. Évaluez le score CVSS en tenant compte de la SAPI PHP, de l'exposition à Internet, des protections existantes et de l'impact sur l'activité. Les environnements mod_php non mis à jour et exposés à Internet nécessitent une attention urgente, tandis que les autres SAPI doivent encore faire l'objet d'une évaluation.

02
Déployer les correctifs en toute sécurité

Répertoriez les applications concernées, les pools de workers PHP et les résumés d'images de conteneurs. Effectuez des tests en environnement de préproduction et préparez un plan de reprise avant le déploiement. Appliquez les correctifs aux paquets concernés ou reconstruisez les images, puis redémarrez ou remplacez tous les workers affectés. Les règles WAF et les mesures d'atténuation au niveau de la configuration peuvent réduire l'exposition à certaines voies d'exploitation spécifiques. Elles ne corrigent toutefois pas le runtime vulnérable.

03
Vérifier la mise en œuvre des mesures correctives

Vérifiez quelle version de PHP traite les requêtes en production et vérifiez l'état de ses correctifs, y compris tout backport fourni par le fournisseur. Assurez-vous que les workers concernés ont été redémarrés ou remplacés, exécutez des tests de régression, puis répétez le contrôle de sécurité qui avait échoué précédemment. Surveillez l'environnement de production pour détecter d'éventuelles erreurs après le déploiement.

04
Enquêter sur une éventuelle violation de sécurité

L'application du correctif permet de corriger la vulnérabilité. Toute intrusion antérieure doit encore faire l'objet d'une enquête. Vérifiez les journaux du serveur, les plantages des processus, les fichiers inhabituels et toute activité réseau suspecte. Sur mod_php, PHP2Shell peut s'exécuter avant que la journalisation de l'application ne commence ; par conséquent, des journaux de framework « propres » ne permettent pas d'exclure une attaque. Signalez les signes avant-coureurs à l'équipe de gestion des incidents et conservez les preuves.

05
Assurer la sécurité

Suivre les nouvelles vulnérabilités liées à PHP et à ses dépendances, et ajouter des contrôles de sécurité au processus CI/CD. Fonder les évaluations régulières sur l'exposition des applications et les risques opérationnels, et procéder à une réévaluation après toute modification majeure ou divulgation critique.

arrow-icon.arrow-icon.
01 Hiérarchiser les vulnérabilités

Donnez la priorité aux systèmes exposés aux attaques. Évaluez le score CVSS en tenant compte de la SAPI PHP, de l'exposition à Internet, des protections existantes et de l'impact sur l'activité. Les environnements mod_php non mis à jour et exposés à Internet nécessitent une attention urgente, tandis que les autres SAPI doivent encore faire l'objet d'une évaluation.

arrow-icon.arrow-icon.
02 Déployer les correctifs en toute sécurité

Répertoriez les applications concernées, les pools de workers PHP et les résumés d'images de conteneurs. Effectuez des tests en environnement de préproduction et préparez un plan de reprise avant le déploiement. Appliquez les correctifs aux paquets concernés ou reconstruisez les images, puis redémarrez ou remplacez tous les workers affectés. Les règles WAF et les mesures d'atténuation au niveau de la configuration peuvent réduire l'exposition à certaines voies d'exploitation spécifiques. Elles ne corrigent toutefois pas le runtime vulnérable.

arrow-icon.arrow-icon.
03 Vérifier la mise en œuvre des mesures correctives

Vérifiez quelle version de PHP traite les requêtes en production et vérifiez l'état de ses correctifs, y compris tout backport fourni par le fournisseur. Assurez-vous que les workers concernés ont été redémarrés ou remplacés, exécutez des tests de régression, puis répétez le contrôle de sécurité qui avait échoué précédemment. Surveillez l'environnement de production pour détecter d'éventuelles erreurs après le déploiement.

arrow-icon.arrow-icon.
04 Enquêter sur une éventuelle violation de sécurité

L'application du correctif permet de corriger la vulnérabilité. Toute intrusion antérieure doit encore faire l'objet d'une enquête. Vérifiez les journaux du serveur, les plantages des processus, les fichiers inhabituels et toute activité réseau suspecte. Sur mod_php, PHP2Shell peut s'exécuter avant que la journalisation de l'application ne commence ; par conséquent, des journaux de framework « propres » ne permettent pas d'exclure une attaque. Signalez les signes avant-coureurs à l'équipe de gestion des incidents et conservez les preuves.

arrow-icon.arrow-icon.
05 Assurer la sécurité

Suivre les nouvelles vulnérabilités liées à PHP et à ses dépendances, et ajouter des contrôles de sécurité au processus CI/CD. Fonder les évaluations régulières sur l'exposition des applications et les risques opérationnels, et procéder à une réévaluation après toute modification majeure ou divulgation critique.

Exemple concret : un correctif de production qui semble avoir fonctionné, mais qui n'est en réalité pas le cas

Une boutique Symfony fonctionne sous PHP 8.3 derrière nginx et PHP-FPM. L'administrateur met à jour les paquets du système d'exploitation et exécute la commande `php -v`. La commande affiche une version corrigée, tout semble donc fonctionner correctement. Cependant, la commande `php -v` ne vérifie que le binaire PHP de la ligne de commande.

Les requêtes des clients continuent de passer par nginx vers les workers PHP-FPM qui ont été lancés avant la mise à jour. Les tâches en arrière-plan s’exécutent également dans un conteneur distinct doté d’une couche de base PHP vulnérable. Les paquets ont peut-être été mis à jour sur le serveur, mais ces charges de travail continuent d’exécuter l’ancien code.

PHP build checks for web, workers, and CLI.

Pour finaliser le correctif, l’équipe doit identifier toutes les applications et tous les pools de workers concernés, redémarrer les workers FPM et redéployer le conteneur de file d’attente avec une image corrigée. Elle doit ensuite vérifier que les processus PHP en cours d’exécution utilisent des versions corrigées ou des backports vérifiés par le fournisseur.

Tester les opérations de checkout et de téléchargement de fichiers en environnement de préproduction, effectuer des tests de fumée en production, puis répéter les contrôles de sécurité qui avaient échoué précédemment. Le rapport de déploiement doit inclure la SAPI PHP gérant le trafic web, les versions vérifiées des paquets ou les hachages d’images, les preuves de redémarrage et de test, ainsi que le nom du responsable.

Un audit Composer réussi ne prouve pas que la vulnérabilité PHP2Shell a été corrigée. Cette commande vérifie les dépendances, et non l’interpréteur PHP traitant les requêtes Web.

Vérifiez l’ID utilisateur du PHP worker, les répertoires accessibles en écriture, les secrets montés, les autorisations de base de données et l’accès réseau sortant. Ces éléments déterminent si un attaquant pourrait modifier les fichiers de l’application, lire des identifiants ou accéder à d’autres systèmes. Le principe du moindre privilège et la segmentation du réseau peuvent limiter les dégâts si un worker est compromis, mais l’application d’un correctif sur l’interpréteur reste nécessaire.

La commande `php -v` affiche la version de PHP en ligne de commande, mais elle ne permet pas de déterminer quel interpréteur traite le trafic de production ni si les processus de fond à exécution longue utilisent toujours la version vulnérable. Avec PHP2Shell, nous vérifions d’abord l’environnement d’exécution actif, puis nous examinons les dépendances et le code de l’application. Nous ne considérons la correction comme achevée qu’après avoir confirmé que la version corrigée traite bien les requêtes en production.
Stanislav Kazanov, Head of GRC and Cybersecurity.
Stanislav Kazanov
Responsable GRC, cybersécurité et développement durable

Comment Innowise peut vous aider à sécuriser vos applications PHP

Chez Innowise, nous allions expertise en développement PHP et en sécurité. Nos plus de 100 développeurs PHP ont mené à bien plus de 250 projets, et nos plus de 50 ingénieurs en cybersécurité contribuent à identifier et à corriger les vulnérabilités. Notre travail est également certifié ISO/IEC 27001:2022 et ISO 9001:2015.

Nous analysons vos applications PHP à la recherche de failles de sécurité, notamment les dépendances vulnérables et les composants obsolètes. Nos développeurs se chargent des corrections et mises à jour nécessaires, tandis que nos ingénieurs en sécurité testent les modifications avant leur déploiement. Si vous ne savez pas par où commencer, notre équipe de conseil en sécurITé informatique peut évaluer les risques et vous aider à hiérarchiser les tâches.

ISO 27001 icon.
ISO-27017-2015.
ISO-27018 icon.
ISO 9001 icon.

Nos projets PHP

Refonte et reconstruction du site web de MedSpa Network
Innowise a refondu le site web de MedSpa Network sur WordPress, permettant ainsi à son équipe de gérer elle-même les mises à jour quotidiennes du contenu.
2 mois entre le coup d'envoi et le lancement
3-5 3 à 5 prospects par semaine (contre 1 par mois auparavant)
Bot IA pour la campagne marketing de TBC Bank
Innowise a développé un bot Telegram bilingue qui génère des selfies créés par l'IA avec l'ambassadeur de marque de la TBC Bank, une star du football.
3,000 utilisateurs actifs
2 langues prises en charge
Définition de la stratégie produit pour la plateforme de prêt de bitcoins de Bitlendex
Innowise a mené une phase d'analyse pour Bitlendex, aidant ainsi le client à transformer un concept de produit à un stade précoce en un modèle économique validé et en un MVP clairement défini.
1 mois pour une phase de découverte complète
Système de conseil financier pour Bonnfinanz
Innowise a aidé Bonnfinanz à mettre en place un système de conseil et de gestion en ligne qui facilite le travail à distance et permet une interaction directe avec le client.
Plateforme de recharge pour véhicules électriques avec facturation flexible
Innowise a contribué à la modernisation de la plateforme de mobilité électrique de SMART/LAB en améliorant ses fonctionnalités de facturation, de paiement, de gestion des transactions et de reporting.
>50% accélération de la facturation et du traitement des paiements
Transformation DevOps cloud-native de FinXP
Innowise a aidé FinXP à moderniser son infrastructure de services financiers en migrant ses API et applications héritées basées sur PHP vers une architecture native pour le cloud.
11 Applications migrées vers Azure App Service
100% Infrastructure as Code
SEO technique pour plateforme e-commerce
Innowise a résolu des problèmes techniques critiques liés au référencement naturel (SEO) et aux performances sur la plateforme de commerce électronique d'Officine 08.
< 500 ms temps de réponse du serveur
5 mois pour mener à bien le projet
Développement continu d'une plateforme d'abonnement aux parfums
Innowise a aidé Scentbird à développer sa plateforme d'abonnement afin de proposer de nouvelles expériences d'achat et de soutenir sa croissance à l'international.
4 ans de soutien sans faille
01 / 01
Close popup icon

Conclusion

PHP2Shell a mis en évidence une faille grave au sein même de l’interpréteur PHP. Les mises à jour des frameworks et les vérifications des dépendances ne permettent pas de corriger les vulnérabilités à ce niveau. Les entreprises doivent identifier tous les environnements d’exécution PHP traitant les requêtes Web, installer les mises à jour de sécurité et vérifier que les serveurs de production exécutent bien les versions corrigées.

La sécurité PHP nécessite également des vérifications régulières du code des applications, de la configuration et des contrôles d’accès, en particulier après la divulgation de vulnérabilités critiques ou la publication de mises à jour majeures. Si vous avez besoin d’aide pour évaluer votre exposition ou vérifier les correctifs, Innowise propose sécurITé informatique et évaluation de la cybersécurité d’Innowise peuvent vous aider dans cette tâche.

FAQ

Votre application pourrait être exposée à un risque si votre serveur utilise une version de PHP qui n'a pas été corrigée pour les vulnérabilités CVE-2026-109618 et CVE-2026-109619. Vérifiez quelle version de PHP est effectivement utilisée et si votre hébergeur a appliqué les correctifs. Apache mod_php présente le risque confirmé le plus élevé, mais PHP-FPM doit également être vérifié. Comme les vulnérabilités se trouvent dans PHP lui-même, la mise à jour de WordPress ou d’un autre framework ne permettra pas de les corriger.

Les correctifs pour PHP2Shell sont disponibles dans PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Certains éditeurs Linux ont rétroporté les correctifs vers des versions antérieures ; consultez donc l'avis de sécurité de votre éditeur. Assurez-vous que vos workers PHP en cours d'exécution utilisent la version corrigée. Sous Windows, installez les paquets mis à jour du 26 octobre se terminant par -1, qui corrigent également une autre vulnérabilité de Brotli.

Si vous ne pouvez pas mettre à jour PHP immédiatement, limitez l'accès public aux applications concernées dans la mesure du possible. Pour les sites qui doivent rester en ligne, votre administrateur de serveur peut appliquer les mesures temporaires recommandées dans l’avis de sécurité PHP, telles que la limitation de la taille des requêtes ou la désactivation de la progression des téléchargements en session. Testez ces modifications pour vous assurer que le site fonctionne toujours. Elles ne font que réduire le risque ; l’installation d’une version corrigée de PHP reste donc urgente.

Non. La mise à jour de PHP corrige les vulnérabilités du moteur d'exécution PHP, mais elle ne résoudra pas les problèmes de sécurité liés au code de votre application, aux plugins obsolètes ou à la configuration du serveur. Vous devez les vérifier et les corriger séparément.

Je recommande de vérifier au moins une fois par mois si les applications PHP présentent des vulnérabilités connues, et d'effectuer des contrôles plus fréquents pour les systèmes à haut risque. Surveillez en permanence les avis de sécurité PHP et les dépendances, et programmez des audits plus approfondis en fonction de l'exposition de votre application et des risques pour votre entreprise. Il est important de procéder à des tests supplémentaires après des mises à jour majeures ou la divulgation de vulnérabilités critiques.

Consultez les avis de sécurité PHP ainsi que les bulletins de votre hébergeur ou de votre fournisseur de système d'exploitation pour connaître les vulnérabilités connues. Utilisez la commande `composer audit --locked` pour vérifier les dépendances, recourez à l’analyse statique et à la revue de code pour détecter les problèmes au niveau de l’application, et utilisez OWASP ZAP pour tester votre application web avec autorisation. Pour vérifier les correctifs de sécurité, vérifiez la version PHP exécutée en production ainsi que les correctifs rétroportés par votre fournisseur.

Oui. Les mises à jour peuvent entraîner des problèmes de compatibilité avec d'anciens codes ou extensions. Testez-les en environnement de préproduction avant de mettre à jour votre application en production, et prévoyez un plan de secours au cas où quelque chose ne fonctionnerait plus.

Corrélez les journaux du proxy inverse, d’Apache/nginx, de PHP-FPM et de l’EDR/de l’hôte. Recherchez les plantages de workers, les fichiers ou processus suspects, le trafic sortant inattendu et les signes d’exposition des identifiants. Les journaux d’application peuvent ne pas détecter les exploits d’exécution PHP survenant avant que le framework ne commence à enregistrer les événements. Si vous constatez une activité suspecte, lancez une procédure de réponse aux incidents et conservez les preuves techniques.

Voir plus Voir moins

Table des matières

Découvrez quelles charges de travail PHP nécessitent une mise à jour de sécurité en priorité

    Contactez-nous

    Réservez un appel ou remplissez le formulaire ci-dessous. Nous vous contacterons dès que nous aurons examiné votre demande.

    Envoyez-nous un message vocal
    Joindre des documents
    Téléverser un fichier

    Vous pouvez joindre un fichier d'une taille maximale de 2 Mo. Formats de fichiers valables : pdf, jpg, jpeg, png.

    En cliquant sur « Envoyer », vous consentez au traitement de vos données personnelles par Innowise conformément à notre Politique de confidentialité afin de vous fournir des informations pertinentes. En soumettant votre numéro de téléphone, vous acceptez que nous puissions vous contacter par appels vocaux, SMS et applications de messagerie. Des frais d'appel, de message et de transfert de données peuvent s'appliquer.

    Vous pouvez également nous envoyer votre
    demande à contact@innowise.com
    Que se passe-t-il ensuite?
    1

    Une fois votre demande reçue et examinée, nous vous contacterons afin de préciser les besoins de votre projet et de signer un accord de confidentialité.

    2

    Après avoir examiné vos souhaits, vos besoins et vos attentes, notre équipe élaborera une proposition de projet avec l'étendue des travaux, la taille de l'équipe, les délais et les coûts estimés.

    3

    Nous organiserons une réunion avec vous pour discuter de la proposition et finaliser les détails.

    4

    Enfin, nous signerons le contrat et commencerons immédiatement à travailler sur votre projet.

    Autres services couverts

    arrow