Elastic épinglé par le CERT-FR : onze avis de sécurité pour Elasticsearch, Kibana et Fleet Server

Le CERT-FR a publié le 2 juillet 2026 l'avis CERTFR-2026-AVI-0826, qui documente onze bulletins de sécurité distincts touchant l'ensemble de la pile logicielle Elastic — Elasticsearch, Kibana, Fleet Server et Elastic Defend. Les failles recensées permettent un déni de service à distance, une atteinte à la confidentialité des données et une atteinte à leur intégrité. Pour toute organisation qui s'appuie sur Elastic pour indexer des journaux d'accès, des données de sécurité ou, plus largement, des données personnelles, l'article 32 du RGPD s'active immédiatement.

Onze bulletins, une seule pile logicielle

L'avis du CERT-FR agrège onze bulletins de sécurité publiés par l'éditeur le 1er juillet 2026, correspondant à onze CVE distincts (dont CVE-2026-32283, CVE-2026-49087 à 49091, et CVE-2026-56148 à 56152). Les versions concernées couvrent une large partie du parc installé :

• Elasticsearch : versions 7.x antérieures à 7.17.24, 8.x antérieures à 8.19.17, 9.x antérieures à 9.3.5, et 9.4.x antérieures à 9.4.3
• Kibana : versions 7.x, 8.16.x à 8.19.x et 9.x, selon des seuils de correctifs différents
• Fleet Server : versions 8.x antérieures à 8.19.15 et 9.x antérieures à 9.3.4
• Elastic Defend : versions 9.3.x, 9.x et les branches postérieures à 8.6.x, chacune avec son propre seuil de correctif

Les risques cumulés — déni de service, contournement de la politique de sécurité, atteinte à la confidentialité et à l'intégrité des données — touchent des composants qui, par construction, centralisent des volumes importants de journaux techniques et, souvent, de données à caractère personnel (adresses IP, identifiants utilisateurs, adresses email).

Pourquoi cette alerte concerne directement les DPO et les RSSI

Le paradoxe est net : Elastic Stack sert très souvent d'infrastructure de journalisation ou de SIEM (system de gestion des informations et des événements de sécurité) — l'outil censé détecter les intrusions. Une vulnérabilité qui compromet la confidentialité de cette même infrastructure élargit d'autant le périmètre d'un incident potentiel. C'est exactement le terrain que couvre l'article 32 du RGPD, qui impose des mesures techniques et organisationnelles adaptées au risque, et qui structure aussi les obligations croisées avec la directive NIS 2 pour les entités qui y sont soumises.

Si une exploitation de ces failles a permis un accès non autorisé à des données personnelles avant l'application du correctif, l'obligation de notification à la CNIL sous 72 heures prévue par l'article 33 du RGPD peut se déclencher. Le guide Leto sur la violation de données détaille la procédure et les exceptions à cette obligation.

Cet avis n'est pas isolé : Leto a suivi ces derniers mois des avis CERT-FR similaires visant SAP, Nextcloud, GLPI et Atlassian. Le rythme mensuel de ces publications montre que la gestion des vulnérabilités logicielles est devenue un poste permanent de la conformité RGPD, et non plus un événement exceptionnel.

Ce que ça change pour les organisations : le plan d'action à 72 heures

Les équipes DPO et RSSI qui utilisent Elastic — en instance auto-hébergée ou via Elastic Cloud — doivent enclencher, dans les meilleurs délais :

• Inventorier les instances Elasticsearch, Kibana, Fleet Server et Elastic Defend déployées, en distinguant celles exposées sur Internet des instances internes
• Patcher vers les versions corrigées indiquées par l'éditeur pour chaque composant concerné
• Auditer les journaux pour détecter tout signe d'exploitation antérieure au correctif, en particulier sur les instances exposées publiquement
• Qualifier l'incident : si un accès non autorisé aux données est confirmé ou suspecté, documenter la décision de notifier ou non la CNIL, dans les délais de l'article 33
• Vérifier les obligations contractuelles si Elastic est opéré par un prestataire tiers, au titre de l'article 28 du RGPD sur l'encadrement des sous-traitants

Ce que Leto pense de cette décision

Un avis CERT-FR par mois sur un composant d'infrastructure critique n'est plus une anomalie, c'est un régime de croisière. Traiter chaque publication comme un exercice ponctuel de gestion de crise coûte cher en énergie et en attention ; l'enjeu pour les DPO est désormais de construire un processus répétable — inventaire à jour, cadence de patch, grille de décision de notification — plutôt que de réinventer la réponse à chaque avis. Le cas Elastic ajoute une dimension supplémentaire : quand l'outil de détection devient lui-même la surface d'attaque, les angles morts se multiplient plus vite qu'ailleurs.

Sources : CERT-FR, avis CERTFR-2026-AVI-0826