Slashdot Mirror
Backdoor Found In WordPress Plugin With More Than 200,000 Installations (bleepingcomputer.com)
According to Bleeping Computer, a WordPress plug that goes by the name Display Widgets has been used to install a backdoor on WordPress sites across the internet for the past two and a half months. While the WordPress.org team removed the plugin from the official WordPress Plugins repository, the plugin managed to be installed on more than 200,000 sites at the time of its removal. The good news is that the backdoor code was only found between Display Widgets version 2.6.1 (released June 30) and version 2.6.3 (released September 2), so it's unlikely everyone who installed the plugin is affected. WordPress.org staff members reportedly removed the plugin three times before for similar violations. Bleeping Computer has compiled a history of events in its report, put together with data aggregated from three different investigations by David Law, White Fir Design, and Wordfence. The report adds: The original Display Widgets is a plugin that allowed WordPress site owners to control which, how, and when WordPress widgets appear on their sites. Stephanie Wells of Strategy11 developed the plugin, but after switching her focus to a premium version of the plugin, she decided to sell the open source version to a new developer who would have had the time to cater to its userbase. A month after buying the plugin in May, its new owner released a first new version -- v2.6.0 -- on June 21.
This situation doesn't back up your point at all. Technical considerations about features and what's easy to learn versus hard to learn are remarkably subjective. What's objectively clear is that Sharepoint (a proprietary CMS) doesn't allow users to inspect what it's doing, alter the code, or share improved versions. Any problems with Sharepoint have to be fixed by the proprietor (Microsoft), and a backdoor in Sharepoint may well not be viewed as something that needs to be "fixed" from the proprietor's point of view.
WordPress, by contrast, respects a user's freedom to run, inspect, share, and modify. Site owners can decide how much time and effort they want to put into keeping their WordPress install secure. If they find a problem, improvements can be vetted, shared, and completely understood. The limits of review and improvement are the site owner's to choose and site owners retain the freedom to fully control their site (so long as they host on free software systems). Even bad free software (for any definition of "bad") is better than nonfree software because users have software freedom. Writing one's own code would grant one the freedoms only Microsoft gets with Sharepoint.
It's not fair to WordPress to conflate a WordPress plugin with WordPress itself ("Wordpress is a joke") or being horribly vague about what is so bad about various free CMSes. WordPress can't take responsibility for what others put in their WordPress plugins. They can only delist the malware plugins and describe why users shouldn't run that plugin downloaded from another source.
Finally, your point fails to describe how this particular WordPress plugin is critical to useful WordPress sites. This matters to WordPress' main audience—nontechnical users—who might want to know why they should not want particular functionality the plugin ostensibly delivers, or how to get comparable functionality another way. Lots of users aren't technical and won't know why they shouldn't install a bunch of plugins, or how to vet the plugins they find provide genuinely necessary functionality (including not blindly accepting every upgrade but vetting the changes along the way). I don't like malware either, but it's not fair to conflate software freedom with non-freedom (as if nonfree software was inevitable or just as reasonable a choice, an alternative), or to blame one party (WordPress in this case) for another' choices, and objections are far more useful when they are specific.
Digital Citizen