CSIRT européens : qui publie les meilleurs avis ? Notre Top 3

À la suite de la publication des vulnérabilités php2shell, on a découvert que l'ENISA référençait sur son dépôt GitHub les liens vers les avis des différents CSIRT européens sur les vulnérabilités ou les incidents majeurs.

On a rapidement constaté que tous ces avis ne se valent pas. Certains donnent les versions corrigées, les commandes de contournement et des règles de détection. D'autres se contentent de dire « appliquez les correctifs ».

On a donc voulu mesurer cet écart à plus grande échelle, avec une question pratique en tête : quand on rassemble pour chaque vulnérabilité les informations utiles à la remédiation, quels avis méritent d'être agrégés, et comment arbitrer quand ils se contredisent ? On a évalué tous les avis nationaux référencés par le réseau européen des CSIRT pour 51 vulnérabilités ou incidents majeurs, de Log4Shell (décembre 2021) à php2shell (octobre 2026).

Le dépôt compte 51 événements et 604 liens vers des avis. C'est une base idéale pour comparer les CSIRT : même vulnérabilité, même période, des auteurs différents.

Notre méthode

Chaque page a été notée sur 7 critères, de 0 à 3 chacun, soit un total sur 21 :

Critère	Ce qu'on attend au meilleur niveau (3)
Correctif	Versions corrigées par branche, plus les branches en fin de vie, les rétroportages ou les produits qui embarquent le composant
Contournements	Valeurs ou commandes exactes, où les appliquer, et leurs limites
Détection	Indicateurs de compromission, règles (Sigma, YARA, Suricata…) ou script de détection
Exploitation	Chronologie datée : PoC, tentatives, exploitation confirmée
Technique	Cause racine et conditions qui rendent un système exploitable
Apport propre	Information absente de l'avis de l'éditeur : télémétrie nationale, outillage, analyse originale
Mises à jour	Plusieurs révisions datées qui suivent l'évolution de l'événement

La notation s'est d'abord basée sur php2shell avant d'élargir aux autres vulnérabilités ou incidents.

Dans un second temps, on a essayé de repérer les contradictions entre les différents avis telles que des versions corrigées différentes, des statuts d'exploitation divergents ou des contournements jugés efficaces par les uns et insuffisants par les autres.

Quelques règles importantes :

• Seules les pages encore en ligne ont été évaluées. Un lien mort ou un site qui refuse l'accès automatisé est compté comme « non évaluable », pas comme un mauvais avis.
• Quand un CSIRT a publié plusieurs pages sur un même événement (un avis par CVE, ou une alerte suivie d'un article), nous avons retenu la meilleure.
• Alertes, avis et articles d'actualité sont notés de la même façon car chaque CSIRT a son propre vocabulaire.
• Quand un lien du dépôt est mort mais que le même avis existe à une nouvelle adresse, nous avons évalué la nouvelle adresse. C'est le cas de 11 avis du NCSC néerlandais, qui a changé de site.
• L'apport propre est mesuré par rapport à l'avis de l'éditeur. Pour chaque événement, nous avons récupéré l'avis de l'éditeur (ou du projet concerné, comme PHP ou Apache). Ce qu'il contient déjà (versions corrigées, contournements, explications techniques) n'est pas compté comme un apport du CSIRT, même traduit ou reformulé. Limite : nous avons lu ces avis dans leur version actuelle. Si un éditeur a complété sa page après coup, le CSIRT qui avait donné l'information en premier n'en a plus le crédit.

Au total, 464 avis ont pu être évalués. L'IA nous a aidés à traiter ce volume. Elle a extrait de chaque page les informations utiles (versions corrigées, contournements, statut et date d'exploitation) puis nous a permis de les trier et de comparer les avis entre eux.

Le classement

Chaque CSIRT est noté sur la moyenne de ses meilleurs avis par événement. Pour éviter les moyennes instables, ce tableau ne retient que les 17 CSIRT évalués sur au moins 10 événements (vulnérabilités ou incidents majeurs).

