CVE-2026-54677 in Scoold
Summary
by MITRE • 09/17/2026
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.is_default_space_public 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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in Scoold prior to version 1.69.0 represents a critical authorization bypass within the platform's question and answer infrastructure, specifically affecting environments configured with private spaces where public access is restricted. The core technical flaw resides in an inconsistency between read and write operations regarding space membership verification. While the application correctly enforces access controls when users attempt to view or retrieve questions from private spaces through standard read paths, it fails to apply equivalent authorization checks during content creation endpoints. Specifically, the QuestionController.reply() method and CommentController.createAjax() endpoint do not validate whether the authenticated user possesses the necessary permissions for the target space before allowing them to post replies or comments. This architectural oversight allows any authenticated user who can enumerate a question identifier within a private space to inject content into that thread without being granted read access, effectively creating an asymmetric permission model where write operations are permitted while read operations remain restricted.
From a technical perspective, this flaw is classified under CWE-862, which denotes Missing Authorization, as the application fails to enforce proper checks on user actions for specific resources. The attack vector leverages the fact that question identifiers can often be enumerated through various means such as URL patterns or API responses from other public interactions, allowing an attacker with a valid session token to target private threads they are not officially members of. By sending POST requests to /question/{id} and /comment endpoints, malicious actors can inject replies and comments into discussions intended for confidential team communication. This capability undermines the fundamental security boundary established by the is_default_space_public configuration setting, rendering the privacy settings ineffective against authenticated but unauthorized users who possess sufficient knowledge of internal identifiers.
The operational impact of this vulnerability extends beyond simple data leakage or modification. The ability to post content in private spaces can lead to significant information disclosure through side-channel effects such as notification systems. When a user posts in a restricted thread, it may trigger notifications sent to space members via email or in-app alerts, thereby revealing the existence of the discussion and potentially exposing metadata about ongoing confidential activities even if the attacker cannot read the content themselves. Furthermore, this unauthorized modification can corrupt the integrity of private discussions by introducing spam, misinformation, or malicious links that are visible only to authorized members but originated from an untrusted source. This erodes trust in the platform's ability to maintain secure silos for sensitive team collaboration and knowledge sharing.
To mitigate this risk, organizations running Scoold must upgrade immediately to version 1.69.0 or later, where the developers have implemented consistent authorization checks across both read and write operations for space resources. Until an upgrade is feasible, administrators should consider restricting public registration if possible to limit the pool of potential attackers to known entities, although this does not fully mitigate the risk from compromised accounts. Additionally, implementing strict input validation and monitoring logs for unusual patterns in POST requests to question and comment endpoints can help detect ongoing exploitation attempts. This incident highlights the importance of applying defense-in-depth principles where authorization checks are uniformly enforced across all API endpoints interacting with sensitive resources, aligning with ATT&CK techniques related to unauthorized access to restricted information within enterprise environments.