Unrestricted refresh-token replay: a stolen refresh_token issues 12-hour access tokens indefinitely
Submitted
The refresh endpoint accepted the same refresh_token repeatedly, always answering with a fresh 12-hour access token — 8 out of 8 attempts — with no rotation, no reuse detection and no session invalidation. A single stolen token therefore means permanent access without ever touching the password again.
Outcome
| Field | Value |
|---|---|
| Submission | SALTOSYSTEMS-QYI046FH |
| Submitted | 2026-10-05 |
| State | Closed — duplicate of SALTOSYSTEMS-T4UQKDQ3 |
| CVSS (as submitted) | AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N |
| Bounty | None — not paid |
Triager: "...this has been reported before... duplicate."
What I take from it
Same program, second duplicate in two weeks. That is a signal about the queue, not about the bugs: on a program with heavy researcher traffic, a technically solid OAuth finding will usually have been found before. If I hunt it again, the value is in the chained version (token replay + no session revocation) submitted within hours of the feature shipping, not in a clean writeup of the obvious behaviour.
Note
Refresh-token reuse without rotation is still worth testing and still worth reporting: it is one of the few authentication flaws where the proof is a loop of identical 200s.