#	CSIRT	Pays	Événements évalués	Note /21
1	CERT-Bund (BSI)	Allemagne	33	12,9
2	CERT-FR (ANSSI)	France	37	11,2
3	CIRCL	Luxembourg	18	11,1
4	NCSC-NL	Pays-Bas	29	10,6
5	CERT-EU	Institutions de l'UE	27	10,4
6	CSIRT Italia (ACN)	Italie	19	10,4
7	SK-CERT	Slovaquie	14	10,3
8	CERT.be	Belgique	12	10,2
9	CERT-SE	Suède	31	9,8
10	SI-CERT	Slovénie	14	9,7
11	CERT.at	Autriche	30	9,6
12	NCSC-FI	Finlande	30	9,6
13	NCSC-IE	Irlande	38	9,0
14	CERT.hr	Croatie	13	8,2
15	INCIBE-CERT	Espagne	38	8,1
16	CCN-CERT	Espagne	22	7,8
17	NCSC-HU	Hongrie	11	6,7

Les moyennes vont presque du simple au double (de 6,7 à 12,9). Derrière le CERT-Bund, les quatre suivants se tiennent en moins d'un point, et aucun ne domine sur tous les critères.

Le CERT-Bund allemand se détache nettement. Ses avis combinent versions corrigées par produit, contournements détaillés, indicateurs de compromission et chronologie d'exploitation datée. C'est le seul CSIRT du tableau à dépasser 2/3 en moyenne sur l'exploitation.

Le CERT-FR est 2e et se distingue par le suivi. Il met régulièrement ses avis à jour au fil de l'événement. C'est aussi l'un des plus assidus (37 événements évalués sur 39 référencés).

Le CIRCL luxembourgeois, 3e à un dixième de point, est l'un des plus forts en détection et en apport propre.

Le CERT-EU obtient la meilleure note technique du panel, mais parle peu de l'exploitation.

Ces moyennes masquent de beaux avis partout. Les meilleurs avis individuels (20/21) sont ceux de SK-CERT et du CCN-CERT espagnol sur Log4Shell. Le CCN-CERT a publié six révisions datées, avec scanners, règles YARA et flux d'indicateurs. C'est pourtant un CSIRT dont la moyenne est basse : la qualité dépend beaucoup de l'événement.

Les 11 autres CSIRT avaient moins de 10 événements évalués : leurs moyennes sont trop fragiles pour être classées.

Étude de cas : php2shell

php2shell est le dernier événement du dépôt (21 octobre 2026) : des vulnérabilités critiques dans PHP (CVE-2026-109618 et CVE-2026-109619, puis une troisième, CVE-2026-115560), corrigées dans PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12.

Le dépôt CNW référence 26 CSIRT, dont 22 avec un avis évaluable.

CSIRT	Note /21	Avis
CERT-Bund (BSI)	19	Lien
CSIRT Italia (ACN)	18	Lien
NCSC-HU	18	Lien
NCSC-FI	17	Lien
CIRCL	17	Lien
CERT-EU	16	Lien
INCIBE-CERT	16	Lien
CERT-FR	15	Lien
NCSC-NL	14	Lien
CERT Polska	13	Lien
CERT.LV	12	Lien
SI-CERT	12	Lien
SK-CERT	11	Lien
CERT.hr	10	Lien
NCSC-IE	10	Lien
CERT.at	9	Lien
CERT-SE	9	Lien
CERT-EE (RIA)	8	Lien
CERT.bg	8	Lien
CFCS / SAMSIK	6	Lien
CERT ZSIS / NCSC.hr	6	Lien
CCN-CERT	5	Lien

Sur le même événement, les notes vont de 5/21 à 19/21.

