Zum Hauptinhalt springen
S-EDV news
← Alle News
Docker 19.10.2026 · 4 min Lesezeit

Gitea 28.2.0 schließt neun Sicherheitslücken, zwei erlauben Kontoübernahme

Gitea 28.2.0 ist seit dem 18. Oktober 2026 verfügbar und schließt neun Sicherheitslücken. Zwei hoch eingestufte Fehler bei SSH-Zertifikat-Principals und OpenID-Verknüpfung ermöglichten unter bestimmten Bedingungen die Anmeldung als fremder Benutzer. Dazu kommen ein DoS in der Actions-Artifact-API und mehrere Datenlecks.

Mit KI erstellt – redaktionelle Prüfung ausstehend

Grafik mit der Überschrift Gitea 28.2 schließt Sicherheitslücken, daneben ein stilisierter Git-Graph und ein Schutzschild mit Schlüsselloch

Das Gitea-Projekt hat am 18. Oktober 2026 die Version 28.2.0 veröffentlicht. Das zweite Wartungsrelease der 28er-Reihe schließt neun Sicherheitslücken, darunter zwei mit hoher Einstufung: Über SSH-Zertifikate und über OpenID 2.0 konnten sich Angreifer unter bestimmten Bedingungen als fremde Benutzer anmelden. Betroffen sind alle selbst betriebenen Gitea-Instanzen bis einschließlich 28.1.0. Das Projekt empfiehlt das Update so bald wie möglich.

Wer Gitea mit vertrauenswürdiger SSH-Benutzer-CA, mit OpenID-Anmeldung oder mit aktivierten Actions betreibt, sollte heute aktualisieren. Instanzen ohne diese Funktionen tragen ein geringeres Risiko, erhalten mit 28.2.0 aber ebenfalls mehrere Korrekturen für Rechteprüfungen und Datenlecks. Hinweise auf aktive Angriffe nennen weder Blog noch Advisories.

Was ist neu in Gitea 28.2.0?

Laut Gitea-Blog behebt 28.2.0 Sicherheitsprobleme sowie Fehler in Actions, Pull Requests, Authentifizierung und Paketverwaltung. Im Blogeintrag listet das Projekt zwölf CVEs auf. Neun davon sind laut den GitHub Security Advisories erst in 28.2.0 behoben, drei waren bereits in 28.1.0, 28.0.0 oder 1.27.x korrigiert und werden jetzt nur offengelegt. Linuxiac kommt zur gleichen Zählung.

Die Docker-Images stehen bereit: Auf Docker Hub verweisen die Tags gitea/gitea:28.2.0, 28.2, 28 und latest seit dem 18. Oktober 2026 auf denselben Digest.

Wer ist betroffen?

Alle neun neu behobenen Lücken betreffen laut Advisories Versionen bis einschließlich 28.1.0. Wie stark eine Instanz gefährdet ist, hängt von der Konfiguration ab:

  • SSH-Zertifikate: Nur Instanzen, die einer SSH-Benutzer-CA vertrauen (SSH_TRUSTED_USER_CA_KEYS). Besonders kritisch, wenn Principals nicht eingeschränkt sind (SSH_AUTHORIZED_PRINCIPALS_ALLOW=anything).
  • OpenID 2.0: Instanzen, auf denen Benutzer OpenID-Identitäten verknüpfen und sich damit anmelden können.
  • Gitea Actions: Instanzen mit aktivierten Actions, auf denen Benutzer Workflows auslösen dürfen.
  • Releases und Anhänge: Mehrbenutzer-Instanzen mit privaten Repositories, auf denen Benutzer Releases anlegen dürfen.

Die wichtigsten Lücken im Detail

CVE-2026-109553 (hoch, CVSS 7.5): Gitea suchte SSH-Zertifikat-Principals unter allen gespeicherten öffentlichen Schlüsseln statt nur unter Principal-Einträgen. Ein Zertifikat, das den öffentlichen Schlüssel eines anderen Benutzers als Principal enthält, authentifizierte daher als dieser Benutzer. Laut Advisory ist dafür eine vertrauenswürdige Benutzer-CA nötig, die beliebige Principals akzeptiert, oder die Möglichkeit, mit dieser CA Zertifikate auszustellen.

