Gravity SMTP : une faille exposait les clés API de votre messagerie sur 100 000 sites WordPress

Gravity SMTP, plugin d'envoi d'emails installé sur environ 100 000 sites WordPress, contenait un endpoint accessible sans aucune authentification qui livrait un rapport système complet : clés API, tokens OAuth, identifiants de services email, versions logicielles et structure de la base de données. Le correctif existe depuis mars 2026 - mais l'exploitation massive n'a commencé que fin mai, avec un pic de plus de 4 millions de tentatives bloquées en une seule journée début juin. Wordfence en a comptabilisé plus de 17 millions au total. Sans maintenance corrective WordPress, un correctif disponible depuis des mois ne protège rien s'il n'est jamais appliqué.

Gravity SMTP : un plugin d'envoi d'emails sur 100 000 sites

Gravity SMTP est un plugin qui configure et fiabilise l'envoi d'emails transactionnels depuis WordPress, en remplaçant la fonction d'envoi native peu fiable par une connexion directe à des services professionnels comme Amazon SES, Google, Mailjet, Resend ou Zoho. Plus de 100 000 sites l'utilisent selon WordPress.org.

Le 31 mars 2026, Wordfence publie la faille référencée CVE-2026-4020, notée 5.3 sur l'échelle CVSS - une exposition d'informations sensibles sans authentification. Le correctif, lui, était déjà disponible depuis le 17 mars, dans la version 2.1.5. Près de trois mois plus tard, l'exploitation à grande échelle documentée par SecurityWeek montre qu'un nombre important de sites n'avait toujours pas appliqué cette mise à jour.

La faille : un endpoint qui répond toujours "oui, vous avez le droit"

Gravity SMTP enregistre un endpoint de l'API REST de WordPress à l'adresse /wp-json/gravitysmtp/v1/tests/mock-data. Chaque endpoint REST doit normalement vérifier, via une fonction appelée permission_callback, si la personne qui appelle a le droit d'accéder à la ressource demandée. Celui de Gravity SMTP renvoie inconditionnellement true - littéralement : "oui, accès autorisé", quelle que soit la personne qui pose la question.

En ajoutant le paramètre ?page=gravitysmtp-settings à cette requête, n'importe quel visiteur anonyme reçoit en retour l'intégralité du rapport système du plugin, au format JSON. Selon les chercheurs de Defiant (Wordfence) : « the impacted REST API endpoint does not perform authentication or capability checks » - l'endpoint concerné n'effectue aucune vérification d'authentification ni de droits.

Ce que révèlent 365 Ko de données exposées

La réponse de l'endpoint pèse environ 365 Ko de JSON - un rapport système complet, pas un message d'erreur anodin. Concrètement, il contient :

• Clés API, secrets et tokens OAuth pour chaque connecteur email configuré : Amazon SES, Google, Mailjet, Resend, Zoho
• Versions exactes de WordPress, PHP et des extensions PHP chargées
• Type et version du serveur web, chemin racine du site sur le serveur
• Informations sur la base de données : type, version, noms des tables
• Liste complète des plugins et du thème actifs

Les clés API et tokens OAuth sont la pièce la plus monétisable de ce lot. Une clé Amazon SES ou Google compromise permet d'envoyer des emails au nom du domaine légitime - utile pour des campagnes de phishing crédibles - ou de consommer un quota facturé à l'usage jusqu'à ce que le titulaire s'en rende compte. Le reste du rapport (versions, structure de base de données, plugins actifs) sert moins à l'attaque immédiate qu'à la préparation d'une attaque ultérieure mieux ciblée.

Pourquoi cette faille explose deux mois après le correctif

C'est l'aspect le plus instructif de cet incident. Le correctif est sorti le 17 mars 2026. La faille a été documentée publiquement le 31 mars. Et pourtant, selon CrowdSec, la première exploitation confirmée à grande échelle ne remonte qu'au 27 mai - près de deux mois plus tard. Le volume a ensuite grimpé brutalement début juin, avec un pic de plus de 4 millions de requêtes bloquées en une seule journée le 7 juin.

Ce délai n'a rien d'inhabituel. Les groupes qui automatisent l'exploitation de masse ne réagissent pas instantanément à chaque divulgation - ils intègrent une nouvelle faille à leurs outils de scan quand elle atteint une masse critique de cibles non corrigées, ou quand sa valeur de revente (ici, des clés API monétisables) en fait une priorité. Une fois ce seuil franchi, le scan devient indiscriminé et touche tous les sites non mis à jour, sans exception.

Dans les audits que nous menons sur des installations négligées depuis plusieurs mois, c'est précisément ce type de fenêtre - correctif disponible, mais non appliqué - qui explique la majorité des compromissions que nous traitons. Le danger n'est presque jamais la faille du jour zéro : c'est la faille connue depuis des semaines sur un plugin qu'on a oublié de mettre à jour.