Le meilleur avis, celui du CERT-Bund, donne les versions corrigées, y compris les correctifs rétroportés pour les versions en fin de vie, et des contournements détaillés avec leurs limites. Il rappelle que mettre à jour l'application ne suffit pas : c'est PHP lui-même qu'il faut corriger, images Docker comprises. Il liste les équipements réseau touchés ou non (F5, QNAP, Synology), réfute les rumeurs de correctifs incomplets et propose des pistes de recherche de compromission. Il a connu trois versions en deux jours.

Juste derrière, à 18/21, l'avis de l'ACN italienne donne les versions corrigées par branche, explique la cause racine et suit le statut d'exploitation, avec plusieurs mises à jour jusqu'au 28 octobre.

La détection fait la différence. Le NCSC hongrois, dernier du classement général, obtient lui aussi 18/21. C'est le seul avis à fournir des règles de détection prêtes à l'emploi, reprises de l'éditeur de sécurité Lorikeet Security :

• une règle auditd qui signale les shells lancés par le compte du serveur web et les écritures dans /tmp et /dev/shm ;
• une règle Falco pour les conteneurs et Kubernetes, qui lève une alerte critique quand un processus PHP-FPM ou Apache lance un shell ;
• une signature Suricata/Snort qui repère les requêtes POST multipart répétées, avec un Content-Length démesuré, visant les limites mémoire du moteur Zend (CVE-2026-109618).

L'avis ajoute des pistes de recherche dans les journaux : réponses HTTP 500 vides en série, processus PHP-FPM arrêtés par SIGSEGV ou SIGABRT, connexions sortantes depuis les comptes www-data ou apache, et les User-Agent des outils de preuve de concept publics (php2shell-poc, php2shell-verify/1.0). Il liste aussi les processus suspects à surveiller sous Linux et sous Windows/IIS (w3wp.exe qui lance cmd.exe ou powershell.exe, par exemple).

À l'inverse, 10 avis sur 22 ne disent rien de la détection.

Les 3 avis avec les notes les plus faibles ne donnent aucune version corrigée, alors que la plupart des autres les listent. Certains avis recommandent même toujours, à la date de rédaction de cet article, de mettre les systèmes hors ligne en attendant une mise à jour.

L'événement concentre aussi plusieurs contradictions, qui montrent à quel point la lecture d'un seul avis peut induire en erreur :

• Exploitation. Le 21 octobre, la plupart des avis signalent un PoC public, et trois affirment que la faille n'est pas exploitée. Le CERT-Bund signale des tentatives dès le 22 octobre, les avis mis à jour le 26 octobre aussi, ceux des 28 et 30 octobre une exploitation active. Au moment de l'étude, le 1er novembre 2026, trois CSIRT écrivaient encore « non exploitée » : leurs pages, publiées le 21 octobre, n'avaient pas été mises à jour depuis.
• Contournement par memory_limit. La majorité recommande memory_limit=-1, imposé côté administrateur. Le CERT Polska propose 128M ou plus en solution de repli, alors que l'INCIBE-CERT précise que 128M ne désactive pas la vulnérabilité. L'avis de PHP donne raison à l'INCIBE-CERT.
• Où appliquer session.upload_progress.enabled=0. Cinq avis, dont celui du CERT-Bund, précisent qu'il faut le faire dans php.ini ou la configuration du serveur, pas dans .user.ini. Le CERT-EE indique au contraire que .user.ini convient. L'avis de PHP donne raison aux cinq premiers.
• Versions en fin de vie. Certains CSIRT signalent des correctifs rétroportés (en code source) pour PHP 7.4, 8.0 et 8.1. D'autres affirment qu'aucun correctif n'existera et qu'il faut isoler ou retirer ces systèmes.

Un administrateur qui n'aurait lu qu'un de ces avis pouvait donc croire la faille non exploitée, appliquer un contournement inefficace, ou décommissionner un serveur qu'il pouvait corriger.

225 contradictions entre CSIRT

