Cookie security fixes for Plug

Hello everyone,

A vulnerability has been disclosed to Plug. All applications that set cookies based on user input is vulnerable. The vulnerability affects code in the following format:

put_resp_cookie(conn, "username", conn.params["username"])
put_resp_cookie(conn, conn.params["username"], "valid")

In the code above, one of the cookie key or value is set based on user input, which may allow an attacker to set arbitrary headers.

We have released new Plug versions v1.0.6, v1.1.9, v1.2.5 and v1.3.5. If you can’t upgrade immediately, we also include fixes you can directly add to your applications.

  • Versions affected: v1.3.4 and early, v1.2.4 and earlier, v1.1.8 and earlier, v1.0.5 and earlier
  • Versions fixed: v1.3.5+, v1.2.5+, v1.1.9+, v1.0.6+
  • Reporter: Griffin Byatt (@griffinbyatt)


The Plug documentation has always included the following advice in the put_resp_cookie documentation:

The cookie value is not automatically escaped. Therefore, if you want to store values with comma, quotes, etc, you need to explicitly escape them or use a function such as Base.encode64 when writing and Base.decode64 when reading the cookie.

If you are following the advice above, you are safe.

If you can’t upgrade immediately, we recommend encoding and decoding the value, per above, or at least make sure characters such as new lines carriage returns, commas and semi-colons are not present on the cookie value.

For example, instead of:

put_resp_cookie(conn, "username", conn.params["username"])

You may write:

username = conn.params["username"]
if String.contains?(username, ["\r", "\n", ";", ","]), do: raise "no donut for you"
put_resp_cookie(conn, "username", username)

End of life for Plug v1.0.x

We are also announcing the end-of-life support for Plug v1.0.x. If you are running on Plug v1.0, please update to more recent versions. We have updated the README to list all supported versions.


We want to thank Griffin Byatt for reporting this vulnerability.


Awesome work. We’re very grateful that you guys are on top of these!


Is there a plan for Elixir to adopt a security policy where CVEs are filed? Many other languages and frameworks do this. An example of Ember’s security policy (with the steps they follow for CVEs and announcements:

I can’t speak to the broader security policy, but fwiw I’ve been applying for CVEs. They’re just taking forever to be approved :slight_smile: