Authorize/consent page: open redirect on both Deny and Approve paths

⚠️ Search for existing issues first ⚠️

• I have searched the existing issues, and there is no existing issue for my problem

Which Operating System are you using?

Docker

Which version of AutoGPT are you using?

Master (branch)

What LLM Provider do you use?

Other (detail in issue)

Which area covers your issue best?

Other

What commit or version are you using?

c035ab1f91b8556f86e87be26dcaf31677f64ba5

Describe your issue.

The authorize/consent page (route /auth/authorize, file page.tsx) treats the redirectURI query parameter as a trusted navigation target: Deny navigates to it verbatim via window.location.href (page.tsx:111-118, no scheme/host validation anywhere on the page); Authorize unconditionally follows response.data.redirect_url (:96-101, the product of the backend error branches). Verified in a real browser: both paths navigated to an attacker-controlled external domain and rendered it.

Expected behavior

Validate redirectURI against the client's registered callback (fetched by client_id) before rendering/navigating; the Deny branch must not navigate to unregistered URIs either.

Actual behavior

Setup: an OAuth app poc-app exists in the platform with the registered callback https://registered-callback.example/real — the only URL this app should ever be allowed to redirect a user to. The consent page is the page a logged-in user sees at /auth/authorize?... after opening an authorize link; it shows the app name plus Authorize / Deny buttons.

1. The attacker sends the victim an authorize link whose redirect_uri points at the attacker's domain instead of the app's registered callback:

   https://<platform-host>/auth/authorize?client_id=poc-app&redirect_uri=https://example.com/deny-phish&response_type=code&state=st777

2. The victim opens the link → the consent page renders normally; nothing signals that redirect_uri is unregistered.

3. The victim clicks Deny → the browser navigates verbatim to https://example.com/deny-phish?error=access_denied&error_description=User+denied+access&state=st777; the attacker's external page is actually rendered.

4. The victim clicks Authorize instead (with response_type=token in the link, so the backend hits its unsupported-response_type error branch) → the backend returns 200 with a redirect_url built from the same tampered redirect_uri, and the page follows it: https://example.com/approve-phish?error=unsupported_response_type&state=st999&… — again the attacker's page.

5. The intermediate error states (nonexistent app, bad parameters) render a "Return to Application" button that navigates the same way.

In none of these paths is redirect_uri compared against the app's registered callback.

Upload Activity Log Content

No response

Upload Error Log Content

No response