Today, we are writing to share the discovery and squashing of a bug that occurred earlier this year. This particular bug was also one of the rare instances in which we kept a Phabricator ticket private to address a security issue. To help address questions about when and why we make a security-related ticket private, we’re also sharing some insight into what happens when a private ticket about a security issue is closed.

Late last year, User:Suffusion of Yellow spotted a bug that could have allowed an association to be made between logged-in and non-logged-in edits made from the same IP address. Users with dynamic IP addresses could have been affected, even if they personally never made any non-logged-in edits.

Suffusion of Yellow created a Phabricator ticket about it, and immediately worked to get eyes on the issue. The bug was repaired with their help. We’re grateful for their sharp eyes and their diligent work to diagnose and fix the problem. As part of our normal procedure, the Security team investigated once the bug was resolved. They found no evidence of exploit. We are not able to reveal further technical details about the bug, and here is why:

When a Phabricator ticket discussing a security bug is closed, Legal and Security teams at the Wikimedia Foundation evaluate whether or not to make the ticket public. Our default is for all security tickets to become public after they are closed, so that members of the communities can see what issues have been identified and fixed. The majority of tickets end up public. But once in a while, we need to keep a ticket private.

We have a formal policy we use to determine whether a ticket can be publicly viewable, and it calls for consideration of the following factors:

• Does the ticket contain non-public personal data? For example, in the case of an attempt to compromise an account, the ticket may include IP addresses normally associated with the account, to identify login attempts by an attacker.
• Does the ticket contain technical information that could be exploited by an attacker? For example, in discussing a bug that was ultimately resolved, a ticket may include information about other potential bugs or vulnerabilities.
• Does the ticket contain legally sensitive information? For example, a ticket may contain confidential legal advice from Foundation lawyers, or information that could harm the Foundation’s legal strategy.

In this case, we evaluated the ticket and decided that it could not be made public based on the criteria listed above.

Even when we can’t make a ticket public, we can sometimes announce that a bug has been identified and resolved in another venue, such as this blog. In this case, Suffusion of Yellow encouraged us to make the ticket public, and while pandemic-related staff changes have caused a delay, that request reminded us to follow through with this post. We appreciate their diligence. Keeping the projects secure is a true partnership between the communities of users and Foundation technical staff, and we are committed to keeping users informed as much as possible.

Respectfully,

David Sharpe
Senior Information Security Analyst
Wikimedia Foundation