Bitwarden 2026.10: Self-Hosting erhält einstellbare Token-Laufzeit

Bitwarden hat die Version 2026.10.0 seines Servers veröffentlicht, das Self-Host-Paket ist seit dem 15. Oktober 2026 verfügbar. Für Betreiber eigener Bitwarden-Instanzen ist vor allem eine neue Umgebungsvariable relevant: Die Gültigkeitsdauer der Zugriffstoken lässt sich erstmals selbst festlegen. Dazu kommen mehrere Korrekturen mit Sicherheitsbezug, etwa ein SSRF-Schutz für die Teams-Integration und weniger Fehlerdetails bei SSO-Fehlern.

Betroffen sind Organisationen, die den offiziellen Bitwarden-Server per bitwarden.sh, Docker oder Helm selbst betreiben. Nutzer der Bitwarden-Cloud müssen serverseitig nichts tun. Vaultwarden-Instanzen sind eine eigenständige Implementierung und von diesem Release nicht berührt. Eine CVE nennen die Release Notes nicht, ein Notfall-Update ist daher nicht nötig. Das Update gehört aber ins nächste reguläre Wartungsfenster.

Was ist neu in Bitwarden 2026.10?

Laut den offiziellen Release Notes gehören zum Zyklus 2026.10.0 der Server sowie Web, Browser-Erweiterung, Desktop, Mobile und CLI mit derselben Versionsnummer. Das GitHub-Release des Servers ist auf den 14. Oktober 2026 datiert, das Release im Repository bitwarden/self-host folgte am 15. Oktober und hebt Core und Web auf v2026.10.0.

• Teilen per Link: Premium-Nutzer und Mitglieder bezahlter Organisationen können eine temporäre Kopie eines Tresor-Eintrags per Link an bestimmte Personen weitergeben. Regeln legen fest, wer den Link öffnen darf und wie lange.
• Tresor-Berichte in der Browser-Erweiterung: Offengelegte, schwache und mehrfach verwendete Passwörter lassen sich direkt in der Erweiterung auswerten. Premium- und Families-Abos sehen die konkreten Einträge, das kostenlose Abo nur die Anzahl.
• Self-Host: Neue Umgebungsvariable für die Lebensdauer der Zugriffstoken.
• Web-Tresor: Schnellere Entschlüsselung, bessere Importe aus Proton Pass und LastPass sowie ein behobener Fehler, durch den der Tresor bei bestimmten SSH-Schlüssel-Einträgen nicht lud (laut Deskmodder).

Die neue Variable für Zugriffstoken im Detail

Die Variable heißt globalSettings__identityServer__AccessTokenLifetimeSeconds und wird wie andere Einstellungen in ./bwdata/env/global.override.env gesetzt. Laut Bitwarden-Dokumentation gilt ohne Angabe weiterhin eine Stunde. Der zugehörige Pull Request #8367 im Server-Repository beschreibt das Verhalten genauer:

• Der Wert gilt für die interaktiven Clients Web, Mobile, Browser, Desktop und CLI.
• Der Directory Connector ist bewusst ausgenommen und behält seine 24 Stunden, ebenso unberührt bleiben API-Key-Zugänge und der Send-Client.
• Ein Wert von 0 oder kleiner verhindert den Start des Identity-Dienstes mit einer Fehlermeldung.
• Unter 600 Sekunden schreibt der Server beim Start eine Warnung ins Log, weil die Clients Token bereits fünf Minuten vor Ablauf erneuern. Sehr kurze Werte erzeugen sonst vor fast jedem API-Aufruf eine neue Token-Anfrage.
• Für die Bitwarden-Cloud ändert sich laut Pull Request nichts.

Für Admins ist das ein echter Sicherheitshebel: Wer kürzere Laufzeiten verlangt, etwa wegen interner Richtlinien zu Sitzungsdauern, kann ein abgegriffenes Zugriffstoken früher wertlos machen. Der Preis ist mehr Last auf dem Identity-Dienst. Zusammen mit den bereits vorhandenen Variablen für Refresh-Token ergibt sich nun ein vollständig steuerbares Token-Modell.

