Share
Beitragsbild zu Millionen Webserver legen sensible Git-Daten offen – Sicherheitslücke durch Fehlkonfiguration

Millionen Webserver legen sensible Git-Daten offen – Sicherheitslücke durch Fehlkonfiguration

9. Februar 2026

Repository-Metadaten weltweit ungeschützt im Netz + Eine Untersuchung des Mysterium VPN-Forschungsteams aus dem Jahr 2026 zeigt ein erhebliches Sicherheitsproblem: Knapp 5 Millionen IP-Adressen weltweit stellen ihre Git-Repository-Metadaten ungeschützt zur Verfügung. Mehr als 250.000 dieser Konfigurationsdateien enthalten direkte Zugangsdaten.

Umfang der Sicherheitslücke

Die Forschungsergebnisse dokumentieren 4.964.815 IP-Adressen mit frei zugänglichen .git-Strukturen. In 252.733 Fällen – rund 5,09 Prozent – finden sich Authentifizierungsinformationen direkt in den .git/config-Dateien.

Die USA führen mit 1.722.949 betroffenen IPs (34,70 Prozent), gefolgt von Deutschland (419.102), Frankreich (237.593), Indien (218.661), Singapur (189.900), den Niederlanden (165.174), Japan (164.768), Russland (147.859), Großbritannien (140.341) und Hongkong (127.223).

Technischer Hintergrund: Was .git-Verzeichnisse preisgeben

Der verborgene .git-Ordner speichert sämtliche Versionsinformationen und Konfigurationsdaten. Bei öffentlicher Zugänglichkeit können Angreifer über bekannte Pfade wie /.git/HEAD, /.git/config oder /.git/index auf die interne Struktur zugreifen und mit gängigen Werkzeugen den kompletten Website-Inhalt rekonstruieren. Dies ermöglicht die Extraktion von API-Schlüsseln, Dienstzugängen und weiteren Konfigurationsgeheimnissen.

Besondere Bedeutung der .git/config-Datei

Die .git/config-Datei birgt ein erhöhtes Risiko, da sie Repository-Einstellungen einschließlich Remote-URLs enthält. In praktischen Bereitstellungsprozessen landen hier häufig Zugangsdaten: in URLs eingebettete Basis-Authentifizierung, CI/CD-Automatisierungskonten oder temporäre Zugriffstoken ohne implementierte Rotation. Die identifizierten 252.733 Fälle markieren die Grenze zwischen Metadaten-Offenlegung und direktem unbefugtem Systemzugriff.

Ursachen der wiederkehrenden Fehlkonfiguration

Die Problematik tritt aus mehreren Gründen kontinuierlich auf: Entwickler übertragen komplette Projektordner auf Live-Systeme, ohne den .git-Ordner auszuschließen. Automatisierte Bundling-Tools schließen versteckte Verzeichnisse ein, die nicht für die Veröffentlichung vorgesehen sind. Während Haupt-Domains oft geschützt werden, bleiben alternative Zugriffswege wie direkte Server-IPs ungesichert. Zudem blockieren Webserver versteckte Ordner nicht automatisch – dies erfordert manuelle Konfiguration.

Risikospektrum offener Git-Metadaten

Rekonstruierter Quellcode ermöglicht die Identifikation fest codierter Geheimnisse, ungepatchter Bibliotheken, Admin-Routen und proprietärer Geschäftslogik. Offengelegte Zugangsdaten in .git/config ermöglichen Repository-Zugriff, böswillige Commits und Manipulation der Lieferkette – Angreifer können schädlichen Code vor der Bereitstellung einschleusen.

Git-Daten offenbaren zudem Remote-Hostnamen, Branch-Strukturen, Commit-Autoren-Informationen und Bereitstellungsskripte. Ein häufiger Eskalationspfad führt vom Code zur Cloud: Offengelegte API-Schlüssel gewähren Zugang zu Storage-Buckets, Datenbanken oder Messaging-Queues und ermöglichen Zugriff auf Produktionsdaten.

Gegenmaßnahmen und Absicherung

Die Behebung erfordert parallele Maßnahmen: Webserver müssen alle Anfragen an .git-Pfade ablehnen. .git-Verzeichnisse sollten in Produktionsumgebungen nicht existieren – Bereitstellungen sollten ausschließlich Build-Artefakte oder Container-Images enthalten.

Bei Anzeichen gespeicherter Zugangsdaten in .git/config sind diese als kompromittiert zu behandeln: Rotation von Zugriffstoken, Zurücksetzen von Passwörtern und Überprüfung von Protokollen auf ungewöhnliche Aktivitäten. Scanning-Tools können Passwörter vor Code-Commits erkennen, Pre-Commit-Prüfungen verhindern die Aufnahme sensitiver Daten. Zentralisierte Geheimnisverwaltung hält Zugangsdaten aus dem Code fern.

Verifizierung der eigenen Exposition

Autorisierte Teams können ihre Domains und IP-Bereiche selbst testen: Prüfung bekannter .git-Pfade auf HTTP-200-Antworten, Verifikation der Serverkonfiguration über primäre Domains, alternative Hostnamen und direkte IP-Zugriffspfade sowie Durchsuchung historischer Bereitstellungsartefakte.

Bewertung der 5-Prozent-Credential-Exposition

Bei Millionen exponierter Server repräsentieren selbst 5 Prozent Hunderttausende live zugänglicher Zugangsdaten. Die Suche nach diesen Fällen lässt sich vollständig automatisieren – sobald eine .git/config-Datei öffentlich sichtbar ist, kann die Credential-Extraktion skaliert erfolgen. Sicherheitsuntersuchungen zeigen wiederholt, dass durchgesickerte Zugangsdaten weitaus mehr Schaden verursachen als Quellcode-Offenlegung allein.

Präventionsstrategien für Entwicklungsteams

Server sollten Zugriff auf versteckte Ordner wie .git, .svn und .env blockieren – für alle Zugriffswege. Passwörter gehören in sichere Verwaltungssysteme, nicht in Code-Dateien. .gitignore-Einträge verhindern versehentliche Commits. Monitoring sollte Zugriffsversuche auf .git-Dateien melden. Dokumentierte Prozesse ermöglichen schnelle Schlüsselrotation im Kompromittierungsfall.

Zusammenfassung

Die 2026 durchgeführte Untersuchung identifizierte nahezu 5 Millionen öffentliche Webserver mit offengelegten Git-Repository-Metadaten. Diese Fehlkonfiguration ermöglicht Quellcode-Rekonstruktion, Credential-Diebstahl und Kompromittierung nachgelagerter Systeme. In über 250.000 Fällen enthielten exponierte .git/config-Dateien aktive Bereitstellungszugänge.

Die Ergebnisse zeigen ein systematisches Problem durch Bereitstellungspraktiken, inkonsistente Serverkonfigurationen und fehlerhafte Sicherheitsannahmen. Effektive Abhilfe erfordert vollständige Entfernung von Git-Metadaten aus Produktionsumgebungen, verbesserte Code-Hygiene und präventive Kontrollen im gesamten Softwareentwicklungszyklus.

Interessante Whitepaper