v3.2.116 — Security: no more shared default password

A single security fix, and the one v3.2.115's notes listed as a known weakness. Recommended for anyone
whose St0r login page is reachable by people you would not hand an administrator account to.

Security advisory: GHSA-2xmc-6xrh-rj4x — rated critical, affecting every release before 3.2.116.

The shared default password is gone

Every installation created the same first account — admin / admin123 — and the product then advertised
it:

• GET /api/setup/status answered, without authentication, whether the default password was still in use.
• While it was, the login page printed the username and password on screen to any anonymous visitor.

So on a fresh installation, anyone who could reach the login page could read working administrator
credentials. No guessing required.

What happens now

First run generates a password unique to your installation. It is logged once, written to
/opt/urbackup-gui/initial-admin-password.txt at mode 0600, and printed by the installer when it finishes:

sudo journalctl -u urbackup-gui | grep -A3 "First run"

Delete that file once you have signed in.

/api/setup/status is removed, and so is the login page banner. The forced password change is now driven
by a must_change_password flag returned by the login response only to the authenticated account it
applies to — previously the browser inferred it by checking whether you had typed admin123, which is
why the state had to be public at all.

Upgrading

Migration 008 adds the flag, defaulting to off. So that existing installations do not silently lose the
prompt, the backend checks each account against the old default on first start after updating, and flags
any that still use it:

Account 'admin' still uses the old default password — a change is now required at next login.

If your administrator password is already something other than admin123, nothing changes for you —
no account is flagged and no one is forced to do anything.

If you are still on admin123, this release is the prompt to change it.

Verified

Exercised on a scratch database: a fresh install generates a password and requires a change; the old
default is rejected; an existing admin123 account is flagged at startup; changing the password clears the
flag; and a restart does not re-flag it. The shipped frontend bundle contains neither admin123 nor
setup/status.

Full changelog: v3.2.115...v3.2.116