- Affected version
- 2.2.12
When a search has a valid search handler, and
This allows constructing a query which likely side-steps
For example: example search.
This will lack the normal node visibility checks that a post/thread search would have.
The problem is in
These arguments should also only be evaluated if there is a valid search handler, and the value is a member of
XF still does canView validation php-side, but this can result in more results being filtered out and which displays less results than expected to the end-user.
c.type or c.content are used , XenForo does not validate that they are covered by getSearchableContentTypes.This allows constructing a query which likely side-steps
getTypePermissionConstraints for those types.For example: example search.
This will lack the normal node visibility checks that a post/thread search would have.
The problem is in
prepareSearchQuery which handles these arguments separately (likely predating getTypePermissionConstraints being added like XF1.x had):
PHP:
protected function prepareSearchQuery(array $data, &$urlConstraints = [])
{
if ($input['search_type'] && $searcher->isValidContentType($input['search_type']))
{
$typeHandler = $searcher->handler($input['search_type']);
$query->forTypeHandler($typeHandler, $searchRequest, $urlConstraints);
}
...
if ($input['c.content'])
{
$query->inType($input['c.content']);
}
else if ($input['c.type'])
{
$query->inType($input['c.type']);
}These arguments should also only be evaluated if there is a valid search handler, and the value is a member of
getSearchableContentTypesXF still does canView validation php-side, but this can result in more results being filtered out and which displays less results than expected to the end-user.
Last edited:
