CVE-2026-57183: Scoold: Forged JWT Accepted as Admin API Token Allowing Unauthorized Access to Sensitive Configuration and Logs
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 appsecretkey or parasecretkey for /api/config and /api/stats without requiring a registered API-key jti, and maps the request to the hardcoded administrative APIUSER. The special endpoint checks run even when scoold.apienabled 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.
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.1
Event History
Frequently Asked Questions
Which deployments are affected?
Scoold versions prior to 1.69.1 are affected. The vulnerable checks for /api/config and /api/stats can run even when scoold.api_enabled is false.
What does an attacker need to exploit this issue?
An attacker must obtain either the app_secret_key or para_secret_key and use it to forge a JWT. A normal login-session token alone is not sufficient.
What access can a successful attacker obtain?
A forged token is treated as the hardcoded administrative API_USER for the affected endpoints. This can expose sensitive configuration and server logs and provide access to privileged configuration functionality.
What is the remediation?
Upgrade Scoold to version 1.69.1 or later. If immediate patching is not possible, protect and rotate app_secret_key and para_secret_key, since possession of either secret enables token forgery.