Les indicateurs de compromission à vérifier

Versions concernées et correctif

Ce qu'il faut faire maintenant

Si vous gérez plusieurs sites et n'avez pas le temps de vérifier chaque mise à jour de sécurité disponible depuis des mois, c'est exactement ce que couvre un contrat de maintenance WordPress : application systématique des correctifs dès leur publication, sans attendre qu'une exploitation de masse les rende urgents.

Chronologie

• 1
  17 mars 2026

  Publication de la version 2.1.5 de Gravity SMTP, corrigeant le contrôle d'accès de l'endpoint REST vulnérable.
• 2
  31 mars 2026

  Wordfence publie la faille CVE-2026-4020, deux semaines après la disponibilité du correctif.
• 3
  27 mai 2026

  Première exploitation confirmée à grande échelle, selon le suivi de CrowdSec - près de deux mois après le correctif.
• 4
  6-7 juin 2026

  Pic d'exploitation : plus de 4 millions de requêtes bloquées par Wordfence en une seule journée le 7 juin.
• 5
  Juin 2026

  Plus de 17 millions de tentatives d'exploitation bloquées au total par Wordfence depuis le début de la campagne.

FAQ - Faille Gravity SMTP CVE-2026-4020

Mon site est-il concerné si je n'ai configuré aucune intégration email tierce ?

L'endpoint vulnérable expose un rapport système complet même sans intégration tierce configurée - versions PHP et WordPress, plugins actifs, détails serveur et base de données. Le risque de vol de clés API est nul sans connecteur configuré, mais l'exposition d'informations système reste un problème en soi, car elle facilite la préparation d'autres attaques ciblées.

La mise à jour vers 2.1.5 suffit-elle à corriger le problème ?

La mise à jour ferme l'endpoint vulnérable, mais elle ne change rien aux clés API déjà exposées avant son installation. Si une clé a été consultée par un tiers avant la mise à jour, elle reste valide et exploitable jusqu'à ce qu'elle soit explicitement révoquée. Mise à jour et rotation des clés sont les deux étapes indispensables, pas une alternative à l'autre.

Pourquoi cette faille est-elle massivement exploitée maintenant, alors qu'elle est corrigée depuis mars ?

Le correctif est sorti le 17 mars 2026, la faille a été rendue publique le 31 mars. L'exploitation à grande échelle n'a commencé que fin mai, avec un pic début juin - près de deux mois et demi plus tard. Les groupes qui automatisent l'exploitation de masse mettent du temps à intégrer une nouvelle faille dans leurs outils, mais une fois que c'est fait, ils scannent indistinctement tous les sites non mis à jour.

Quelles données précises un attaquant peut-il récupérer avec cette faille ?

L'endpoint renvoie environ 365 Ko de JSON contenant les clés API et tokens OAuth des connecteurs configurés (Amazon SES, Google, Mailjet, Resend, Zoho), les versions de WordPress, PHP et des extensions, les détails du serveur et le chemin racine du site, des informations de base de données, ainsi que la liste des plugins et thèmes actifs.

Le score CVSS de 5.3 semble modéré, pourquoi en faire une alerte si sérieuse ?

Le score CVSS mesure la facilité technique d'exploitation et la portée directe de la faille, pas la valeur de ce qui est exposé. Techniquement, c'est une simple divulgation d'informations sans élévation de privilèges, d'où le score modéré. Mais parmi ces informations figurent des clés API actives reliées à des comptes facturés à l'usage. La gravité réelle dépend de ce que contient le rapport exposé, pas seulement du mécanisme technique.

Le danger n'est presque jamais la faille du jour zéro

Un correctif disponible depuis deux mois et demi n'a protégé qu'une partie des 100 000 sites concernés. Les 17 millions de tentatives bloquées ne représentent pas 17 millions de sites différents - elles représentent un nombre bien plus restreint de sites non mis à jour, scannés de façon répétée par des bots qui n'ont aucune raison de s'arrêter tant que la porte reste ouverte.

Le parallèle avec la récente exposition de clés API IA dans WordPress 7.0 est frappant : deux incidents distincts, à quelques semaines d'écart, qui ciblent la même catégorie d'actif - des clés facturées à l'usage, devenues une monnaie d'échange à part entière pour les attaquants. La faille de suppression de fichiers dans Avada Builder suivait elle aussi un schéma de divulgation puis d'exploitation différée. Trois incidents, trois plugins différents, le même calendrier : les correctifs sortent, l'exploitation suit son propre rythme, et l'écart entre les deux est la fenêtre dans laquelle se jouent la plupart des compromissions évitables.