Please don’t ‘test’ submitting other people’s plugins.

tl;dr: Never test vulnerabilities on someone else’s live site without their permission.

By now, a lot of you have read the post about the so-called “WordPress Plugin Confusion” whereby a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party hosted on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ can ‘override’ a plugin not hosted here, by using the same name/permalink. Someone even made a CVE for it.

Please stop ‘testing’ this vulnerability with us.

This is not a new issue by any means. Heck, this has been something people report on now and then for years. In the past, the plugin team coordinated a release of a plugin to intentionally do that and protect users from a significantly dangerous plugin. We’ve locked out permalinks to prevent abuse and so on.

Sadly, the post conflated a couple of issues, which have to do with social engineering and a misunderstanding of why we have those permalink-checks for trademarks. Also it’s entirely incorrect with this one claim:

and the whole approval process is automated

This could not be further from the truth. All new plugins submitted go through human review. When you submit a plugin, somebody reads your plugin code, your submitted slug and name, checks on the history of the plugin, checks that the developer isn’t a returned banned user, etc. The process is by no means “automated” and while it has some automated pre-flight checks, they’re really there to weed out things that would end with a pended review, to make the process faster for everyone. While we have some tools we run, they don’t actually approve or reject anything, they’re just fancy code-sniffers, customized to look for specific patterns or known bad behavior, outside of the overall quality like PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS. (you are using that, right?). Submitting things to test out what you think is an “automated” system is wasting the time of our volunteers and reviewers.

See, that trademark ‘blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.’ isn’t actually there to protect trademarks for the owners. We have them to make our life easier and to protect you, the developers, from making some pretty common mistakes. Just for an example, we block ‘akismet’ not because we were asked to by Automattic, but because over 50 people a year tried to submit a copy of Akismet instead of uploading it to their own site.

As the post (properly) notes, you can’t submit a plugin with a permalink that’s already in use, be it on WordPress.org or if it has a notable user-base outside of WordPress.org. Even if a name gets by those checks, the review team can see if the permalink is being used and by (roughly) how many people. That’s a large part of why we have humans checking these things. A human can look at an email and a plugin and check for proper ownership.

By the way, as a number of people have complained about, this is why we require official plugins to be owned by demonstrably official accounts (like with an email address that uses the right domain, and so on). It’s not just to prevent trademark abuse, it’s to ensure that kind of thing is less likely to happen.

Now. Do you need to test this? No. All you’re doing is making things more stressful and more likely to be missed, which doesn’t solve a problem. Do you need to add your trademark to the blocked list? Again, no. Unless it’s being actively abused, or there’s a high-risk situation that it might be, it’s just adding more work for a low (to negligible) risk in the first place.

How DO you protect your own, non-org hosted plugins, from this?

Use the UPDATE URI flag.

We check for it on .org, and won’t allow you in with it (since… why?) but for plugins we don’t host, well that’s literally why it exists 🙂 Use it. Love it. But please, remember the first step in ethical hacking is never trying out a vulnerability on someone else’s site without their permission.

#reminder, #security, #trademarks