CVE-2026-55840
MediumCVSS 5.4Exploitation Probability (EPSS)
Low risk17th percentile - higher than 17% of all known CVEs
Summary
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.
Risk Assessment
An attacker can redirect a user to a malicious site after login, potentially leading to phishing and theft of credentials. This requires tricking the victim into clicking a crafted link.
Recommendation
Update Scoold to version 1.69.1 or later, which fixes this vulnerability.
Other vulnerabilities in Scoold
See all- CVE-2026-57183Medium
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.
- CVE-2026-55842Medium
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.
- CVE-2026-54677Medium
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.
- CVE-2026-54676Medium
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.
- CVE-2026-39354Medium
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.
- CVE-2026-34832Medium
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.
Original NVD description (English source)
Scoold is a Q&A and a knowledge sharing platform for teams. Prior to 1.69.1, the getBackToUrl() method in src/main/java/com/erudika/scoold/utils/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. This issue is fixed in version 1.69.1.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS