MyBB is free and open source forum software. Prior to version 1.8.39, the search component does not validate permissions correctly, which allows attackers to determine the existence of hidden (draft, unapproved, or soft-deleted) threads containing specified text in the title. The visibility state (mybb_threads.visible
integer column) of threads is not validated in internal search queries, whose result is used to output a general success or failure of the search. While MyBB validates permissions when displaying the final search results, a search operation that internally produces at least one result outputs a redirect response (as a HTTP redirect, or a success message page with delayed redirect, depending on configuration). On the other hand, a search operation that internally produces no results outputs a corresponding message in the response without a redirect. This allows a user to determine whether threads matching title search parameters exist, including draft threads (visible
with a value of -2
), soft-deleted threads (visible
with a value of -1
), and unapproved threads (visible
with a value of 0
); in addition to displaying generally visible threads (visible
with a value of 1
). This vulnerability does not affect other layers of permissions. In order to exploit the vulnerability, the user must have access to the search functionality, and general access to forums containing the thread(s). The vulnerability does not expose the message content of posts. MyBB 1.8.39 resolves this issue.
The product prevents direct access to a resource containing sensitive information, but it does not sufficiently limit access to metadata that is derived from the original, sensitive information.
Developers might correctly prevent unauthorized access to a database or other resource containing sensitive information, but they might not consider that portions of the original information might also be recorded in metadata, search indices, statistical reports, or other resources. If these resources are not also restricted, then attackers might be able to extract some or all of the original information, or otherwise infer some details. For example, an attacker could specify search terms that are known to be unique to a particular person, or view metadata such as activity or creation dates in order to identify usage patterns.