# Zeabur : des jetons non expirants, 101 serveurs root et une clé réapparue dans les backups

> Le rapport Zeabur documente deux chemins d’intrusion, des jetons en clair, 101 serveurs atteints et des secrets relus via sauvegarde. Analyse de la chaîne.

Publié le: 2026-11-04  
Canonical: https://rootzero.eu/research/zeabur-tokens-cluster-backups-fuite-2026/

**Intrusion documentée les 14 et 15 octobre 2026 ; rapport préliminaire du 19 octobre.** [Zeabur](https://dash-new.zeabur.com/blogs/october-2026-security-incident) décrit une compromission de son cluster partagé, de serveurs dédiés GCP et de sa base de données de plateforme. Le rapport distingue avec soin ce qui est confirmé par les logs, évalué comme probable et encore hypothétique. Cette précision permet une analyse technique rare : l'attaquant a suivi **deux voies parallèles**, l'une par les jetons du cluster et l'autre par des clés GCP, avant de les réunir sur le réseau interne. La société a annoncé ensuite qu'elle cesserait ses activités le 31 décembre 2026, conséquence opérationnelle majeure mais distincte de la mécanique de l'intrusion.

## Première voie : une clé ancienne devient une autorité actuelle

L'attaquant possédait des clés AWS et des jetons d'administration du cluster partagés. Zeabur explique que ces valeurs figuraient **en clair dans un dépôt privé de configuration**, que les jetons n'expiraient pas et que l'interface d'administration restait accessible depuis Internet. L'origine exacte de leur acquisition n'est pas confirmée ; le rapport évoque un possible lien avec un incident d'août, explicitement comme hypothèse. La conséquence, elle, est documentée : le cluster était joignable depuis l'extérieur et les droits associés couvraient neuf régions.

L'attaquant a lu des paramètres et secrets de services, puis exécuté des commandes de lecture dans des conteneurs de bases de données. Zeabur compte **865 services de base de données visés par des commandes**, tout en précisant que toutes n'ont pas réussi. Une autre clé trop privilégiée a permis, selon l'évaluation de Zeabur, d'atteindre la sauvegarde d'un ancien cluster ; cette sauvegarde contenait un accès au service de gestion des secrets. Environ **53 secrets de production** y ont ensuite été lus de façon confirmée, dont les identifiants du réseau interne et un compte de base de données.

## Deuxième voie : les mots de passe root dans les paramètres d'initialisation

Sur GCP, un ancien compte de service permettait de lire des paramètres d'initialisation contenant des mots de passe `root` en clair. Zeabur constate des connexions `root` sur **101 serveurs dédiés** et estime que la clé GCP a servi à récupérer ces mots de passe. L'acteur a aussi ajouté sa propre clé SSH dans la configuration des serveurs. Ici encore, la source première de l'ancienne clé n'est pas établie. Il serait inexact d'affirmer que l'attaquant a commencé par le service de secrets de production, car les connexions GCP ont précédé certaines lectures observées de ce service.

## Quand les deux chemins se rencontrent

Le 15 octobre, l'attaquant a utilisé un serveur GCP déjà contrôlé et les identifiants du réseau interne obtenus par la première voie pour ajouter un nœud au réseau Zeabur. Ce nœud pouvait atteindre la base de données de plateforme ; l'acteur s'y est connecté avec un compte en lecture. Zeabur affirme avoir relié **29 connexions** et **8 903 opérations** à ce nœud. Sa table d'impact donne **3 218 965 enregistrements de variables d'environnement** lus et des données de **321 810 comptes** dans la base de plateforme. Ce sont des enregistrements et des comptes, pas un décompte universel de personnes dont chaque secret aurait été abusé.

Un détail du rapport rend la réponse à incident particulièrement instructive : une clé remplacée pendant l'incident s'est retrouvée dans une **sauvegarde automatique**, que l'attaquant pouvait encore atteindre avec une ancienne clé d'accès. Zeabur confirme que la nouvelle clé a été utilisée sans autorisation après sa rotation et évalue l'accès à la sauvegarde comme voie probable. Cela montre pourquoi « tourner une clé » n'est pas un événement isolé ; il faut vérifier copies, backups, caches et accès qui peuvent réintroduire le nouveau secret dans un périmètre déjà compromis.

## Ce que l'enquête enseigne

Un audit préventif aurait cherché les jetons sans date d'expiration, les interfaces d'administration exposées, les secrets en clair dans les dépôts et métadonnées cloud, puis la capacité d'une sauvegarde à faire sortir un nouveau secret du périmètre de rotation. La revue doit suivre les **droits réels** de chaque clé : lecture de backups, ajout de nœuds, accès au réseau de production, déchiffrement de variables. Le rapport permet de reconstituer ces transitions, sans inventer la source initiale de toutes les clés.

Zeabur recommande la rotation des identifiants stockés sur la plateforme, y compris ceux déjà remplacés après l'incident d'août. Son [suivi du 28 octobre](https://dash-new.zeabur.com/blogs/october-2026-security-incident-follow-up) annonce la fermeture future et des démarches d'aide pour les frais de tiers associés à des clés abusées. Une lecture honnête conserve les mots de son rapport : « confirmé », « évalué » et « hypothèse » ne décrivent pas le même niveau de preuve.

**Sources principales :** [rapport préliminaire Zeabur](https://dash-new.zeabur.com/blogs/october-2026-security-incident), [suivi Zeabur](https://dash-new.zeabur.com/blogs/october-2026-security-incident-follow-up).