WordPress is supposed to be an open source project, but a lack of openness is a reoccurring issue. That has a negative impact on security.

According to the Security page for WordPress, “[t]he WordPress Security Team works to identify and resolve security issues across the WordPress core software.” The team is supposed to be rather large:

In addition to more than 50 trusted experts, including lead developers, security researchers, and key contributors to every component of WordPress, sponsored members of the Security Team dedicate time to identifying and addressing concerns in the software and ecosystem.

Who those people are supposed to be is hidden. So is the team itself, as it appears that there isn’t really a WordPress Security Team. The link in the quoted text doesn’t provide any information on the people who are supposed to be getting paid “to identifying and addressing concerns in the software and ecosystem.” If people are getting paid, it doesn’t appear there is basic accountability as to what they are actually doing for that pay.

The make.wordpress.org section on security consists of posts about bounties offered to others to find vulnerabilities, a post about dropping support for older versions of WordPress, and only one post about addressing a security issue. That post is from 2017. What is missing there or anyone else we can find is an accounting of known security issues that haven’t been fixed in years. We have been compiling a list of those. It is incomplete. One thing we hadn’t had time to look further into since running in to it was the issue of WordPress functions designed to prevent server-side request forgery (SSRF) failing to do that. Someone that did mentioned a response they got from WordPress about it:

In this post, I will talk about an SSRF (Server Side Request Forgery) vulnerability that I reported more than 3 months ago, and unfortunately, it has been dismissed as “a fix for this has been in the works for a few years, due to complexity and low severity.”

So they haven’t addressed the issue in years. Where the fix is in the works is also unclear. Looking at the Trac ticket system we couldn’t find a ticket that would appear related to that. Maybe there is one, but it isn’t easy to find. (We will have more on this issue and how a major WordPress security has been ignoring it in an upcoming post.)

If a security issue hasn’t been addressed in a year, it shouldn’t be something that needs to remain hidden. Standard disclosure withholding periods vary, but giving 30 days to fix an issue before disclosing it is common and Google’s Project Zero has a 90 day deadline. So well before a year an issue should have been fixed. If it hasn’t, that means its disclosure wouldn’t be a security concern or if it is, then it shouldn’t already been fixed, and disclosure is needed to make sure that the issues are getting fixed in a timely manner going forward.