Fix unbounded server-controlled retry sleep on HTTP 429 (OKTA-1235975) - #1707
Open
prachi-okta wants to merge 2 commits into
Open
prachi-okta wants to merge 2 commits into
prachi-okta wants to merge 2 commits into
Conversation
The 429 retry delay was computed entirely from the server-supplied x-rate-limit-reset header with no upper bound, so a malicious or MitM server could force the client thread to sleep indefinitely. Since this can happen inside OAuth2ClientCredentials.applyToParams (synchronized), one blocked thread could stall every other caller waiting on token refresh. RetryUtil.get429DelayMillis now clamps the computed delay to a maxDelayMillis ceiling. OktaHttpRequestRetryStrategy derives that ceiling from retryMaxElapsed if explicitly configured, otherwise falls back to the same 20s cap already used for 503/504/IOException retries. DefaultClientBuilder now actually wires clientConfig.getRetryMaxElapsed() into the strategy, which was previously set on ClientConfiguration but never read anywhere. Co-Authored-By: Claude Code
httpclient5 5.6.2 fails to release the underlying connection back to the connection manager on an invalid/unsupported Content-Encoding header value in the classic I/O model, allowing connection pool exhaustion (DoS). Fixed upstream in 5.6.3+; bumping to the latest 5.6.x patch release. Co-Authored-By: Claude Code
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
OKTA-1235975: the SDK's 429 retry delay was computed entirely from the server-suppliedx-rate-limit-resetheader with no upper bound, so a malicious or MitM server could force the client thread to sleep indefinitely. Since this sleep can happen insideOAuth2ClientCredentials.applyToParams(synchronized), one blocked call could stall every other caller waiting on token refresh — a client-side DoS triggerable by untrusted response data.RetryUtil.get429DelayMillisnow clamps the computed delay to amaxDelayMillisceiling.OktaHttpRequestRetryStrategyderives that ceiling fromretryMaxElapsedif explicitly configured, otherwise falls back to the same 20s cap already used for 503/504/IOException retries — so 429 is no longer the exception.DefaultClientBuildernow actually wiresclientConfig.getRetryMaxElapsed()into the strategy (previously set onClientConfigurationbut never read anywhere — dead config).requestTimeout/setRetryMaxElapsedescape hatch for anyone who needs a longer wait.Separately (own commit, unrelated root cause): bumps
httpclient55.6.2 → 5.6.4 to resolve CVE-2026-64607 (connection-leak DoS in the classic I/O model on malformedContent-Encodingheaders), found while chasing an unrelated stalledrelease:preparerun. This supersedes the existingdependabot/maven/.../httpclient5-5.6.3branch.Have added more details of the fix in the comments: https://oktainc.atlassian.net/browse/OKTA-1235975