Zurück zu Updates
24. April 2026
Tool Updatevon Claudius Neidig

GitHub App Installation Tokens: Neues Format ab April 2026

GitHub stellt App Installation Tokens auf ein neues, statisches JWT-Format um. Tokens wachsen von 40 auf rund 520 Zeichen — der Prefix ghs_ bleibt, aber Längen-Validierungen, Regex-Patterns und Datenbank-Spalten müssen vor dem Rollout angepasst werden.

Was sich am Token-Format ändert

GitHub kündigt im Changelog an, das Format von App Installation Tokens umzustellen. Die neuen Tokens folgen dem Schema ghs_APPID_JWT und sind mit rund 520 Zeichen deutlich länger als die bisherigen 40-Zeichen-Strings. Der Präfix ghs_ bleibt erhalten, sodass bestehende Token-Type-Detection weiter funktioniert.

Technisch sind die Tokens nun stateless: Das eingebettete JWT ist mit GitHubs internem Issuer signiert und enthält Installation, Application und Validierungs-Metadaten. Wer Tokens bisher als opaque String behandelt hat, ist auf der sicheren Seite.


Rollout-Timeline 2026

Der Rollout läuft in zwei Phasen:

  • 27. April – Mitte Mai 2026: Start mit GitHub Actions GITHUB_TOKEN sowie First-Party-Integrationen wie Dependabot, Slack und Teams.
  • Mitte Mai – Ende Juni 2026: Schrittweise Ausweitung auf alle App Installation Tokens, inklusive Brownout-Phase, in der GitHub gezielt abhängige Apps identifiziert.

Was Entwickler-Teams jetzt anpassen müssen

Drei typische Bruchstellen, die vor dem Rollout entschärft werden sollten:

  • Hardcodierte Längen-Validierungen (etwa token.length === 40) entfernen — die neuen Tokens passen nicht in diese Annahme.
  • Regex-Patterns wie ghs_[A-Za-z0-9]{36} aus Validatoren, Loggern und Secret-Scannern entfernen oder erweitern.
  • Datenbank-Spalten für Token-Storage auf mindestens 520 Zeichen erweitern — sonst werden Tokens beim Insert abgeschnitten.

Grundregel: Tokens als opaque Strings behandeln und keine Annahmen über interne Struktur, Länge oder Zeichenraum treffen. Wer das beherzigt, übersteht zukünftige Format-Wechsel ohne Codeänderung.


Enterprise-Einordnung

Plattform- und DevOps-Teams sollten jetzt drei Bereiche auditieren: eigene CI-Pipelines mit GitHub Actions, alle GitHub-App-Integrationen (intern wie extern) und Secret-Stores in Vaults oder Kubernetes-Secrets. Besonders riskant sind ältere Worker-Skripte oder Lambda-Funktionen, in denen Längen-Checks aus Defensiv-Reflex eingebaut wurden — die fallen oft unter dem Radar moderner Linter.

Bei selbst entwickelten GitHub Apps lohnt sich ein gezielter Test gegen die Brownout-Phase ab Ende April: GitHub schaltet Tokens stichprobenartig auf das neue Format, um Fehlerquellen sichtbar zu machen.


Fazit

Die Umstellung ist technisch unaufwändig — solange der eigene Code Tokens korrekt als opaque behandelt. Wer noch alte Validierungs-Layer aus der 40-Zeichen-Ära hat, sollte sie diese Woche ausräumen, bevor der Rollout in Produktion ankommt. Empfehlung: Audit der eigenen GitHub-Integrationen, DB-Migrationen vorbereiten, Regex-Validatoren entfernen.