Improve remember me cookie expiration in Devise (CVE-2015-8314)

A security bug (CVE-2015-8314) has been reported in Devise’s remember me system.

Devise implements the “Remember me” functionality by using cookies. While this functionality works across multiple devices, Devise ended-up generating the same cookie for all devices. Consequently, if a malicious user was able to steal a remember me cookie, the cookie could be used to gain access to the application indefinitely unless the user changed his password (which may not be a frequent event).

Although all Devise versions are vulnerable to this bug, the bug can only be exploited if the attacker can steal cookies in the first place. Regardless, we recommend all users to upgrade to the latest Devise version.


Devise 3.5.4 has been released with a fix. This release adds a timestamp to the cookie, guaranteeing cookies can be expired on a case-by-case basis instead of an all or nothing approach.

We also have made a patch available for those running on older versions.


We want to thank Alfredo Ramirez ( from VSR for reporting the issue and working with us on a fix.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone
  • Hi, sorry but it’s not clear to me. Even if the user can steal the cookies, why would them be able to access the application indefinitely? If the remember-me cookie is valid for 2 weeks, for example, shouldn’t the cookie become invalid after that even if it is stolen?

  • 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.

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

  • 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.

  • Richard Baptist

    Is there a mailing list for security announcements on the Devise gem? Have you considered posting this in the Ruby security announcements Ruby group?