When Is It Right To Keep WordPress Vulnerabilities Secret?
Bugs are an inevitable part of the software development process. As hard as developers try to avoid them — and they try very hard indeed — mistakes will be made and some of those mistakes will cause security vulnerabilities. What’s important is how developers handle vulnerabilities when they do occur, including how they communicate about them with users.
In the open source and security world, it’s generally agreed that when a vulnerability is discovered, as much information as possible should be provided to users. They need to know about the vulnerability so they can protect themselves. Information is power where security is concerned, and if only criminals and security researchers know about a vulnerability, users are at an unfair disadvantage. As Aaron D. Campbell, WordPress Core Security Team Lead, remarks in a recent blog post,
“Disclosing the vulnerability is best for your users. It builds trust. It’s also the best thing you can do for the future of security. Hopefully other people can learn from your issue and not have to face the same one themselves.”
But sometimes, developers and security researchers choose to keep vulnerability information to themselves, for a short time at least. Secrecy rubs some people up the wrong way, and for good reason. Professionals and other developers need all the information they can get to protect their sites, users, and clients. They don’t trust developers to make sensible decisions about what should be kept secret, an attitude informed by a long history of vulnerabilities that were hidden to benefit developers and their companies rather than users.
This January, WordPress 4.7.2 was released. It included a patch for a serious vulnerability, but there was no mention of the patch in the initial release notes. Details of the vulnerability were released several days later, much to the chagrin of those who demand complete and immediate transparency. In this case, WordPress developers were justified in keeping the vulnerability to themselves.
It’s important to distinguish between secrecy to protect users and secrecy for selfish reasons. There are many selfish reasons a developer might want to keep a vulnerability secret: because it makes them look bad, because it might discourage people from buying their product, and, in the worst cases, because keeping it a secret is less expensive than fixing it. None of those reasons apply to WordPress and most other open source projects.
When a WordPress update is released, it’s installed by millions of site owners in the following days. The release is also scrutinized by criminals who know that many WordPress sites won’t be updated immediately. They use information gleaned from the public disclosure of vulnerabilities to attack WordPress sites that have not been patched.
While there’s nothing to prevent criminals from analyzing the code of an update to discover what is being patched, declining to widely publicize vulnerabilities gives WordPress users a chance to update before criminals begin to exploit a vulnerability.
In good time, all vulnerabilities should be announced and publicized. No one wants to go back to the dark days of security by obscurity. Users and professionals who want to know about vulnerabilities as soon as possible have a good case, but a project’s developers have a difficult decision to make: publicize a vulnerability immediately and put users at risk, or hold off and give them time to update. Vulnerabilities should be kept secret for no more than a few days, but sometimes protecting users is more important than complete transparency.
