Make WordPress Core

Tagged: security Toggle Comment Threads | Keyboard Shortcuts

  • Matt Mullenweg 5:32 pm on January 9, 2017 Permalink |
    Tags: security   

    Aaron Campbell Leading Security 

    @aaroncampbell is now the new lead of security triage and resolution for the WordPress project, also known as the Security Czar. Many thanks to Nikolay Bachiyski for kicking this role off and getting a lot of the infrastructure we use in place. This is also a good time to thank the dozens of volunteers who participate in the security group, and the researchers and reporters who bring issues to our attention.

  • voldemortensen 10:37 pm on January 6, 2017 Permalink |
    Tags: , , , , security   

    4.7.1 Release Candidate 

    A Release Candidate for WordPress 4.7.1 is now available. This security and maintenance release fixes 62 issues reported against 4.7 and is scheduled for final release on Wednesday, January 11, 2017. Note this does not address a number of other issues, which are slated for a 4.7.2 release.

    Thus far WordPress 4.7 has been downloaded over 9 million times since its release on December 6, 2016. Please help us by testing this release candidate to ensure 4.7.1 fixes the reported issues and doesn’t introduce any new ones. As always, the entire WordPress project is grateful to security reporters for practicing responsible disclosure.

    PHPMailer Update

    Last month a security vulnerability (CVE 20016-10033) in the PHPMailer library was made public. WordPress uses this library as the basis for its email functionality. The Security Team has spent some time analysing this vulnerability, and how it applies to WordPress. This vulnerability does not appear to be directly exploitable in WordPress Core, or any major plugins in the plugin directory. The wp_mail() function, which WordPress Core and most plugins use for sending email, blocks this vulnerability from being exploited.

    All Changes

    Here’s a list of all closed tickets, sorted by component:


    • #39132 –¬†WP 4.7, object-cache.php breaks the site if APC is not enabled in php

    Build/Test Tools

    • #39327 –¬†Database connection errors in unit tests on 4.7

    Bundled Theme

    • #39138 –¬†wordpress 4.7 default theme does not get installed when upgrading
    • #39272 –¬†Twenty Seventeen: Incorrect $content_width
    • #39302 –¬†Twenty Seventeen: Featured image not displayed on single template
    • #39335 –¬†Twenty Seventeen: customize-controls.js incorrectly assumes theme_options section is always present
    • #39109 –¬†Twenty Seventeen: starter content array needs a filter
    • #39489 –¬†Twenty Seventeen: Bump version and update changelog


    • #37982 –¬†4.6.1 Breaks apostrophes in titles and utf-8 characters


    • #39280 –¬†comment permalink wrong in WordPress 4.7
    • #39380 –¬†wp_update_comment can cause database error with new filter


    • #39009 –¬†Customizer: the preview UI language should be the user language
    • #39098 –¬†Customize: Clicking on child elements of preview links fails to abort navigation to non-previewable links
    • #39100 –¬†Customize: Edit shortcuts do not work if page hasn’t been saved and published
    • #39101 –¬†Customize: edit shortcuts for custom menu widgets do not work
    • #39102 –¬†Customize: Shift-click on placeholder nav menu items fails to focus on the nav menu item control
    • #39103 –¬†Customize: menus aren’t deleted
    • #39104 –¬†Customize: starter content home menu item needs to be a link, not a page
    • #39125 –¬†Customize: Video Header YouTube field has issues when whitespace is inserted at beginning or end of URL
    • #39134 –¬†Customize: custom CSS textarea is scrolled to top when pressing tab
    • #39145 –¬†custom-background URL escaped
    • #39175 –¬†Customizer assumes url is passed with replaceState and pushState
    • #39194 –¬†Invalid parameters in Custom CSS and Changeset queries
    • #39198 –¬†Customize: Apostrophes in custom CSS cause false positives for validation errors
    • #39227 –¬†Changeset parameter not generated
    • #39259 –¬†‘custom_css_post_id’ theme mod of `-1` doesn’t prevent queries
    • #39270 –¬†Use a higher priority on wp_head for inline custom CSS
    • #39349 –¬†Customizer (mobile preview) site title extra padding
    • #39444 –¬†Text Decoration Underline removes on hover in Customizer


    • #39276 –¬†Link Editor bug – target=”_blank” not removed
    • #39313 –¬†Add New button not disappearing in Distraction-free Writing mode
    • #39368 –¬†.page-template-default body class in editor doesn’t appear in initial post/page load.

    External Libraries

    • #37210 –¬†Update PHPMailer to 5.2.21


    • #39066 –¬†`fetch_feed()` changes REST API response `Content-Type`
    • #39141 –¬†RSS feeds have incorrect lastBuildDate when using alternate languages


    • #39148 –¬†Correct concatenated dynamic hooks
    • #39433 –¬†Update copyright year in license.txt


    • #37839 –¬†wp_remote_get sometimes mutilates the response body
    • #37991 –¬†fsockopen logic bug
    • #37992 –¬†fsockopen hard codes port 443 when http scheme used
    • #38070 –¬†RegEx to remove double slashes affects query strings as well.
    • #38226 –¬†“cURL error 23: Failed writing body” when updating plugins or themes
    • #38232 –¬†Setting `sslverify` to false still validates the hostname


    • #39195 –¬†Undefined index: extension in class-wp-image-editor-imagick.php on line 152
    • #39231 –¬†Allow the pdf fallback_intermediate_image_sizes filter to process add_image_size() sizes.
    • #39250 –¬†Undefinded Variable in Media-Modal

    Posts, Post Types

    • #39211 –¬†is_page_template could return true on terms


    • #38700 –¬†REST API: Cannot send an empty or no-op comment update
    • #38977 –¬†REST API: `password` is incorrectly included in arguments to get a media item
    • #39010 –¬†REST API: Treat null and other falsy values like `false` in ‘rest_allow_anonymous_comments’
    • #39042 –¬†REST API: Allow sanitization_callback to be set to null to bypass `rest_parse_request_arg()`
    • #39070 –¬†WP-API JS client can’t use getCategories for models returned by collections
    • #39092 –¬†REST API: Add support for filename search in media endpoint
    • #39150 –¬†Empty JSON Payload Causes rest_invalid_json
    • #39293 –¬†WordPress REST API warnings
    • #39300 –¬†REST API Terms Controller Dynamic Filter Bug
    • #39314 –¬†WP-API Backbone Client: buildModelGetter fails to reject deferred on fetch error


    • #39215 –¬†Support for string $args in wp_get_object_terms() broken in 4.7
    • #39328 –¬†Adding terms without AJAX strips “taxonomy” query arg


    • #39246 –¬†Theme deletion has a JS error that prevents multiple themes from being deleted.


    • #39047 –¬†Installer tries to create nonce before options table exists
    • #39057 –¬†FTP credentials form doesn’t display the SSH2 fields on the Updates screen


    • Angelika Reisiger 12:26 pm on January 7, 2017 Permalink | Log in to Reply

      thanks to the complete core team for this release and to you @voldemortensen for the detailed release announcement.
      One point to mention: a security release only for test purposes sounds odd.

      I know (or I believe to know), that the security fix concerns only the updated PHPMailer_library. So it is no “urgent” fix, since WP itself is not directly exploitable in WP Core and major plugins.

      However, a _security release for testing_ could confuse less informed WordPress users.
      Just my2Cents.

      Keep up the great work and have a nice weekend.

  • Joe Hoyle 1:32 pm on May 6, 2016 Permalink
    Tags: imagick, security   

    ImageMagick Vulnerability Information 

    A few days ago an ImageMagick vulnerability was disclosed dubbed “ImageTragick” that affects WordPress websites whose host has ImageMagick installed. If you control your own hosting for your WordPress site, you should look to implement the following fix(es) immediately.

    The full effect of this issue is still unfolding and it’s not clear what the full impact will be; however, there are mitigation steps that should keep you safe with the known exploits so far. This vulnerability is already being exploited in the wild, and proof of concepts are being published.

    How is WordPress affected?

    Uploaded images to the WordPress admin that contain malicious data can perform a number of exploits via the underlying ImageMagick library. Uploads are available to all users who have the upload_files capability. By default that’s authors, editors, and administrators; contributors, subscribers, and anonymous users do not have that capability. This issue is still developing; however, it should be noted that if un-patched, this exploit allows for Remote Code Execution (RCE).

    What steps is the WordPress Core Team taking to mitigate this?

    The exploit is in the Imagick PHP extension, not WordPress itself (or any library that is shipped with WordPress). The WordPress Security Team is exploring ways to help mitigate this exploit due to the wide usage of ImageMagick in the WordPress ecosystem; however, this exploit is best handled at the hosting level (instructions below).

    How do I know if my site is vulnerable?

    If you do not control your own hosting environment then it’s likely that your host is taking steps to fix the issue. We recommend you reach out to your hosting provider to verify they are handling the “ImageTragick (CVE-2016-3714, CVE-2016-3718 and CVE-2016-3715)” exploit.

    Only WordPress sites that have the PHP Imagick extension installed are vulnerable to this exploit. If you don’t know if your server has this PHP extension, there are a few ways to identify this:

    1. Inspect the output of the phpinfo() function for “Imagick”.
    2. Run php -m | grep imagick on the command line.

    How do I patch the vulnerability?

    Currently the best known fix is to add a policy.xml file to your ImageMagick installation to limit the delegates that ImageMagick will use. Due to the ongoing nature of this issue, we recommend you refer to and follow https://imagetragick.com/ for instructions on how to handle the problem.

    ImageMagick 6.9.3-10

    ImageMagick released an update on 2016-05-03 to fix this issue; however, there are questions around whether this update provides a complete fix. At the time of writing it should be presumed version 6.9.3-10 does not fix the issues completely and you should take steps to patch the issue via the policy.xml file.

    Further reading

    More information and updates on this exploit can be found at https://imagetragick.com/. We recommend you keep an eye out for updates to this issue, as the full extent of problem is still being discovered.

    Documentation on the policy.xml file can be found at https://www.imagemagick.org/script/resources.php.

  • Ryan McCue 7:29 am on August 14, 2015 Permalink
    Tags: , , , security,   

    WP REST API: Versions 1.2.3 (Security Release) and 2.0 Beta 4 

    First and foremost: version 1.2.3 of the REST API is now available. Download it from the plugin repository or from GitHub. This is a security release affecting sites running version 1.2 or a 2.0 beta releases.

    Security Release

    Recently, we were alerted to a potential XSS vulnerability introduced in version 1.2 of the API related to the JSONP support. This vulnerability also existed in version 2.0. Thanks to Alex Concha (@xknown) for reporting this issue to the team responsibly.

    This release was coordinated by the REST API team and the WordPress core security team. The security team is pushing automatic updates for version 1.2.3, but do not wait or rely on the automatic update process. We recommend sites or plugins that are using either v1.2.x or 2.0 beta releases update the plugin immediately.

    If you’d prefer not to upgrade, you can instead disable JSONP support through a filter. For version 1:

    add_filter( 'json_jsonp_enabled', '__return_false' );

    To disable JSONP on version 2:

    add_filter( 'rest_jsonp_enabled', '__return_false' );

    If you have a question about the security release, you can find the team in #core-restapi on WordPress.org Slack, or you can privately message @rachelbaker, @rmccue, @danielbachhuber, or @joehoyle.

    Version 2.0 Beta 4

    Alongside the security release for version 1.2, we’re also releasing the latest beta for version 2.0: 2.0 Beta 4 “See My Vest”. You can download this from the plugin repository or from GitHub.

    This beta release includes the security fix from version 1.2.3, so we recommend everyone running a version 2 beta update immediately to fix the issue.

    As well as the security release, this beta also includes a bunch of other changes. Here’s some highlights:

    • Show public user information through the user controller.

      In WordPress as of r32683 (scheduled for 4.3), WP_User_Query now has support for getting users with published posts. To match current behaviour in WordPress themes and feeds, we now expose this public user information. This includes the avatar, description, user ID, custom URL, display name, and URL, for users who have published at least one post on the site. This information is available to all clients; other fields and data for all users are still only available when authenticated.

    • Send schema in OPTIONS requests and index.

      Rather than using separate /schema endpoints, the schema for items is now available through an OPTIONS request to the route. This means that full documentation is now available for endpoints through an OPTIONS request; this includes available methods, what data you can pass to the endpoint, and the data you’ll get back.

      ‚ö†ÔłŹ This breaks backwards compatibility for clients relying on schemas being at their own routes. These clients should instead send OPTIONS requests.

    • Update JavaScript API for version 2.

      Our fantastic JavaScript API from version 1 is now available for version 2, refreshed with the latest and greatest changes. Thanks to Taylor Lovett (@tlovett1), K. Adam White (@kadamwhite) and Nathan Rice (@nathanrice).

    • Embed links inside items in a collection.

      Previously when fetching a collection of items, you only received the items themselves. No longer! You can now request a collection with embeds enabled (try /wp/v2/posts?_embed).

    • Move /posts WP_Query vars back to filter param.

      In version 1, we had internal WP_Query vars available via filter (e.g. filter[s]=search+term). For our first betas of version 2, we tried something different and exposed these directly on the endpoint. The experiment has now concluded; we didn’t like this that much, so filter is back.

      ‚ö†ÔłŹ This breaks backwards compatibility for users using WP Query vars. Simply change your x=y parameter to filter[x]=y.

    • Respect rest_base for taxonomies.

      ‚ö†ÔłŹ This breaks backwards compatibility by changing the /wp/v2/posts/{id}/terms/post_tag endpoint to /wp/v2/posts/{id}/tag.

    As always, we have a detailed changelog as well as the full set of changes if you’re interested.

    (Note that while this version 2 beta breaks backwards compatibility, the 1.2.3 security release does not break compatibility with the 1.2 branch.)

    This release had 11 contributors, and we’d like to thank each and every one of them:

    $ git shortlog 2.0-beta3...2.0-beta4 --summary
         1   Daniel Bachhuber
        11   Daniel Jalkut
         1   Fredrik Forsmo
         1   Jared Cobb
         3   Jay Dolan
        26   Joe Hoyle
        10   Josh Pollock
        25   Rachel Baker
        50   Ryan McCue
        24   Stephen Edgar
         8   Taylor Lovett

    Thank you again to all of our beta testers, and thanks to everyone who let us know how you’re using the API. We’re taking note of all of your feedback, and you might see some further changes related to that in coming releases.

    • Ahmad Awais 8:18 am on August 14, 2015 Permalink | Log in to Reply

      Hey, Ryan!
      Did you change the folder name or main file name in WP REST API 1.2.3 since I am using 1.2.2 and I didn’t get any update notification, which is weird.

      • Ryan McCue 10:10 pm on August 14, 2015 Permalink | Log in to Reply

        The patch in 1.2.3 is minimal and didn’t change the filename. If you’re using the API from GitHub, your folder might accidentally be called WP-API, whereas it should be json-rest-api to match the repo.

    • CotswoldPhoto 9:40 am on August 14, 2015 Permalink | Log in to Reply

      Great work team REST API. I really hope that this makes it into core for 4.4.

    • Rachel Baker 12:56 pm on August 14, 2015 Permalink | Log in to Reply

      Oh, please won’t you see my vest! ūüé∂

  • Scott Taylor 5:49 pm on June 20, 2014 Permalink
    Tags: , , , , security   

    like_escape() is Deprecated in WordPress 4.0 

    @miqrogroove has written a blog post on his personal blog explaining why like_escape() has been deprecated in WordPress 4.0. It has been reposted below.

    Plugin authors and website developers who work with WordPress database queries should notice an important change coming in WordPress 4.0.

    The function like_escape() is no longer used in WordPress core code. It is still available as a deprecated function, so it still works in any existing plugins that rely on it. However, a new and different function is available that should be used in all new code.

    Deprecated means that anyone using code that calls like_escape() with WP_DEBUG enabled will see an error message. If WP_DEBUG_LOG is also enabled, the error message will appear in the /wp-content/debug.log file.

    Let’s look at an example of core code where I removed like_escape() and implemented the new function $wpdb->esc_like().

    3.9 Old Style

    $search_orderby_s = like_escape( esc_sql( $q['s'] ) );
    $search_orderby .= "WHEN $wpdb->posts.post_title LIKE '%{$search_orderby_s}%' THEN 1 ";

    What did this do? It was an old snippet from /wp-includes/query.php that set up a search for post titles. The input $q['s'] was escaped using two functions before it was added to the post_title LIKE expression. Now let’s see how I replaced that snippet in the next version.

    4.0 New Style

    $like = '%' . $wpdb->esc_like( $q['s'] ) . '%';
    $search_orderby .= $wpdb->prepare( "WHEN $wpdb->posts.post_title LIKE %s THEN 1 ", $like );

    There are two important differences to notice.

    • I changed the like_escape() call to $wpdb->esc_like().
    • I changed the esc_sql() call to $wpdb->prepare().

    The second change is important because esc_sql() is not secure if it is called before, or inside, the call to the new function $wpdb->esc_like(). By relying on the preferred style of the function prepare(), I can easily see that each instance of $wpdb->esc_like() will run first instead of last.

    4.0 Alternative Style

    Here is something that still works, but I avoided using it. Notice the old query is unchanged. It is critically important to call the two escaping functions in the correct order when using $wpdb->esc_like().

    $search_orderby_s = esc_sql( $wpdb->esc_like( $q['s'] ) ); // This is the correct order.
    $search_orderby .= "WHEN $wpdb->posts.post_title LIKE '%{$search_orderby_s}%' THEN 1 ";

    How Should I Get My Code Ready for 4.0?

    The nice thing about deprecated functions is that you can still use them and they don’t change. Your existing code should work fine.

    When you write new code, remember that using $wpdb->esc_like() is not compatible with WordPress 3.9. This should be avoided if you need compatibility with old versions. When you are ready to adopt 4.0 as your minimum version, consider using the new function.

    If you have a specific need for the new function in old versions of WordPress, I suggest copying the new function into your plugin under a different name. This would be the simplest solution, but rarely necessary.

    Why Did like_escape() Change to $wpdb->esc_like()?

    There were several problems with the old function that could not be fixed.

    • Documentation said the function‚Äôs output was safe to use in SQL queries. That was not correct.
    • The function‚Äôs output was not fully compatible with LIKE expressions in MySQL.
    • The function had been used many different ways in core code, some of which were incompatible with the desired output.
    • Changing the old function instead of creating a new one would have caused many security problems in plugins.
    • The function was related to $wpdb because of its MySQL syntax, which does not work on other databases.

    Is There a Security Problem with like_escape()?

    The old function like_escape() was not intended to be used in any security sensitive context. There are no security problems when it is used correctly.

    With that said, I am concerned that plugin authors frequently confused the old function like_escape() with esc_sql(), which was used for security. The documentation for like_escape() was misleading and very confusing about this point.

    Just remember, like_escape() does not provide any security for your database!

    So What Does $wpdb->esc_like() Do Anyway?

    Whenever user input or other raw data are copied into a WordPress query, the data must be escaped using $wpdb->prepare() or esc_sql(). This prevents certain characters, such as quotes, from getting confused with SQL commands.

    In a LIKE expression, there are additional special characters that are used as wildcards to search for partial matches in the database. Those wildcard characters have to be escaped from the user input so that they are not confused with the wildcards added by the programmer.

    Before adding user input to this type of search query, $wpdb->esc_like() should be called for compatibility, and then $wpdb->prepare() must be called for security, in that order.

    How to Use $wpdb in Functions

    It is very rare to use $wpdb->esc_like() without also running a query. But just in case you want to …

    function my_search( $input ) {
        global $wpdb;
        $escaped = $wpdb->esc_like( $input );

    … remember to reference $wpdb as a global variable.

    • Mike Schinkel 6:08 pm on June 20, 2014 Permalink | Log in to Reply

      Nice writeup.

      Note there’s a code type in your “40 Alternate Style”: $wpdb->esc_like( $q[‘s’] )

    • JasWSInc 6:09 pm on June 20, 2014 Permalink | Log in to Reply

      I hope we will see an `esc_like()` function to serve as a wrapper for this wpdb class member like all the others (i.e. `esc_sql()`, `esc_attr()`, `esc_html()`, etc). Not a big deal to call it through the class instance, but it would be nice to have the function also; i.e. `function esc_like()`

    • Michael Adams (mdawaffe) 8:30 pm on June 25, 2014 Permalink | Log in to Reply


      $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %L", "Something%" ) would be cool.

      • Robert Chapin 11:38 am on July 9, 2014 Permalink | Log in to Reply

        We wouldn’t be able to interpret the % chars in a meaningful way with that syntax. By running $wpdb->esc_like() first, you still have the power to add % chars that are not escaped before preparing the query.

        • Michael Adams (mdawaffe) 9:37 pm on July 14, 2014 Permalink | Log in to Reply

          You’re right. My example was bad. Thanks.

          The following would work:

          $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %L%%", "Something" )

          Which would be the same as:

          $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %s%%", $wpdb->esc_like( "Something" ) )

          Which is the same as:

          $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %s", $wpdb->esc_like( "Something" ) . "%" )

    • rajlaksh 5:36 pm on August 9, 2014 Permalink | Log in to Reply

      Thanks for This Valuable Post.

      But i found it little difficult so i swift $WPDB to MySqli.

      MySqli easier than $WPDB. ūüôā

  • Andrew Nacin 4:52 pm on June 21, 2013 Permalink
    Tags: security, swfupload   

    Announcing a secure SWFUpload fork 

    The WordPress security team has officially forked the long-abandoned SWFUpload project and is strongly encouraging all web developers who use SWFUpload to update.

    We strongly suggest you do not use SWFUpload. But if you must, use this fork. You can find it on GitHub at github.com/wordpress/secure-swfupload.

    WordPress does not use SWFUpload, but we continue to include it in WordPress core for plugins that have yet to be updated to use Plupload, our upload library of choice. Plupload is written and actively maintained by Moxiecode, the developers of TinyMCE.

    We do not condone the use of abandonware. We only wish to make the web a better place by ensuring that developers have access to a secure version of SWFUpload, when the only alternative may be to use insecure code.

    This is a fork of SWFUpload and includes cross-site scripting fixes that have been reported by Szymon Gruszecki (CVE-2013-2205 and CVE-2012-2399), and Neal Poole and Nathan Partlan (CVE-2012-3414). It also includes fixes from Yelp’s engineering team for CVE-2012-2399.

    WordPress 3.5.2, released moments ago, includes fixes for CVE-2013-2205 and CVE-2012-2399. WordPress 3.3.2 (2012-04-20) included a fix for CVE-2012-3414 and an incomplete fix for CVE-2012-2399.

    If you think you have found a vulnerability in this fork of SWFUpload, we appreciate your help in disclosing it to us responsibly. Please email reports of security vulnerabilities to swfupload-security AT wordpress.org. These reports will be reviewed by the WordPress security team and by security researchers contributing to this project, including Neal and Szymon.

  • Andrew Nacin 8:00 pm on December 31, 2010 Permalink
    Tags: security   

    The published exploit for WordPress 3.0.4 isn’t accurate 

    We were informed yesterday of a published vulnerability for WordPress 3.0.4, “Stored XSS (via Editor role)”.

    This is an 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. 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, 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 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.

    For WordPress, suspected vulnerabilities can be privately emailed to our security team at security@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.

    • Andrew Nacin 9:48 pm on December 31, 2010 Permalink | Log in to Reply

      The report is being removed from the exploit DB. I’ve updated the post.

    • Travis Miller 4:15 pm on January 3, 2011 Permalink | Log in to Reply

      Hi Andrew –

      Thanks for the update. I’ve been trying to research this security patch, and a few things still aren’t clear.

      1. Do I need to upgrade my 3.x sites to 3.0.4, or not? This post seems to be saying that the vulnerability that 3.0.4 supposedly fixes did not exist in the first place. Am I understanding that correctly?

      2. If there *is* a vulnerability, does it exist in the 2.x branch as well, or only 3.x?

      3. If the vulnerability does exist in 2.x, is there an official or quasi-official patch for that branch, or am I stuck doing a major version upgrade from 2.x to 3.x?

      Sorry if this isn’t the best venue for this question – comments are closed on the post on the main WordPress blog, so I can’t ask there. I’m sure others in the WordPress community would appreciate some clarification on these questions.

      • Jane Wells 4:31 pm on January 3, 2011 Permalink | Log in to Reply

        Hi Travis. I think you misunderstood Andrew’s post. After 3.0.4 came out, a website started reporting that there was a new vulnerability. That is the one that is invalid. Yes, you should update to 3.0.4. The 2.x versions are no longer supported, so please please update to the most current version. If you are still running 2.x versions, you are likely facing multiple vulnerabilities.

    • Travis Miller 6:58 pm on January 3, 2011 Permalink | Log in to Reply

      Thanks, Jane. You’re correct; I misunderstood the post. Thanks for the info.

  • Mark Jaquith 4:54 pm on May 18, 2009 Permalink
    Tags: , , esc_url_raw, security   

    Deprecated clean_url() in favor of esc_u… 

    Deprecated clean_url() in favor of esc_url(), and deprecated sanitize_url() in favor of esc_url_raw().

  • Mark Jaquith 3:13 pm on May 18, 2009 Permalink
    Tags: , , security   

    Deprecated wp_specialchars() in favor of… 

    Deprecated wp_specialchars() in favor of esc_html() (also: esc_html__() and esc_html_e()). Using wp_specialchars() with more than one param works for backwards compat. Also, esc_html() (or wp_specialchars() with one param) escapes quotes, just like esc_attr(). This buys security for plugin authors who were mistakenly using a one-param wp_specialchars() call in an HTML attribute. See this wp-hackers message for more detail.

  • Mark Jaquith 9:16 pm on May 5, 2009 Permalink
    Tags: , , security   

    Standardizing and shortening the WP secu… 

    Standardizing and shortening the WP security escaping functions.

    attribute_escape() is now esc_attr()

    Additionally, you can do attribute escaping and translation in one go. Just add the translation function to the end. Like so:

    • esc_attr__() — translate and return, attribute-escaped.
    • esc_attr_e() — translate and echo, attribute-escaped.

    Will be following up with esc_html (with __() and _e() variants), esc_url(), maybe some more. Will be nice, short, predictable, and allow you do translate/escape in one go without a lot of nested parenthesis.

    • Viper007Bond 5:04 am on May 6, 2009 Permalink | Log in to Reply

      An esc_js() or whatnot might be useful to (i.e. an improved js_escape() (see #7648).

      • Mark Jaquith 5:58 am on May 6, 2009 Permalink | Log in to Reply

        Yes, I meant to include that in the list of “coming soon” ones. Though js_escape() would continue to work, as would attribute_escape() and wp_specialchars().

        Improvements to esc_js() n√©e js_escape() are a separate issue — I’ll take a look at that ticket.

    • Leandro Vieira Pinho 3:11 am on May 9, 2009 Permalink | Log in to Reply

      Why not escape_attr than esc_attr?. Write escape is more intuitive than esc.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar