Version 1.3 of the Disable REST API plugin is out now, to support the recent updates to the REST API introduced in WordPress 4.7.

Previous versions of the plugin accessed the available filters which let developers to turn the REST API off like a light switch. These filters have been deprecated in 4.7, which means that while they exist they no longer actually disable the API.

This shift makes a lot of sense from the core team’s point of view. Editing tools in the admin area are going to plan to use the REST API in the future, to improve the admin area experience for editing content. To that end, they don’t want something which easily disables the content endpoints of the REST API.

The new recommendation is to raise an authentication error if you do not wish for endpoints to be accessible, so that’s exactly what the plugin does as of version 1.3. If you are logged into a website as a user, the endpoints will all function as designed. However, if you are an unauthenticated anonymous user who tries to access endpoints of the API (even ones that are typically designated as publicly accessible) you will be greeted with an authentication error when this plugin is installed and activated.

WordPress versions 4.4x, 4.5.x, and 4.6.x will all continue to use the `rest_enabled` filters; but please don’t use this as an excuse to not patch your website. I still strongly recommend everyone keep their websites up to date and running the latest version of core whenever possible.

I will gauging interest in an update to the plugin which would allow administrators to further tighten up access to the REST API based on user role: it is very possible that websites that have basic Subscriber users or custom low-permission users (like websites running WooCommerce, BuddyPress, or numerous other custom applications with user login areas) will still want to disable the REST API for some reason, and currently any site that allows these types of users could still easily be accessed by one of those users.


While the Slider Revolution exploit is, at this point, fairly old news, it seems that not everyone got the memo. In a recent post by Wordfence, they claim that the recent Panama Papers fiasco may have begun by a breach of the Mossack Fonseca web server through this exploit.

The agency where I work applied fixes to all of our client sites as soon as the initial news hit, but I have a college friend who recently inherited a number of WordPress websites at his job. After reading the Wordfence article, he realized he didn’t know if any of his new clients had versions of the plugin that would still be vulnerable. Of course the simple answer is “go update all of your plugins”, but since the plugin is baked into the theme in so many cases (and how many made-by-another-developer sites do you have that are all properly child-themed and easy to update?) he couldn’t simply go to his Plugins page on every site to download the new version.

The exploit itself is quite easy to test for: simply use your browser to navigate to admin-ajax.php with the appropriate parameters, and if the site is running a vulnerable copy of the plugin your browser will automatically download the site’s wp-config file.



What I did to help him out was write a quick Chrome Extension that allowed him to browse to his client sites, click the button, and the extension would attempt to download the `wp-config.php` file from the server. If he got the file, he knew he had a problematic copy of Slider Revolution. If the site responded in any other way, he was likely fine.

The extension was put together in about 15 minutes, and is the first Chrome Extension I’ve written, so it isn’t very fancy. I could have done something rather than try to download the file in the browser, so we could display “success” or “failure” when trying to exploit the site. It also assumes that WordPress lives at the root of the website, since the extension will attempt to access `/wp-admin/` at the root of the domain – if a site has a vulnerable plugin installed but, for example, contains the WordPress installation in the `/wordpress/` directory, this extension will not effectively find the exploitable path.


Click here to download the extension now

I’m distributing the extension in its “unpacked” state, so that people can review it before use. Since the zip file contains a folder with all of the raw files, you will need to enable Developer Mode in Chrome in order to load the extension if you’d like to use it yourself. Click here for instructions on how to load an unpacked extension in Google Chrome

NOTE: Obviously you use this code at your own risk and for your own purposes. You alone are responsible for your own actions. I cannot be held responsible for anything you do with this extension, or the code/information provided on this page.


You may also view the source code of the `manifest.json` and `background.js` files below, which are the only pieces of code in the whole extension. Enjoy!

  "manifest_version": 2,

  "name": "Revolution Slider Checker",
  "description": "This extension will check the current website to see if their Revolution Slider is vulnerable to the known exploit that allows you to download the wp-config.php file",
  "version": "1.0",

  "browser_action": {
    "default_icon": "icon.png",
	"default_title": "Click here to check"
  "background": {
    "scripts": ["background.js"]
  "permissions": [
// More info on the Slider Revolution exploit

chrome.browserAction.onClicked.addListener(function(tab) { 
	var uri = tab.url;
	var origin = uri.match(/^[\w-]+:\/{2,}\[?[\w\.:-]+\]?(?::[0-9]*)?/)[0];		// regex taken from 

	chrome.tabs.update(, {
		url: origin + '/wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php'


This is a bit different from my usual WordPress/PHP posts, but I still wanted to share as a general development exercise and also to hopefully let other people know what I discovered about working with Child’s Play.

Childs Play Logo

I am friends with the couple who runs the Game On Marathon, a 100-hour video gaming marathon which raises money every year for the Child’s Play charity. As part of the festivities when the event is happening, they needed the ability to trigger different giveaways based on when we hit certain milestones in the fundraising effort. There is a C++ script which handles these giveaways, but it needs to be told what dollar amount the event is at and that was game on marathoncurrently being done by hand. Child’s Play has a website widget which displays the info, but there didn’t seem to be a way of easily getting their hands on the donation total at different points in time for the program so they asked if I may be able to help.

At first I tried to scrape the website via remote POST, but that was a bust. Since the Child’s Play widget is driven by a `.js` script include, none of the generated markup was available in the DOM when you hit the page from a remote script. While looking through the js source, however, I found reference to a JSON API endpoint which looked promising. I had initially tried googling for such a thing, but came up empty, so my guess is that this is an API they possibly only mean to use internally / by their own tools.

Continue reading