CVE-2026-73085 in Audiobookshelf exposes a pattern you should be hunting in your own code: refresh tokens accepted as access tokens due to missing token_type validation in the auth middleware. The vulnerability scores 5.3 because it requires the attacker to already possess a refresh token — but that precondition is weaker than it appears. Refresh tokens live longer, transmit more frequently (on every silent refresh), and in many self-hosted applications live in localStorage or mobile storage rather than httpOnly cookies, making theft more feasible than CVSS assumes.
The core failure is architectural: JWT middleware that accepts any valid token and delegates claim enforcement to the developer creates a frictionless path for exactly this mistake. When 'valid signature + user ID' is sufficient to pass, the secure path (explicitly validating token_type) requires an extra step the framework doesn't make mandatory. This is why this bug class keeps appearing across projects — the abstraction that makes auth middleware convenient is the same abstraction that makes this class of bypass easy to introduce.
For defenders: audit your auth middleware to confirm it enforces token_type (or equivalent) as a structural gate, not an optional claim. If you're using a JWT library that accepts any valid token, you're one forgotten conditional away from this vulnerability. Check whether your refresh tokens are stored in httpOnly cookies — if they're in localStorage or mobile storage, the practical severity is closer to 8 than 5. The fix in 2.36.0 adds the missing check; the question for your codebase is whether token type is a gate or a suggestion.