WordPress core < 6.3.2 allowed any logged in user to execute arbitrary shortcodes. This issue was report in July 2016 and was finally resolved in October 2023. Around June 2023 another hackerone user (whitecybersec) also reported the same issue and was looped into my report. I did receive a $450 bounty for this on the hackerone platform, which equates to 17 cents per day for every day the issue went unresolved.

I typically stick to the only the facts, but I’m going to split this up into the facts and my opinion on the situation.  I’ve included most of the details from the hackerone conversation in the Timeline, it’s an interesting read.

Table of Contents

• Vulnerability Information
• How not to run a bug bounty program
• Timeline

Vulnerability Information

The “parse_media_shortcode” AJAX function allowed any logged in user, even a “subscriber” which is frequently enabled by default, to execute arbitrary shortcodes and see the results.

The “parse_media_shortcode” AJAX function was added with WordPress 4.0 and at that point had proper protection to keep unauthorized users from calling the function.  There was a change with WordPress 4.2 that removed this protection in specific cases.

WordPress shortcodes are intended to be included by higher privileged users like authors or editors to include plugin or theme functionality, normal users are not expected to be able to adjust the arguments passed in or execute arbitrary shortcodes.  We’ve previously posted about the risks of shortcodes: WordPress shortcode injection as an attack vector

An except from that post about Shortcode functionality I have seen in various third party plugins:

• Include arbitrary files from the file system
• Execute arbitrary PHP code
• Retrieve arbitrary data from WordPress custom post type fields
• Generate HTML forms that allow editing WordPress posts or users
• View content that is supposed to be protected by password or other specific protections
• Provide list of discount codes for an E-Commerce plugin

My Opinion

If there were any dangerous shortcodes in WordPress core this would have been fixed immediately, but all of the dangerous shortcodes were in 3rd party plugins.  It’s clear the WordPress security team was only focused on issues that could affect Automattic and WordPress core.  All but the most basic sites depend on 3rd party plugins and many of these ship with insecure shortcodes, becaused plugin developers expect them to be included by higher privileged users.

Release after release went by with “we’re looking into it,” promises of updates “next week,” even a severity bump and draft patches, and then more delays over compatibility worries.  In the meantime, plugin developers and site maintainers had no idea they were vulnerable.

A team of volunteers working the security team for a product that claims to power a significant portion of the internet is a joke.  When limited resourcing leads to long gaps in communication and repeated deferrals, the community pays the price.  This experience pushed me to step away from the WordPress ecosystem, and I frequently recommend people avoid it.

if something this straightforward could simmer for years because it was “minor” to core, who knows what other issues are still treated as minor to them but critical to everyone else running real sites.

Timeline

• 7/15/2016 Initial report submitted
• 7/18/2016 Followup report including other WordPress.com VIP MU plugins that are vulnerable
• 7/19/2016 WordPress staff reply: “Thanks for the report, James. We are looking into it and will update here when we have more information.”
• 8/3/2016 Followup: “I know these issues have to be handled delicately, but I was just curious if anything is going to happen with this.”
• 9/7/2016 Followup: “Just saw that another security release was made with this flaw still included. Is this going to be dealt with?”
• 12/6/2016 Followup: “Another WordPress release (4.7) without this issue being addressed. Is this going to be resolved?”
• 1/11/2017 Followup: “Sigh, another security release that does not address this issue.”
• 1/26/2017 Followup: “4.7.2 came out today with… surprise, no fix for this issue. Is anyone paying attention?”
• 1/26/2017 WordPress staff reply: ”
  Yes, we are paying attention. I apologize for the lack of communication. We are trying to get better at that, I promise.
  We actually considered this item for inclusion in this release, but there wasn’t enough confidence that the fix was right at the time we hit the cutoff for the 4.7.2 release. I’ll try to have one of the people that was working on it give you an update here within the next week. The good news is, the next minor release is not expected to be too far off and we’ll keep working on this in the mean time.”
