Handling Security Vulnerabilities in Resources

Mike

XenForo developer
Staff member
Unfortunately, security vulnerabilities are almost a fact of life in software today. Vulnerabilities have the possibility of being disastrous for users affected. Therefore, how developers fix the issues and take steps to prevent them is paramount.

For third-party resources listed in the XenForo community, we want to set out clear guidelines for reporting vulnerabilities and for how developers should handle vulnerability fixes.

Reporting a vulnerability

If you discover a what you believe to be a vulnerability in a resource, we expect you to follow a responsible disclosure approach. Please contact the resource author privately to disclose the details of the vulnerability, including as far as possible:
  • A clear explanation of the issue
  • Explanation of how it can be exploited or significance of the issue
  • Steps to reproduce or proof of concept demonstration of the issue
You should allow a reasonable amount of time for the author to acknowledge your message, determine the actions they wish to take, and to resolve the issue. Be aware that many resource authors are lone developers, so it's possible they may simply be away and unable to respond (rather than acting in bad faith and disregarding your message). Please wait at least a week for a response before escalating an issue. As long as a developer is actively engaging you, work with them directly for as long as possible before escalating the issue.

If you are unable to successfully contact the author or the author refuses to fix a genuine issue, at that point, please escalate the issue to XenForo staff. Please report the first message of the conversation (the initial disclosure) and add @Mike and @Chris D to the conversation so that we can determine the necessary actions to take. In the case of serious issues, we may remove the resource.

Developers: responding to a vulnerability report

Understand that security issues are essentially inevitable. They are potentially very significant, so you should treat analyzing a vulnerability as a top priority, even if you believe it may not be legitimate.

If you confirm that the issue is legitimate and it is a serious issue, you should consider releasing a fix as soon as possible. Serious issues can include (but aren't limited to) SQL injection and remote code execution; some XSS issues can also be very serious. You should make a determination about the significance of the issue on a case by case basis. You may wish to resolve less serious issues in your next regularly scheduled release; if you are unsure of how serious an issue may be, err on the side of caution and release a fix as soon as possible.

When releasing an update that resolves a security issue, you update details should include:
  • A clear indication that there was a fix for an exploitable issue
  • A basic explanation of the issue fixed and what it could have led to (for example, you may have fixed an SQL injection, which could allow the database and user accounts to be compromised)
  • A reporter credit, if the issue was responsibly disclosed and you've received confirmation from the reporter
If you do not respond to or resolve a vulnerability report, the issue may be escalated to the XenForo staff. We may be able to provide some guidance on the issue, but we will not fix the issue on your behalf. If the issue cannot be resolved, in serious cases, we may need to remove the resource from the XenForo Community until the issue is fixed.
 
It would be worth still following the same procedure, but if that coincides with the author not being online for an extended period of time (or otherwise being unable to respond) then it might be worth escalating to us sooner.
 
Sounds like a resonable action plan. But what if said vulneribility is already made public knowledge, on some of these havker sites, and is being actively exploited on some sites?
 
Still follow the same procedure, but it may be worth escalating to us at the same time, e.g. start a conversation with the author, Mike and I.
 
Top Bottom