Comment les systèmes Zendesk sont détournés pour des vagues de spam mondiales : analyse et remèdes
Aurélien Fontevive
Une vague de spam massive et chaotique a ciblé des millions d’utilisateurs à travers le monde depuis le 18 janvier 2026. Les victimes rapportent avoir reçu des centaines d’e-mails aux sujets étranges et alarmants, provenant de plateformes de support client légitimes comme Discord, Tinder ou Dropbox. Cette campagne, qui n’est pas une simple nuisance, révèle une faille critique dans la configuration par défaut de nombreuses instances Zendesk, transformant des outils d’assistance en canaux de spam involontaires.
Comprendre le mécanisme du détournement Zendesk
Le vecteur d’attaque repose sur une fonctionnalité inhérente au fonctionnement de Zendesk, conçue pour faciliter l’accès des clients au support. Les attaquants exploitent la capacité du système à permettre à des utilisateurs non vérifiés de soumettre des tickets de support. En créant des milliers de faux tickets avec des adresses e-mail cibles, l’attaquant déclenche automatiquement une réponse de confirmation générée par Zendesk. Ces réponses, envoyées depuis des domaines de sociétés réputées, contournent efficacement les filtres anti-spam conventionnels.
Cette méthode de « spam par relais » (relay spam) utilise la réputation des entreprises comme bouclier. Les e-mails ne contiennent généralement pas de liens malveillants ou de pièces jointes suspectes ; leur but semble être le harcèlement et la confusion, plutôt que le vol de données ou l’infection. L’impact est double : une nuisance directe pour les destinataires et une atteinte à la réputation des marques dont les systèmes sont détournés.
L’ampleur du problème et les entreprises touchées
La liste des organisations affectées est longue et variée, incluant des géants de la tech, des jeux vidéo et même des entités gouvernementales. Des rapports indiquent que Discord, Tinder, Riot Games, Dropbox, CD Projekt (2k.com), Maya Mobile, NordVPN, le Département du Travail du Tennessee, Lightspeed, CTL, Kahoot, Headspace et Lime figurent parmi les systèmes compromis. Cette diversité montre que la vulnérabilité n’est pas liée à un secteur spécifique mais à une configuration courante de Zendesk. Un exemple marquant de l’impact des supply chain attacks est le ransomware Qilin qui a compromis 478 000 patients chez Covenant Health
Les sujets des e-mails sont délibérément chaotiques, mêlant des avertissements légaux fictifs (« TAKE DOWN ORDER NOW FROM CD Projekt »), des offres trompeuses (« FREE DISCORD NITRO!! »), des messages de détresse (« Help Me! ») et même des textes dans des polices Unicode ou des langues multiples, comme le démontre ce fragment : « 鶊坝鱎煅貃姄捪娂隌籝鎅熆媶鶯暘咭珩愷譌argentine恖 ». Cette stratégie vise à accroître l’intrusion et l’alarme chez le destinataire.
Analyse de la vulnérabilité technique
La faille exploite le workflow standard de création de ticket Zendesk. Pour permettre aux clients de soumettre des demandes sans créer de compte, de nombreuses entreprises configurent leur instance Zendesk pour accepter les soumissions de tickets depuis n’importe quelle adresse e-mail. C’est cette « porte ouverte » que les attaquants utilisent.
Le processus d’attaque se déroule en trois étapes :
- Scanning et identification : Les attaquants identifient les instances Zendesk publiques, souvent via des moteurs de recherche ou des listes d’entreprises connues pour utiliser la plateforme.
- Automatisation des soumissions : À l’aide de scripts, ils soumettent des tickets en masse en bouclant sur des listes d’adresses e-mail. Chaque soumission inclut une adresse e-mail cible comme destinataire de la réponse.
- Exploitation des réponses automatiques : Zendesk envoie une confirmation de ticket reçu à l’adresse e-mail spécifiée. Ces e-mails, provenant de domaines légitimes, sont perçus comme authentiques par les filtres de messagerie.
Pourquoi les filtres anti-spam échouent-ils ?
Les filtres traditionnels s’appuient sur la réputation de l’expéditeur, la présence de liens suspects ou de mots-clés malveillants. Dans ce cas, l’expéditeur (ex: support@discord.com) a une excellente réputation. Le contenu, bien que bizarre, ne contient pas d’éléments techniques dangereux. Les fournisseurs de messagerie (Gmail, Outlook, etc.) peinent à distinguer ces e-mails légitimes des vraies réponses de support.
« Les emails étant générés par des plateformes de support légitimes, ils contournent les filtres anti-spam, les rendant plus intrusifs et alarmants que le spam ordinaire. »
Conséquences pour les entreprises et les utilisateurs
Impact sur la confiance et la réputation
Pour les entreprises cibles, la conséquence immédiate est une atteinte à leur réputation. Cette vulnérabilité s’inscrit dans un contexte plus large où les ransomware ont explosé en 2025, avec l’émergence de nouveaux groupes menaçants Même si les e-mails ne sont pas malveillants, les clients peuvent percevoir le manque de sécurité comme une négligence. La réponse de 2K à ses clients est révélatrice : « Vous avez peut-être reçu une réponse automatisée concernant un ticket de support que vous n’avez pas soumis. […] Notre politique ouverte signifie que n’importe qui peut potentiellement soumettre un ticket en utilisant n’importe quelle adresse e-mail. » Cette explication, bien que transparente, peut sembler insuffisante face à une vague de spam de cette ampleur.
Risques de confusion et de détresse psychologique
Pour les utilisateurs, l’impact est avant tout psychologique. Recevoir des centaines d’e-mails aux sujets alarmants (« IMPORTANT LAW ENFORCEMENT NOTIFICATION », « TAKE DOWN NOW ORDER ») peut générer un stress important, surtout pour des personnes moins technophiles. La nature chaotique et parfois angoissante des sujets fait que ces e-mails sont bien plus intrusifs qu’un spam classique, qui serait simplement relégué dans le dossier indésirable.
Un précédent récurrent chez Zendesk
Il est important de noter que ce n’est pas la première fois que Zendesk est confronté à ce type d’abus. En décembre 2025, la société avait déjà publié un avertissement à ses clients concernant le « relay spam », expliquant précisément le mécanisme d’attaque. Cette récidive souligne la difficulté de corriger une faille qui est liée à un design de fonctionnalité et à des configurations courantes.
Mesures de protection et bonnes pratiques
Les entreprises utilisant Zendesk peuvent et doivent agir pour se protéger et protéger leurs clients. Zendesk lui-même a annoncé l’introduction de nouvelles fonctionnalités de sécurité pour détecter et arrêter ce type d’activité anormale, incluant une surveillance renforcée et des limites de taux (rate limiting).
Cependant, la responsabilité première revient aux administrateurs des instances Zendesk. Voici les mesures correctives prioritaires :
- Restreindre la création de tickets aux utilisateurs vérifiés : Désactiver l’option « Tout le monde peut soumettre des tickets » et obliger les utilisateurs à s’authentifier ou à utiliser une adresse e-mail vérifiée.
- Supprimer les placeholders : Éliminer les champs qui permettent de définir librement l’adresse e-mail du destinataire ou le sujet du ticket lors de la soumission d’un ticket par un utilisateur non authentifié.
- Mettre en place des règles de filtrage automatisées : Utiliser les outils de Zendesk pour créer des règles qui détectent les patterns de soumission suspects (ex: volumes élevés depuis une même IP, sujets répétitifs ou chaotiques).
- Surveiller activement les logs : Consulter régulièrement les journaux d’activité pour identifier des pics anormaux dans la création de tickets.
Tableau comparatif des configurations de sécurité Zendesk
| Configuration | Niveau de risque (par défaut) | Recommandation de sécurité | Impact sur l’expérience utilisateur |
|---|---|---|---|
| Création de tickets publique | Élevé | À désactiver. Limiter aux utilisateurs vérifiés ou à un formulaire de contact public contrôlé. | Léger : nécessite une authentification préalable pour les clients existants. |
| Champs de destination modifiables | Moyen à Élevé | À restreindre. Bloquer la modification des champs « Destinataire » et « Sujet » pour les soumissions publiques. | Nul : les champs sont prédéfinis par l’entreprise. |
| Limitation de débit (Rate Limiting) | Faible (par défaut) | À activer et à ajuster. Définir des seuils stricts pour les soumissions de tickets depuis une même IP. | Nul : protège l’ensemble des utilisateurs. |
| Surveillance et alertes | Faible | À mettre en œuvre. Configurer des alertes pour les volumes de tickets anormaux. | Nul : mesure passive. |
Étapes actionnables pour les administrateurs
Pour mettre en œuvre ces recommandations de manière concrète, voici une procédure étape par étape :
- Audit de configuration actuelle : Connectez-vous à l’interface d’administration Zendesk et examinez les paramètres de sécurité, en particulier dans la section
Paramètres > Tickets > Général. Vérifiez qui peut soumettre des tickets. - Modification des permissions : Désactivez l’option « Les visiteurs peuvent soumettre des tickets » si elle est activée. Créez plutôt un formulaire de contact public qui limite les champs et valide les entrées.
- Configuration des règles de sécurité : Dans
Paramètres > Règles de sécurité > Limites de débit, définissez des limites strictes pour les soumissions de tickets. Par exemple, limiter à 5 soumissions par heure depuis une même adresse IP. - Mise en place de filtres : Utilisez les règles de mise en file d’attente (
Paramètres > Règles de mise en file d'attente) pour créer des règles qui mettent en quarantaine ou ferment automatiquement les tickets dont le sujet correspond à des patterns de spam connus (mots-clés comme “TAKE DOWN”, “FREE NITRO”, etc.). - Communication et transparence : Si votre organisation a été touchée, communiquez clairement avec vos utilisateurs, comme l’ont fait Dropbox et 2K. Expliquez la nature du problème, assurez-les qu’aucune donnée n’a été compromise et présentez les mesures correctives prises.
- Audit régulier : Planifiez un audit trimestriel de vos configurations de sécurité Zendesk pour vous assurer qu’elles sont toujours optimales face aux nouvelles menaces.
« Pour supprimer les barrières et améliorer votre expérience, notre système permet à n’importe qui de soumettre un ticket de support, de fournir un retour d’information et de signaler des bugs sans avoir à créer un compte de support dédié et vérifier son adresse e-mail. Cette politique ouverte signifie que n’importe qui peut potentiellement soumettre un ticket en utilisant n’importe quelle adresse e-mail. » — Extrait de la communication de 2K
Conclusion : Vers une gestion proactive des risques de support
La vague de spam exploitant les systèmes Zendesk de janvier 2026 est un rappel brutal que la fonctionnalité la plus utile peut devenir une vulnérabilité critique si elle est mal configurée. Cette campagne, bien que non destructive techniquement, a un impact réel sur la confiance des utilisateurs et la réputation des marques.
Les entreprises ne peuvent plus se contenter de déployer Zendesk en mode « par défaut ». La sécurité des canaux de support doit être intégrée dès la configuration initiale, avec une attention particulière aux paramètres de soumission de tickets. En restreignant l’accès aux utilisateurs vérifiés et en mettant en place des contrôles proactifs, les organisations peuvent continuer à bénéficier des avantages de Zendesk tout en se protégeant contre son détournement.
La prochaine étape pour les responsables de la sécurité et les administrateurs IT est d’auditer immédiatement leurs instances Zendesk et d’appliquer les mesures correctives recommandées. Dans un paysage où les attaques par le biais des services légitimes (supply chain attacks) sont de plus en plus courantes, notamment avec l’explosion des ransomware et des attaques de la chaîne d’approvisionnement en 2025, la vigilance sur les outils tiers est non négociable.