Hi FD Readers, If you're using cookie-based session storage with any version of the Laravel Framework since 4.1 (inclusive), and you turned encryption off (I can't imagine why anyone would do that, but I've seen some weird setups), you are vulnerable to PHP Object Injection. The story begins here: https://github.com/laravel/framework/blob/253d63a550b4508e56ec0f7536e5e4f302661148/src/Illuminate/Session/SessionManager.php#L34 No matter which driver you select, it calls buildSession(): https://github.com/laravel/framework/blob/253d63a550b4508e56ec0f7536e5e4f302661148/src/Illuminate/Session/SessionManager.php#L173 If encryption is turned off, it creates an instance of the Store class, which contains this gem: https://github.com/laravel/framework/blob/253d63a550b4508e56ec0f7536e5e4f302661148/src/Illuminate/Session/Store.php#L123 /** * Read the session data from the handler. * * @return array */ protected function readFromHandler() { $data = $this->handler->read($this->getId()); if ($data) { $data = @unserialize($this->prepareForUnserialize($data)); if ($data !== false) return $data; } return []; } For the record, prepareForUnserialize() just returns whatever you pass it. If you're using the CookieSessionHandler without encryption, you're allowing the client to arbitrarily change the session contents. While that's bad in and of itself, that Laravel passes this data to unserialize() is even worse. When I informed Taylor Otwell on their Slack chat about this and recommended a fix, this is what he had to say: we will consider it, however, since encryption is on in laravel i wouldn't view it as a security issue I didn't find any exploitable flaws in their encryption implementation. I might look again soon. The takeaway: If any Laravel developers are reading this: If you have foregone server-side session storage, please make sure you have encryption turned on. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com>