CVE-2026-57183 in Scoold
Summary
by MITRE • 10/15/2026
Scoold is a Q&A and a knowledge sharing platform for teams. Prior to 1.69.1, checkApiAuth() in src/main/java/com/erudika/scoold/utils/ScooldUtils.java accepts a JWT signed with app_secret_key or para_secret_key for /api/config and /api/stats without requiring a registered API-key jti, and maps the request to the hardcoded administrative API_USER. The special endpoint checks run even when scoold.api_enabled is false. An attacker who obtains either signing secret can forge a token that reads sensitive configuration and server logs and reaches privileged configuration functionality, while an ordinary login-session token is not sufficient. This issue is fixed in version 1.69.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Scoold prior to version 1.69.1 represents a critical authentication bypass within the platform's API infrastructure, specifically affecting endpoints designed for configuration management and statistical data retrieval. Scoold operates as a Q&A and knowledge-sharing platform where administrative functions are typically protected by strict access controls. However, the implementation of the checkApiAuth method in the ScooldUtils utility class contained a logical flaw that allowed unauthorized actors to escalate privileges under specific conditions. The core issue lies in how the application validates JSON Web Tokens (JWTs) for requests directed at /api/config and /api/stats endpoints. Instead of enforcing a multi-factor verification process involving both a valid signature and a registered API key identifier, the system relied solely on the cryptographic validity of the token's signature.
From a technical perspective, the flaw stems from an incomplete validation routine that accepts any JWT signed with either the app_secret_key or the para_secret_key as legitimate administrative access. The application maps these requests directly to a hardcoded administrative user account designated as API_USER without verifying whether the token includes a valid jti (JWT ID) claim corresponding to a registered and authorized API key in the system's database. This design oversight means that possession of one of the signing secrets is sufficient to forge tokens with arbitrary claims, effectively bypassing the intended authentication mechanism. Furthermore, this vulnerability persists even when the scoold.api_enabled configuration flag is set to false, indicating that the security check was not properly gated by the feature toggle and remained active for these specific endpoints regardless of administrative intent to disable API access.
The operational impact of this vulnerability is severe due to the nature of the affected endpoints. The /api/config endpoint exposes sensitive server configurations which may include database connection strings, third-party service credentials, or internal application settings that are not intended for public exposure. Similarly, the /api/stats endpoint provides access to server logs and usage statistics that can reveal architectural details, user activity patterns, and potentially other confidential data. An attacker who obtains either signing secret through source code leakage, configuration file exposure, or side-channel attacks can forge a JWT token claiming administrative privileges. This allows them to read sensitive configuration data and view server logs without any form of legitimate authentication, leading to significant information disclosure. The fact that ordinary login-session tokens are insufficient for this access highlights the specific nature of the flaw as an API-level privilege escalation rather than a general session hijacking issue.
This vulnerability aligns with CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity, as it involves failing to properly verify that the entity presenting credentials is authorized for the requested action using all required factors. In terms of attack vectors, this behavior corresponds to MITRE ATT&CK technique T1078 Valid Accounts, specifically involving legitimate accounts or tokens being misused due to weak validation logic. The ability to access administrative functions without proper authorization also touches upon CWE-269 Improper Privilege Management. To mitigate this risk, organizations running Scoold must upgrade immediately to version 1.69.1 where the checkApiAuth method has been corrected to enforce strict verification of registered API keys alongside signature validation. Additionally, administrators should ensure that signing secrets are stored securely using environment variables or secret management systems rather than hardcoding them in configuration files accessible via source control repositories. Regular auditing of JWT implementations and ensuring that security controls remain active regardless of feature toggles is essential for maintaining robust application security posture.