Installationstoken für GitHub Apps sind jetzt JWTs mit 520 Zeichen

GitHub hat die Umstellung aller neu erstellten Installationstoken für GitHub Apps auf ein neues "zustandsloses" Format abgeschlossen, teilte das Unternehmen am 2. Oktober 2026 in seinem Changelog mit. Die Token beginnen weiterhin mit ghs_, sind jetzt aber etwa 520 statt 40 Zeichen lang. Jeder Code, der von der alten Länge ausging, etwa ein Validierungsmuster oder eine Datenbankspalte, kann ein gültiges Token jetzt ablehnen oder abschneiden.

Was sich geändert hat

Ein Installationstoken ist das kurzlebige Passwort, mit dem eine GitHub App in den Repositorys handelt, in denen sie installiert ist. GitHub begann am 27. April 2026 mit einer schrittweisen Einführung des neuen Formats. Laut dem Changelog vom 2. Oktober ist diese Einführung abgeschlossen, das neue Format ist also jetzt der Standard.

Das neue Token ist ein JWT, kurz für JSON Web Token: eine signierte Zeichenkette, die Informationen in sich trägt. Laut GitHubs Changelog vom Mai lassen sich die beiden Formate unterscheiden, indem man die Punkte zählt. Ein zustandsloses Token enthält zwei Punkte, das alte opake Token keinen.

	Altes Format	Neues Format
Präfix	ghs_	ghs_
Länge	40 Zeichen, fest	etwa 520 Zeichen, kann variieren
Punkte im Token	0	2
Gültigkeit	1 Stunde	1 Stunde, unverändert

Berechtigungen, die Beschränkung auf bestimmte Repositorys und der Ablauf nach einer Stunde bleiben gleich, sagt GitHub. Nur die Form der Zeichenkette hat sich geändert.

Was das Token enthält

Das Projekt Kingfisher von MongoDB, ein Scanner, der nach geleakten Secrets sucht, beschrieb das Format in einem Issue vom 26. April. Es schreibt das Muster als ghs_APPID_JWT. Der JWT-Teil enthält laut dem Issue Angaben wie die Zielinstallation und die App sowie grundlegende Validierungsdaten.

Dieses JWT wird von GitHubs eigenem internen Aussteller signiert. Laut dem Kingfisher-Issue sollten Client-Apps nicht versuchen, es zu validieren. Für deinen Code sollte das Token eine opake Zeichenkette bleiben: etwas, das du speicherst und sendest, aber nie parst.

Kingfisher wies außerdem darauf hin, dass seine eigene Erkennungsregel für diese Token nach Abschluss der Einführung ein Update brauchen würde. Secret-Scanner, die auf die alte Form mit 40 Zeichen prüfen, gehören zu den Stellen, an denen sich diese Änderung zuerst zeigt.

Der Override-Header und seine Frist

Im Mai fügte GitHub der Anfrage, die ein Installationstoken erzeugt, einen vorübergehenden Header hinzu: X-GitHub-Stateless-S2S-Token. Wer enabled sendet, bekommt ein Token im neuen Format. Wer disabled sendet, bekommt ein Token im alten Format, selbst bei Apps, die bereits umgestellt sind. Ohne den Header gilt der Standard.

Dieser Notausgang schließt sich. Laut dem Changelog vom 2. Oktober wird der Header am 30. November 2026 als veraltet markiert (deprecated). Nach diesem Datum verlieren Teams, die das alte Format festgelegt haben, um Zeit zu gewinnen, diese Option.

GitHubs Changelog vom Mai nennt GitHub Enterprise Cloud und seine Regionen mit Datenresidenz als abgedeckt. Neben den Server-zu-Server-Tokens von Apps nennt er auch das GITHUB_TOKEN von Actions, also das Token, das Workflows verwenden.

Was das für Entwickler bedeutet

Durchsuche deinen Code nach allem, was diese Token als Werte fester Größe behandelt. GitHubs Hinweise nennen vier Problemstellen: Längenprüfungen, Grenzen von Datenbankspalten, abgeschnittene Header und Log-Muster. Jede davon kann still fehlschlagen. Eine Spalte, die 40 oder 255 Zeichen fasst, schneidet das Token ab, und der API-Aufruf scheitert dann mit etwas, das wie ein Authentifizierungsfehler aussieht.

Korrigiere als Nächstes die Validierungsmuster. Ein Muster wie ghs_[A-Za-z0-9]{36} lehnt das neue Token ab, weil das Token länger ist und Punkte enthält. GitHubs Changelog vom Mai schlägt ghs_[A-Za-z0-9.\-_]{36,} vor, das beide Formate erkennt. Prüfe dein eigenes Muster in einem Regex-Tester an einem erfundenen Beispiel jeder Form, nie an einem echten Token.

Stelle sicher, dass der Speicher mindestens 520 Zeichen fasst, sagt GitHub. Das gilt auch für Caches, Secret-Stores und Umgebungsvariablen mit Größenbegrenzung. Wenn du Secrets in Logs schwärzt, teste, ob deine Schwärzung das längere Token noch erfasst. Sonst könnte ein Teil eines echten Zugangsschlüssels im Klartext landen.

Wenn du den Override-Header in diesem Frühjahr auf disabled gesetzt hast, hast du bis zum 30. November Zeit, ihn zu entfernen. Teste zuerst mit enabled, dann lösche den Header.