Hmm, I just realized we used a custom strategy for our own rememberable code which is not affected by this exploit. In our case the cookie is signed and contains the expire_at key. It seems I have created this strategy exactly due to this issue because this is the single comment in the code:

# make sure no permanent hacked cookie could be used:

Actually, I think this was initially created due to another issue regarding expiration handling but when I wrote the new strategy I noticed that the expire_at cookie should be signed.

Oh, I always thought the expire was set in the cookie and signed. Thanks for letting us know, will upgrade immediately!

The 2 weeks is stored in the client, as part of the “Expires” value in the Set-Cookie header. So anyone can strip the Expires from the cookie and continue using it. That’s why we have decided to move the expire date to inside the cookie and sign it, so the server has control over the expires and users will no longer be able to fiddle with it.