The check is split across two requests, and that split is where the bug lives. At the authorization endpoint the server holds a code_challenge and no verifier; at the token endpoint it holds a verifier and has to go looking for the challenge it stored against the issued code [8][10]. Two implementations of that lookup pass a conformance run driven by a client that behaves. One asks a question about stored state: was this code issued with a challenge, and does SHA256 of the presented verifier match it, returning invalid_grant when it does not [9]. The other asks a question about the request in hand: is code_verifier present, and if it is, does it match [11].
Only the second one fails when somebody deletes a parameter. The five-step version in the writeup wants a position on the traffic, via HTTP MITM, a browser extension, or a malicious redirect handler, then strips code_challenge and code_challenge_method before the request lands [12]. The authorization-endpoint variant needs none of that. According to the writeup, an attacker could send a phishing link with PKCE already absent from the URL, and the server issued the unbound code without an error [14], so a stripped flow is indistinguishable from a working one on the client side.
authentik's token-endpoint fix shipped in 2023.10.4 and 2023.8.5 [13]. The authorization-endpoint CVE covers everything up to and including 2023.10.6 and 2023.8.6 [14], which is two further patch releases on the 2023.10 branch and one on 2023.8 with the flow still strippable at the front door [22]. The two map cleanly onto separate clauses of RFC 9700 §2.1.1, which sets three MUST-level requirements: support PKCE, enforce the correct code_verifier at the token endpoint when a code_challenge was present, and mitigate downgrade attacks [19]. The first CVE breaks the second requirement; the second CVE breaks the third. RFC 9700 §4.8.2 adds a case neither advisory covers, the server rejecting a token request that carries a verifier when no challenge was ever registered [20].
The one place the source shows a shipped default rather than a coding error is OpenAM, where CVE-2026-48717 describes verifier enforcement gated on a realm-wide setting named codeVerifierEnforced, disabled out of the box, so every new install accepted token exchanges with no verifier at all [15]. That is the config line the argument rests on, and it is a single product. The writeup asserts that most servers ship with enforcement disabled [4] and counts five CVEs across four codebases between 2023 and 2026 [21], but it names three of the five [23]. For the claim to transfer to your own authorization server, its default would have to look like OpenAM's rather than like a bug that got patched, which is a question your admin console answers and this evidence does not. The cost of getting it wrong falls on public clients: a confidential client presents a secret at the token endpoint, while a SPA or native app has none, leaving PKCE as the only thing binding the code to the client that started the flow [16]. In a SPA the code arrives in the redirect URL, which Referer headers hand to analytics scripts and ad networks loaded straight after the redirect [18]; on mobile, the original RFC 7636 threat model is a second app registering the same custom URI scheme and reading the redirect first [17]. Without the binding, whoever holds the code can spend it [17].
