You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Colm O hEigeartaigh (Jira)" <ji...@apache.org> on 2026/09/25 06:15:00 UTC

[jira] [Closed] (CXF-9243) AuthorizationCodeGrantHandler consumes (burns) authorization code before performing validation (PKCE/redirect_uri), causing availability DoS on legitimate retries

     [ https://issues.apache.org/jira/browse/CXF-9243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Colm O hEigeartaigh closed CXF-9243.
------------------------------------
    Resolution: Won't Fix

> 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)