Zeabur ferme après une deuxième intrusion en deux mois

Les 14 et 15 octobre 2026, un attaquant a utilisé les identifiants internes de Zeabur pour entrer dans son cluster partagé, dans certains serveurs dédiés, puis dans la base de la plateforme. Le 17 octobre, l’entreprise a annoncé qu’elle fermait. Les services du cluster partagé sont mis en pause le 1er décembre. Les serveurs dédiés et les clusters partagés s’arrêtent au plus tard le 31 décembre.

Si vous n’avez jamais hébergé de projet chez Zeabur, vous n’avez rien dans cette fuite. Ce qui est utile, c’est pourquoi une deuxième intrusion, deux mois après la première, a atteint des secrets que le nettoyage d’août était censé avoir fermés.

Ce que Zeabur dit qu’il s’est passé

Le rapport préliminaire du 19 octobre sépare ce qu’un journal enregistre (« confirmé ») de ce que le calendrier suggère (« évalué ») et de ce qu’il ne peut pas vérifier. La voie confirmée, en bref :

Les jetons d’administration du cluster partagé n’avaient pas d’échéance. Ils ont été créés le 10 janvier 2024, écrits en clair dans un dépôt de configuration privé le 20 janvier 2026, et laissés de côté lors de la rotation après l’incident d’août. L’interface d’administration était joignable depuis l’Internet public. À partir de 01 h 40 UTC le 14 octobre, ces jetons ont ouvert le cluster partagé dans neuf régions.

À partir de 12 h 39 ce jour-là, l’attaquant a lu les réglages et les secrets des services du cluster, y compris les variables d’environnement. Zeabur dit que les régions dont les journaux sont complets confirment la lecture, et que les régions sans journaux sont traitées comme compromises. À partir de 13 h 40, l’attaquant a lancé des commandes de lecture dans des conteneurs de bases de données d’utilisateurs. Zeabur compte des commandes dans 865 services de bases de données. Toutes n’ont pas réussi, et les journaux ont gardé les commandes, pas leur résultat. Zeabur ne prétend donc pas avoir une copie complète de chaque base.

Une deuxième voie a ouvert une session root sur 101 serveurs dédiés que Zeabur gère sur Google Cloud, à partir de 13 h 40 UTC le 14 octobre. Zeabur estime qu’une ancienne clé Google Cloud a servi à lire des mots de passe root stockés en clair dans les réglages d’initialisation de ces serveurs. Sur 50 des 101 serveurs, l’attaquant a ajouté sa propre clé SSH. Zeabur dit avoir écrit à ces utilisateurs et réinitialisé les mots de passe root.

Le 15 octobre, les deux voies se sont rejointes. Avec des identifiants du réseau interne pris sur la première voie, l’attaquant a ajouté un nœud depuis un serveur Google Cloud compromis. De 16 h 10 à 16 h 47 UTC, ce nœud a lu la base de la plateforme avec un compte interne en lecture seule. Zeabur dit que les 29 connexions à la base dans cette fenêtre correspondent à ce nœud, et que la lecture est confirmée.

Ce qui a été lu

Dans la base de la plateforme, Zeabur confirme :

• 3 218 965 enregistrements de variables d’environnement, noms et valeurs
• les données de compte, de projet et de service de 321 810 comptes, y compris le courriel, le nom d’utilisateur et le numéro de téléphone lorsqu’ils figuraient au profil
• 566 clés d’API zSend, stockées en clair, depuis révoquées
• 11 536 jetons d’accès à la plateforme, stockés seulement sous forme d’empreintes, tous révoqués

Zeabur dit que l’attaquant a cherché des clés d’API dans ce qu’il avait pris, surtout des clés de services d’IA, et qu’il a tenté d’appeler Amazon Bedrock avec les clés AWS de Zeabur. Ces appels ont échoué. Zeabur traite quand même tout ce qui a été lu comme compromis, pas seulement les clés que l’attaquant semblait chercher.

Parmi les instances n8n qui utilisent PostgreSQL, Zeabur dit que 602 des 607 qu’il a vérifiées gardaient la clé de chiffrement n8n dans une variable d’environnement. Les identifiants de tiers dans n8n étaient donc en clair dans les faits. Changer un mot de passe de base après août ne fermait pas une lecture faite depuis l’intérieur du conteneur.

Les projets qui ont suivi le conseil d’août et déplacé leurs variables d’environnement sur leur propre serveur dédié étaient hors de cette lecture de la base. Cela ne couvre pas un serveur dédié sur lequel l’attaquant s’est connecté.