Korrekturen mit Sicherheitsbezug

Das Changelog des Servers listet neben Funktionen eine Reihe von Fehlerbehebungen, die Admins kennen sollten. Eine CVE oder ein Security Advisory ist ihnen nicht zugeordnet:

• Der Teams-Dienst nutzt nun einen gegen SSRF geschützten HTTP-Client, Teams- und Slack-Integrationen lassen sich nicht mehr über API-Updates ändern.
• Fehlermeldungen bei lizenzierten SSO-Anmeldungen und bei der Abrechnung geben keine internen Ausnahmedetails mehr preis.
• Die Richtlinie zum Einschränken des Löschens von Einträgen greift jetzt auch bei Dateianhängen.
• Ungültige Kombinationen von Verwalten- und Nur-Lesen-Rechten bei Sammlungen werden abgewiesen.
• Der Endpunkt zum Bestätigen von Einladungen prüft zusätzlich die E-Mail-Verifizierung.

Wie dringend ist das Update?

Ohne bekannte, ausgenutzte Schwachstelle ist 2026.10.0 ein reguläres Wartungsupdate. Dringlicher wird es für Instanzen mit Teams- oder Slack-Integration und für Umgebungen mit SSO, weil dort die genannten Härtungen greifen. Bitwarden weist in der Update-Dokumentation darauf hin, dass Updates Korrekturen für die Sicherheit der Instanz enthalten können und Tresordaten als kritisch gelten. Da Clients und Server im selben Zyklus erscheinen, sollten beide Seiten zeitnah auf denselben Stand kommen.

Was Admins jetzt tun sollten

• Zuerst den laufenden Stand prüfen: Server-Version in der Admin-Konsole oder per docker ps an den Image-Tags der Bitwarden-Container ablesen.
• Backup des Verzeichnisses bwdata und der Datenbank anlegen, bevor das Update startet.
• Standardinstallation aktualisieren mit ./bitwarden.sh updateself und anschließend ./bitwarden.sh update, bei Helm zuerst helm repo update.
• Entscheiden, ob die Token-Laufzeit angepasst werden soll. Werte unter 600 Sekunden nur nach Lasttest setzen, danach das Log des Identity-Dienstes auf Warnungen prüfen.
• Bestehende Teams- und Slack-Integrationen nach dem Update testen.
• Vor Freigabe der Link-Freigabe intern regeln, welche Daten auf diesem Weg an Externe gehen dürfen.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen mit eigener Bitwarden-Instanz ist 2026.10.0 vor allem ein Gewinn an Kontrolle. Die frei wählbare Token-Laufzeit schließt eine Lücke, die bisher nur über Umwege oder gar nicht zu schließen war. Die neue Link-Freigabe ist praktisch, sollte aber nicht ohne Richtlinie aktiviert werden, weil sie den Weg von Zugangsdaten nach außen vereinfacht. Für Vaultwarden-Betreiber gilt: Ob neue Serverfunktionen wie die Link-Freigabe oder die Token-Variable dort verfügbar sind, entscheidet allein das Vaultwarden-Projekt, das Bitwarden-Release ändert daran nichts.

Passende Anleitungen auf S-EDV

• Bitwarden selbst hosten mit Vaultwarden, Docker und Nginx Proxy Manager: Grundlagen für den eigenen Passwort-Tresor.
• Vaultwarden härten, sichern und mit Fail2ban schützen: Backup und Härtung für selbst betriebene Tresore.
• Vaultwarden als Passwort-Tresor für kleine Unternehmen: Einordnung der Alternative zum offiziellen Server.

Quellen

• Bitwarden: Release Notes 2026.10.0
• GitHub: bitwarden/server Release v2026.10.0 (14.10.2026)
• GitHub: bitwarden/self-host Release v2026.10.0 (15.10.2026)
• GitHub: Pull Request #8367 zur Laufzeit der Zugriffstoken
• Bitwarden: Dokumentation der Umgebungsvariablen
• Bitwarden: Server aktualisieren
• Deskmodder: Bitwarden 2026.10 mit Änderungen beim Self-Hosting