Exposition de Gitea et n8n : pourquoi la configuration compte plus que le nombre d'actifs

Des scans récents d'Internet ont identifié des centaines de milliers d'instances publiquement accessibles de Gitea et n8n, deux outils auto-hébergés populaires pour la gestion de code et l'automatisation des flux de travail. Bien que le volume considérable d'actifs exposés soulève des inquiétudes immédiates, les experts en sécurité soulignent que la présence de ces services en ligne n'équivaut pas automatiquement à une violation. Le facteur critique n'est pas seulement la visibilité, mais la manière dont ces plateformes sont configurées pour gérer les identifiants sensibles qu'elles stockent au nom des utilisateurs.

Ce qui s'est passé

Le 28 octobre 2026, des mesures collectées via la plateforme ZoomEye ont révélé un nombre significatif d'actifs indexés correspondant à des applications auto-hébergées spécifiques. Le scan a trouvé 117 523 actifs correspondant à la signature de Gitea, un service Git léger. Pour n8n, un outil d'automatisation de flux de travail, le nombre était nettement plus élevé avec 420 452 actifs correspondant à sa signature d'application, auxquels s'ajoutent 401 268 correspondances basées sur les titres de page. Ces chiffres représentent le nombre de systèmes ayant répondu aux sondes d'identification, et non nécessairement le nombre de serveurs compromis ou mal configurés.

L'analyse souligne que Gitea et n8n servent tous deux de dépôts centraux pour les secrets. Gitea stocke les clés de déploiement, les secrets Webhook, les jetons d'accès et souvent les clés SSH utilisées pour les poussées de code. De même, les flux de travail n8n contiennent des identifiants API pour divers services externes intégrés dans des processus automatisés. Comme ces plateformes concentrent des données d'authentification de haute valeur, toute instance laissée ouverte sur Internet public nécessite un examen rigoureux. Le risque ne réside pas seulement dans l'accès non autorisé à la plateforme elle-même, mais aussi dans le vol potentiel des identifiants tiers stockés en son sein.

Détails clés

• ZoomEye a enregistré 117 523 instances Gitea et 420 452 instances n8n le 28 octobre 2026.
• Gitea stocke des éléments sensibles tels que les clés de déploiement, les secrets Webhook et les clés SSH aux côtés des dépôts de code.
• Les flux de travail n8n intègrent des identifiants API pour les services externes connectés, ce qui en fait des cibles de grande valeur.
• Les paramètres par défaut de Gitea incluent INSTALL_LOCK pour sécuriser la page de configuration et DISABLE_REGISTRATION pour empêcher les inscriptions non autorisées.
• Les instances n8n nécessitent souvent une accessibilité publique pour les Webhooks, augmentant leur exposition par rapport aux configurations Gitea uniquement accessibles via VPN.
• Le nombre d'actifs n'indique pas une vulnérabilité ; de nombreuses instances indexées peuvent être correctement durcies avec une authentification unique (SSO) et un accès restreint.

Contexte

Les logiciels auto-hébergés donnent aux organisations le contrôle sur leurs données et leur infrastructure, mais ils transfèrent également entièrement la responsabilité de la sécurité à l'opérateur. Contrairement aux services cloud gérés où le fournisseur assure la correction des failles et le contrôle des accès, les instances auto-hébergées dépendent de l'administrateur pour configurer correctement les paramètres de sécurité dès le premier jour. Des outils comme Gitea et n8n sont conçus pour s'intégrer profondément avec d'autres systèmes, ce qui nécessite le stockage local des jetons d'authentification et des clés. Ce choix architectural crée un effet de « coffre-fort d'identifiants », où la compromission de l'hôte donne accès à plusieurs services externes.

La différence de visibilité publique entre Gitea et n8n provient de leurs modèles de déploiement typiques. Gitea est souvent utilisé par les équipes de développement qui y accèdent via un VPN d'entreprise, lui permettant de rester invisible sur Internet public. En revanche, n8n repose sur des Webhooks pour recevoir des déclencheurs de fournisseurs externes tels que les passerelles de paiement ou les systèmes CRM. Cette exigence fonctionnelle oblige souvent les instances n8n à être accessibles publiquement, ce qui les rend plus susceptibles d'apparaître dans les scans à l'échelle d'Internet. Comprendre cette distinction aide à contextualiser pourquoi n8n apparaît plus fréquemment dans les index publics malgré l'adoption large des deux outils.

Pourquoi cela compte

Pour les équipes exécutant leurs propres logiciels, ces résultats soulignent le danger des déploiements « installer et oublier ». Il est courant que les administrateurs installent un outil pour une évaluation ou une configuration initiale et le laissent fonctionner avec les configurations par défaut. Dans Gitea, si INSTALL_LOCK n'est pas activé, la page de configuration initiale reste accessible, permettant potentiellement à un attaquant de réinitialiser les paramètres administratifs. De même, si l'inscription n'est pas désactivée, des utilisateurs non autorisés peuvent créer des comptes et potentiellement accéder aux dépôts internes ou aux définitions de flux de travail. Ces négligences ne sont pas des exploits complexes, mais de simples lacunes de configuration qui laissent la porte ouverte.

L'accumulation d'identifiants obsolètes pose une autre menace silencieuse. Les plateformes d'automatisation comme n8n ont tendance à croître organiquement, avec de nouvelles intégrations ajoutées au fil du temps. Les anciens flux de travail connectés à des services dépréciés ou utilisant des identifiants d'anciens employés restent souvent actifs car leur suppression semble risquée. Si une instance est exposée, les attaquants peuvent récolter ces jetons depuis longtemps oubliés. Des audits réguliers des contrôles d'accès de la plateforme ainsi que des secrets spécifiques stockés dans les flux de travail sont essentiels pour maintenir une posture sécurisée. Le nombre élevé d'actifs indexés suggère que de nombreuses organisations n'effectuent peut-être pas ces vérifications de routine.

Que pouvez-vous faire

• Vérifiez que INSTALL_LOCK est défini sur true dans votre configuration Gitea pour bloquer l'accès à l'assistant de configuration.
• Assurez-vous que DISABLE_REGISTRATION est activé dans Gitea sauf si vous souhaitez spécifiquement permettre les inscriptions publiques.
• Examinez les paramètres de gestion des utilisateurs n8n pour confirmer que seul le personnel autorisé peut créer des comptes ou modifier des flux de travail.
• Auditez toutes les clés de déploiement et les secrets Webhook dans Gitea, en supprimant ceux appartenant à des collaborateurs partis ou à des projets inutilisés.
• Vérifiez les flux de travail n8n pour détecter les identifiants API obsolètes et faites pivoter les clés pour tous les services encore activement utilisés.
• Envisagez de placer les instances auto-hébergées derrière un proxy inverse ou un VPN pour limiter l'exposition publique aux seuls points de terminaison nécessaires.