[
https://issues.apache.org/jira/browse/CXF-9243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18119050#comment-18119050
]
Colm O hEigeartaigh edited comment on CXF-9243 at 9/25/26 6:14 AM:
-------------------------------------------------------------------
{*}{*}Consuming the code first is intentional. It follows RFC 6749
§4.1.2/§10.5, RFC 6819 §5.2.1.1 and RFC 9700, and it keeps redemption atomic.
Checking before removing would open a double-redemption race and would allow
repeated attempts against an intercepted code. The legitimate client recovers
by starting a new authorization request.
was (Author: coheigea):
{*}{*}Consuming the code first is intentional. It follows RFC 6749
§4.1.2/§10.5, RFC 6819 §5.2.1.1 and RFC 9700, and it keeps redemption atomic.
Checking before removing would open a double-redemption race and would allow
repeated attempts against an intercepted code. The legitimate client recovers
by starting a new authorization request.
> AuthorizationCodeGrantHandler consumes (burns) authorization code before
> performing validation (PKCE/redirect_uri), causing availability DoS on
> legitimate retries
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-9243
> URL: https://issues.apache.org/jira/browse/CXF-9243
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
> Affects Versions: 4.2.3
> Environment: Apache CXF 4.2.3, OAuth2 Authorization Code Grant with
> PKCE.
> Reporter: Guanping Zhang
> Priority: Minor
>
> h3. Problem
> In AuthorizationCodeGrantHandler, the authorization code is consumed (removed
> from the data provider store) at line 57 BEFORE any validation checks are
> performed. The expiry check, client_id match, redirect_uri match, and PKCE
> verification all run AFTER the code is already deleted.
> If ANY check fails (e.g., an attacker intercepts the code and submits a
> wrong/absent code_verifier for a PKCE-protected public client), the flow
> throws INVALID_GRANT — but the code is permanently burned. The legitimate
> client's subsequent correct retry receives null and fails with HTTP 400.
> h3. Impact
> This is an availability defect (CWE-400 / CWE-367). While PKCE successfully
> prevents the attacker from obtaining a token (confidentiality preserved), the
> consume-first ordering defeats the availability guarantee for the legitimate
> user, who did everything correctly but is denied access due to the attacker's
> interference.
> h3. Suggested Fix
> Reorder the logic to peek-and-validate: retrieve the grant, perform all
> validation checks (including PKCE), and only consume (delete) the code
> atomically if all checks pass.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
