Dev Chat Summary: October 4th (4.9 week 10)

This post summarizes the dev chat meeting from October 4th (agendaSlack archive).

4.9 schedule

  • Today is the Beta 1 deadline for enhancements and feature requests. All tickets have been scrubbed as of earlier today, any that are still open when the Beta 1 build process begins later today will be punted to Future Release.
  • Next on the 4.9 release schedule will be Beta 2 on Wednesday, October 11th.
  • 30 enhancements and features still in the milestone
  • Beta 1 build process will begin around Wednesday, October 4th 20:00 PDT / Thursday, October 5th 03:00 UTC

Gutenberg block data storage

  • Want to start thinking about and discussing how block data is stored. We currently (specially after allowing meta attributes) have a lot of ways to store block data, with different tradeoffs. It’s going to be important to communicate when each is appropriate.
  • This will come through examples and documentation, but generally such knowledge has also spread by core contributors doing talks and blog posts, etc.
  • As people start to look at creating blocks, there are various ways to specify attributes, and different ways things can be saved (static blocks, dynamic blocks, etc). A lot of the reason people used custom fields or meta attrs will be different as blocks allow individual attributes that are still part of the content.
  • If you have input to share on that, please join in #core-editor and their weekly meetings.

REST API Handbook

  • They are moving / have moved the REST API Handbook content to GitHub.
  • Once it’s deployed, the REST API handbook’s content will be managed in GitHub.

General announcements

  • @rskansing: I want to give a thanks to the security team for always being very nice and polite in regards to my many queries and questions

#4-9, #core, #core-restapi, #dev-chat, #gutenberg, #security, #summary

Dev Chat Summary: September 20th (4.9 week 8)

This post summarizes the dev chat meeting from September 20th (agendaSlack archive).

