CVE-2026-63493 is a high severity (CVSS 8.1) two-factor bypass in Snipe-IT before 8.7.0. A session that has passed the password check but not the second factor can create a persistent API token. The token gives broad API access. Version 8.7.0 fixes it.
What's affected
The record says Snipe-IT before 8.7.0. The GitHub advisory (GHSA-hxcx-9h4f-42xx) lists snipe/snipe-it up to and including 8.6.3, patched in 8.7.0. The weakness is CWE-288 (authentication bypass using an alternate path).
Source conflict on severity. The record rates this High at 8.1. The GitHub advisory labels it Moderate. The versions agree.
The cause: two-factor checks run in the web middleware group but not in the API group, and the endpoint that creates personal access tokens sits in the API group. A password-authenticated session can therefore get a token before it enters a code. For an administrator, the token can reach the endpoint that resets two-factor enrollment, after which the attacker can enroll their own device and lock the real user out. The token does not give a web session.
The fix pull request adds middleware that enforces two-factor enrollment for API tokens.
How to check if you're exposed
Check your Snipe-IT version against 8.7.0, then review issued API tokens.
docker ps --format '{{.Names}} {{.Image}}' | grep -i snipe
In the application, each user's account page lists personal API keys. Look for keys you do not recognise, particularly on administrator accounts, and for administrators whose two-factor enrollment was reset without a request from them.
Whatever the product, a current inventory of what you run is what turns a CVE notice into a quick answer. The Gold page for this CVE tracks how its record changes over time, and the free in-browser dependency scan at gold.safeguard.sh/scan covers the application libraries you ship.
What to do now
- Upgrade to Snipe-IT 8.7.0 or later.
- Revoke personal API tokens you cannot account for, starting with administrators.
- Check administrator accounts for unexpected two-factor resets and force re-enrollment where there are doubts.
- Rotate passwords of accounts at risk.
- Review the audit log for token creation near logins that never completed two-factor.
Why it matters
Two-factor is only as strong as its coverage. If an alternate route, here the API, issues credentials before the second factor is proven, the second factor protects the front door while a side door is open. Every path that creates a credential must apply the same checks.
The attacker still needs the victim's password, which is why the impact is limited to accounts whose passwords are already exposed, such as through reuse. The class is CWE-288. The record does not mark the CVE as exploited in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does the attacker need the password?
Yes. The flaw lets someone who already knows the password skip the second factor. It does not remove the password requirement.
Sources
Last reviewed: 18 October 2026.
