Title: Making WordPress Secure – Page 2 --- [ ](https://profiles.wordpress.org/courane01/) [Courtney Robertson](https://profiles.wordpress.org/courane01/) 1:39 pm _on_ November 30, 2023 Tags: make.wordpress.org/meta, [p2-xpost ( 10 )](https://make.wordpress.org/security/tag/p2-xpost/) # 󠀁[X-post: Create Tours for Make P2s](https://make.wordpress.org/security/2023/11/30/xpost-create-tours-for-make-p2s/)󠁿 X-comment from [+make.wordpress.org/meta](https://make.wordpress.org/meta/): Comment on [Create Tours for Make P2s](https://make.wordpress.org/meta/2023/11/29/create-tours-for-make-p2s/#comment-9646) * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fsecurity%2F2023%2F11%2F30%2Fxpost-create-tours-for-make-p2s%2F%23respond&locale=en_US) [ ](https://profiles.wordpress.org/ehtis/) [Ehtisham Siddiqui](https://profiles.wordpress.org/ehtis/) 12:44 pm _on_ September 26, 2023   # 󠀁[Bug bounty for WordPress 6.4 Beta](https://make.wordpress.org/security/2023/09/26/bug-bounty-for-wordpress-6-4-beta/)󠁿 Think you found a security bug in WordPress 6.4 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.? The WordPress Security Team wants to find potential security issues before they land in the final WordPress release. Like last time, we’d love to see researchers focusing more of their attention on new code being introduced in beta releases, so we’re offering to double the bounty for any new vulnerability in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that is reported after Beta 1 and before the final release candidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. (RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge.). For example, a bug that would normally be awarded $600 would be doubled to $1200 if reported in the new code between Beta 1 and the final RC. Release schedule for WordPress 6.4 Beta/RC releases can be [found here](https://make.wordpress.org/core/6-4/)( Beta 1 is scheduled for today). There’s usually about a month between the first beta and the last release candidate (RC). ## How can I report security issues? WordPress security team accepts security issues through our [HackerOne program](https://hackerone.com/wordpress). The general eligibility criteria for reports is mentioned in the program policy and must be followed. ## Do existing vulnerabilities qualify if I report them during the beta period? No, the intent of the bonus is to catch security bugs before they make it into a final release, so only vulnerabilities in new code qualify. * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fsecurity%2F2023%2F09%2F26%2Fbug-bounty-for-wordpress-6-4-beta%2F%23respond&locale=en_US) [ ](https://profiles.wordpress.org/ehtis/) [Ehtisham Siddiqui](https://profiles.wordpress.org/ehtis/) 5:12 pm _on_ June 28, 2023 Tags: [Bounties ( 2 )](https://make.wordpress.org/security/tag/bounties/) # 󠀁[Doubling the Bounties for WordPress 6.3 Beta](https://make.wordpress.org/security/2023/06/28/doubling-the-bounties-for-wordpress-6-3-beta/)󠁿 WordPress 6.3 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 will be released later today, June 28th. As with the previous release cycles, this time too we’re focused on finding new security issues before they make it to the final release. WordPress security team is inviting security researchers to find security bugs in WordPress 6.3. We will double the bounties for any new vulnerabilities reported in the new code for WordPress. The submission window will open today with the release of Beta 1 and close before the final release candidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. (RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge.) is out. We post here whenever a beta or RC release is ready: [https://wordpress.org/news/](https://wordpress.org/news/). Release schedule for WordPress 6.3 beta/RC releases can be [found here](https://make.wordpress.org/core/6-3/). ## **How can I report security issues?** WordPress security team accepts security issues through our HackerOne program, which can be [found here](https://hackerone.com/wordpress). The general eligibility criteria for reports is mentioned in the program policy and must be followed. ## Do existing vulnerabilities qualify if I report them during the beta period? No, the intent of the bonus is to catch security bugs before they make it into a final release, so only vulnerabilities in new code qualify. We have more info in this [previous](https://make.wordpress.org/security/2019/02/13/doubling-bounties-for-vulnerabilities-discovered-before-release/) announcement. [#bounties](https://make.wordpress.org/security/tag/bounties/) * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fsecurity%2F2023%2F06%2F28%2Fdoubling-the-bounties-for-wordpress-6-3-beta%2F%23respond&locale=en_US) [ ](https://profiles.wordpress.org/peterwilsoncc/) [Peter Wilson](https://profiles.wordpress.org/peterwilsoncc/) 12:55 pm _on_ September 7, 2022   # 󠀁[Dropping security updates for WordPress versions 3.7 through 4.0](https://make.wordpress.org/security/2022/09/07/dropping-security-updates-for-wordpress-versions-3-7-through-4-0/)󠁿 The WordPress Security Team will cease providing updates for WordPress versions 3.7 – 4.0 in three months time, as of December 1, 2022. Officially WordPress only provides support for the latest version of the software. The [Security team](https://make.wordpress.org/security/) historically has a practice of backporting security fixes as a courtesy to sites on older versions in the expectation the sites will be automatically updated. Until now, these courtesy backports have included all versions of WordPress supporting automatic updates. Versions WordPress 3.7 – 4.0 have reached levels of usage, namely [less than 1% of total installs](https://wordpress.org/about/stats/), where the benefit of providing these updates is outweighed by the effort involved. ## Background Sites running WordPress 3.7 – 4.0 form a very low percentage of total WordPress installations. Conversely, backporting security updates to older versions of WordPress takes a substantial amount of time; this effect compounds with each new major version released. The effect of this imbalance means that the Security team spends most of the time preparing backports for the vast minority of WordPress installations. By dropping support for these older versions, the newer versions of WordPress will become more secure as more time can be focused on their needs. The decision on which versions to drop support for was based on the percentage of sites reported on the [statistics page](https://wordpress.org/about/stats/). ## Process An out of date version of WordPress, in this case versions 4.0.* and older, will display a non-dismissible notice in the dashboard informing users an update is available. In the final updates for these WordPress versions, these notices will be made more prominent and inform the administrator their version of WordPress is no longer receiving security updates. ![Update notice for sites no longer receiving security updates: "WordPress 6.0.2 is available! Please update now. Important! Your version of WordPress (3.8.39) is no longer supported, you will not receive any security updates for your website. To keep your site secure, please update to the latest version of WordPress".](https:// make.wordpress.org/security/files/2022/09/edited-insecure-version-notice-1024x115. png) An additional string will be added to the code base to allow for the future dropping of security support. These strings will be committed to trunk and backported to each of the earlier versions prior to the release date. This will allow the [Polyglot teams](https://make.wordpress.org/polyglots/teams/) to translate them and for the strings to begin appearing in translation packages.** Don’t panic**: not all of the versions of WordPress containing these strings will be affected any time soon. * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fsecurity%2F2022%2F09%2F07%2Fdropping-security-updates-for-wordpress-versions-3-7-through-4-0%2F%23respond&locale=en_US) [ ](https://profiles.wordpress.org/juliarosia/) [Julia Golomb](https://profiles.wordpress.org/juliarosia/) 8:25 pm _on_ July 7, 2022 Tags: [make.wordpress.org/community ( 2 )](https://make.wordpress.org/security/tag/make-wordpress-org-community/), [p2-xpost ( 10 )](https://make.wordpress.org/security/tag/p2-xpost/)    # 󠀁[X-post: Contributor Teams: Submit WCUS 2022 Table Leads Signup Form by July 29](https://make.wordpress.org/security/2022/07/07/xpost-wcus2022-contributor-team-signup/)󠁿 X-comment from [+make.wordpress.org/community](https://make.wordpress.org/community/): Comment on [Contributor Teams: Submit WCUS 2022 Table Leads Signup Form by July 29](https://make.wordpress.org/community/2022/07/07/wcus2022-contributor-team-signup/#comment-30196) * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fsecurity%2F2022%2F07%2F07%2Fxpost-wcus2022-contributor-team-signup%2F%23respond&locale=en_US) [ ](https://profiles.wordpress.org/angelasjin/) [Angela Jin](https://profiles.wordpress.org/angelasjin/) 4:01 pm _on_ May 26, 2022 Tags: [make.wordpress.org/updates ( 2 )](https://make.wordpress.org/security/tag/make-wordpress-org-updates/), [p2-xpost ( 10 )](https://make.wordpress.org/security/tag/p2-xpost/)    # 󠀁[X-post: Announcement: Incident Response Training](https://make.wordpress.org/security/2022/05/26/xpost-announcement-incident-response-training/)󠁿 X-comment from [+make.wordpress.org/updates](https://make.wordpress.org/updates/): Comment on [Announcement: Incident Response Training](https://make.wordpress.org/updates/2022/05/26/announcement-incident-response-training/#comment-5629) * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fsecurity%2F2022%2F05%2F26%2Fxpost-announcement-incident-response-training%2F%23respond&locale=en_US) [ ](https://profiles.wordpress.org/ehtis/) [Ehtisham Siddiqui](https://profiles.wordpress.org/ehtis/) 8:50 pm _on_ June 13, 2021   # 󠀁[WordPress 5.8 Beta & Double the Bounties](https://make.wordpress.org/security/2021/06/13/wordpress-5-8-beta-double-the-bounties/)󠁿 WordPress 5.8 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 was [released](https://wordpress.org/news/2021/06/wordpress-5-8-beta-1/) last week. It’s the upcoming major update and we’d love our security researcher friends to take a look at it, see if you can find any vulnerabilities in the new code. WordPress 5.8 will contain new features and optimizations. For example, the new 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. based [Widgets Editor](https://make.wordpress.org/core/2021/05/12/help-test-the-widgets-editor-for-wordpress-5-8/); it’s an upgrade to the widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget- ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. areas provided by WordPress through themes and a complete replacement for the widgets admin screen. As a reminder, we double the bounty for all our [covered](https://hackerone.com/wordpress) software, provided you’re able to find issues in new code before the final release candidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. (RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge.) is out. For example, a $600 bounty would be doubled to $1200, flat. Things normally start from beta1 – that’s currently the case for WordPress 5.8 Beta 1. You can take a look at the release schedule for 5.8 beta/RC releases [here](https://make.wordpress.org/core/5-8/). Potential issues can be submitted [here](https://hackerone.com/wordpress). Happy bug hunting! * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fsecurity%2F2021%2F06%2F13%2Fwordpress-5-8-beta-double-the-bounties%2F%23respond&locale=en_US) [ ](https://profiles.wordpress.org/chanthaboune/) [Josepha](https://profiles.wordpress.org/chanthaboune/) 10:56 pm _on_ May 25, 2021 Tags: [make.wordpress.org/updates ( 2 )](https://make.wordpress.org/security/tag/make-wordpress-org-updates/), [p2-xpost ( 10 )](https://make.wordpress.org/security/tag/p2-xpost/)    # 󠀁[X-post: Experiment: A Public Channel for All Team Reps](https://make.wordpress.org/security/2021/05/25/xpost-experiment-a-public-channel-for-all-team-reps/)󠁿 X-comment from [+make.wordpress.org/updates](https://make.wordpress.org/updates/): Comment on [Experiment: A Public Channel for All Team Reps](https://make.wordpress.org/updates/2021/05/25/experiment-a-public-channel-for-all-team-reps/#comment-5328) * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fsecurity%2F2021%2F05%2F25%2Fxpost-experiment-a-public-channel-for-all-team-reps%2F%23respond&locale=en_US) [ ](https://profiles.wordpress.org/iandunn/) [Ian Dunn](https://profiles.wordpress.org/iandunn/) 3:09 am _on_ February 13, 2019 Tags: [Bounties ( 2 )](https://make.wordpress.org/security/tag/bounties/) # 󠀁[Doubling Bounties for Vulnerabilities Discovered Before Release](https://make.wordpress.org/security/2019/02/13/doubling-bounties-for-vulnerabilities-discovered-before-release/)󠁿 The best time to discover a security bug is before it’s ever released to users. Not only does that keep everybody safe, but it also makes the process of fixing the bug much simpler and faster. The WordPress Security Team would love to see researchers focusing more of their attention on new code being introduced in betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. releases, so we’re offering to double the bounty for any new vulnerability in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that is reported after Beta 1 and before the final release candidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. (RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge.). For example, a bug that would be awarded $600 if it were reported after the release will instead be awarded $1,200 if it’s reported between Beta 1 and the final RC. You can learn more about our bug bounty program by [visiting our HackerOne page](https://hackerone.com/wordpress). ### Do vulnerabilities qualify if reported after the final RC but before the release? No, because there’s sometimes only a day or two between the final RC and the last release, and we may not receive and triage your report in time for it to prevent the vulnerability from being released. ### How can I know when a beta1 is released? We publish posts at [w.org/news](https://w.org/news) whenever a beta or RC release is ready. To get email notifications, enter your address in the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. and click on the`Subscribe` button. ### How are Beta and RC releases scheduled? When an upcoming release is ready for initial testing, we publish a `beta1` (for example, [5.1-beta1](https://wordpress.org/news/2019/01/wordpress-5-1-beta-1/)). If significant bugs are discovered, we’ll fix them and publish `beta2`, `beta3`, etc. Once the code seems like it might be stable enough for production, we’ll publish` RC1` (for example [5.1-RC1](https://wordpress.org/news/2019/02/wordpress-5-1-release-candidate/)). If significant bugs are discovered, we’ll fix them and publish `RC2`, `RC3`, etc. Once we’re confident that the code is ready for production servers, we’ll publish the final release (for example, [5.0](https://wordpress.org/news/2018/12/bebo/)). ### How can I know how much time I’ll have before the final RC? The timing and number of betas/RCs can vary, but there’s usually about a month between the first beta and the last RC. You can view a rough schedule for the release by visiting [the Make Core blog](https://make.wordpress.org/core/), and following the link in the sidebar under `Current Release`. To give yourself the most time, we recommend that you start testing when `beta1` is released. ### Are bounties doubled for unreleased vulnerabilities in other software, like GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. 󠀁[https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/)󠁿 and WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is 󠀁[http://wp-cli.org/](http://wp-cli.org/)󠁿 󠀁[https://make.wordpress.org/cli/](https://make.wordpress.org/cli/)󠁿? Yes! Everything here applies to [all of our software](https://hackerone.com/wordpress), as long as you report it between `beta1` and the final RC. ### Do existing vulnerabilities qualify if I report them during the beta period? No, the intent of the bonus is to catch security bugs before they make it into a final release, so only vulnerabilities in new code qualify. [#bounties](https://make.wordpress.org/security/tag/bounties/) * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fsecurity%2F2019%2F02%2F13%2Fdoubling-bounties-for-vulnerabilities-discovered-before-release%2F%23respond&locale=en_US) [ ](https://profiles.wordpress.org/aaroncampbell/) [Aaron D. Campbell](https://profiles.wordpress.org/aaroncampbell/) 2:00 pm _on_ November 13, 2017   # 󠀁[The War on SQLi, or What Happened in 4.8.2 and 4.8.3](https://make.wordpress.org/security/2017/11/13/the-war-on-sqli-or-what-happened-in-4-8-2-and-4-8-3/)󠁿 WordPress is complex software used by a large percentage of the internet in millions of unique ways. So when there is an issue that touches deep in the internals of the WordPress codebase, we need to be careful and deliberate. Even more so if the issue has security implications. An incorrect or incomplete fix could break millions of sites or, possibly worse yet, leave them vulnerable. ## The Original Issues Yes, “issues” plural. There were two of them that were somewhat worse when linked together. Both were first discovered by one of our WordPress security team members. #### Array Handling in prepare() The first was that `wpdb::prepare()` accepted an array of replacements as the second parameter, or any number of mixed placeholders. In other words, both of these were valid and functionally identical: ```notranslate $wpdb->prepare( '%s %d %s', array( 'testing', 1, '2 3' ) ); $wpdb->prepare( '%s %d %s', 'testing', 1, '2 3' ); ``` However, if the first argument was array, then the following arguments were ignored. So this would give a potentially unexpected and possibly unsafe returned value: ```notranslate $wpdb->prepare( '%s %d %s', array( 'testing', 0, 'NO!' ), 1, '2 3' ) ); ``` #### Poor Defense Against Unsupported Placeholders The second issue was that `wpdb::prepare()` worked with both the `%c` as well as numbered placeholders, even though it was documented as not supporting those. We realized this could be potentially exploitable. For example, if a user could control both the `page_title` and the `post_type` of a `get_page_by_title()` call: ```notranslate get_page_by_title( '39', OBJECT, array( '%1$c) OR 1 = 1 -- -' ) ) // as sprintf( '%1$c', '39' ) == "'", the following happens to the query: // // $sql = $wpdb->prepare( "SELECT ID FROM $wpdb->posts WHERE post_title = %s AND post_type IN ( '%1$c) OR 1= 1 -- -' )", "39" ); // $sql = "SELECT ID FROM $wpdb->posts WHERE post_title = '39' AND post_type IN ( '' ) OR 1 = 1 -- - ' )" ``` As is often the case, the further we got into researching it, the more we found. Eventually coming up with a proof of concept that followed a commonly used coding pattern and showed that it was exploitable: ```notranslate $user = $wpdb->prepare( "user_login = %s", "%1$' OR [SQLi PAYLOAD] -- -" ); $sql = $wpdb->prepare( "SELECT * FROM wp_users WHERE ID != %d AND " . $user, 1337 ); //SELECT * FROM wp_users WHERE ID != 1337 AND user_login = '' OR [SQLi PAYLOAD] -- -' ``` The problem was coming up with a fix that would close the vulnerability without breaking too many plugins and sites. ## The Outside Report It was around this time, on October 28th of last year, that we received a report from Slavco via our security E-Mail address. Five days later, on November 3rd, an invitation to HackerOne was sent and Slavco opened a report on the [WordPress HackerOne program](https://hackerone.com/wordpress). Both issues were noted in the report. The array issue: ```notranslate //Issue number 1 //no matter how many input arguments have prepare method, if first one is an array will use it and avoid any of the another parameters $in1 = array("a","b","c");//only sql escaped variable... $in2 = 2;//example: cleaned variable $in3 = 3;//example: user id echo $demo->prepare("Test %s %s %s", $in1, $in2, $in3)."\n"; ``` And the “double prepare” issue as we were now calling it: ```notranslate //Issue number 2 //If you use wpdb::prepare on string that is already prepared //could be combined with issue 1 or with sprintf argument swapping e.g. %1$%s $str = $demo->prepare("where a = %s ","'%s'"); echo $demo->prepare("select * from t $str and q = %s or g = %s", array(" and 1=1 #", "a", "b"), 1 )."\n"; $str = 'valid sql \'%1$\'%s\' test@gmail.com #\''; echo $demo->prepare("select * from t $str and q = %d ", 1 )."\n"; ``` ## The Fix(es) We had potential fixes for both of these issues at the time the report was opened and they were combined into a single patch and added to the report on November 9th, eleven days after the first E-Mail. However, we were not yet comfortable with the backwards compatibility of the fix. It changed the inner workings of `wpdb::prepare()` in two ways and while it brought it more in line with the documentation for that function, we were uneasy about how many plugins or sites might be affected. It took a lot of time, but we continued to test the fixes that we had developed, try alternatives, etc. We had some back and forth on the HackerOne report, ran some checks against the 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/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. directory, and had a select group of plugin developers test part of the fix. In hindsight, I should have had them test the entire patch – more on this in a bit – but by September we were ready for a release. ## 4.8.2 The fix was packaged with eight other security fixes (oh yeah, this wasn’t the only thing we’d been working on) and [WordPress 4.8.2 was released](https://wordpress.org/news/2017/09/wordpress-4-8-2-security-and-maintenance-release/) on September 19th. The day after release a ticket was opened wanting to add the support for numbered placeholders back to `wpdb::prepare()`. We expected this. We knew that taking away functionality is never popular. Finding the right balance between security and functionality is one of the hardest things we do as a team. Other than the expected push to reintroduce the functionality we had limited, the release seemed to go pretty well. There were no abnormal spikes in issues on the support forums, no hosts complained of unexpected increases in support requests ( and I talked to several), and the actual update numbers looked relatively normal. Unfortunately, we now know that we broke more plugins than we needed to. If we had given the full patch to our plugin test group, we could have caught some of the potential breakage. That was my fault. I’m sorry, and lesson learned. One of the plugins that broke was one running on a site belonging to [Anthony Ferrara](https://twitter.com/ircmaxell). When he dug into why, he realized that it was due to how we blocked numbered placeholders, and he saw a problem. He opened a HackerOne report on September 20th, the day after 4.8.2 was released. ## The New Problem The new problem, as specified in the report, was that there were some cases where queries using numbered or padded placeholders could have been secure in 4.8.1 and vulnerable in 4.8.2. While I do think that we fixed far more than we broke with 4.8.2, the issue was still valid. A proof of concept was included: ```notranslate $wpdb->prepare("SELECT * FROM foo WHERE name= '%4s' AND user_id = %d", $_GET['name'], get_current_user_id()); ``` Because our fix for 4.8.2 didn’t allow for `%4s`, this query would no longer try to select the current user with a user-specified name, but instead try to select a user with the name `%%4s` and the user-specified “name” used as the `user_id`. There was some back and forth on the ticket where we tried to give background on the original issue and why we fixed it the way we did. What we had dubbed “double prepares” _were_ in fact an issue, but our fix had left some potential edge cases worse off than before. Obviously not ideal. We dug in again. ## Security is Complicated The technical issue was relatively easy to agree on: User supplied content – that could resemble a placeholder – ending up in the first parameter of `wpdb::prepare()`. The correct solution though, was much harder to find and agree upon. One solution that was offered was to disallow all double prepares, making them throw a hard error. Unfortunately, looking through the plugin directory told us that this would likely break a lot of plugins. It was an “ideal” solution from a security standpoint, but realistically it wasn’t an option for us. The solution we came up with, on the other hand, was very complex and convoluted. It tried to keep existing functionality while still mitigating the vulnerability, but the rabbit hole seemed to be extremely deep. The patch became more complex as we discovered unexpected idiosyncrasies with the internal workings of certain PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. [https://www.php.net/manual/en/index.php](https://www.php.net/manual/en/index.php) functions. ## Communication is Important and Hard Working with people can often be complicated, and working with our security team on a complex WordPress issue is no exception. Communication broke down some during the process and things got difficult. Luckily both sides kept working at it. Ultimately, working back and forth through the issues we were able to continue to improve our approach. Implementing ideas from both sides allowed us to simplify the code and come up with a solution that was not prohibitively complex, addressed the issues, and avoided widespread plugin breakage. There _was_ some [changed behavior in `esc_sql()`](https://make.wordpress.org/core/2017/10/31/changed-behaviour-of-esc_sql-in-wordpress-4-8-3/), that mostly affects its use when **not** used in conjunction with `wpdb::query()`. ## Success The resulting fix was [released in WordPress 4.8.3](https://wordpress.org/news/2017/10/wordpress-4-8-3-security-release/) on October 31, 42 days after 4.8.2. Updates rolled out smoothly and the release seems to be working well for people. Thanks to all involved for their hard work on this one! * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fsecurity%2F2017%2F11%2F13%2Fthe-war-on-sqli-or-what-happened-in-4-8-2-and-4-8-3%2F%23respond&locale=en_US) ## Post navigation [Newer posts →](https://make.wordpress.org/security/?output_format=md)