• v1.36.9 9ae7d862e8

    Vaultwarden-Plus v1.36.9
    All checks were successful
    auto-image-build / docker-build (push) Successful in 21m45s
    ci / rust-checks (push) Successful in 2m43s
    validate-publish-surface / validate-publish-surface (push) Successful in 3s
    Stable

    StefanSA released this 2026-07-28 13:56:14 +02:00 | 2 commits to main since this release

    Vaultwarden-Plus v1.36.9

    Date: 2026-07-28

    Status: PASS

    Highlights

    • Bundles upstream Web Vault 2026.6.4 from immutable manifest sha256:e7d3b31ec6a991a6bf447721ea341b4192ce5d3b920929211672fd4f3f891427.
    • Preserves the Vaultwarden 1.37.0 and Vaultwarden-Plus v1.36.4-v1.36.8 security baseline.
    • Uses Web Vault 2026.6.4 native Account Recovery requests and removes the obsolete recovery browser adapter.
    • Retains the Plus branding and device-login approver adapters.
    • Integrates upstream Vaultwarden #7442 for [bit-dialog] custom-role markup.

    Compatibility

    • Account Recovery retains direct /recover-account, legacy /reset-password, resetMasterPassword=true, resetTwoFactor=false, forced temporary-password update, and subsequent-login behavior.
    • Web Vault 2026.6.4 can selectively reset master password, two-step login, or both through the native recovery dialog.
    • Passkey Login and PRF unlock retain the official Web Vault request/response surface and remain feature-gated where configured.
    • Trusted Device, Authentication Request, and Device Login prototype contracts remain server-side compatible; prototype behavior remains disabled by default.
    • Send Email Verification/OTP retains legacy and bearer-token access behavior for email-protected text and file Sends.
    • Login, registration, organization, Send, and Bitwarden 2026.7.x request compatibility remain on the Vaultwarden-Plus 1.37.0 baseline.

    Build And Packaging

    • The Web Vault image remains tag-and-digest pinned.
    • A dedicated vault_plus build stage applies and packages the retained adapters without invoking the Rust stage.
    • A repeated vault_plus build uses cached source, adapter copy, and injection layers.
    • The final release image is built once and reused for runtime validation and registry publication.

    Validation

    • Complete Bitwarden clients tag delta: 2,859 changed files, including 561 apps/web files and 1,255 shared-library files.
    • Complete bw_web_builds tag delta and Vaultwarden #7442 patch reviewed.
    • Web Vault adapter-stage build and static packaging passed.
    • Native recovery and passkey markers are present in the packaged bundle.
    • Branding and approver adapter syntax and runtime packaging passed; the removed recovery adapter is absent.
    • Rust fmt, locked SQLite/MySQL/PostgreSQL/sqlite,ses checks, and the full locked SQLite test suite passed in forgejo-rust-node:1.97.1.
    • Focused Playwright Web Vault integration coverage is included for static packaging, branding, adapter contracts, login, and passkey routing.
    • The focused SQLite Playwright integration passes. The broader legacy suite was attempted but its account-creation fixture is parked because the Web Vault 2026.6.4 SDK rejects the harness's insecure HTTP registration URL before issuing an API request; this fixture-only limitation does not block the release.
    • Container runtime health and release publication use the same validated image and commit.

    Security

    • No authentication, cryptographic, session, token, or recovery server semantics were weakened.
    • The recovery browser shim was removed only after its request rewrite/defaulting behavior became native in Web Vault 2026.6.4.
    • Legacy compatibility remains server-side, where it is covered by focused Rust request-contract tests.
    • Unsupported Custom Role controls remain hidden for both legacy <bit-dialog> and new [bit-dialog] hosts.

    Image

    • forgejo.sabolowitsch.org/stefansa/vaultwarden-plus:1.36.9
    • forgejo.sabolowitsch.org/stefansa/vaultwarden-plus:latest

    Migration

    • Database migration: NO.
    • Configuration migration: NO.
    • Operators using custom branding or the device-login prototype do not need to change configuration.

    Residual Risks

    • Provider-specific Account Recovery, Key Connector recovery, and broader custom-role parity remain outside the supported core flow.
    • Desktop and mobile passkey-login coverage remains narrower than Web Vault and official Chromium Extension coverage.
    • The device-login approval adapter remains an explicitly non-token-issuing prototype.
    • Full browser Account Recovery/login/organization regression remains limited by the parked insecure-HTTP signup fixture; focused browser, static package, API contract, and Rust validation passed.
    Downloads