CVE-2026-54677: Scoold: Authenticated user can post replies and comments to private-space questions without space membership
Scoold is a Q&A and a knowledge sharing platform for teams. Prior to 1.69.0, authenticated users who are not members of a private space can create content in questions belonging to that space because src/main/java/com/erudika/scoold/controllers/QuestionController.java in QuestionController.reply() and src/main/java/com/erudika/scoold/controllers/CommentController.java in CommentController.createAjax() do not apply the canAccessSpace authorization check used by the question read path. With scoold.isdefaultspacepublic set to false and private spaces in use, a user with a valid session and a known or enumerable question identifier can send requests to POST /question/{id} and POST /comment, causing replies and comments to be stored in a thread the user cannot read. This permits unauthorized modification of private discussions and can trigger notifications that reveal the existence or metadata of private activity. This issue is fixed in version 1.69.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Scooldto a version that resolves this vulnerability.Fixed in 1.69.0
Event History
Frequently Asked Questions
Which deployments are exposed?
Scoold deployments prior to 1.69.0 are affected when private spaces are in use and scoold.is_default_space_public is set to false. The issue concerns questions belonging to those private spaces.
What does an attacker need to exploit this?
An attacker needs a valid authenticated session but does not need membership in the target private space. They also need a known or enumerable question identifier and can submit requests to POST /question/{id} or POST /comment.
What is the practical impact?
A non-member can store replies or comments in a private-space discussion they cannot read, resulting in unauthorized modification of private discussions. Resulting notifications can also reveal the existence or metadata of private activity.
How can I determine whether my instance is vulnerable?
Check whether the Scoold version is earlier than 1.69.0, whether private spaces are used, and whether scoold.is_default_space_public is false. In that configuration, test authorization for an authenticated non-member attempting to create a reply or comment on a private-space question.
What should be done to remediate the issue?
Upgrade Scoold to version 1.69.0, which fixes the missing canAccessSpace authorization checks in reply and comment creation paths.