CVE-2026-54676 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, users with personal API tokens can retrieve replies from questions in private spaces they cannot access because src/main/java/com/erudika/scoold/api/ApiController.java in ApiController.getPostReplies() does not apply canAccessSpace before returning data from GET /api/posts/{id}/answers. The issue is reachable when scoold.api_user_access_enabled and scoold.api_enabled are true and a token holder knows or enumerates a private question identifier. Under those conditions, the question endpoint can deny access while the answers endpoint returns the private reply bodies, exposing confidential team or project discussions. This issue is fixed in version 1.69.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
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 its RESTful API implementation, specifically affecting the retrieval of post replies. Scoold functions as a collaborative Q&A and knowledge-sharing platform where teams rely on private spaces for confidential discussions. The core technical flaw resides in the ApiController class, particularly within the getPostReplies method located at src/main/java/com/erudika/scoold/api/ApiController.java. When an authenticated user possesses a valid personal API token and makes a GET request to the endpoint /api/posts/{id}/answers, the application fails to enforce proper access control checks against the underlying space or project associated with the question being queried. While the initial retrieval of the question itself correctly validates whether the requesting user has permission to view that specific private content, the subsequent logic for fetching replies completely omits this verification step. This architectural inconsistency allows an attacker who knows or can enumerate a valid post identifier from a restricted area to bypass access controls and retrieve sensitive reply data directly through the API endpoint.
From a security classification perspective, this vulnerability is categorized under CWE-284, which describes Improper Access Control, as well as CWE-639, indicating Authorization Bypass Through User-Controlled Key. The attacker leverages an authorized credential but exploits a logic flaw to access resources outside their permitted scope. In the context of the MITRE ATT&CK framework, this behavior aligns with T1078, Valid Accounts, where legitimate credentials are used for unauthorized purposes, and potentially T1530, Data from Local System, if viewed through the lens of exfiltrating data that should remain isolated within specific team boundaries. The vulnerability is exploitable only under specific configuration conditions: both scoold.api_user_access_enabled and scoold.api_enabled must be set to true, and the attacker must possess a valid API token along with knowledge or ability to enumerate private question identifiers. This combination creates a scenario where confidential team discussions, project details, or sensitive operational data can be extracted by unauthorized individuals who have been granted basic access privileges but not specific permissions for those private spaces.
The operational impact of this vulnerability is significant due to the nature of Scoold as a repository for professional and potentially proprietary information. Since users with API tokens often integrate these credentials into automated scripts, monitoring tools, or third-party applications, the exposure of private replies can lead to data leakage across multiple systems that trust the integrity of the Scoold API responses. Competitors could gain insights into ongoing projects, internal team dynamics might be exposed through informal discussions in private channels, and regulatory compliance issues may arise if sensitive personal data is inadvertently shared with unauthorized parties. The ease of exploitation via simple HTTP requests means that even users with minimal technical expertise can exploit this flaw once they have identified a target post ID from other sources or through enumeration attacks against public-facing endpoints that might leak identifiers.
To mitigate this vulnerability, organizations running Scoold must upgrade to version 1.69.0 or later, where the developers have corrected the logic in ApiController.getPostReplies() to properly invoke canAccessSpace before returning any data. This ensures that every API call for post replies undergoes the same rigorous authorization checks as other endpoints within the application. For environments unable to upgrade immediately due to compatibility constraints, administrators should consider disabling public API access if it is not strictly required by business operations. Additionally, implementing strict rate limiting and monitoring logs for unusual patterns of POST ID enumeration can help detect potential exploitation attempts in real-time. It is also advisable to review existing API token permissions to ensure that users are granted the minimum necessary privileges, reducing the blast radius should a credential be compromised or misused. Regular security audits focusing on authorization logic across all API endpoints will further strengthen the platform against similar bypass techniques.