Late last week, Yan Zhu, a Staff Technologist for the publicly a security vulnerability she discovered with WordPress.com and how it handles cookies. More specifically, she discovered the “wordpress_logged_in” cookie being sent in the clear to a WordPress authentication endpoint. She was able to use the authenticated cookie to publish blog posts, view private posts, post comments on others blogs, see their stats, and related administrative tasks that didn’t require logging in a second time.
Zhu contacted and as the directions say to within the . Within 24 hours of notifying Automattic, Zhu publicly disclosed the vulnerability on her blog. The information was picked up by resulting in millions of readers finding out about the security issue before a fix was available. What was once a good deed is now an example of irresponsible disclosure.
According to Wikipedia, is defined as:
A term describing a model. It is like , with the addition that all stakeholders agree to allow a period of time for the to be before publishing the details. Developers of hardware and software often require time and resources to repair their mistakes.
When why she didn’t give Automattic more time, Zhu responded:
However, in this case, I believe that 24hrs was a fair amount of time. The main reason is that SSL support nowadays is widely accepted as the bare *minimum* security guarantee that a website should provide for users’ private information, and this is essentially a bug in WordPress’s SSL support. “Only send auth info over SSL” has been the most basic security recommendation to website operators for the last 15+ years.
Although they’ll try to contact the reporter within 24 hours, I’d give them at least 72. The WordPress core handbook states that in all cases, you should not publish the details. The Automattic submission form states, “If you happen to find a security vulnerability in one of our services, we would appreciate letting us know before disclosing the issue publicly.” Perhaps the Automattic submission form should also request that reporters not publish the details.
Any time a security vulnerability is disclosed before it’s fixed within a reasonable time frame, it’s irresponsible disclosure. Of course, what is a reasonable time frame is subjective but common sense dictates at least 3-5 days to hear a response back. Besides, they have to verify and duplicate the report in order to come up with a fix. Even if the issue is already known to attackers or is easy to find, it doesn’t make it ok to publicize it through the media. These types of actions fan the flames and make the reporter look like the bad person.
When it comes to how long of a time frame is acceptable before going to the public, everyone likely has a different answer. It also depends on what has gone on behind the scenes. For instance, when was it reported and when did the company respond back? Did they promise a fix but haven’t released it in months? In rare instances, publicizing a vulnerability is the only way to get a company to act but should be treated as the nuclear option.
In the comments of Zhu’s article, for the report with a request that she allow more time for Automattic to act.
Thank you very much for finding and investigating this problem. If there’s a next time, I would definitely appreciate it if you gave us a few days more next time to protect users before it’s public.
Do you think Zhu is in the wrong for publishing details of the security issue too soon or was 24 hours enough time for Automattic to implement a fix? If you discovered a security vulnerability and reported it to the vendor, what would need to happen to convince you that publicizing is the only way to get it fixed?