TokenBasedRememberMeServices2.makeTokenSignature() returns the literal string "no-prop" when UserSeedProperty is null, completely bypassing the HMAC signature computation. An attacker can forge a remember-me cookie for any user by setting the signature field to "no-prop".

Before (vulnerable):

if (userSeedProperty == null) {
    return "no-prop"; // predictable, no secret involved
}
userSeed = userSeedProperty.getSeed();

After (fixed):

if (userSeedProperty == null) {
    userSeed = "no-prop";
} else {
    userSeed = userSeedProperty.getSeed();
}
// Falls through to MAC.mac(token) — HMAC always computed with server secret

This is consistent with the DISABLE_USER_SEED path which uses "no-seed" as the seed but still computes the HMAC.

Changes

• TokenBasedRememberMeServices2.java: Replace return "no-prop" with userSeed = "no-prop" so the HMAC is always computed with the server's secret key
• TokenBasedRememberMeServices2Test.java: Add regression tests verifying forged cookies with "no-prop" signature are rejected and that makeTokenSignature never returns a literal fallback

Attack vector

Craft cookie: Base64("admin:<future_ts>:no-prop") → signature matches when UserSeedProperty is null (extension filtered out, startup race, legacy user config) → authenticated as target user.

CVSS 9.8 — network-exploitable, no auth required, full compromise of any account.

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.