CVE-2026-82274 in Twenty
Summary
by MITRE • 08/28/2026
Twenty through 2.35.0 contains an open redirect vulnerability in the OAuthPropagatorController.propagateOAuthCallback endpoint that treats the state query parameter as a redirect URL. Attackers can craft malicious requests to redirect users to arbitrary hosts while forwarding OAuth authorization codes, bypassing domain validation when IS_MULTIWORKSPACE_ENABLED is disabled.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in versions twenty through 2.35.0 of the software involves an open redirect flaw within the OAuthPropagatorController.propagateOAuthCallback endpoint. This specific component handles the callback phase of the OpenID Connect and OAuth authentication flows, where it is responsible for processing authorization responses from identity providers. The core technical deficiency lies in how the application processes the state query parameter during this redirection process. Instead of validating that the destination URL belongs to an expected or trusted domain list, the implementation directly utilizes the value provided in the state parameter as the target location for the HTTP redirect response. This design oversight allows any arbitrary Uniform Resource Locator supplied by a client request to be executed as the final landing page after authentication completes.
From a technical perspective, this flaw represents a classic case of improper validation of user-supplied input during navigation logic. In secure implementations, the state parameter is typically used solely for maintaining application state and preventing Cross-Site Request Forgery attacks through cryptographic randomization or hashing mechanisms that are verified server-side before any redirection occurs. Here, however, the system fails to enforce domain restrictions on this value when the configuration flag IS_MULTIWORKSPACE_ENABLED is set to false. This conditional logic gap means that under standard single-workspace configurations, which may be common in many deployments, there are no safeguards preventing an attacker from specifying external domains as redirect targets. The vulnerability effectively bypasses standard domain validation checks because the code path responsible for enforcing these restrictions is either skipped or incorrectly implemented when multi-workspace features are disabled.
The operational impact of this open redirect vulnerability extends beyond simple navigation manipulation and poses significant risks to user security and data integrity. Attackers can craft malicious URLs that appear legitimate, often mimicking the application's own domain structure in the initial part of the link while embedding a different host within the state parameter. When an unsuspecting user clicks such a link after authenticating via OAuth, they are redirected away from the trusted application to a phishing site controlled by the attacker. Because this redirection occurs immediately following successful authentication, it often carries over sensitive context or tokens if not properly isolated, potentially facilitating credential harvesting sessions that appear trustworthy due to their proximity in time and visual similarity to legitimate login flows. This mechanism is frequently exploited in targeted spear-phishing campaigns where social engineering plays a critical role in deceiving users into entering credentials on fraudulent sites.
In terms of industry standard classifications, this vulnerability aligns with CWE-601, which defines Open Redirect as the web application accepts user-controlled input that specifies a URL for redirection without proper validation against an allow list or other security controls. Furthermore, within the MITRE ATT&CK framework, this technique corresponds to T1583.002, specifically Acquire Infrastructure: Domains, and supports phishing campaigns categorized under T1566.002 as a method for delivering malicious payloads through deceptive redirections that leverage trusted domains to lower user suspicion. The exploitation of this flaw does not require complex technical bypasses but relies heavily on the social engineering aspect of tricking users into initiating the OAuth flow with a manipulated state parameter, making it particularly dangerous in enterprise environments where trust in internal or partner applications is high.
To mitigate this vulnerability and restore secure authentication flows, immediate remediation efforts should focus on enforcing strict domain validation for all redirect targets within the propagateOAuthCallback endpoint. Developers must implement an allow-list mechanism that restricts redirection URLs to a predefined set of trusted domains associated with the application's official infrastructure. Alternatively, if dynamic redirects are necessary, the state parameter should be decoupled from navigation logic entirely, serving only as a cryptographic token for session verification rather than a direct URL pointer. Additionally, reviewing and hardening the conditional logic surrounding the IS_MULTIWORKSPACE_ENABLED flag is essential to ensure that security controls remain consistent regardless of workspace configuration settings. Regular code audits focusing on OAuth implementation patterns and automated testing using fuzzing tools can help detect similar flaws in other endpoints before they are exploited in production environments.