This was determined by the Security team to be suitable to post publicly
CommentDefaultFormatter does not check any access control and assumes the default permissions like 'access comments' are the only access logic in play.
You can reproduce this problem by:
Commentary from Berdir:
The problem is that we have no concept of a "can access list of entities" operation, that simply doesn't exist and would need to be handled specially, like create access, as there is no entity to operate on/with, so we can not simply introduce a new operation.
Given that there is no "proper" way to do it, not sure if this is a security issue.
There are a few other as well, for example checking for being able to create comments, that's something we could do better. But even that sounds like a normal or maybe a security hardening bug to me.
CommentDefaultFormatter itself is also just a plugin, so if you have a case like this where you want to customize comment access, you could use a different formatter...
Many other listing pages are equally hardcoded (although this is arguably more exposed than most default (config) entity listings. The only thing that comes close to the concept of overview-access is having an admin permission, see \Drupal\Core\Entity\Routing\DefaultHtmlRouteProvider::getCollectionRoute().
And last,
\Drupal\comment\CommentStorage::loadThread()implements comment_filter and entity_access (this is arguably a bit weird, since we always use ${entity_type}_access as tag. So you can for example add a condition there to deny access if the host is a certain entity or entity type.
original report:
I customized the view access logic for comments by setting my own access class. This worked for viewing a comment at comment/{comment} but not when viewing a list of comments in a comment field.
CommentDefaultFormatter does not check any access control and assumes the default permissions like 'access comments' are the only access logic in play.
Active
11.0 🔥
comment.module
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I'm not sure this can be fixed in CommentDefaultFormatter.
If ✨ Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter() Needs work adds a generic system to alter access in entity queries, then custom code could alter access in comment queries and it would hopefully apply everywhere including in CommentStorage::loadThread().