La comparaison des avis a relevé 225 contradictions sur 46 événements, dont 36 jugées à fort impact pour les équipes sécurité.

Sujet	Contradictions
Versions corrigées	70
Statut d'exploitation	63
Contournements	37
Périmètre affecté	16
Gravité, impact	7
Autres	32

Log4Shell en est l'exemple le plus parlant. Selon le CSIRT consulté, la version « corrigée » était 2.15.0, 2.17.0 ou 2.17.1. Le paramètre formatMsgNoLookups=true était présenté comme un contournement valable par certains avis (CCN-CERT, CIRCL, GR-CSIRT, CSIRT-CY, INCIBE-CERT), et comme insuffisant par d'autres (CERT-FR, CERT.at, CERT.hr, SI-CERT, SK-CERT, CERT ZSIS / NCSC.hr), car il ne protège pas contre la CVE-2021-45046.

Souvent, personne ne se trompe au moment où il écrit. La contradiction vient d'un avis publié tôt et jamais mis à jour. Par exemple, sur les failles Exchange ProxyNotShell de 2022 (CVE-2022-41040 et CVE-2022-41082), certains avis ne proposent que des contournements (CIRCL, NCSC-IE, GovCERT.CZ, INCIBE-CERT), et l'un d'eux affirme même qu'aucun correctif n'existe (CERT.at), alors que Microsoft a publié les correctifs depuis.

Pour une équipe sécurité, un avis lu seul peut être incomplet. Il faut vérifier la date de la dernière mise à jour et croiser les sources.

Ce qu'il faut en retenir

1. Aucun avis n'est complet. Même le CSIRT le mieux noté plafonne à 12,9/21 en moyenne. Pour remédier vite, il faut croiser plusieurs sources.
2. La détection est le maillon faible. C'est le critère le moins bien noté sur l'ensemble des avis : sur php2shell, 10 avis sur 22 n'en disent rien. Les CSIRT qui en fournissent régulièrement, comme le CERT-Bund ou le CIRCL, méritent d'être suivis même hors de votre pays.
3. La date compte autant que le contenu. Beaucoup de contradictions viennent de pages figées. Un avis non mis à jour depuis le correctif est à lire avec prudence.
4. Lire au-delà de son CSIRT national est pertinent car les avis d'autres pays apportent souvent des détails que l'avis local n'a pas.

C'est la question qui a lancé cette analyse, et le problème que SYRN cherche à résoudre : rassembler, pour chaque vulnérabilité, les informations dispersées entre éditeurs, CSIRT et sources de renseignement, et faire ressortir la plus récente plutôt que la première publiée.

Limites de l'étude

• Pages en ligne uniquement. Beaucoup de liens de 2021 à 2023 sont morts. Les CSIRT qui ont refondu leur site sont donc moins bien couverts sur les événements anciens.
• Notation automatique. La grille est fixe et a été validée sur un événement noté à la main, mais un modèle de langage peut se tromper sur une page donnée.
• Petits échantillons. Un CSIRT évalué sur 2 ou 3 événements a une moyenne peu fiable ; c'est pourquoi le classement ne retient que les CSIRT évalués sur au moins 10 événements.
• Utilité pour la remédiation, pas qualité générale. Un avis court publié très tôt pour alerter peut être exactement ce qu'il fallait à ce moment-là, même s'il obtient une note basse ici.
• Des formats nationaux différents. Certains CSIRT séparent des alertes d'urgence, publiées tôt et peu détaillées, d'avis plus techniques publiés ensuite : le CERT-FR distingue ainsi ses « alertes » de ses « avis ». Nous avons retenu la meilleure page de chaque CSIRT, mais quand un CSIRT ne publie qu'une alerte, elle est comparée à des avis complets. Cela désavantage les CSIRT dont le modèle privilégie la réactivité.
• Le dépôt CNW n'est pas exhaustif. Un CSIRT peut avoir publié un avis que le dépôt ne référence pas.