• 2/14/2017 Followup: “Are we talking about earth weeks or something closer to what a week would be on Jupiter?”
• 3/6/2017 Followup: “Sigh, this must have just missed the cutoff for 4.7.3 as well.”
• 4/20/2017 Followup: “I noticed the 4.7.4 build for testing still has this vulnerability. I’m sure (or at least I hope) that there are unseen activity going on related to this but a little communication would be good. Last I heard (3 months ago) was I would get an update about the issue in a week.”
• 5/16/2017 Followup: “4.7.5 is out with no fix”
• 9/20/2017 Followup: “Over 14 months, yet another security release and no fix for this. It’s been 8 months since the “I’ll try to have one of the people that was working on it give you an update here within the next week”
• 11/21/2017 Followup: “With 4.9 recently released, should I assume this is just not going to be fixed? It’s obviously not a showstopper to you, but to many other plugins this is a serious deal (some of them in use in JetPack and on WordPress.com)”
• 11/21/2017 WordPress staff reply: ”
  Hi James,
  I don’t know what to say about our terrible communication on this ticket, other than sorry. We’re struggling to catch up with a backlog of reports, and unfortunately prioritising things with limited time and resources is proving to be harder than we expected.
  I think the most comprehensive fix here is to limit the shortcodes that can be executed to just the media shortcodes and no others. I’m going to do a search of the plugin and theme repos to make sure that there aren’t any plugins or themes directly calling this endpoint for some reason. Barring a surprising discovery, I’ll work on a patch and share it here with you for feedback.”
• 11/21/2017 Followup: ”
  Thanks for responding. I know this ticket isn’t necessarily the place for it but it’s been very clear for some time to outsiders that a volunteer security team for a project that powers 25-30% of the internet is not the best move. I’m not criticizing the team, but the upper levels that run things. A paid and dedicated security team will never have a profitable line item in a year end statement but when some/many serious security issues come out there could be a noticeable negative impact on the bottom line.
  This is a trivial issue to fix and it could have been easily inserted into one of the many previous security or major releases.”
• 11/29/2017 Followup: “Wow, seriously? Another security release without addressing this.”
• 11/29/2017 WordPress staff reply: “Thank you for your support. The team are working hard on a backlog of issues. As much as we’d like to fix every issue in one release, that’s just not an option right now. We’re working hard and we’ll let you know when we have a plan to get this fixed in a release.”
• 1/16/2018 Followup: “580 days, 10 security releases, 4 major releases and this still has not been resolved.”
• 1/17/2018 WordPress staff reply: ”
  Hi James,
  I’d like to apologise for the continuous delays on this report, reading through the history of discussion around this issue, there’s been a few directions suggested, but unfortunately no solid approach agreed upon. This hasn’t been helped by shortcodes being introduced into non-post contexts, such as within widgets recently and upcoming Gutenberg changes.
  I’m going to attach a copy of the latest draft patch direction we’ve trialed internally – It limits users who cannot publish posts to a whitelist of media-related shortcodes – We’d probably add a filter here too.
  Does this seem like a direction which would be viable in your opinion? It does have some serious shortcomings, for example, Contributors would no longer be able to preview plugin and theme provided shortcodes (and many themes and plugin rely upon shortcodes for layouts), but we don’t really see any other option but to break these use cases.”
• 1/17/2018 Followup: ”
  Since WordPress doesn’t have a proper security context there isn’t really a proper way to solve this issue.
  I’d probably just check if current_user_can( ‘unfiltered_html’ ) in situations that don’t have a $post and punt otherwise. I suspect that in most typical cases this would be sufficient that end users never notice an issue, I have not looked into how Gutenberg works or hooks into things to know if it would be an issue.
  If the approach in the patch is used, I’d at least make sure there is a filter called to allow other developers access to the allowed shortcode list.
  The long term target would be to have a proper security context where more data is registered when shortcodes are added which would specify who should be allowed to execute, insert them in posts, edit existing entries in posts. I would have the shortcode processor only process shortcodes that are properly signed (by WordPress itself) to keep people from editing the parameters/content of a shortcode they are not allowed to edit.”
• 1/18/2018 WordPress staff reply: ”
  Thanks for your comment @jamesgol
  I agree (as I’d mentioned) that a filter would be needed here.
  The reason we went for publish_posts rather than unfiltered_html is mostly that if you can publish a post, you can publish whatever shortcodes in that content that you want. I don’t think that unfiltered_html would be a viable option here instead – primarily as even users who don’t have that should be able to preview most shortcodes. There’s further unfiltered_html checks in that patch for a few edge cases of what shortcodes actually do.. but that’s a bit of a rabbit hole to try to explain 🙂
  Long term, having some kind of security context around shortcodes would be nice, however realistically I don’t think that’s something we’d want to add and support in the future. Gutenberg blocks are more likely to be a better use-case in the future than shortcodes, and the API calls behind those should be more open to having proper security baked into them from the get-go.
  I apologise again for the time that this report has been open, we’re slowly getting on top of the backlog of reports and I’m hopeful that this can be patched in one of the upcoming releases soon. I’m not guarantee’ing it’ll be in the next security release, as we can only manage so many things at once, but we’ve definitely not forgotten it!”