4.9 schedule

  • 1 week until the feature project merge deadline, 2 weeks until Beta 1
  • Drafting and scheduling (#39896) has designs and is working through development
  • Gallery widget (#41914) is now available in the Core Media Widgets feature plugin, so please test that as we plan to merge it into core next week
  • Updating a plugin via ZIP (#9757) or drag/drop (#24579) is not getting any traction, so they will likely be punted
  • Review needed on #34115 to bring the ability to use oEmbed outside the context of posts
    • This allows the Text widget to have embeds in it, as well as to be able to remove the restriction on the Video widget to only show YouTube and Vimeo
  • Long list of Code Editor tickets that could use contributors
    • If you’re interested and capable with JS and playing with CodeMirror, #41873 is a great place to start
  • Any tickets related to goals in the 4.9 Goals post should be prioritized
  • Bug scrub post will be published with dates/times to scrub features and enhancements ahead of the Beta 1 deadline. If you’re interested in helping run a scrub, then please let @jbpaul17 know.
  • User testing needed on #39693, especially running it through a battery of theme switching tasks; the goal is to improve the “it just works” experience
    • Testing steps include installing a theme, populating sidebars with widgets, switching to another theme, and checking how the widgets appear in the newly switched theme
    • If you switch back to the old theme, the sidebar widgets get restored
    • Testing should be done when switching themes via the WP admin themes page, and also via live preview in the Customizer
    • Themes that have varying numbers of sidebars would be the key to test with. Switching from a theme with 2 sidebars, to one with 4, to another with 1, to another with 5, and so on.
    • If you want to have a public test environment set up with the patch to test, then please ping @westonruter

Editor update

General announcements

#4-9, #core, #core-editor, #dev-chat, #feature-oembed, #media-widgets, #security, #summary

Dev Chat Summary: August 16th (4.9 week 3)

This post summarizes the dev chat meeting from August 16th (agendaSlack archive).

Feedback on 4.9 goals

  • @johnbillion: as part of ongoing Security focus, planning on several user account security related changes, for example bringing some of the Multisite confirmation emails when you change your email address into single site
  • @flixos90: Multisite team is working on REST API endpoints for the multisite objects, like sites and networks, plus improvements to the users endpoint that make it compatible with multisite
  • @westonruter: just published 0.2.0 of the codemirror-wp plugin which adds an a11y option to the user profile screen to opt-out of syntax highlighting in the same way that a user can opt-out of the visual editor
  • @westonruter: feedback and help welcomed via the CodeMirror repo
  • @westonruter: Customizer drafting and scheduling (essentially porting the features from the Customize Snapshots plugin) is currently working through designs with @joshuawold, once that’s set this will move to implementation

Component roadmaps

  • @desrosj: Multisite team using weekly meetings to re-organize the Network & Sites component’s roadmap to align with Core’s current focuses and the component’s short and long term goals
  • @desrosj: We propose using make.wordpress.org/core/roadmap/ as a location for components to house their roadmaps (multisite living at `make.wordpress.org/core/roadmap/multisite`) as roadmap posts on the Make/Core blog slowly get pushed away as new posts are published
  • @desrosj: The roadmap outline (brief descriptions of each item, a timeline, some tickets to focus on immediately) would live on these roadmap pages, and link out to make blog posts with specific details about each item.
  • Agreement to proceed with this with Multisite and assess how its working before pushing other components to do the same

General announcements

  • @koenhuybrechts: looking for update on #17268
  • @mte90: looking for update on #12955
    • @drewapicture: concern with potential performance hit due to the sheer number of times it’s called on a given page load; will leave a comment on the ticket
  • @mte90: looking for an update on #13657
    • No one around related to the Database component, will continue to look for updates via the ticket
  • @mte90: looking for an update on #40542 as well as my other patches

#4-9, #components, #core-customize, #core-multisite, #core-restapi, #dev-chat, #roadmaps, #security, #summary

Disclosure of Additional Security Fix in WordPress 4.7.2

WordPress 4.7.2 was released last Thursday, January 26th. If you have not already updated, please do so immediately.

In addition to the three security vulnerabilities mentioned in the original release post, WordPress 4.7 and 4.7.1 had one additional vulnerability for which disclosure was delayed. There was an Unauthenticated Privilege Escalation Vulnerability in a REST API Endpoint. Previous versions of WordPress, even with the REST API Plugin, were never vulnerable to this.

We believe transparency is in the public’s best interest. It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.

On January 20th, Sucuri alerted us to a vulnerability discovered by one of their security researchers, Marc-Alexandre Montpas. The security team began assessing the issue and working on solutions. While a first iteration of a fix was created early on, the team felt that more testing was needed.

Meanwhile, Sucuri added rules to their Web Application Firewall (WAF) to block exploit attempts against their clients. This issue was found internally and no outside attempts were discovered by Sucuri.

Over the weekend, we reached out to several other companies with WAFs including SiteLock, Cloudflare, and Incapsula and worked with them to create a set of rules that could protect more users. By Monday, they had put rules in place and were regularly checking for exploit attempts in the wild.

On Monday, while we continued to test and refine the fix, our focus shifted to WordPress hosts. We contacted them privately with information on the vulnerability and ways to protect users. Hosts worked closely with the security team to implement protections and regularly checked for exploit attempts against their users.

By Wednesday afternoon, most of the hosts we worked with had protections in place. Data from all four WAFs and WordPress hosts showed no indication that the vulnerability had been exploited in the wild. As a result, we made the decision to delay disclosure of this particular issue to give time for automatic updates to run and ensure as many users as possible were protected before the issue was made public.

On Thursday, January 26, we released WordPress 4.7.2 to the world. The release went out over our autoupdate system and, over a couple of hours, millions of WordPress 4.7.x users were protected without knowing about the issue or taking any action at all.

We’d like to thank Sucuri for their responsible disclosure, as well as working with us to delay disclosure until we were confident that as many WordPress sites were updated to 4.7.2 as possible. We’d also like to thank the WAFs and hosts who worked closely with us to add additional protections and monitored their systems for attempts to use this exploit in the wild. As of today, to our knowledge, there have been no attempts to exploit this vulnerability in the wild.

#4-7, #release, #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.

#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:

Bootstrap/Load

  • #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

Charset

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

Comments

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

Customize

  • #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

Editor

  • #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

Feeds

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

General

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

HTTP API

  • #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

Media

  • #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

REST API

  • #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

Taxonomy

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

Themes

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

Upgrade/Install

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

 

#4-7, #4-7-1, #maintenance, #release, #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.

#imagick, #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.

#feature-plugins, #json-api, #rest-api, #security, #updates

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.

#4-0, #database, #dev-notes, #query, #security

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 2.2.0.1 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.

#security, #swfupload