Situation actuelle : PHP2Shell. Deux failles PHP critiques (CVSS 9.2) permettent d'exécuter du code malveillant sans authentification. Correctifs disponibles depuis le 21 octobre 2026.Ce qu'il faut faire maintenant →

Glossaire : PHP et sécurité informatique

125 termes techniques en langage clair, chacun avec un renvoi vers la page spécialisée correspondante.

#

2FA
L'A2F (authentification à deux facteurs, 2FA) exige lors de la connexion, en plus du mot de passe, une seconde preuve, par exemple un code issu d'une application ou une clé de sécurité. Un mot de passe volé ne suffit alors plus. L'A2F devrait être la norme pour tous les accès d'administration aux CMS, aux panneaux d'hébergement et aux serveurs. Mettre en place l'authentification à deux facteurs pour les accès administrateur →

A

Apache
Apache HTTP Server est l'un des serveurs web les plus anciens et les plus répandus. PHP y fonctionne soit comme module (mod_php), soit via PHP-FPM par FastCGI. Avec les fichiers .htaccess, la configuration peut être adaptée répertoire par répertoire. Sécuriser Apache avec mod_php →

B

Backport
Un backport reporte une correction de sécurité dans une version plus ancienne d'un programme, sans passer à la nouvelle version. Les distributions Linux et les hébergeurs le font souvent ; le numéro de version affiché reste alors le même. Pour savoir si un backport est appliqué, il faut se fier au journal des modifications du paquet et à la confirmation du fournisseur, pas au numéro. Mise à niveau de PHP ou rétroportage ? La décision pour les anciens systèmes →
BSI
Le BSI (Bundesamt für Sicherheit in der Informationstechnik, office fédéral allemand de la sécurité des technologies de l'information) est l'autorité fédérale allemande de cybersécurité. Il publie des alertes, des recommandations et des normes comme l'IT-Grundschutz. Pour PHP2Shell, le BSI a déclaré le niveau d'alerte 3 (orange) et recommandé une mise à jour immédiate. Ce que recommande le BSI au sujet de PHP2Shell →

C

CDN
Un CDN (Content Delivery Network) diffuse des contenus via de nombreux serveurs répartis et se place ainsi devant le site web proprement dit. De nombreux CDN proposent en plus des règles WAF, par exemple Cloudflare contre PHP2Shell. La protection ne vaut que pour le trafic passant par le CDN et ne remplace pas une mise à jour de PHP. Règles de protection Cloudflare contre PHP2Shell : ce qu'elles apportent et ce qu'elles n'apportent pas →
CERT-Bund
CERT-Bund est le Computer Emergency Response Team de l'administration fédérale allemande, rattaché au BSI. Il publie des services d'alerte et d'information sur les vulnérabilités et prévient les opérateurs de réseaux des systèmes vulnérables. Pour PHP2Shell aussi, CERT-Bund a émis une alerte. Ce que CERT-EU et CERT-Bund conseillent pour PHP2Shell →
CERT-EU
CERT-EU est l'équipe de cybersécurité des institutions, organes et agences de l'Union européenne. Selon des rapports, CERT-EU estime possible que, pour PHP2Shell, des versions à partir de PHP 5 soient concernées. Il conseille d'isoler les applications accessibles publiquement si elles ne peuvent pas être corrigées rapidement. Ce que CERT-EU et CERT-Bund conseillent pour PHP2Shell →
CGI
CGI (Common Gateway Interface) est une ancienne interface dans laquelle le serveur web lance un programme externe pour chaque requête et renvoie sa sortie. Elle est simple mais lente, et a été largement remplacée par FastCGI pour PHP. On trouve encore d'anciennes configurations CGI sur certains systèmes d'hébergement et sous Windows. CGI et FastCGI : les bases →
cgroups
Les cgroups (control groups) sont une fonction du noyau Linux permettant de limiter la mémoire, le CPU et d'autres ressources pour des groupes de processus. Les conteneurs et systemd les utilisent, par exemple avec MemoryMax. Comme mesure transitoire contre PHP2Shell, php.net recommande une limite de mémoire via conteneur ou cgroup plutôt que via RLIMIT_AS ou RLIMIT_DATA. Définir des limites de mémoire avec systemd et cgroups →
Chaîne de custodie
La chaîne de custodie (chain of custody) documente sans faille qui a sécurisé, transmis et traité un élément de preuve, et quand. Complétée par des sommes de contrôle, elle prouve que les données n'ont pas été modifiées. Sans cette documentation, les traces perdent de leur valeur devant un tribunal ou face aux assureurs. Forensique informatique après une attaque de serveur web →
Chronologie
Une chronologie (timeline) ordonne chronologiquement toutes les traces d'un incident : entrées de journaux, modifications de fichiers, connexions, processus. Elle montre quand l'attaque a commencé et dans quel ordre les événements se sont déroulés. Un fuseau horaire unique, de préférence UTC, est important. Établir la chronologie d'un incident →
CLI
CLI (Command Line Interface) désigne PHP en ligne de commande, par exemple pour les tâches cron, les commandes console des CMS et Composer. Le PHP en ligne de commande peut être d'une autre version que le PHP qui sert les pages web. La commande php -v n'affiche donc que la version en ligne de commande ; les deux voies doivent être corrigées. PHP en ligne de commande (CLI) →
CloudLinux
CloudLinux est une distribution Linux pour l'hébergement mutualisé qui sépare les clients dans des environnements limités. Avec alt-php, elle met à disposition côte à côte de nombreuses versions de PHP, y compris anciennes. Chacune de ces versions doit être corrigée individuellement. CloudLinux et alt-php : ce que les clients d'hébergement doivent savoir →
Composer
Composer est le gestionnaire de paquets de PHP. Il installe les bibliothèques selon les indications de composer.json et conserve les versions exactes dans composer.lock. Avec composer audit, les paquets installés peuvent être vérifiés au regard des failles de sécurité connues ; les failles dans PHP lui-même ne sont pas détectées par cette commande. Composer : le gestionnaire de paquets de PHP →
Conteneur
Un conteneur est un environnement d'exécution isolé qui démarre une application avec toutes ses dépendances à partir d'une image, par exemple avec Docker. Le PHP du conteneur provient de l'image, pas du système hôte. Une mise à jour sur l'hôte ne le corrige donc pas ; l'image doit être reconstruite et le conteneur redémarré. Exploiter PHP en conteneurs →
Contrat de sous-traitance (AVV)
Un contrat de sous-traitance de données (AVV, Auftragsverarbeitungsvertrag) au titre de l'art. 28 du RGPD est nécessaire lorsqu'un prestataire traite des données personnelles pour le compte d'un client ou peut y accéder. C'est souvent aussi le cas pour les hébergeurs, les agences et les prestataires informatiques disposant d'un accès au serveur. Le contrat règle notamment les instructions, les mesures de protection et les circuits de notification. Sous-traitance de données lorsque des prestataires accèdent aux serveurs →
Contrôle d'intégrité
Lors d'un contrôle d'intégrité, des fichiers sont comparés à un état d'origine connu, généralement au moyen de sommes de contrôle. De nombreux CMS offrent pour cela leurs propres commandes, par exemple pour WordPress, Nextcloud ou Matomo. Les fichiers personnalisés, les fichiers envoyés et le contenu de la base de données ne sont pas couverts par une telle comparaison. Comparer les fichiers du noyau du CMS avec l'original →
Correctif
Un correctif (patch) est une correction de l'éditeur qui ferme une faille dans le code du programme. Il n'agit qu'une fois installé et que tous les processus en cours ont été redémarrés. Un correctif ne supprime pas un logiciel malveillant déjà introduit et ne prouve pas que rien ne s'est produit auparavant. Service de correctifs PHP : mise à jour installée, avec redémarrage et attestation →
Correctif virtuel
Le correctif virtuel bloque les attaques contre une faille connue en amont de l'application, généralement avec un WAF, sans modifier le code vulnérable. Il fait gagner du temps jusqu'à ce que la vraie mise à jour soit possible. Pour PHP2Shell, Cloudflare met par exemple en garde : les règles fondées sur les seules données de la requête ne suffisent pas ; la mise à jour reste obligatoire. WAF et correctif virtuel pour PHP →
cPanel
cPanel est un panneau d'administration pour l'hébergement web, avec WHM comme interface pour l'administrateur du serveur. Les versions de PHP y sont généralement fournies via des paquets propres (EasyApache). Les builds qui sont corrigés sont confirmés par l'état des paquets et par l'hébergeur. cPanel et WHM : sécuriser PHP →
Credential stuffing
Dans le credential stuffing, les attaquants essaient des identifiants issus de fuites de données antérieures chez d'autres services. Cela fonctionne parce que de nombreuses personnes réutilisent leurs mots de passe. La protection repose sur un mot de passe unique par service et sur l'authentification à deux facteurs. Mettre en place l'authentification à deux facteurs pour les accès administrateur →
Cryptomineur
Un cryptomineur est un logiciel malveillant qui calcule de la cryptomonnaie sur des serveurs tiers. Les signes typiques sont une charge CPU élevée en permanence et des processus inconnus. Un mineur montre qu'un attaquant peut exécuter du code ; le serveur doit alors être considéré comme compromis. Mineur de cryptomonnaie sur le serveur web : signes et marche à suivre →
CSP
CSP (Content Security Policy) est un en-tête qui définit les sources à partir desquelles une page peut charger des scripts, des images et d'autres contenus. Elle complique les XSS et l'introduction de scripts tiers, par exemple lors d'un skimming. Une CSP stricte doit être testée avec soin pour que le site web continue de fonctionner. En-têtes de sécurité pour les sites web : bien définir les en-têtes de sécurité →
CSRF
CSRF (Cross-Site Request Forgery) amène le navigateur d'un utilisateur connecté à déclencher involontairement une action sur un autre site web. Typiquement, il s'agit de modifications dans des espaces d'administration. La protection repose sur des jetons aléatoires dans les formulaires et sur des cookies avec l'attribut SameSite. Protection CSRF dans les applications PHP →
CVE
CVE (Common Vulnerabilities and Exposures) est un répertoire utilisé dans le monde entier qui attribue un numéro unique à chaque faille de sécurité connue, par exemple CVE-2026-109618. Ce numéro rend comparables les avis des éditeurs, des autorités et des distributions. Le numéro CVE permet aussi de vérifier dans le journal des modifications d'un paquet si un correctif a été appliqué. Prouver les numéros CVE dans le changelog d'un paquet →
CVSS
CVSS (Common Vulnerability Scoring System) évalue la gravité d'une faille sur une échelle de 0 à 10. L'évaluation tient compte, par exemple, du fait qu'une attaque est possible par le réseau et sans authentification. Les failles PHP2Shell ont chacune un CVSS v4.0 de 9.2 ; cette valeur seule ne dit rien du risque concret dans votre environnement.
Cyberassurance
Une cyberassurance prend en charge, selon le contrat, les coûts après une attaque, par exemple pour la forensique, la restauration ou l'interruption d'activité. De nombreux contrats comportent des obligations comme des mises à jour rapides et une déclaration immédiate du sinistre. Ce qui s'applique dans votre cas, vous le clarifiez avec votre assureur. Cyberassurance : ce qui compte en cas de sinistre →
Cycle de publication
Chaque version de PHP reçoit d'abord des corrections d'erreurs, puis, pendant un certain temps, uniquement des corrections de sécurité. Le projet PHP publie sur php.net, parmi les versions prises en charge, la date de fin de chaque version. Selon php.net, PHP 8.2 atteint la fin de la prise en charge le 31 décembre 2026. Versions de PHP et cycle de publication →

D

DDoS
Une attaque DDoS (Distributed Denial of Service, déni de service distribué) surcharge un service de requêtes provenant de nombreuses sources jusqu'à ce qu'il ne soit plus joignable. En règle générale, aucune donnée n'est volée. Un DDoS doit être distingué d'un exploit, qui exploite de manière ciblée une faille. DDoS ou piratage ? Bien qualifier les attaques →
disable_functions
disable_functions est un paramètre de php.ini qui désactive certaines fonctions PHP, typiquement celles qui servent à exécuter des commandes système. Il ne peut être défini que dans php.ini, pas dans le code de l'application. Il complique la tâche des attaquants, mais ne remplace ni les mises à jour ni une gestion correcte des droits. Bien utiliser PHP disable_functions →
display_errors
display_errors détermine si PHP affiche les messages d'erreur directement dans le navigateur. En production, la valeur doit être Off ; les erreurs sont alors écrites dans un journal avec log_errors. Des messages visibles révèlent sinon des chemins, des versions et des extraits de code. display_errors off : désactiver l'affichage des erreurs en production →
Durcissement
Le durcissement consiste à configurer un système de manière à offrir le moins de surface d'attaque possible : uniquement les services nécessaires, des droits restreints, des réglages par défaut sûrs. Pour les serveurs PHP, cela comprend par exemple des pools séparés, des fonctions bloquées et aucune exécution de PHP dans les dossiers d'envoi. Le durcissement limite les dégâts, mais ne remplace pas les mises à jour. Durcissement de serveurs web PHP →
Défacement
Lors d'un défacement, des attaquants modifient de façon visible la page d'accueil ou les contenus d'un site web, par exemple avec des messages ou des images. C'est spectaculaire, mais souvent seulement le signe visible d'une intrusion plus profonde. Le site web doit être traité comme compromis jusqu'à clarification. Site web piraté, que faire ? Aide d'urgence à distance →
Désérialisation
La désérialisation reconvertit des données enregistrées en objets, en PHP par exemple avec unserialize(). Si les données proviennent d'utilisateurs, des attaquants peuvent construire des objets de telle sorte qu'un code indésirable s'exécute au chargement. Pour les données d'utilisateurs, JSON est le choix le plus sûr. Désérialisation non sécurisée en PHP : unserialize et sécurité →

E

EDR
L'EDR (Endpoint Detection and Response) est un logiciel installé sur les serveurs et les postes de travail qui observe les processus, les accès aux fichiers et les connexions réseau, et signale ou arrête les comportements suspects. Sur les serveurs web, il peut par exemple détecter que PHP-FPM lance un shell. Comme il n'existe pas d'IOC confirmés pour PHP2Shell, une telle analyse comportementale est particulièrement importante. Signal d'alerte : le serveur web lance un shell →
Embargo
Un embargo est le délai convenu pendant lequel les détails d'une faille restent confidentiels jusqu'à ce que les correctifs soient prêts. Les éditeurs et les distributions peuvent ainsi préparer leurs mises à jour. Pour PHP2Shell, selon plusieurs rapports, des détails sont devenus publics avant la fin de l'embargo ; php.net a donc annoncé les correctifs le 20 octobre 2026. Pourquoi la faille PHP est devenue publique avant le correctif →
En-têtes de sécurité
Les en-têtes de sécurité sont des lignes d'en-tête de réponse HTTP qui donnent au navigateur des règles de protection, par exemple Content-Security-Policy, Strict-Transport-Security ou X-Content-Type-Options. Ils protègent les visiteurs contre certaines attaques dans le navigateur. Ils n'aident pas contre les failles du serveur comme PHP2Shell. En-têtes de sécurité pour les sites web : bien définir les en-têtes de sécurité →
End of Life
End of Life (EOL, fin de vie) signifie qu'une version de logiciel ne reçoit plus de mises à jour de l'éditeur, pas même de corrections de sécurité. PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour officielles du projet PHP ; pour 7.4, 8.0 et 8.1, il n'existe que des backports minimaux du code source. Les systèmes exécutant des logiciels EOL ont besoin d'un plan de migration. Fin de vie de PHP : les risques des versions obsolètes →
Exploit
Un exploit est un code ou un procédé qui exploite réellement une faille précise. Dès qu'un correctif paraît, les attaquants peuvent l'analyser et en dériver des exploits. C'est pourquoi, après la publication d'un correctif, le délai avant les attaques se raccourcit souvent nettement. Le délai entre le correctif et l'attaque →
expose_php
expose_php détermine si PHP révèle sa version dans l'en-tête HTTP X-Powered-By. En production, ce paramètre doit être sur Off, afin que les attaquants ne voient pas d'emblée quelle version de PHP est en service. C'est une protection de l'information, pas un substitut à une mise à jour. expose_php et en-têtes Server : masquer les indications de version →
Extension
Une extension complète PHP avec des fonctions, par exemple pour les bases de données, les images ou le chiffrement. Les extensions s'exécutent dans le même processus que PHP et ont les mêmes droits. Désactiver les extensions inutiles réduit la surface d'attaque. Comprendre les extensions PHP →

F

Fail2ban
Fail2ban lit les fichiers journaux et bloque temporairement dans le pare-feu les adresses IP après des tentatives échouées répétées. Les usages typiques sont SSH, la messagerie et les connexions d'administration de sites web. Contre les attaques distribuées depuis de nombreuses adresses, il n'aide que de façon limitée. Configurer Fail2ban pour les serveurs web →
FastCGI
FastCGI est un protocole par lequel un serveur web transmet des requêtes à des processus de programme qui tournent en permanence, par exemple PHP-FPM. Contrairement au CGI classique, un nouveau processus n'est pas lancé pour chaque requête. Comme les processus traitent plusieurs requêtes l'une après l'autre, un redémarrage propre après les mises à jour est important. CGI et FastCGI : les bases →
Force brute
Dans une attaque par force brute (brute force), un attaquant essaie automatiquement de nombreux mots de passe pour un compte. Les cibles sont souvent les connexions d'administration de CMS, SSH ou FTP. La protection repose sur des mots de passe robustes, l'authentification à deux facteurs et des blocages automatiques comme Fail2ban. Protéger les connexions administrateur contre la force brute : une protection pour chaque connexion →
Forensique
La forensique informatique examine méthodiquement, après un incident, ce qui s'est passé : comment l'attaquant est entré, ce qu'il a fait et quelles données sont concernées. La base en est constituée de copies sécurisées de supports de données, de la mémoire vive et des journaux. Les résultats sont importants pour les obligations de notification, l'assurance et le dépôt de plainte. Forensique informatique après une attaque de serveur web →
FrankenPHP
FrankenPHP est un serveur d'applications moderne pour PHP, basé sur le serveur web Caddy. PHP y est directement intégré ; en mode worker, l'application reste en mémoire entre les requêtes. Selon l'équipe PHP, FrankenPHP fait partie des modes d'exécution concernés ; après la mise à jour, le serveur doit être redémarré avec le nouveau PHP. Sécuriser FrankenPHP →

G

GHSA
GHSA est l'identifiant d'un GitHub Security Advisory, c'est-à-dire d'un avis de sécurité dans la base de données de GitHub. De nombreux projets open source, dont PHP, y publient leurs avis en plus du numéro CVE. Pour PHP2Shell, il s'agit de GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp.

H

HSTS
HSTS (HTTP Strict Transport Security) est un en-tête par lequel un site web indique au navigateur de ne plus l'ouvrir qu'en HTTPS pendant une durée déterminée. Cela empêche que les connexions soient rétrogradées vers HTTP non chiffré. Avant de l'activer, HTTPS doit fonctionner de manière fiable sur tous les domaines concernés. En-têtes de sécurité pour les sites web : bien définir les en-têtes de sécurité →
.htaccess
Les fichiers .htaccess sont des fichiers de configuration par répertoire pour Apache et les serveurs compatibles comme LiteSpeed. Les CMS les utilisent pour les redirections et la protection des accès, les attaquants pour des redirections cachées. Nginx n'interprète pas .htaccess ; les règles de protection doivent y figurer dans la configuration du serveur. Configurer Apache pour PHP en toute sécurité →
Hébergement mutualisé
Dans l'hébergement mutualisé (shared hosting), de nombreux clients se partagent un serveur exploité par l'hébergeur. L'hébergeur est responsable de PHP, du système d'exploitation et du serveur web, le client de son application. Pour PHP2Shell, cela signifie : demander l'état des correctifs à l'hébergeur et vérifier son propre site web à la recherche de traces. Hébergement mutualisé : ce que fait l'hébergeur et ce que vous devez faire →

I

Image digest
Un image digest est une valeur de hachage (sha256) qui identifie sans ambiguïté le contenu d'une image de conteneur. Contrairement à une étiquette (tag) comme php:8.3-fpm, qui peut être déplacée vers de nouveaux builds, un digest ne change jamais. Qui fige ses images par digest doit le mettre à jour volontairement après une mise à jour de sécurité. Images Docker PHP officielles : tags, digests et reconstruction →
ini_set()
ini_set() est une fonction PHP par laquelle un script modifie des paramètres à l'exécution. Ce qu'un script a le droit de modifier dépend du mode de modification du paramètre. Comme un code malveillant peut lui aussi appeler ini_set(), les paramètres de protection relèvent de la configuration du serveur ou du pool, pas du code de l'application. Le php.ini expliqué : structure, niveaux et priorité →
Injection de commandes
Dans une injection de commandes (command injection), des saisies parviennent sans contrôle dans une commande système que l'application exécute. L'attaquant peut ainsi lancer ses propres commandes avec les droits du serveur web. La protection consiste à éviter, autant que possible, les appels au shell et à échapper systématiquement avec escapeshellarg(). Empêcher l'injection de commandes en PHP →
Injection SQL
Dans une injection SQL, un attaquant introduit dans une application, par le biais de saisies, ses propres commandes de base de données. Cela permet de lire ou de modifier des données. La protection repose sur des requêtes préparées (prepared statements) avec des paramètres plutôt que sur des textes SQL assemblés. Prévenir l'injection SQL en PHP →
IOC
Les IOC (Indicators of Compromise, indicateurs de compromission) sont des traces concrètes d'une attaque, par exemple des noms de fichiers, des valeurs de hachage, des adresses IP ou des domaines. Ils permettent de vérifier de manière ciblée si des systèmes sont touchés par une attaque connue. Pour PHP2Shell, il n'existe pas d'IOC publiés et confirmés ; la détection repose sur l'analyse comportementale. Suis-je déjà compromis ? Les signes après PHP2Shell →
ISO 27001
ISO/IEC 27001 est la norme internationale des systèmes de management de la sécurité de l'information (SMSI). Elle exige une gestion réglée des risques, des mesures et des améliorations, y compris la gestion des vulnérabilités et des incidents. Les entreprises peuvent se faire certifier selon cette norme. ISO 27001 et TISAX : ce que cela implique pour les serveurs web →
IT-Grundschutz
L'IT-Grundschutz du BSI est une méthodologie allemande (socle de sécurité informatique) avec des modules et des exigences pour la sécurité de l'information dans les entreprises et les administrations. Il existe des modules propres, par exemple pour les serveurs web et les applications web. Il peut servir de base à un SMSI ou à une certification. Benchmarks CIS et modules du BSI pour serveurs web →

J

JIT
Le JIT (Just-in-Time Compiler) traduit à l'exécution le code PHP fréquemment exécuté en code machine. Il est apparu avec PHP 8.0 et fait partie d'OPcache. Pour les sites web typiques, le gain de performance est généralement faible ; il est plus important pour les tâches exigeant beaucoup de calcul. JIT et performances dans PHP 8 →
Journal des modifications
Un journal des modifications (changelog) énumère les changements d'une version de programme ou de paquet, avec le numéro CVE pour les corrections de sécurité. Sous Debian et Ubuntu, apt-get changelog affiche le journal des modifications du paquet ; dans la famille RHEL, c'est rpm -q --changelog. Cela permet de justifier un backport même lorsque le numéro de version est identique. Prouver les numéros CVE dans le changelog d'un paquet →

L

LFI
LFI (Local File Inclusion) se produit lorsqu'une application inclut un fichier local dont le chemin peut être influencé par l'attaquant. Cela permet de lire des fichiers de configuration ou, dans certaines circonstances, d'exécuter du code introduit. La protection repose sur des listes d'autorisation fixes plutôt que sur des noms de fichiers issus de saisies utilisateur. Prévenir la Local File Inclusion en PHP : LFI et RFI →
LiteSpeed
LiteSpeed est un serveur web largement compatible avec les configurations Apache comme .htaccess et qui raccorde PHP via sa propre interface LSAPI. Il est répandu chez les hébergeurs ; OpenLiteSpeed en est la variante libre. Selon l'équipe PHP, LiteSpeed fait partie des modes d'exécution concernés par PHP2Shell. LiteSpeed et LSAPI : mettre PHP à jour →

M

memory_limit
memory_limit limite la quantité de mémoire vive qu'un script PHP individuel peut occuper ; la valeur par défaut est de 128 Mo. Lorsque la limite est atteinte, PHP s'interrompt avec une erreur de mémoire insuffisante. Contre CVE-2026-109618, php.net conseille à titre transitoire memory_limit=-1, défini de façon fixe, et une limite de mémoire via conteneur ou cgroup. Bien régler memory_limit →
mod_php
mod_php est le module PHP du serveur web Apache. PHP s'exécute alors directement dans le processus Apache, généralement avec les droits de son utilisateur. L'équipe PHP évalue le risque lié à PHP2Shell comme le plus élevé avec mod_php ; un exploit y a été démontré avant même que le code de l'application ne s'exécute. mod_php expliqué : PHP dans le processus Apache →
ModSecurity
ModSecurity est un WAF open source répandu qui fonctionne comme module dans Apache, Nginx ou d'autres serveurs web. Il évalue les requêtes à l'aide de règles et peut les journaliser ou les bloquer. Il est généralement utilisé avec le OWASP Core Rule Set. Mettre en œuvre ModSecurity et l'OWASP Core Rule Set →
Moindre privilège
Le moindre privilège (least privilege) signifie que chaque utilisateur et chaque processus ne reçoit que les droits dont il a réellement besoin. Si PHP s'exécute avec des droits restreints, un attaquant peut faire moins de dégâts après une intrusion. Cela concerne les utilisateurs système, les droits sur les fichiers, les comptes de base de données et les accès d'administration. Moindre privilège : les droits de l'utilisateur du serveur web →

N

Nginx
Nginx est un serveur web et proxy inverse répandu. Il n'exécute pas PHP lui-même, mais transmet les requêtes à PHP-FPM via FastCGI. Il importe d'avoir une configuration qui ne transmet à PHP que les vrais fichiers PHP et qui exclut les dossiers d'envoi. Sécuriser Nginx avec PHP-FPM →
NIS2
NIS2 est une directive de l'UE qui impose à de nombreuses entreprises et institutions des obligations de gestion des risques et de notification des incidents de sécurité. Elle concerne nettement plus de secteurs et de tailles d'entreprise que la réglementation précédente. Vous devez vérifier si votre entreprise est couverte au regard de la transposition nationale et avec un conseil juridique. NIS2 et sécurité des serveurs web →
Niveau d'alerte
Le BSI classe la situation de menace lors des alertes de sécurité en niveaux, également signalés par des couleurs. Le niveau 3 (orange) correspond à une situation critique pour l'activité, avec une perturbation massive possible du fonctionnement normal. Pour PHP2Shell, le niveau d'alerte 3 / orange s'applique. Niveau d'alerte orange du BSI : ce que cette évaluation signifie →

O

OPcache
OPcache est le cache de bytecode fourni avec PHP. Il stocke le code déjà compilé dans la mémoire partagée afin que les fichiers PHP ne soient pas recompilés à chaque requête. Après une mise à jour ou un nettoyage, le cache doit être vidé ou PHP redémarré, sinon l'ancien code peut continuer à s'exécuter. OPcache expliqué : le cache de bytecode de PHP →
open_basedir
open_basedir limite les répertoires auxquels les scripts PHP peuvent accéder avec des fonctions de fichiers. Sur les serveurs hébergeant plusieurs sites web, cela empêche un site de lire simplement les fichiers d'un autre. Ce n'est pas une isolation complète ; des utilisateurs système séparés et des pools FPM distincts en font partie. open_basedir et isolation par site web →
Out of Memory
Out of Memory (mémoire insuffisante) désigne l'état dans lequel un programme n'obtient plus de mémoire et doit s'interrompre. En PHP, cela se produit lorsque memory_limit est dépassé. Avec CVE-2026-109618, un tel arrêt peut interrompre PHP alors que les données de la requête ne sont initialisées qu'en partie. memory_limit et Out-of-Memory : ce qui se passe à l'intérieur →
OWASP CRS
Le OWASP Core Rule Set (CRS) est un ensemble de règles librement disponible pour ModSecurity et les WAF compatibles. Il détecte les classes d'attaques typiques comme l'injection SQL ou l'injection de commandes. Les règles doivent être adaptées à l'application, sinon elles bloquent aussi des requêtes légitimes. Mettre en œuvre ModSecurity et l'OWASP Core Rule Set →
OWASP Top 10
Le OWASP Top 10 est une liste régulièrement mise à jour des principaux risques pour les applications web, publiée par la fondation à but non lucratif OWASP Foundation. Il sert de base au développement, aux audits et aux formations. En complément, l'OWASP propose les Cheat Sheets avec des contre-mesures concrètes.

P

PECL
PECL (PHP Extension Community Library) est le répertoire des extensions PHP écrites en C qui ne font pas partie de l'ensemble standard. Ces extensions doivent correspondre à la version de PHP installée. Après un changement de version majeure de PHP, elles doivent souvent être recompilées ou remplacées. Comprendre les extensions PHP →
PHP
PHP est un langage de script qui s'exécute surtout sur des serveurs web, où il génère des pages web. De nombreux CMS et systèmes de boutique répandus, comme WordPress, TYPO3 ou Shopware, sont écrits en PHP. Une faille dans l'interpréteur PHP concerne donc toutes les applications qui s'exécutent dessus, indépendamment de leur propre niveau de mise à jour. Qu'est-ce que PHP ? Le langage de programmation expliqué →
php-cgi
php-cgi est le programme PHP destiné à l'exécution via CGI ou FastCGI. Selon l'équipe PHP, il fait partie des modes d'exécution concernés par PHP2Shell. Là où php-cgi est encore utilisé, il vaut la peine de vérifier s'il est possible de passer à PHP-FPM. php-cgi : un héritage risqué →
PHP-FPM
PHP-FPM (FastCGI Process Manager) est un service autonome qui gère les processus PHP en pools et reçoit les requêtes du serveur web via FastCGI. C'est aujourd'hui le mode d'exécution habituel avec Nginx et sur de nombreux serveurs Apache. Après une mise à jour de PHP, PHP-FPM doit être redémarré afin qu'aucun ancien processus ne continue de tourner. PHP-FPM expliqué : gestionnaire de processus, pools et workers →
php.ini
Le fichier php.ini est le fichier de configuration central de PHP. Il définit des limites ainsi que des paramètres de sécurité et d'erreurs, par exemple memory_limit ou display_errors. Il existe souvent un php.ini distinct par SAPI (FPM, CLI, Apache), à entretenir séparément. Le php.ini expliqué : structure, niveaux et priorité →
PHP2Shell
PHP2Shell est le nom donné à deux failles critiques dans PHP lui-même, CVE-2026-109618 et CVE-2026-109619, toutes deux avec un CVSS v4.0 de 9.2. Elles permettent d'exécuter du code malveillant à distance sans authentification. Elles sont corrigées dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiés le 21 octobre 2026. Qu'est-ce que PHP2Shell ? La faille expliquée simplement →
php_admin_value
php_admin_value définit un paramètre PHP dans le pool FPM ou dans la configuration Apache de telle sorte que les applications ne puissent pas l'écraser par ini_set() ou .htaccess. Pour les interrupteurs, il existe php_admin_flag. php.net recommande cette voie pour les mesures transitoires contre PHP2Shell, par exemple pour memory_limit. php_admin_value : verrouiller les paramètres contre l'écrasement →
Plan d'urgence
Un plan d'urgence informatique définit qui fait quoi lors d'un incident : contacts, circuits de décision, premières mesures, reprise d'activité. Il doit aussi être disponible hors ligne, au cas où les systèmes tomberaient en panne. Des exercices réguliers montrent s'il fonctionne en situation réelle. Créer un plan d'urgence informatique pour serveurs web →
Plesk
Plesk est un panneau d'administration répandu pour serveurs web, qui permet de régler les domaines, les versions de PHP et les gestionnaires par site web. Il fournit ses propres paquets PHP, mais peut aussi utiliser ceux de la distribution. En cas de backports, Plesk peut continuer à afficher un ancien numéro comme 8.2.34 alors que le correctif est appliqué. Serveur Plesk : vérifier et corriger les versions de PHP →
Pool FPM
Un pool est un groupe de processus PHP-FPM avec sa propre configuration, son propre socket et, idéalement, son propre utilisateur système. Un pool distinct par site web sépare les sites les uns des autres, de sorte qu'une intrusion dans un site n'atteint pas directement les fichiers des autres. Dans le pool, les paramètres peuvent être imposés de façon fixe avec php_admin_value. Isoler les pools PHP-FPM site par site →
Porte dérobée
Une porte dérobée (backdoor) est un accès caché par lequel des attaquants peuvent revenir après une intrusion. Ce peut être un fichier, un compte administrateur, une tâche cron ou une clé SSH. C'est pourquoi tout nettoyage inclut la recherche de tous les types d'accès, pas seulement des fichiers. Trouver une backdoor WordPress : repérer les portes dérobées méthodiquement →
post_max_size
post_max_size définit la taille totale maximale du contenu d'une requête POST ; la valeur par défaut est de 8 Mo. Comme mesure transitoire contre PHP2Shell, php.net indique 8M pour les sites sans envoi de fichiers et 32M avec envois. upload_max_filesize doit rester en dessous. Limiter judicieusement post_max_size et upload_max_filesize →
Preuve de concept
Une preuve de concept (PoC, proof of concept) démontre qu'une faille est exploitable, souvent sous la forme d'un simple code de démonstration. Elle sert aux éditeurs et aux chercheurs pour l'évaluation, mais peut aussi servir de modèle aux attaquants. Un PoC publié accroît donc en règle générale l'urgence de la correction.
Proxy inverse
Un proxy inverse (reverse proxy) reçoit les requêtes venant d'Internet et les transmet à un ou plusieurs serveurs situés derrière lui. Il peut prendre en charge TLS, répartir la charge et servir d'emplacement pour des règles de filtrage ou un WAF. Il n'offre une protection que si les serveurs situés derrière ne sont pas en plus directement joignables. Filtrer les requêtes d'upload en bordure : chances et risques →
Préservation des preuves
La préservation des preuves consiste à sécuriser les traces d'un incident avant qu'elles ne soient perdues par un nettoyage, un redémarrage ou une réinstallation. Cela comprend les fichiers journaux, les images de supports de données et, selon le cas, la mémoire vive. Après PHP2Shell, la presse spécialisée conseille de conserver les journaux du serveur à partir du 20 octobre 2026. Sécuriser les preuves avant de réinstaller le serveur →

R

Rançongiciel
Un rançongiciel (ransomware) chiffre des données et exige une rançon pour le déchiffrement, souvent accompagnée de la menace de publier les données volées. Un serveur web compromis peut en être le point d'entrée. La protection la plus efficace repose sur des sauvegardes séparées et testées ainsi que sur un plan d'urgence. Stratégie de sauvegarde pour serveurs : sauvegardes selon la règle 3-2-1 →
RCE
RCE (Remote Code Execution, exécution de code à distance) signifie qu'un attaquant peut exécuter son propre code sur un système tiers depuis l'extérieur. Si aucune authentification n'est nécessaire, on parle d'unauthenticated RCE, la classe la plus grave de failles de serveurs web. Avec une RCE, un attaquant peut lire des données, installer des portes dérobées et continuer à détourner le serveur. Qu'est-ce que PHP2Shell ? La faille expliquée simplement →
Retour d'expérience
Le retour d'expérience (lessons learned) est le bilan d'un incident : que s'est-il passé, qu'est-ce qui a bien fonctionné, que faut-il changer ? L'objectif est de définir des mesures concrètes avec des responsables et des échéances, sans chercher de coupables. Les résultats alimentent le plan d'urgence, le processus de correctifs et les formations. Retour d'expérience : s'améliorer après l'incident →
RFI
RFI (Remote File Inclusion) est la variante dans laquelle une application charge et exécute du code provenant d'une adresse extérieure. En PHP, le paramètre allow_url_include=Off, valeur par défaut depuis longtemps, empêche l'inclusion de fichiers distants. Les anciennes applications et configurations doivent être vérifiées à ce sujet. Prévenir la Local File Inclusion en PHP : LFI et RFI →
RGPD art. 33
L'art. 33 du RGPD oblige les responsables de traitement à notifier une violation de la protection des données personnelles à l'autorité de contrôle compétente, si possible dans les 72 heures après en avoir pris connaissance. L'obligation ne tombe que s'il est peu probable que la violation engendre un risque pour les personnes concernées. Au cas par cas, les délégués à la protection des données ou les avocats conseillent. Obligation de notification RGPD : 72 heures après l'incident →
RGPD art. 34
L'art. 34 du RGPD régit l'information des personnes concernées elles-mêmes. Elle est nécessaire lorsqu'une violation de données est susceptible d'engendrer un risque élevé pour leurs droits et libertés. Il convient d'évaluer si c'est le cas avec les délégués à la protection des données ou les avocats. Obligation de notification RGPD : 72 heures après l'incident →
Réponse aux incidents
La réponse aux incidents (incident response) est le traitement ordonné d'un incident de sécurité : détecter, contenir, préserver les traces, nettoyer, rétablir et faire le bilan. Une procédure définie évite que, dans la précipitation, des preuves soient détruites ou des portes dérobées oubliées. Des responsabilités claires et une documentation sans faille sont essentielles. Réponse aux incidents en cas d'attaques de serveurs →

S

SAPI
SAPI (Server Application Programming Interface) est l'interface par laquelle PHP communique avec son environnement, par exemple avec Apache, PHP-FPM ou la ligne de commande. La SAPI utilisée détermine la façon dont les processus PHP sont démarrés, réutilisés et redémarrés. Pour PHP2Shell, plusieurs modes d'exécution sont concernés selon l'équipe PHP, mod_php présentant le risque le plus élevé. SAPI expliquée : comment PHP dialogue avec le serveur web →
Sauvegarde 3-2-1
La règle 3-2-1 recommande trois copies des données sur deux supports de stockage différents, dont une dans un autre lieu. Au moins une copie ne devrait pas pouvoir être modifiée depuis le serveur, afin que les attaquants ne puissent ni la supprimer ni la chiffrer. Une sauvegarde ne compte que lorsque la restauration a été testée. Stratégie de sauvegarde pour serveurs : sauvegardes selon la règle 3-2-1 →
serialize_handler
session.serialize_handler détermine le format dans lequel PHP enregistre les données de session, par exemple php, php_binary ou php_serialize. L'avis relatif à CVE-2026-115560 ne concerne qu'une configuration inhabituelle dans laquelle ce format est modifié à l'exécution alors que Session Upload Progress est actif. En attendant la prochaine version corrective, la parade est session.upload_progress.enabled=0. CVE-2026-115560 : avis sur Session Upload Progress →
Serveur d'origine
Le serveur d'origine (origin server) est le véritable serveur web situé derrière un CDN ou un proxy inverse. S'il est aussi directement joignable par son adresse IP, des attaquants peuvent contourner la protection placée en amont. L'origine ne devrait donc accepter que les connexions du CDN ou du proxy. Règles de protection Cloudflare contre PHP2Shell : ce qu'elles apportent et ce qu'elles n'apportent pas →
Serveur géré
Avec un serveur géré (managed server), le fournisseur met à disposition un serveur dédié et assure contractuellement certaines parties de l'exploitation, souvent les mises à jour du système d'exploitation et de PHP. Ce qui en fait exactement partie figure dans le contrat et varie fortement d'un fournisseur à l'autre. Dans le doute, la responsabilité des correctifs doit être confirmée par écrit. Serveur managé : clarifier la responsabilité →
Serveur root
Un serveur root est un serveur loué sur lequel le client dispose de tous les droits d'administrateur. La pleine responsabilité des mises à jour, du durcissement et de la surveillance incombe donc aussi au client. Le fournisseur ne met à disposition que le matériel et le réseau. Sécuriser soi-même un serveur dédié et un vServer →
Serveur virtuel (vServer)
Un serveur virtuel (vServer) est une machine virtuelle sur du matériel partagé, avec son propre système d'exploitation et généralement un accès root. En matière de sécurité, la même chose que pour le serveur root s'applique : les mises à jour et le durcissement incombent au client. De nombreux serveurs virtuels fonctionnent avec des panneaux préinstallés comme Plesk. Sécuriser soi-même un serveur dédié et un vServer →
Session
Une session relie plusieurs requêtes d'un même visiteur, par exemple pour la connexion ou le panier. PHP enregistre les données côté serveur et remet au navigateur un identifiant de session, par défaut dans le cookie PHPSESSID. Quiconque connaît l'identifiant de session d'un tiers peut, dans certaines circonstances, se faire passer pour cet utilisateur. Sessions et cookies en PHP →
session.upload_progress
Session Upload Progress est une fonction PHP qui enregistre dans la session la progression des envois de fichiers en cours ; elle est activée par défaut. php.net conseille à titre transitoire session.upload_progress.enabled=0 dans php.ini, le pool FPM ou la configuration du serveur, puis de redémarrer tous les workers. Selon des rapports spécialisés, ce paramètre seul ne referme pas les deux failles PHP2Shell ; la mise à jour reste obligatoire. Désactiver session.upload_progress : correctement et durablement →
SIEM
Un SIEM (Security Information and Event Management) collecte de manière centralisée les données de journaux de nombreux systèmes et les analyse pour y détecter des événements de sécurité. Cela permet de repérer des corrélations qui se perdent dans les journaux isolés. Un SIEM a besoin de règles entretenues et de personnes qui traitent les alertes. Supervision de sécurité pour serveurs web →
Skimming
Dans le skimming sur les boutiques en ligne, des attaquants introduisent dans le tunnel de paiement un JavaScript qui lit et transmet les données de paiement et de clients. Le code se cache souvent dans des fichiers de thème, des scripts de suivi ou des entrées de base de données. Les clients ne s'en aperçoivent pas, le commerçant souvent seulement grâce aux alertes des prestataires de paiement. Boutique en ligne piratée ? Sécurité informatique pour les commerçants →
Spam SEO
Le spam SEO désigne des pages, des liens ou des redirections introduits, par lesquels des attaquants placent des offres tierces dans les moteurs de recherche. Souvent, seuls les moteurs de recherche ou les visiteurs venant de Google voient les contenus manipulés. Outre le nettoyage, une vérification dans Google Search Console est ensuite nécessaire. Spam SEO et pages étrangères dans l'index Google →
SSRF
SSRF (Server-Side Request Forgery) amène une application à envoyer, pour le compte de l'attaquant, des requêtes vers d'autres adresses, y compris vers des systèmes internes. Des services normalement isolés de l'extérieur deviennent ainsi accessibles. La protection repose sur des listes d'autorisation pour les destinations et sur le blocage des plages d'adresses internes. Empêcher le Server-Side Request Forgery (SSRF) en PHP →
Superglobales
Les superglobales sont des variables que PHP met à disposition dans chaque script, par exemple $_GET, $_POST, $_COOKIE, $_FILES, $_SERVER et $_SESSION. Elles contiennent les données de la requête en cours, qui proviennent en grande partie du visiteur. Tout ce qu'elles contiennent doit être considéré comme non fiable et être vérifié. Superglobales : $_GET, $_POST, $_FILES et consorts →
Supervision
La supervision (monitoring) est la surveillance continue des systèmes, par exemple la disponibilité, la charge, les fichiers journaux et les modifications de fichiers. La supervision de sécurité recherche spécifiquement des anomalies comme de nouveaux fichiers PHP ou des shells lancés par le serveur web. Elle n'est utile que si quelqu'un évalue rapidement les alertes. Supervision de sécurité pour serveurs web →
sury.org
sury.org est un dépôt de paquets d'Ondřej Surý contenant des versions récentes et anciennes de PHP pour Debian et Ubuntu. C'est une offre de tiers et non l'archive de sécurité de Debian. Selon des rapports, des builds pour toutes les branches de 5.6 à 8.5 y ont été mis à disposition. Le dépôt sury.org : des paquets PHP issus d'une source tierce →

T

Threat hunting
Le threat hunting est la recherche active d'attaquants dans son propre réseau, sans qu'une alerte ait été émise. Le point de départ est constitué d'hypothèses, par exemple : un processus de serveur web a-t-il lancé un shell depuis le 20 octobre ? On y découvre des intrusions que les outils automatiques ont manquées. Signal d'alerte : le serveur web lance un shell →
TISAX
TISAX est un processus d'évaluation et d'échange pour la sécurité de l'information dans l'industrie automobile. Il repose sur un catalogue d'exigences de l'association allemande de l'industrie automobile (VDA) et est exploité par l'ENX Association. Les sous-traitants doivent ainsi prouver leur niveau de sécurité aux constructeurs. ISO 27001 et TISAX : ce que cela implique pour les serveurs web →
TLS
TLS (Transport Layer Security) chiffre la connexion entre le navigateur et le serveur ; on le reconnaît à HTTPS. Les versions actuellement recommandées sont TLS 1.2 et 1.3 ; les anciennes versions du protocole devraient être désactivées. TLS protège les données en transit, pas contre les failles du serveur lui-même. Bien configurer TLS et HTTPS →
Type juggling
On appelle type juggling la conversion automatique de types en PHP, par exemple lors d'une comparaison lâche avec ==. Des valeurs peuvent ainsi être considérées comme égales alors qu'elles ne le sont pas, ce qui devient dangereux lors de vérifications de mots de passe ou de jetons. La protection repose sur des comparaisons strictes avec === et sur hash_equals() pour les secrets. Type juggling en PHP : les comparaisons lâches comme risque de sécurité →

U

upload_max_filesize
upload_max_filesize limite la taille d'un fichier envoyé individuellement ; la valeur par défaut est de 2 Mo. La valeur doit être inférieure à post_max_size, car le fichier fait partie de la requête POST. Des valeurs trop généreuses agrandissent la surface d'attaque sans utilité. Limiter judicieusement post_max_size et upload_max_filesize →
.user.ini
Les fichiers .user.ini sont des paramètres PHP définis par répertoire, pris en compte par PHP-FPM et CGI. Ils permettent aux exploitants de sites web de modifier certaines valeurs sans accès au serveur, mais seulement celles que PHP autorise pour cela. Selon php.net, les consignes de sécurité comme session.upload_progress.enabled=0 contre PHP2Shell ne doivent pas être définies via .user.ini. Le php.ini expliqué : structure, niveaux et priorité →

V

VdS 10000
VdS 10000 est une directive de VdS Schadenverhütung (organisme allemand de prévention des sinistres) pour la sécurité de l'information dans les petites et moyennes entreprises. Elle est plus légère qu'ISO 27001 et adaptée aux moyens des PME. Une certification selon cette directive est possible. VdS 10000 : la sécurité de l'information pour les petites et moyennes entreprises →

W

WAF
Un WAF (Web Application Firewall) examine les requêtes HTTP en amont de l'application et bloque les schémas d'attaque connus. Il peut fonctionner comme service cloud, comme proxy ou comme module de serveur web. Il fait gagner du temps, mais ne remplace pas une mise à jour, et il est contourné si le serveur est aussi directement joignable. WAF et correctif virtuel pour PHP →
Webshell
Une webshell est un script que des attaquants déposent sur un serveur web pour le contrôler à distance via le navigateur. Elle est souvent petite, dissimulée et cachée dans des dossiers d'envoi ou de cache. Une webshell subsiste même après une mise à jour de PHP ou du CMS et doit être recherchée de manière ciblée. Détecter et supprimer un webshell →

X

XSS
XSS (cross-site scripting) signifie qu'un JavaScript étranger est exécuté, via un site web, dans le navigateur d'autres visiteurs. Cela permet de détourner des sessions ou de lire des saisies de formulaires. La protection repose sur un encodage systématique de toutes les sorties et sur une Content Security Policy. Prévenir le XSS en PHP : se défendre sûrement contre le cross-site scripting →
XXE
XXE (XML External Entities) exploite le fait que les analyseurs XML peuvent charger des références externes dans les documents. Cela peut permettre de lire des fichiers du serveur ou de déclencher des requêtes internes. La protection consiste à désactiver le chargement des entités externes lors du traitement de données XML non fiables. Empêcher les XML External Entities (XXE) en PHP →

Z

ZAC
Les ZAC (Zentrale Ansprechstellen Cybercrime, points de contact centraux pour la cybercriminalité) de la police allemande sont des points de contact spécialisés pour les entreprises et les autorités victimes d'une cyberattaque. Il en existe dans tous les Länder et auprès du BKA. Ils enregistrent les plaintes et conseillent sur la suite à donner. Porter plainte : les Zentrale Ansprechstellen Cybercrime →
Zend Engine
La Zend Engine est le cœur de l'interpréteur PHP. Elle traduit le code PHP en instructions internes (opcodes), les exécute et gère la mémoire. Les erreurs de la Zend Engine affectent toutes les applications PHP et ne peuvent être corrigées que par une mise à jour de PHP. La Zend Engine : le cœur de PHP →
Zero-Day
Un zero-day est une faille exploitée ou connue publiquement avant que l'éditeur ne fournisse un correctif. Les exploitants disposent alors de zéro jour d'avance. Jusqu'au correctif, seules les mesures transitoires, l'isolation et la surveillance aident. Le délai entre le correctif et l'attaque →
Contact immédiat

Chaque heure compte. Écrivez-nous maintenant.

Décrivez brièvement votre système, votre version de PHP et ce que vous avez observé. Nous vous répondons, faisons le point et travaillons à distance jusqu'à la clôture et la documentation de l'incident.

Aide immédiate