The 100,000+ active install WordPress plugin Custom Permalinks has been phoning home to the developer with information about the websites it is installed on for over two years, despite it being in violation of the rules for the WordPress Plugin Directory to do that without consent.

Two days ago Jaime Martinez posted about that on the support forum for the plugin after finding that it was going on, while debugging an issue with a client’s website. So far the developer hasn’t responded to that and the plugin remains in the plugin directory.

The phone home code is located in the function update_version_details() in the file /admin/class-custom-permalinks-updates.php. That collects up information, including the admin email address for the website and sends it to https://www.custompermalinks.com/plugin-update/:

44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

private function update_version_details() {
	$admin_email = get_bloginfo( 'admin_email' );
	$request_url = 'https://www.custompermalinks.com/plugin-update/';
	$site_name   = get_bloginfo( 'name' );
	$site_url    = get_bloginfo( 'wpurl' );
	$wp_version  = get_bloginfo( 'version' );
 
	$updates = array(
		'action'         => $this->method,
		'admin_email'    => $admin_email,
		'plugin_version' => CUSTOM_PERMALINKS_VERSION,
		'site_name'      => $site_name,
		'site_url'       => $site_url,
		'wp_version'     => $wp_version,
	);
 
	// Performs an HTTP request using the POST method.
	wp_remote_post(
		$request_url,
		array(
			'method' => 'POST',
			'body'   => $updates,
		)
	);
}

That code runs when the plugin is activated, updated, and deactivated.

That violates guideline 7 of the rules for the WordPress plugin directory, “Plugins may not track users without their consent.“:

In the interest of protecting user privacy, plugins may not contact external servers without explicit and authorized consent. This is commonly done via an ‘opt in’ method, requiring registration with a service or a checkbox within the plugin settings. Documentation on how any user data is collected, and used, should be included in the plugin’s readme, preferably with a clearly stated privacy policy.

Some examples of prohibited tracking include:

• Automated collection of user data without explicit confirmation from the user.

There is no consent mechanism for this phoning home.

That functionality was introduced in to the plugin in version 1.6.0, which was released on August 8, 2020. That wasn’t disclosed in the changelog for that version:

• Bugs

  • Undefined index and undefined variable error
  • count(): Parameter must be an array or an object
  • Fix double slash from the permalink form
  • use ‘view_item’ label for previewing custom post types
  • Fix PHP 7.4 issues
  • Fix Yoast Canonical double slash issue
  • Replacing category_link with term_link
  • Bug with WPML and Use directory for default language
  • Fix Static Homepage redirect issue

• Enhancements

  • Improved Gutenberg Support
  • Added compatibility for WPML language switcher
  • Add filter to exclude Custom Permalinks for certain posts (based on Post IDs, template, etc)
  • Optimized Code

What’s Lurking in WordPress Plugins on Your Website?

While WordPress plugins are supposed to go through a security review before they are allowed in to the WordPress Plugin Directory (whether they actually do is another issue), updates don’t receive a review. So WordPress websites are relying on trusting developers and others checking over the code. As can be seen here, developers are not always trustworthy and most plugins are not having their code reviewed.

With what is going on with this plugin, it shouldn’t be too hard to have an automated system that could check if plugins are phoning home in situations including activating, updating, and deactivating the plugin. That is the kind of thing that the team handling the plugin directory should be working on, but the current team is highly undersized, with only four members, and is restricting others from even applying to join the team.

In other situations where it couldn’t be detected easily with an automated method, such code should still be caught during a security review of a plugin. Most WordPress plugins don’t receive security reviews, even one that comes from major WordPress security providers, so having more security reviews would be a big benefit for WordPress websites.