GitHub ändert Format der App-Installationstokens: von 40 auf ~520 Zeichen, Bruchrisiko für CI/CD-Pipelines

GitHub gab am 24. April 2026 eine bedeutende Änderung des App-Installationstoken-Formats bekannt, die bereits ab dem 27. April 2026 in einem gestaffelten Rollout in die Produktion geht. Die Änderung hat das Potenzial, Integrationen und CI/CD-Pipelines zu beschädigen, die die bisherige 40-Zeichen-Token-Länge fest kodiert haben — was eine große Anzahl benutzerdefinierter Skripte und Datenbankschemas in Produktion betrifft.

Was ist genau das neue Format?

Das alte Format sieht so aus: ghs_ + 36 alphanumerische Zeichen = 40 Zeichen insgesamt. Das neue Format ist als JWT (JSON Web Token) mit dem Präfix ghs_APPID_JWT und einer Gesamtlänge von etwa 520 Zeichen strukturiert, mit dem Hinweis, dass es „vary based on the data stored within it” wird — mit anderen Worten: Die Länge ist nicht fest, sondern hängt vom Inhalt ab. JWT ist ein standardisiertes Format (RFC 7519) für die sichere Übertragung von JSON-Daten, kryptografisch signiert, sodass die Integrität ohne einen Rückruf an den Server verifiziert werden kann. Laut GitHub-Ankündigung enthält das JWT „details about the token such as the target installation, the application, and basic validation details”.

Wer ist betroffen und wann?

GitHub unterteilt den Rollout in zwei Phasen. Phase 1 (27. April – Mitte Mai 2026) umfasst den GitHub Actions GITHUB_TOKEN und sogenannte Featured Integrations wie Dependabot, Slack und Teams Integrationen. Phase 2 (Mitte Mai – Ende Juni 2026) umfasst alle App-Installationstokens, einschließlich Nutzern von GitHub Enterprise Cloud und Umgebungen mit Data Residency-Anforderungen (EU, Australien, andere Regionen). Praktisch gesehen sollte jede Organisation, die GitHub Apps zur Authentifizierung in CI/CD-Pipelines verwendet, sich sofort vorbereiten.

Was MÜSSEN Entwicklerinnen und Entwickler tun?

GitHub ist sehr explizit bei drei wichtigen Maßnahmen:

1. Datenbankschema: „Any database columns for access tokens can fit at least a 520 character string” — prüfen, ob alle Spalten, in denen Tokens gespeichert werden, mindestens 520 Zeichen unterstützen. Ein typisches VARCHAR(40) oder VARCHAR(64) wird nicht mehr funktionieren.
2. Regex-Prüfungen: Alle Regex-Muster wie ghs_[A-Za-z0-9]{36} entfernen, die zur Validierung des Token-Formats verwendet wurden. Das neue Format enthält Unterstriche und Zeichen, die nicht dem alten Muster entsprechen.
3. Längenchecks: „Your apps do not take a dependency on access tokens being a certain length” — jede Logik, die eine feste Länge von 40 Zeichen voraussetzt, muss überarbeitet werden.

Warum tut GitHub das?

Sicherheits- und Performance-Motivation. Das JWT-Format ermöglicht zustandslose Validierung — der Server muss bei jedem Aufruf keine DB-Abfrage durchführen, um die Token-Gültigkeit zu prüfen; die Signatur kann lokal verifiziert werden. GitHub gibt an, dass die Änderung „improves token issuance performance under increased load” bewirkt und „higher reliability at scale” liefert. Mit anderen Worten: GitHub bereitet seine Authentifizierungsinfrastruktur auf das wachsende Anfrageaufkommen vor, das durch die Explosion von KI-Agenten und automatisierten Bot-Integrationen entsteht.

Was passiert, wenn ich die Änderung ignoriere?

Anwendungen, die die alte Länge voraussetzen, werden beim ersten Auftreten eines neuen Tokens Fehler erzeugen. Die häufigsten Symptome: DB-INSERT-Fehler (abgeschnittene Strings), Regex-Validierungsablehnungen, Authorization-Header-Parser-Fehler. Es empfiehlt sich, in den nächsten Tagen proaktiv alle Repositories und benutzerdefinierten Actions zu überprüfen, bevor der Rollout die eigene Organisation erreicht.