Gitea 28.0: Abschied von 1.x, Audit-Logs und Bot-Accounts

Gitea hat am 30. September 2026 Version 28.0.0 veröffentlicht und dabei das historische Präfix „1.“ aus der Versionsnummer gestrichen: Auf 1.27 folgt nicht 1.28, sondern 28.0. Neu sind ein eingebautes Audit-Log, eigene Bot-Accounts, Admin-Impersonation und HTTPS-Deploy-Tokens pro Repository. Das Release enthält außerdem Sicherheitskorrekturen, deren Details das Projekt erst in etwa einer Woche nachreicht.

Relevant ist das für alle, die Gitea selbst betreiben, besonders per Docker. Wer das Image über gitea/gitea:1 oder :1.27 bezieht, bekommt das neue Release nicht automatisch, sondern bleibt auf 1.27.3 stehen. Wer :latest nutzt, ist dagegen seit dem 30. September bereits auf 28.0.0 gelandet, samt Breaking Changes. Akuter Handlungsbedarf besteht heute vor allem darin, den eigenen Tag zu prüfen; das eigentliche Upgrade gehört in ein geplantes Wartungsfenster mit Backup.

Was ist passiert?

Das GitHub-Release v28.0.0 ist auf den 29. September 2026 datiert, der Blogbeitrag des Projekts auf den 30. September. Die wichtigsten Neuerungen laut Release-Ankündigung:

• Audit-Logging: Sicherheitsrelevante Ereignisse werden in Admin-, Organisations-, Repository- und Benutzereinstellungen angezeigt, filterbar nach Actor, Action und Origin, exportierbar als JSONL. Standardmäßig aus, Aufbewahrung 30 Tage.
• Bot-Accounts: Konten für Automatisierung, die sich nur per Access Token anmelden, keinen interaktiven Login haben und keine Benachrichtigungen oder Mails erhalten. Bestehende lokale Konten lassen sich in Bots umwandeln.
• Admin-Impersonation: Admins sehen Gitea aus Sicht eines bestimmten Benutzers, ohne dessen Passwort. Bei aktivem Audit-Log werden beide Konten protokolliert.
• Deploy-Tokens: HTTPS-Gegenstück zu SSH-Deploy-Keys, je Repository mit Lese- oder Lese-Schreib-Recht, auch für LFS.

Für wen ist das relevant?

Betroffen sind alle selbst betriebenen Gitea-Instanzen, die auf 28.0 wechseln oder per :latest bereits gewechselt haben. Laut Docker Hub zeigen 28, 28.0, 28.0.0 und latest auf dasselbe Image, 1 und 1.27 dagegen weiterhin auf 1.27.3. Gleiches gilt für die Rootless-Varianten 28-rootless und 1-rootless. Nicht direkt betroffen sind Instanzen mit festem 1.27er-Pin, solange niemand den Tag ändert. Wer Binaries per Skript lädt, muss Download-Skripte anpassen: Dateinamen tragen kein OS-Versionssuffix mehr, 32-Bit-x86- und gogit-Builds entfallen.

Wie kritisch ist das?

Das Update ist kein Notfall-Patch, aber auch kein reines Funktionsrelease. Die Breaking Changes können eine Instanz nach dem Upgrade am Start hindern oder still das Verhalten ändern:

• Gitea startet nicht mehr mit Git älter als 2.25.0. Ungültige Einträge in [migrations] BLOCKED_HOST_LIST verhindern ebenfalls den Start.
• Migrationen und Mirrors laufen über einen internen Proxy mit neuen Egress-Regeln. Im Standardmodus lax beschränkt [security] ALLOWED_HOST_LIST öffentliche Hosts nicht mehr; als exklusive Allowlist wirkt sie nur mit EGRESS_MODE = strict.
• [server] DOMAIN wird ignoriert, die Domain kommt aus ROOT_URL. Die Selbstregistrierung ist ohne ausdrückliches DISABLE_REGISTRATION = false abgeschaltet.
• Abgeschlossene Actions-Läufe samt Logs und Artefakten werden nach 400 Tagen gelöscht, außer [actions] RUN_RETENTION_DAYS = 0 ist gesetzt.
• Live-Benachrichtigungen nutzen WebSockets unter /-/ws. Ohne weitergeleitete Upgrade-Header am Reverse Proxy fallen Zähler auf Polling zurück.

Welche Schwachstellen die Sicherheitskorrekturen schließen und wie schwer sie wiegen, ist noch nicht veröffentlicht. Der Changelog nennt unter anderem Fixes für Push-Prüfungen, SSH-Schlüsselzuordnung und Team-Berechtigungen.

Was sollten Admins jetzt tun?

• Image-Tag und laufende Version prüfen, etwa mit docker compose images und docker exec <container> gitea --version. Wer unbeabsichtigt per :latest auf 28.0.0 gewechselt hat, sollte die Breaking Changes sofort gegenprüfen.
• Update-Automatik anpassen: Watchtower oder ähnliche Werkzeuge auf :1 holen 28.0 nie. In Renovate erscheint der Wechsel von 1.27.3 auf 28.0.0 als Versionssprung, der bewusst freigegeben werden sollte.
• Vor dem Upgrade ein vollständiges Backup mit gitea dump plus Datenbank- und Volume-Sicherung anlegen, wie es auch das Projekt empfiehlt.
• app.ini auf DOMAIN, Egress-Listen, Registrierung und Actions-Aufbewahrung durchsehen, dann gezielt auf gitea/gitea:28 wechseln.
• Audit-Log mit [audit] RECORD_OUTPUT = database aktivieren und RETENTION_DAYS passend zur eigenen Aufbewahrungsrichtlinie setzen.
• Service-User für CI und Skripte schrittweise durch Bot-Accounts oder Deploy-Tokens ersetzen.

Einordnung für Unternehmen

Für kleinere Teams schließt Gitea 28 zwei Lücken, die bisher oft mit Workarounds überbrückt wurden: Ein nachvollziehbares Audit-Log erleichtert Nachweise bei Rechteänderungen, und Bot-Accounts ersetzen geteilte Service-User mit Passwort und Postfach. Der Versionssprung selbst ändert technisch wenig, wirkt aber auf jede Update-Automatik, die auf das Major-Tag 1 vertraut. Die Instanz bleibt dann ohne Warnung auf 1.27 stehen. Wie lange 1.27 noch Sicherheitsupdates erhält, geht aus den Quellen nicht hervor. Wer zuletzt wegen CVE-2026-60004 kurzfristig patchen musste, weiß, wie wichtig ein bewusst gewählter Update-Kanal ist.

Passende Anleitungen auf S-EDV

• Gitea als Self-Hosted Git-Server mit Docker: Installation, Backup per gitea dump und Updates.
• Renovate für Docker-Abhängigkeiten: Image-Updates kontrolliert per Pull Request freigeben.
• Container-Updates mit Watchtower-Nachfolgern: Update-Benachrichtigung statt blinder Automatik.

Quellen

• Gitea-Blog: Ankündigung von Gitea 28.0.0 mit Breaking Changes (30.09.2026)
• GitHub: Release v28.0.0 von go-gitea/gitea mit vollständigem Changelog
• Docker Hub: Image-Tags von gitea/gitea (abgerufen am 01.10.2026)
• Linuxiac: Bericht zu Gitea 28.0, Audit-Logs und Bot-Accounts (30.09.2026)