• 4/30/2018 WordPress staff reply: ”
  Hi @jamesgol,
  After some further discussion and testing, we’re are going to move forward with a variation on the patch above that effectively whitelists the media shortcodes in WordPress so only they can be processed by the wp_ajax_parse_media_shortcode() function. This removes the ability for arbitrary shortcodes to be processed on a site using the parse-media-shortcode Ajax handler.
  I’m going to be working on this in the next day or two. I’ll let you know when I have an updated patch for you to test if you wish to do so.”
• 4/30/2018 WordPress staff reply: “Attached is an update to the patch above. Later today I’ll be working on unit tests to cover the change.”
• 4/30/2018 Followup: ”
  Looks good. Even if someone was able to figure out a way to trick the get_shortcode_regex() to allow a nested/malformed shortcode through it still wouldn’t execute.
  Is this going to be rolling out soon?”
• 7/20/2018 Followup: “I missed the two year anniversary, but this marks 735 days since this issue was reported.”
• 12/4/2018 Followup: “Is the fix for this going to be included in the upcoming 5.0 and backported to older versions?”
• 12/4/2018 WordPress staff reply: ”
  Hi James, I’m sorry it’s taken us so long to address this. It’s an awful situation. We are working hard on clearing out our backlog, but haven’t gotten to this one yet.
  The major (x.y) releases never include security updates, we always put those in minor releases (x.y.z), so that users can install them without having to worry about any other changes they might not want. Putting them in minor releases also allows them to be automatically installed on the vast majority of WP sites.
  Whenever we release a security patch, we always try to backport it to version 3.7, which is the oldest version that includes auto-updates. We’re not always able to do that (which is why they’re aren’t officially supported), but we are in the vast majority of cases.
  Thanks again for being so patient here. I know it’s been a very long time to wait. We are actively working on the backlog. Give the severity of this particular report, I’m going to set the severity to High so that we can move it closer to the top of the queue.”
• 12/4/2018 Followup: “Sounds like rolling out 4.9.9 before Thursday would be a good choice then”
• 12/4/2018 WordPress staff reply: ”
  Unfortunately we’ve got our hands full with other reports right now, and releasing even a seemingly simple patch can take a few weeks to fully test the backwards-compatibility implications. There’s honestly just no way to release anything on such a short timeframe, without putting a millions of sites at risk.
  We do still intend to finish iterating on the patch above, though, and include it in a future release. We won’t know which release it’ll be in until we get closer to that point, but since it’s marked as High now, it’s closer to the top of our queue.”
• 12/4/2018 Followup: ”
  I honestly do not know what to say, I understand you are a team of volunteers and I can sympathize with the situation. If I did not already have plans this weekend I would consider flying to Nashville and asking in public at the state of the word how something that powers 32% of the internet does not have a dedicated and paid security team and how it is reasonable to sit on security issue for multiple years.
  This is a bad situation that is only going to get worse the longer it drags out. I fear the public disclosure will be the only way to get this resolved in a reasonable time frame. I will certainly give you a bit of notice if I decide to do that.”
• 12/4/2018 WordPress staff reply: ”
  Thanks James, I can definitely understand your frustration, and you have every right to be upset. I definitely agree that we need paid/dedicated team members, and that’s one of the avenues that we’re working on securing.
  While I definitely wouldn’t want to see it disclosed early, I can’t say I’d blame you. If you do plan to do that, I would love as much of a heads up as possible, so that I can try to coordinate a fix in time. Since our resources are limited, it’d mean pulling people off of higher-severity reports, but that’d be better than letting a high-severity report go public without a fix.”
• 7/16/2019 Followup: “Happy 3rd Anniversary!”
• 1/16/2020 Followup: ”
  Another project I help with (<redacted>) had a security issue reported to them by a security researcher that was related to their shortcodes used. His proof of concept including using this ‘parse-media-shortcode’ issue as a normal user.
  Included below is an excerpt of the report. Clearly people know that this vulnerability exists in WordPress and are using it.  <PoC redacted>”