Zeabur dit aussi qu’il ne peut pas confirmer si les jetons de gestion de 359 serveurs Hetzner et de 48 serveurs DigitalOcean ont été utilisés. Il a révoqué ces jetons le 16 octobre à 01 h 09 UTC. Aucun des deux fournisseurs ne garde les journaux d’opérations qui permettraient de trancher.

La phrase antérieure de l’entreprise, selon laquelle « toutes les clés d’administration internes ont été désactivées ou renouvelées » après août, était incomplète. Le rapport d’octobre le dit. Les jetons et les clés AWS du dépôt de configuration, et les mots de passe root des réglages d’initialisation Google Cloud, sont les identifiants utilisés cette fois. La façon dont l’attaquant les a obtenus au départ reste non confirmée. L’hypothèse de Zeabur, qui relie cela à une clé privée d’application GitHub lue en août, est étiquetée comme une hypothèse.

Plus de 16 heures d’activité le 14 octobre n’ont déclenché aucune alerte. Zeabur dit avoir commencé l’enquête le 15 octobre à 13 h 56 UTC après le signalement d’un utilisateur. La dernière activité de l’attaquant observée au moment du rapport était le 15 octobre à 21 h 05 UTC.

La fermeture

La note de fermeture du 17 octobre est signée par le fondateur, Yuanlin Lin. Les nouveaux serveurs dédiés et les domaines ne sont plus en vente. À partir du 1er décembre, le renouvellement des serveurs dédiés s’arrête et chaque serveur s’éteint à sa propre date d’expiration, qui peut précéder le 31 décembre. Les services du cluster partagé sont mis en pause ce jour-là. Zeabur dit que vous pouvez encore en redémarrer un à la main pour faire une copie. Le 31 décembre, les serveurs dédiés et les clusters partagés s’arrêtent.

La date à laquelle Zeabur efface les données restantes, le dernier jour pour les exporter et le jour où le soutien ferme ne sont pas fixés. La note dit de ne pas les attendre. Le transfert des domaines se fait soi-même depuis le tableau de bord. Le remboursement du solde du compte et l’indemnisation des pertes liées à l’incident sont deux demandes distinctes, toutes deux via le soutien Zeabur.

Si vous y avez hébergé quelque chose

1. Remplacez les secrets qui se trouvaient dans les variables d’environnement Zeabur, même si vous les avez déjà remplacés en août. Révoquez l’ancienne clé chez le fournisseur, puis créez-en une nouvelle. La liste de Zeabur comprend les clés d’API, les clés infonuagiques, les mots de passe de bases de données et les clés de signature et de chiffrement. Un projet qui a déplacé ces variables sur son propre serveur après août était hors de la lecture de la base. Si ce serveur fait partie des 101 machines Google Cloud, traitez aussi la copie qui s’y trouve comme exposée.
2. Changez les mots de passe dans la base, pas seulement la variable qui la désigne. Zeabur dit que changer la variable ne change pas le mot de passe dans la base, et n’annule pas les lignes déjà lues. Si la base contient les empreintes de mots de passe de vos utilisateurs ou des jetons de session, révoquez-les aussi.
3. Sur n8n, remplacez la clé de chiffrement et recréez les identifiants de tiers. Sur new-api ou one-api, révoquez les clés d’IA en amont et régénérez les jetons d’accès.
4. Si vous aviez un serveur dédié Google Cloud, reconstruisez-le. Le minimum que Zeabur propose, si vous ne pouvez pas reconstruire tout de suite, est de retirer les clés inconnues dans /root/.ssh/authorized_keys (y compris celles dont le commentaire est @zeabur-pentest), de vérifier sudoers, crontab, systemd et k3s, et de désactiver la connexion SSH par mot de passe. Vérifiez les journaux de connexion jusqu’au 1er septembre, pas seulement le 14 octobre. Zeabur dit qu’une source inconnue s’est connectée à environ 98 de ces serveurs avec le mot de passe root entre le 1er et le 5 septembre, et qu’elle ne peut pas confirmer qu’il s’agissait du même attaquant.
5. Faites la copie avant le 1er décembre, et avant la date d’expiration de votre serveur si elle arrive plus tôt. Le 31 décembre est le dernier jour, pas une promesse que votre service fonctionne jusque-là.

Un mot de passe que vous n’avez utilisé que sur un site sans lien n’est pas dans ce tas. Une clé qui était dans une variable d’environnement Zeabur, un identifiant n8n ou l’un de ces 101 serveurs doit être traitée comme étant désormais à quelqu’un d’autre.

Sources

• Zeabur, « October 2026 security incident (preliminary report) » (en anglais), 19 octobre 2026
• Zeabur, « Zeabur is shutting down: what happens next » (en anglais), 17 octobre 2026