Gitverify-Sicherheitslücke ermöglicht ungültige Tags in Lieferketten

Ein kritischer Fehler in der populären Prüftool-Kette gitverify könnte die Integrität von Software-Lieferketten gefährden. Sicherheitsforscher entdeckten eine Logikumkehr in der Signaturvalidierung, die es ermöglicht, unsignierte Git-Tags als gültig zu akzeptieren – selbst wenn kryptographische Prüfungen eigentlich erzwungen werden sollten.

Die Schwachstelle mit der Kennung GHSA-H829-5CG7-6HFF wurde am 24. April 2026 offiziell veröffentlicht und erhielt einen CVSS-Score von 5,3. Betroffen ist die Gitverify-Komponente, die häufig in automatisierten Build- und Veröffentlichungsprozessen zum Einsatz kommt, um die Echtheit von Code-Tags zu bestätigen. Besonders problematisch: Die Lücke könnte Angreifern ermöglichen, manipulierte, unsignierte Tags in vertrauenswürdige Repositories einzuschleusen.

Wie die Sicherheitslücke funktioniert

Die Ursache der Schwachstelle liegt in einer einfachen, aber folgenreichen Logikverwechslung im Verifizierungsmodul von gitverify. Normalerweise prüft das Tool, ob annotierte Git-Tags mit einer digitalen Signatur versehen sind, um deren Authentizität zu bestätigen. Bei aktivierter Richtlinie requireSignedTags sollten nur signierte Tags akzeptiert werden.

Doch durch die fehlerhafte Implementierung wurde diese Bedingung genau umgekehrt: Statt unsignierte Tags abzulehnen, wurden sie fälschlicherweise als gültig durchgewinkt – sofern die Richtlinie requireSignedTags deaktiviert war. Die korrigierte Version des Tools behebt diesen Fehler, indem die Logik nun korrekt zwischen signierten und unsignierten Tags unterscheidet.

Betroffene Systeme und Software

Die Sicherheitslücke betrifft primär das Tool gitverify in Versionen vor dem Commit c2c60da05d5c73621d0ce7ea02770bacd79ec8b1. Konkrete betroffene Systeme umfassen:

• Die offizielle GitHub-Repository: github.com/supply-chain-tools/gitverify
• Alle Projekte oder CI/CD-Pipelines, die die anfällige Version des Tools verwenden

Die Schwachstelle wurde bereits mit dem genannten Commit behoben. Entwickler sollten daher prüfen, ob ihre Implementierungen die korrigierte Version nutzen.

Praktische Auswirkungen für Entwickler

Die potenziellen Angriffsvektoren sind vielfältig, da gitverify häufig in automatisierten Workflows eingesetzt wird. Mögliche Szenarien umfassen:

• Manipulation von Release-Tags: Ein Angreifer könnte unsignierte, aber manipulierte Tags in ein Repository hochladen, die fälschlicherweise als gültig akzeptiert werden.
• Supply-Chain-Angriffe: Durch das Einschleusen unsignierter Code-Referenzen könnten bösartige Abhängigkeiten in Build-Prozesse eingeschleust werden.
• Umgehung von Sicherheitsrichtlinien: Unternehmen, die explizit signierte Tags für Release-Prozesse vorschreiben, könnten durch diese Lücke ungewollt unsichere Artefakte veröffentlichen.

So schützen Sie sich vor der Schwachstelle

Die Behebung der Lücke erfordert ein mehrstufiges Vorgehen. Zunächst sollten alle Projekte und CI/CD-Systeme, die gitverify verwenden, identifiziert werden. Anschließend ist ein Update auf die korrigierte Version des Tools notwendig:

1. Versionsprüfung durchführen: Überprüfen Sie, welche Version von gitverify in Ihren Projekten oder Pipelines verwendet wird. Die anfälligen Versionen können Sie anhand des betroffenen Commits erkennen.

1. Update auf die korrigierte Version: Aktualisieren Sie das Tool auf mindestens die Version, die den Commit c2c60da05d5c73621d0ce7ea02770bacd79ec8b1 enthält. Dies kann über Paketmanager oder direkte Quellcode-Integration geschehen.

1. Statische Binärdateien neu kompilieren: Falls gitverify in statischen Binärdateien oder eingebetteten Umgebungen verwendet wird, müssen diese neu kompiliert werden, um die korrigierte Version zu integrieren.

1. Tests durchführen: Führen Sie manuelle Tests durch, indem Sie unsignierte annotierte Tags in ein Test-Repository pushen. Gitverify sollte diese nun korrekt ablehnen, sofern die Richtlinie requireSignedTags aktiviert ist.

Als zusätzliche Sicherheitsmaßnahme empfiehlt sich die Implementierung einer Defense-in-Depth-Strategie. Diese könnte eine unabhängige Signaturprüfung direkt in Ihren CI/CD-Pipelines umfassen, um die Integrität von Code-Tags unabhängig von gitverify zu gewährleisten.

Fazit und Ausblick

Die Entdeckung von GHSA-H829-5CG7-6HFF unterstreicht einmal mehr, wie kritisch korrekte Implementierungen von Sicherheitsprüfungen sind. Selbst scheinbar einfache Logikfehler können schwerwiegende Folgen für die Integrität von Software-Lieferketten haben. Entwicklerteams sollten solche Schwachstellen nicht nur als Einzelfall betrachten, sondern proaktiv nach ähnlichen Problemen in ihren eigenen Implementierungen suchen.

Die schnell wachsende Komplexität moderner Build-Systeme erfordert eine kontinuierliche Überprüfung und Anpassung von Sicherheitsmechanismen. Nur so lässt sich sicherstellen, dass Tools wie gitverify ihre beabsichtigte Schutzfunktion erfüllen – und Angreifer keine Lücken für Manipulationen finden.