-
-
Notifications
You must be signed in to change notification settings - Fork 11.7k
fix(mcp): forward short OAuth state upstream, keep session in a cookie #32146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
tin-berri
merged 2 commits into
litellm_internal_staging
from
litellm_mcp_short_oauth_state
Jul 6, 2026
+250
−14
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HTTPException skips cookie cleanup
Medium Severity
On the successful
/callbackpath, when_get_validated_client_redirect_uriraisesHTTPException, the handler re-raises without calling_clear_oauth_state_cookie. Other failure branches in the same handler clear the one-timemcp_oauth_state_*cookie, so the encrypted OAuth session can remain in the browser for the fullMax-Age.Reviewed by Cursor Bugbot for commit 444446e. Configure here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Accurate read of that branch, and it is intentional; the exposure is low enough that reworking it would cost more than it saves
The only thing that raises
HTTPExceptioninside thattryis_get_validated_client_redirect_uri, so the cookie survives only when the decodedclient_redirect_urifails the sink-side VERIA-57 trust check. The re-raise is deliberate; it surfaces that as a 400 rather than the generic authentication-incomplete fallback, and it is pinned by the existing VERIA-57 regression tests, which assertpytest.raises(HTTPException)withstatus_code == 400. Converting the branch to a returned response so it can clear the cookie would break that contract and route around the proxy'sHTTPExceptionhandlerThe surviving cookie is also inert. It carries the encrypted
{original_state, client_redirect_uri, code_challenge, ...}blob with no tokens and no authorizationcode; it isHttpOnlyandSecure, and it expires within its 600sMax-Age. Any replay re-runs the same validation and re-fails with the same 400, and thecodeis only appended to the redirect after validation passes, so a surviving cookie cannot leak it to the untrusted URI. A retry mints a fresh handle and cookie and orphans the stale one, and for the loopback native-client flows this targets the branch never fires at all, since loopback validates identically at/authorizeand/callback; it needs a same-origin UI redirect plus an origin shift between the two requestsLeaving it as intentional on that basis. If strict parity across every branch is wanted later, the safe way is to attach the delete-cookie to the raised exception's headers so the 400 contract and the handler both stay intact, rather than returning a response