Mon prestataire d’envoi d’e-mails a désactivé ma clé d’accès

Le signalement vient toujours de l’extérieur

Le scénario est presque toujours le même. Vous n’avez rien remarqué sur votre boutique, tout semble fonctionner, et c’est un tiers qui vous prévient : votre prestataire d’envoi suspend la clé d’accès du compte, ou vous adresse un message sur un volume d’envois inhabituel, ou vous découvrez sur la facture des milliers de messages que vous n’avez jamais déclenchés. Parfois le premier signe est encore plus discret : les confirmations de commande ne partent plus, alors que personne n’a touché à la configuration.

Un prestataire qui coupe une clé le fait rarement au hasard. Il a vu des envois partir depuis une infrastructure qui n’est pas la vôtre, ou des contenus qui ne ressemblent pas à votre trafic habituel. La clé fonctionne toujours techniquement : elle est simplement utilisée par quelqu’un d’autre. Et si quelqu’un d’autre l’utilise, c’est qu’elle a été lue quelque part.

Dans les cas que je rencontre, l’endroit où elle a été lue n’est presque jamais votre poste de travail. C’est le site lui-même, à travers une extension qui détenait ces identifiants et qui les a rendus accessibles à qui savait où regarder.

Ce qu’une extension d’envoi stocke, et ce qu’un rapport système contient

Une extension qui prend en charge l’envoi des e-mails transactionnels doit se connecter à un service extérieur. Pour cela elle a besoin d’un secret : une clé d’API, un jeton d’autorisation, parfois un couple identifiant et mot de passe. Ce secret est enregistré dans la base de données du site, dans une table de configuration, sous une forme que l’extension doit pouvoir relire à chaque envoi. Elle ne peut donc pas le protéger réellement : ce qui est lisible par l’extension l’est aussi par n’importe quel code capable d’interroger le même endroit.

À cela s’ajoute une fonctionnalité présente dans presque toutes ces extensions : le rapport système. C’est le fichier qu’on vous demande de joindre quand vous ouvrez un ticket au support. Il rassemble en un seul endroit la version de WordPress et de PHP, les informations serveur, les informations de base de données, l’inventaire des extensions installées, le thème actif, et la configuration des connecteurs d’e-mail — donc les clés et les jetons. Ce n’est pas un fichier de diagnostic anodin : c’est la description complète de votre installation, secrets compris. Traitez-le comme un mot de passe, pas comme une capture d’écran.

La faille CVE-2026-4020 illustre exactement ce point. Elle concerne l’extension Gravity SMTP, présente sur environ 100 000 sites, dans toutes les versions jusqu’à la 2.1.4 incluse. Un point d’accès de l’API REST de l’extension disposait bien d’un contrôle de permission, mais celui-ci renvoyait toujours vrai : la porte était fermée à clé, et la serrure disait oui à tout le monde. Ce point d’accès rendait alors environ 365 Ko de données au format JSON, c’est-à-dire le rapport système complet : clés d’API et jetons OAuth des services d’e-mail connectés — Amazon SES, Google, Mailjet, Resend, Zoho — informations de base de données, versions de WordPress et de PHP, informations serveur, inventaire des extensions et thème actif. Le correctif, la version 2.1.5, est sorti le 17 mars 2026 ; la faille a été publiée le 31 mars 2026.

La suite est la partie qui vous concerne directement. L’exploitation de masse a démarré début mai 2026, avec un pic les 6 et 7 juin 2026 : plus de 4 millions de requêtes bloquées en une seule journée, et plus de 17 millions de tentatives au total d’après Wordfence. À cette échelle, la question n’est pas de savoir si votre site a été sollicité, mais s’il était à jour au moment où il l’a été.