CVE-2026-55840 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, 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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Scoold prior to version 1.69.1 represents a critical Open Redirect flaw rooted in flawed input validation logic within the HttpUtils utility class. Specifically, the getBackToUrl method was designed to validate redirect parameters such as backto and returnto by checking if they start with the configured server URL using case-insensitive string comparison via Strings.CI.startsWith. This approach assumes that a simple prefix match is sufficient to ensure the destination remains within the trusted domain boundaries. However, this logic fails to account for the behavior of Java's URI.resolve() method when processing absolute URLs. When an attacker supplies an absolute URL where the hostname begins with the legitimate server's hostname but includes additional path segments or subdomain structures that alter resolution semantics, the URI resolver may retain the malicious host rather than treating it as a relative path appendage to the base URL. This technical oversight allows an adversary to bypass the intended security controls and force the application to redirect users to arbitrary external domains after authentication events.
The operational impact of this vulnerability is significant due to its potential for facilitating phishing attacks and credential theft. Since Scoold serves as a Q&A and knowledge sharing platform, it frequently handles user authentication flows where successful login attempts result in redirects back to previously visited pages or specified return URLs. An attacker can craft a malicious sign-in link containing the vulnerable redirect parameter pointing to a domain controlled by them but constructed to pass the prefix check. When an authenticated victim clicks this link, they are seamlessly redirected away from the legitimate Scoold instance to the attacker's site without any obvious warning indicators in many browser contexts. This seamless transition exploits user trust in the initial authentication step and can be leveraged to harvest sensitive credentials, session tokens, or personal data through deceptive login forms that mimic the original application interface.
From a classification perspective, this vulnerability aligns with CWE-601, which describes URL Redirection to Untrusted Site (Open Redirect). The root cause lies in insufficient validation of user-supplied input used for redirect destinations, failing to enforce strict domain matching rules rather than relying on superficial string prefixes. In the context of the MITRE ATT&CK framework, this technique falls under T1566.002, specifically Phishing: Spearphishing Link, as it enables attackers to deliver malicious links that appear legitimate by leveraging trusted domains for initial access and subsequent credential harvesting. The vulnerability highlights a common pitfall in web application development where developers assume that checking the start of a URL string is equivalent to validating its host component, ignoring how URI resolution algorithms interpret absolute versus relative paths differently depending on the structure provided.
To mitigate this risk, organizations running Scoold versions prior to 1.69.1 must upgrade immediately to version 1.69.1 or later, where the developers have corrected the validation logic to properly handle absolute URLs and prevent redirection to untrusted hosts. For environments unable to patch immediately, implementing a Web Application Firewall rule that inspects redirect parameters for patterns indicating external domains can provide temporary protection. Additionally, adopting strict allow-listing practices for all redirect destinations ensures that only explicitly approved internal paths are permitted, eliminating reliance on heuristic prefix matching which is inherently susceptible to bypass techniques involving absolute URL structures and URI resolution quirks.