An insight in to the program
At MyBB, maintaining secure software is one of our strategic priorities. Both ourselves and our users need to trust that the software they’re using is secure and will remain secure throughout the years. We’ve encountered vulnerabilities which have been disclosed to us by members of the Community and encountered some which have been spread around the web. The latter is something which we want to avoid to protect our users and make understanding the issue easier.
Security contributors to the 1.8.x branch will be listed in the Release Notes of corresponding releases as well as associated Release Blog Posts.
In case of vulnerabilities affecting themes or plugins, we recommend additionally contacting their authors.
How to report a vulnerability
If you have discovered a potential vulnerability or security risk, we encourage you to responsibly disclose it to us via the Private Inquiries forum.
Do not use the form if you notice your browser displays HTTPS warnings, or anything otherwise suspicious happens. You can optionally encrypt your message using GPG keys of at least 3 role leaders, available at https://mybb.com/about/team/.
You can also reach us at [email protected] for security concerns, however we recommend using Private Inquiries for best feedback.
Composing a Good Report
Create a short and descriptive subject (identification, location and vulnerability type) with the [Vulnerability Report] prefix for each vulnerability found (or suspected).
Please compose a brief summary of the issue, followed by more detailed technical analysis. This can include:
- factors contributing to the problem,
- how the vulnerability might be exploited,
- which version was tested,
- proof-of-concept (PoC) - simple demonstration of how the vulnerability might be exploited,
- steps to reproduce the issue or arrive at a vulnerable state,
- error/access/action logs (if applicable),
- whether the vulnerability is public or known to anyone else,
- how the issue was discovered (which tools, regular expressions, checklists, etc.),
- related external resources and references (e.g. reports, analyses for similar issues in other software),
- whether other software packages are affected,
- suggested solutions (code change descriptions, patch/diff files),
- how the process can be improved to prevent similar issues in the future,
- whether publications related to the issue are planned or expected.
You can refer to the MyBB codebase using the repository - for example, you can point anyone to lines 13-16 (
#L13-16) of file
inc/class_session.php in MyBB 1.8.17 (
/mybb_1817/) like this:
More information will likely reduce the estimated resolution time. Please remain available for contact in case more information is needed. The Private Inquiries thread will be used for feedback related to your submission by the MyBB Team.
Additionally, you can include your name, company/group affiliation and personal website (if applicable) that may be used for disclosure attribution in Release Notes and the Release Blog Post.
You should not test, demonstrate or exploit the vulnerability on any active MyBB installations not created to test such vulnerabilities (we recommend using a local copy) nor the MyBB Group infrastructure or its resources.
In order to minimize threats to privacy, safety and security of installations, their administrators and users, we urge you to not disclose any information related to your report to parties other than the MyBB Team through official communication channels until an official solution is published. The Private Inquiries section is monitored daily — avoid notifying or reminding the Team members in publicly accessible channels.
How to be recognized for discovered issues
Attribution is applicable to persons/entities who, having discovered security issues, follow the disclosure process satisfying the following criteria:
- the software in question is limited to the MyBB forum software (vulnerabilities within third party extensions do not count),
- the vulnerability is technical (techniques such as social engineering or phishing do not count),
- the vulnerability affects confidentiality, integrity or availability of the software directly (disclosure of operational information included in PHP or SQL errors, spam attacks, bypassing CAPTCHAs do not count),
- the vulnerability is present in the latest stable release of a supported software branch (vulnerabilities within development releases or older versions do not count),
- no MyBB installations are tested or exploited without explicit permission of their owners,
- no part of the MyBB Project infrastructure or resources (including the Community Forums) is exploited,
- no details regarding the vulnerability are published before it has been addressed.
If you are not sure whether you are eligible — contact us: depending on circumstances, exceptions are possible.
Even if you do not meet the requirements to be eligible for bragging rights or have information that don’t directly translate to vulnerabilities (such as suspicion of security breaches or exploitation of MyBB boards in the wild), do not hesitate to reach us — the MyBB Team members are in the best position to coordinate efforts to improve security of our ecosystem.
Security Workflow for Researchers
Handling of submitted reports
As MyBB is a not-for-profit FOSS project, release times may vary greatly; nonetheless, subsequent versions are expected to address all known vulnerabilities up to the point of their release. In exceptional cases we will otherwise contact the reporter and continue providing follow-up information when such appears. Summaries of vulnerabilities that are not intended to be addressed in near future are published by the Team in
SECURITY.md files in software repositories.
As a vulnerability reporter or external security researcher, you will likely receive multiple responses as your report is processed:
Your report is posted in the Private Inquiries section, tagged [Vulnerability Report].
If no instant assessment is possible, a Team member will initially recognize your report, notify members responsible for handling security issues and take preliminary actions to make sure the responsible disclosure process is correctly followed.
Following internal analysis, the Team will inform you whether your submission is confirmed, invalid, or no fix is expected.
In case of rejection, we recommend delaying public disclosure (if applicable) by at least 7 days to mitigate risk of mistaken and malicious responses. If necessary, you can attempt to reach individual Team members personally via details provided at https://mybb.com/about/team/.
Team members might ask for additional details related to the report or disclosure process. During and after the solution development the patch details may be forwarded to you to verify that all vulnerabilities will be properly addressed in the upcoming solution.
You will be notified once the software version addressing the issue is released.
MyBB aims to promote security research and increase security awareness. If you have published — or intend to publish — an analysis, article or summary after all issues have been resolved, we encourage you to point us to these resources.
We recommend delaying the publication by at least 14 days starting from the day the solutions were officially published to give administrators time to update their installations before exploitation techniques are widely known.
As MyBB currently does not automatically request CVE numbers for vulnerabilities, researchers can request them individually from appropriate Numbering Authorities.
You can learn how MyBB handles vulnerability reports internally from the Security Workflow.