BomboBombone.exe The test for this bug was pleasantly short: send the same OAuth token request twice.
XenForo 2.3.12 answered both requests with HTTP 200. Each response contained a different access token and created its own refresh-token family. Both access tokens belonged to the same test user.
The code stayed live
grantAuthorizationCode() loaded the code, checked isValid(), and passed it to the token creator. Once the new tokens had been saved, the handler returned the response. Nothing deleted the code or marked it as spent.
Two requests reaching the validity check together could also see the same unused code and continue.
If two parties have a copy of the code, the first exchange leaves the second copy usable until expiry. An attacker needs the code, the configured client authentication, and PKCE material where applicable.
Creating a new refresh-token family on every redemption also complicates revocation. Removing the family visible to the legitimate client can leave another family created by the replay.
I reproduced the issue on XenForo 2.3.12 build 2031270. The PoC submits one code twice and checks that both tokens work and differ.
XenForo 2.3.13 atomically consumes authorization codes during token issuance, including simultaneous exchanges.