As patio11 mentioned, moving off the CookieStore is a step in the right direction, with the understanding of course that you guard whatever you move to with your life. That means the db with the ActiveRecord store, or memcached if you're putting it in the cache store with the cache set to memcached. With memcached, be careful not to leave the port open to the internet if you're managing it on your own (it's designed to be used inside a trusted network, just like redis).

In theory, an additional precaution one could take: change the default session serializer to `JSON`. By using `JSON` instead of `Marshal`, you're limited to storing strings, hashes and arrays in the session, but that's a good thing. The remote code execution vulnerability takes advantage of `Marshal` deserializing the session and loading objects deep within the Rails process in order to run arbitrary code. Take away that ability by using `JSON` instead of `Marshal` and you should no longer have to worry about this particular attack vector.

After a brief spelunk of the Rails codebase (and not getting very far, my laptop bricked itself today) there doesn't seem to be an easy way to do this, apart from finding the instance of `ActiveSupport::MessageVerifier` in your rails process and then running something like `verifier.instance_variable_set(:@serializer, JSON)`.