CVE-2026-104627 (hoch, CVSS 8.1): Der OpenID-Rückruf in den Sicherheitseinstellungen prüfte nicht, ob der angemeldete Benutzer die Verknüpfung selbst gestartet hatte. Ein Angreifer mit eigenem OpenID-Provider konnte so seine Identität an das Konto eines Opfers hängen und sich danach als Opfer anmelden. Laut Advisory umgeht dieser Weg auch TOTP und WebAuthn. Der Angriff setzt eine Interaktion des Opfers voraus. Gitea verlangt jetzt einen kurzlebigen, an den Benutzer gebundenen State-Wert.

CVE-2026-105964 (mittel, CVSS 6.5): Die Artifact-v4-API von Gitea Actions las Request-Bodys ohne Größenlimit ein. Wer ein Runner-Token besitzt, konnte den Speicher des Servers erschöpfen und laut Advisory den gesamten Gitea-Prozess beenden. Die Bodys sind jetzt auf 1 MiB begrenzt.

Weitere behobene Lücken betreffen Datenabflüsse und Rechteprüfungen:

  • CVE-2026-110311: Draft-Releases lieferten Metadaten von Anhängen der gesamten Instanz aus, auch aus nicht lesbaren privaten Repositories.
  • CVE-2026-110494: Issue-Anhänge ließen sich an Releases hängen und darüber umbenennen oder löschen.
  • CVE-2026-105661: Anonyme Aufrufe von /{username}/-/repositories lösten bei Einzelbenutzern einen Absturz der Anfrage aus.
  • CVE-2026-107686, CVE-2026-107618 und CVE-2026-97204: Reaktionen auf gesperrte Issues, CSRF bei Repository-Topics und das Löschen fremder Organisations-Labels.

Daneben enthält das Changelog sicherheitsnahe Korrekturen ohne eigene CVE, etwa eine OID-Prüfung bei LFS, das Abweisen von E-Mail-Tokens gesperrter Benutzer und ein Update von golang.org/x/net auf v0.60.0.

Wie kritisch ist das?

Die beiden hoch eingestuften Lücken führen im Erfolgsfall zur Übernahme fremder Konten, greifen aber nur bei SSH-CA-Betrieb beziehungsweise bei genutzter OpenID-Anmeldung. Für Instanzen mit diesen Funktionen ist das Update dringend. Die DoS-Lücke ist für Instanzen relevant, auf denen nicht vertrauenswürdige Benutzer Workflows starten können. Die übrigen Lücken sind mittel bis niedrig eingestuft und gehören ins nächste Wartungsfenster, sofern das Update nicht ohnehin sofort erfolgt.

Was Admins jetzt tun sollten

  • Version prüfen: gitea --version im Container oder die Angabe im Seitenfuß bzw. im Administrationsbereich. Alles bis 28.1.0 ist betroffen.
  • Docker-Setups auf gitea/gitea:28.2.0 anheben, vorher Datenverzeichnis und Datenbank sichern, dann docker compose pull und docker compose up -d.
  • In der app.ini prüfen, ob SSH_TRUSTED_USER_CA_KEYS gesetzt ist und welchen Wert SSH_AUTHORIZED_PRINCIPALS_ALLOW hat.
  • Bei aktivierter OpenID-Anmeldung die in den Benutzerkonten verknüpften OpenID-Identitäten auf unbekannte Einträge sichten.
  • Bei Actions prüfen, wer Workflows auslösen darf, und Speicherabstürze im Log der letzten Wochen nachverfolgen.

Einordnung

28.2.0 folgt zwölf Tage auf 28.1.0, das bereits zahlreiche Lücken schloss. Das Projekt veröffentlicht Sicherheitskorrekturen derzeit in kurzen Abständen, oft mit Sammel-Pull-Requests. Für Betreiber heißt das: Gitea-Updates gehören in einen festen, kurzen Rhythmus statt in seltene Großupdates.

Passende Anleitungen auf S-EDV

Quellen

GiteaSicherheitsupdateCVE-2026-109553CVE-2026-104627Self-HostingGitDocker