Fermeture de Zeabur : un jeton admin sans expiration provoque une seconde fuite en deux mois

Au cœur de l’intrusion des 14 et 15 octobre dans le cluster partagé

Selon BleepingComputer, les 14 et 15 octobre 2026, un attaquant a utilisé des identifiants internes divulgués de Zeabur pour s’introduire dans le cluster partagé. Une fois à l’intérieur, l’attaquant a dérobé 3,2 millions d’enregistrements de variables d’environnement ainsi que les informations de 321,810 comptes.

La compromission de l’infrastructure sous-jacente a été profonde. BleepingComputer rapporte que les attaquants se sont connectés en tant que root sur 101 serveurs GCP en utilisant 92 utilisateurs, ont ajouté des clés SSH sur 50 serveurs et ont rattaché 16 copies de disques clients à leurs propres VMs. De plus, Start With Identity précise que l’attaquant a également accédé aux paramètres de 865 services de bases de données hébergées.

Un jeton jamais renouvelé depuis janvier 2024 et la décision de fermer

L’analyse post-incident a mis en évidence une défaillance élémentaire dans la gestion du cycle de vie des secrets. D’après BleepingComputer, les jetons d’administration n’avaient aucune date d’expiration et n’avaient fait l’objet d’aucune rotation depuis leur création en janvier 2024. Start With Identity indique que la cause première était un jeton d’administration du cluster partagé créé le 10 janvier 2024 sans expiration, combiné à des clés AWS internes.

Il ne s’agissait pas du premier incident de sécurité de l’année pour la plateforme. Dans son annonce de fermeture, Zeabur a reconnu que l’incident d’octobre avait une ampleur plus large que celui de la fin août. Pour expliquer la décision d’arrêter l’activité plutôt que de reconstruire, le fondateur de Zeabur a déclaré que la croissance « commençait à se heurter à des limites » et que le système était devenu de plus en plus complexe et difficile à maintenir.

L’entreprise a fixé un calendrier d’arrêt en deux étapes : le 1 décembre, le renouvellement des serveurs dédiés sera désactivé et les services du cluster partagé seront mis en pause, tandis que le 31 décembre sera la date de fermeture définitive. Pour les développeurs touchés, Start With Identity rapporte qu’il est conseillé aux utilisateurs de considérer chaque variable comme compromise et de révoquer les clés chez les fournisseurs, les identifiants cloud, les mots de passe de bases de données et les clés de signature avant de redéployer.

Ce que cela signifie pour les startups et équipes techniques en Algérie

Bien que les sources citées ne précisent pas combien des 321,810 comptes touchés appartiennent à des développeurs en Algérie, les plateformes de déploiement mutualisées sont prisées par les startups et agences logicielles qui souhaitent éviter l’administration directe de serveurs. Lorsqu’un hébergeur subit une compromission de son cluster partagé, tous les secrets stockés dans les variables d’environnement tombent simultanément. Trois règles d’ingénierie répondent directement à ce risque.

1. Proscrire les jetons d’administration sans date d’expiration

Un seul jeton d’administration du cluster partagé, créé le 10 janvier 2024 sans expiration et jamais renouvelé, a permis un accès root sur 101 serveurs GCP et l’exposition de 3,2 millions d’enregistrements de variables d’environnement. Les équipes techniques doivent imposer une durée de vie limitée et une rotation automatique sur tous les jetons d’administration et clés AWS internes.

2. Restreindre les privilèges des variables d’environnement et les révoquer avant toute migration

Start With Identity recommande aux utilisateurs de Zeabur de traiter chaque variable comme divulguée et de révoquer clés fournisseurs, identifiants cloud, mots de passe de bases de données et clés de signature avant tout redéploiement. Même en dehors de Zeabur, tout secret injecté dans une plateforme tierce de déploiement doit avoir une portée minimale afin qu’une variable divulguée ne donne pas un accès complet au cloud ou aux bases de données.

3. Anticiper la portabilité et la réversibilité de l’hébergement

Avec la mise en pause du cluster partagé le 1 décembre et la fermeture définitive le 31 décembre, 321,810 titulaires de comptes doivent migrer en urgence. Les startups qui s’appuient sur des plateformes de déploiement gérées doivent conserver des configurations portables et des sauvegardes externes au cluster du prestataire — d’autant que les attaquants ont pu rattacher 16 copies de disques clients à leurs propres VMs.

La leçon structurelle

Il est rare qu’une cyberattaque entraîne directement la fermeture d’une entreprise, mais l’arrêt de Zeabur illustre comment dette technique et dette de sécurité se renforcent mutuellement. Comme l’a reconnu son fondateur, un système devenu de plus en plus complexe et difficile à maintenir devient très ardu à défendre lorsque des secrets permanents, tels qu’un jeton créé en janvier 2024, restent actifs.

Pour les équipes logicielles en Algérie et dans le monde, les plateformes de déploiement simplifient la gestion des serveurs, mais ne délèguent jamais la responsabilité des secrets. Chaque variable d’environnement confiée à un cluster partagé doit pouvoir être révoquée immédiatement.

Questions Fréquemment Posées

Sources et lectures complémentaires

• Zeabur shutting down after second security breach in two months — BleepingComputer
• Zeabur is shutting down — Zeabur
• Zeabur to shut down after a non-expiring admin token opened its shared cluster — Start With Identity