• 7/23/2020 Followup: “I can’t believe I missed our 4 year anniversary. Hopefully you’ve been thinking about me and haven’t forgotten our relationship.”
• 7/7/2022 Followup: “We’re coming up on the 6 year anniversary of this report. Will this ever be resolved?”
• 7/15/2022 Followup: “Happy Anniversary! I’m going to request mediation with hackerone because “Team is unresponsive””
• 7/15/2022 Requested remediation with reason: “WordPress security team has shared a patch to fix the issue but has not implemented this after 6 years. This is a vulnerability in WordPress core and it’s sad they allow it to persist after so many years. While the shortcodes included in WordPress core are not a major security threat if unauthorized users can execute them, there are thousands of WordPress plugins that do have shortcodes that allow this issue to be used to extract critical information or completely compromise a website.”
• 7/20/2022 WordPress staff reply: ”
  Hi @jamesgol,
  First of all, please accept my sincere apology for the lack of update in your report. We had lost track of the old issues due to other priorities. I know you are very frustrated right now due to our unresponsiveness. We are really really sorry about that.
  The WordPress security team is doing its best to catch up on old issues like this. We are working to clear our backlogs and are making progress now.
  I like to get this released in the near future, so I will try to get back to you as soon as the patch is ready for release. If you have some questions, please let us know.”
• 1/6/2023 Followup: “It’s been six months since the last response, 6.5 years since this was opened. This is really not the way to run a bug bounty program. “
• 3/29/2023 Followup: “Congratulations on releasing WordPress 6.2. Are you you ready for me to publish my disclosure and exploit code? “
• 3/29/2023 WordPress staff reply: ”
  Security fixes are usually included in point releases, e.g. 6.2.x. I’m hoping that we can resolve all the remaining issues in the fix and release it as soon as possible in one of the upcoming security releases.
  We’d request that you delay the disclosure until a fix is released. Meanwhile, we’ll go ahead and award a bounty for this, as it’s been quite a while. Thank you for your patience and we really do appreciate your responsible disclosure.”
• 4/3/2023 Followup: “Since Automattic purchased WPScan and is now a CNA will you assign a CVE id for this or should I start that process?”
• 4/3/2023 WordPress staff reply: ”
  It’s certainly doable. When requesting CVEs, we usually do it via GitHub around a release’s time as that’s what we use for developing fixes.
  Also, the payment method we use for bounties is having some issues. Working on a resolution so the bounty can be paid out.
• 4/6/2023 WordPress rewarded jamesgol with a $400 bounty and a $50 bonus: ”
  While this issue has yet to be resolved, we are awarding a bounty for this report. Please note that as this issue is still being triaged, public disclosure will only be available (as usual) once the issue is fully resolved.
  Thanks once again for the responsible disclosure.”
• 4/11/2023 Followup: “I just want to make sure the CVE date reflects when the issue was opened. “
• 5/17/2023 Followup: ”
  WordPress 6.2.1 released… Without a fix…
  Seriously guys? Get the PR machine going for when this story hits the press.”
• 5/17/2023 WordPress staff reply: ”
  I’d like to provide some clarity and more info about what’s happening re. the fix. We wanted to include a patch for this issue in 6.2.1, however, introducing user restrictions for shortcodes is leading to some issues in the fix. Many plugins depend on shortcodes being visible to all users, including logged out ones. We’re working to find an approach to fix this in a non-breaking way, so that sites and plugins continue to work once this is out in a security release.
  I’ll share a diff with you that we’re currently working on, which we’re working to include as soon as possible as a security fix. Thank you for your patience so far, I hope you will wait for it to be included in the security release.”
• 5/19/2023 WordPress staff reply: ”
  I wanted to give you a heads-up: We’re currently working on a swift/emergency release 6.2.2 which is meant to resolve a breaking change (that was introduced in 6.2.1). That breaking change is affecting a lot of plugins/sites.
  Please know that we’re working on a fix for this issue and it’s not being ignored. We’re aiming to minimize/eliminate breaking changes from a patch for this issue, and targeting to include in a security release as soon as possible.”
• 5/19/2023: Followup: “I understand completely, thank you for the update.”
• 6/6/2023: whitecybersec  joined this report as a participant with no specified permissions.  I’m not going to include their details here unless they reach out and say it’s ok to, but it was a detailed report.
• Several more messages between whitecybersec and WordPress staff, but I’d given up on WordPress and their security team.
• 10/12/2023 WordPress 6.3.2 released with issue resolved: “John Blackbourn (WordPress Security Team), James Golovich, J.D Grimes, Numan Turle, WhiteCyberSec for each independently identifying a way for logged-in users to execute any shortcode.”