We were informed yesterday of a published vulnerability for WordPress 3.0.4, “Stored XSS (via Editor role)”.
This is an invalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. report. (Edit: The exploit has been delisted by the database.)
The dead giveaway was the title: “via Editor role.” In WordPress, users with the role of Editor or Administrator have the ability to post unfiltered HTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.. It has always been like this.
From the Security FAQ on the Codex:
Users with Administrator or Editor privileges are allowed to publish unfiltered HTML in post titles and content. WordPress is, after all, a publishing tool, and people need to be able to include whatever markup they need to communicate. Users with lesser privileges are not allowed to post unfiltered content.
We also issue a warning for security researchers, which wasn’t followed here:
If you are running security tests against WordPress, use a lesser privileged user so that all content is filtered.
How to change this behavior
In multisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site, only super administrators can publish unfiltered HTML. All other users are considered untrusted in this case, as they can be administrators for their own sites. (There is a plugin 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 to restore unfiltered HTML to editors and regular administrators in this case, if you trust those users: Unfiltered MU.)
There’s a constant you can use to disallow unfiltered HTML for everyone, including administrators and super administrators. To disallow unfiltered HTML for all users, you can add this to wp-config.php:
define( 'DISALLOW_UNFILTERED_HTML', true );
Filtered HTML for Editors
To deny unfiltered HTML for Editors, try the Filtered HTML for Editors plugin, which I put together today. The description and FAQ go into much of what was covered here.
How to report security vulnerabilities
Standard practice when finding a security vulnerability is to privately notify the vendor and give them an opportunity to respond and prepare a fix for public release. It’s the concept of responsible disclosure. We’ll always credit responsible disclosure in the release announcement as the person requests, such as with a link to your blog (versus network, site).
For WordPress, suspected vulnerabilities can be privately emailed to our security team at security@wordpress.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/.
Unfortunately, not everyone follows responsible disclosure. In the case of 3.0.4, an exploit published regarding 3.0.3 forced our hand to release the fix we had been privately testing (thanks to responsible disclosure). This can sometimes force our hand in very bad ways — the fixes included in 3.0.4 were very complicated and involved more than a hundred hours of work from more than a dozen individuals. Had we rushed a release due to a public announcement, we might have missed something.
Not following responsible disclosure also prevents us from responding to invalid reports. Unfiltered HTML results in false reports every so often. The fact that this was published as an exploit, without any confirmation or notification, only contributes to FUD and perception issues.
The status of WordPress 3.0.4
This all said, there are currently no known vulnerabilities for WordPress 3.0.4. I’ll go knock on wood now.
#security
