Currently we create the auto-login cookie using the user_id, and a hash of (a) the per-user network_secret and (b) the password_v4 (which is a hash).
Someone with access to the database or a backup of it could create login cookies for any user.
This is also open to a replay attack.
The main issue here is that we never update the network_secret.

That can be avoided (in case of the stolen DB) or the window can be shortened (replay attack), with some kind of nonce and a new table:
autologin_tokens(object_id int, token_id int, token_hash text, created dom_time_t, last_used dom_time_t) or so.
token_hash: something like sha256(random_nonce, $serverkey)

Creating a new auto-login cookie: "{$oid}:{$token_id}:{$random_nonce}"

Verify: $token_hash=QV("SELECT token_hash FROM autologin_tokens WHERE object_id=$1 AND token_id=$2")
=> hash_equals($token_hash, hash("sha256", $random_nonce . $serverkey))

Renewal: update last_used, optionally rotate random_nonce for that row. "optionally": on every successful login.

password change: delete all autologin tokens of the user.

Simple enough, i think - but i''ll not do it on top of the massive changes in 2026-H1.

One small issue: if an attacker every does a replay attack, the user will notice because he will not be able to auto-login, and will have to enter his password. Which is better than today.