Scoold vulnerabilities

Scoold is a Q&A and knowledge sharing platform for teams. Prior to 1.69.1, checkApiAuth() in 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.

Scoold is a Q&A and knowledge sharing platform for teams. Prior to 1.69.1, apiCorsConfiguration() in ScooldServer.java combines addAllowedOriginPattern("*") with setAllowCredentials(true), causing Spring to reflect any requesting origin while allowing cookies or session tokens. A malicious website visited by a logged-in Scoold user can therefore issue authenticated API requests, read user data, questions, and configuration, and trigger state-changing operations on the user's behalf.

Scoold is a Q&A and knowledge sharing platform for teams. Prior to 1.69.1, getBackToUrl() in HttpUtils.java validates the backto and returnto parameters with Strings.CI.startsWith against the configured server URL. An attacker can supply an absolute URL whose hostname begins with the legitimate hostname, causing URI.resolve() to retain the attacker URL and the prefix check to accept it. A victim who follows the crafted sign-in link can be redirected to an attacker-controlled domain after authentication, enabling phishing and possible credential or token theft.

Scoold is a Q&A and 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 QuestionController.reply() and 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.

Scoold is a Q&A and 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 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.

In Scoold prior to version 1.67.0, the admins configuration value can be modified through /api/config/set/admins using a forged Bearer token accepted as an admin API token. Once changed, the target email is written to the application configuration file, and after a Scoold restart the selected user is recognized as an administrator and gains admin panel access. This gives an attacker a reliable persistence path. The issue is patched in version 1.67.0.

Scoold, a Q&A and knowledge sharing platform for teams, has an authorization flaw that allows any logged-in, low-privilege user to overwrite another user's existing question by supplying its public ID as the postId parameter. This affects versions prior to 1.66.2.

Scoold prior to version 1.66.1 does not enforce authorization when deleting feedback – any logged-in user can delete another user's feedback by providing its ID. Object ownership or moderator privileges are not checked.