Outils / Actualités / Nextcloud GmbH expose 367 000 enregistrements internes via un cluster Elasticsearch mal configuré
Presse

Nextcloud GmbH expose 367 000 enregistrements internes via un cluster Elasticsearch mal configuré

· VaultTools

Les chercheurs de Cybernews ont découvert une base Elasticsearch non protégée appartenant à Nextcloud GmbH contenant environ 367 000 enregistrements (8 Go), dont des factures, des contrats, des données d'employés et des scripts d'installation clients. L'exposition a été rendue publique le 8 juillet 2026 : même l'entreprise derrière le cloud auto-hébergé a raté une configuration d'hébergement.

VaultTools · 16 juillet 2026

Une baie de serveurs dans un centre de données sombre, le type d'infrastructure où une seule erreur de configuration peut exposer une base de données entière. Photo sur Unsplash

Table des matières

Ce qui s’est passé

Nextcloud GmbH, l’entreprise allemande derrière la plateforme open source de cloud auto-hébergé largement utilisée, a laissé une base de données Elasticsearch accessible publiquement sur Internet. Les chercheurs en sécurité de Cybernews ont découvert le cluster exposé le 18 mai 2026 et ont rapporté qu’il contenait environ 367 000 enregistrements totalisant 7,92 Go de données.

L’ironie est difficile à manquer. Tout le discours de Nextcloud repose sur la souveraineté des données : hébergez votre propre cloud pour que vos fichiers ne dorment pas sur les serveurs de quelqu’un d’autre. Pourtant, l’infrastructure d’hébergement de l’entreprise elle-même était mal configurée, au point de mettre des données internes à une URL de quiconque cherchait. Comme l’a résumé l’équipe de Cybernews : « Si notre équipe a pu trouver ce jeu de données exposé, des attaquants auraient pu le faire aussi. »

Ce qui a été exposé

Selon Cybernews, le jeu de données fuité mélangeait des documents de l’entreprise et de ses clients : factures, contrats, données et adresses e-mail d’employés, noms et adresses d’entreprises clientes, ainsi que des scripts d’installation conçus pour des clients professionnels. Une partie des informations n’était pas chiffrée.

Heise online dresse le même tableau, décrivant environ 360 000 entrées et 8 Go de données concernant les clients, partenaires et employés de Nextcloud, avec des contrats et des scripts pour les clients professionnels. SC Media a noté que les chercheurs avertissaient que des bots automatisés parcourent en permanence Internet à la recherche de ce type précis de mauvaise configuration. Les données ont donc pu être copiées avant leur sécurisation, même si Nextcloud n’a trouvé aucune preuve d’utilisation abusive.

La chronologie de la divulgation

  • 18 mai 2026 — les chercheurs de Cybernews découvrent le cluster Elasticsearch accessible publiquement.
  • 25 mai 2026 — les chercheurs notifient Nextcloud GmbH, selon heise online.
  • 27 mai 2026 — Nextcloud ferme la faille et notifie les autorités de contrôle.
  • 8-9 juillet 2026 — l’exposition devient publique via les articles de Cybernews, heise online et SC Media.

La fenêtre entre la découverte et le verrouillage a été courte. La fenêtre entre l’exposition et la découverte reste inconnue, et c’est précisément la partie que personne ne peut auditer après coup.

La réponse de Nextcloud

Nextcloud a attribué l’incident à « une mauvaise configuration de la structure d’hébergement » et a souligné que « le logiciel collaboratif open source et ses utilisateurs n’étaient pas affectés ». Aucun serveur Nextcloud exploité par des clients n’était concerné, et l’entreprise a déclaré : « Nous n’avons actuellement connaissance d’aucun cas où les données auraient été utilisées de manière abusive. »

Cette distinction compte et elle est juste envers Nextcloud : ce n’est pas le produit qui a été compromis, mais l’hébergement propre de l’entreprise. La réaction a par ailleurs été rapide, la base ayant été verrouillée deux jours après la notification. L’épisode reste néanmoins une leçon, car il montre que même une organisation dont le métier est d’exploiter des infrastructures de fichiers peut mal configurer une base de données.

Pourquoi c’est important pour les outils de fichiers dans le navigateur

La leçon n’est pas que Nextcloud serait négligent. C’est que le stockage côté serveur porte toujours un risque de configuration, quel que soit son exploitant. Une entreprise centrée sur la vie privée, avec de vrais experts et toutes les incitations du monde, s’est quand même retrouvée avec 367 000 enregistrements sur l’Internet ouvert, parce que chaque base de données, chaque bucket et chaque cluster n’est qu’à un changement de réglage de devenir public.

Les fichiers traités entièrement dans le navigateur n’ont pas ce mode de défaillance. Quand un PDF est fusionné ou une image compressée localement via WebAssembly, il n’y a ni upload, ni copie côté serveur, ni cluster Elasticsearch qui conserve des résidus. Rien n’a besoin d’être verrouillé plus tard, parce que rien n’a jamais été stocké. Pour les tâches ponctuelles sur des fichiers, l’infrastructure la plus sûre est celle qui n’existe pas.

Sources

← Retour aux actualités