Administrate Vulnerability Disclosure

Jason Yeo By Jason Yeo
March 31, 2016

Last week, I found a CSRF vulnerability in the Administrate gem. The controllers that are generated by the gem do not enforce CSRF protection. As we saw in the previous post, the CSRF protection mechanism in Rails can fail you if you are not careful in ensuring that your callbacks are idempotent to prevent session memoization. In addition, as Rails developers we don't simply work with our own application. We typically include a bunch of gems. You might have done all that you need to protect your own application but if a gem that you're using is vulnerable, your application might be vulnerable too.

Lets take a detailed look at the vulnerability and see how it was fixed in the Administrate gem.


The controllers generated by Administrate inherit from Admin::ApplicationController, which in turns inherits from Administrate::ApplicationController. This particular controller in administrate, which is a direct subclass of Rails' ActionController::Base, does not enforce CSRF protection and is therefore vulnerable to CSRF attacks. Also, none of these controllers in the class hierarchy call protect_with_forgery to enforce CSRF token checks, therefore any controller that inherits from Administrate::ApplicationController or Admin::ApplicationController is vulnerable to CSRF attacks. That is, if you're using version 0.1.4 and below of Administrate, your administrative interfaces are vulnerable to CSRF attacks.


Since houndci is using Administrate to generate its administrative interfaces, I will use a local instance of the hound server as my target. The houndci app has an administrative controller named BulkCustomersController that inherits from Admin::ApplicationController. None of these controllers call protect_from_forgery, thus actions in this controller do not check for the authenticity of CSRF tokens.

To simulate a forged request that is sent from outside of houndci on behalf of the authenticated administrator, I shall use curl and pass it the administrator's cookie like this.

curl -b$COOKIE --data "_method=delete""http://localhost:5000/admin/bulk_customers/1

This curl request calls the destroy action on the BulkCustomersController and removes the first record from the database. We can verify that this happens without CSRF verification by looking at the logs:

Started DELETE "/admin/bulk_customers/1"for127.0.0.1 at 2016-03-2315:06:01 +0800
Processing by Admin::BulkCustomersController#destroy as */*
  Parameters: {"id"=>"1"}
  User Load (1.8ms)  SELECT  "users".* FROM "users" WHERE "users"."remember_token" = $1 LIMIT 1[["remember_token", "7d27248c1d84250a436c74ed3296bb6acdbec2db"]]
  BulkCustomer Load (0.3ms)  SELECT  "bulk_customers".* FROM "bulk_customers" WHERE "bulk_customers"."id" = $1 LIMIT 1[["id", 1]]
   (0.1ms)  BEGIN
  SQL (0.2ms)  DELETE FROM "bulk_customers" WHERE "bulk_customers"."id" = $1[["id", 1]]
   (1.2ms)  COMMIT
Redirected to http://localhost:5000/admin/bulk_customers
Completed 302 Found in8ms (ActiveRecord: 3.6ms)

If CSRF verification is turned on, this request will be denied and an exception will be thrown:

Started DELETE "/admin/bulk_customers/1"for127.0.0.1at2016-03-2315:13:30 +0800
Processing by Admin::BulkCustomersController#destroy as */*
  Parameters: {"id"=>"1"}
Can't verify CSRF token authenticity
Completed 422 Unprocessable Entity in1ms (ActiveRecord: 0.0ms)


After I have determined that Administrate and the applications that use it are vulnerable, I contacted security ^ to notify them of the vulnerability. They were prompt in fixing the vulnerability and today they released version 0.1.5 of the administrate gem that enables protect_from_forgery.


  • 2016-03-29 I contacted thoughtbot regarding the CSRF vulnerability.
  • 2016-03-29 Mike Burns from thoughtbot acknowledged the email and they went on to investigate it.
  • 2016-04-02 Administrate was fixed by Tute Costa.
  • 2016-04-02 They also requested for a CVE and CVE-2016-3098 was assigned.
  • 2016-04-02 Thoughtbot released version 0.1.5, which contains the fix.
  • 2016-04-02 Shortly after, Hound was upgraded to use the fixed version of Administrate

The Fix

The issue was fixed by inserting the protect_from_forgery with: :exception call into Administrate's ApplicationController.


Details about the vulnerability can also be found in our catalog at this link. In other words, if you're a SRC:CLR customer, you are already protected.

Jason is a software engineer at Veracode working on SourceClear's Agent team.