Quick Take
- What: ByteStash 1.5.10 through 1.6.1 do not check account status when validating API keys, so deactivated users retain full API access.
- Who is affected: Self-hosted ByteStash instances running versions 1.5.10 through 1.6.1 where administrators deactivate user accounts but expect API keys to stop working.
- What to do: Upgrade to ByteStash 1.6.2 immediately. The release notes describe this as a security patch requiring immediate update.
- Severity: Medium (CVSS 5.3). Attackers need a valid API key from a deactivated account.
- Fixed in: Version 1.6.2, released November 10, 2026.
In plain English
ByteStash is a self-hosted tool for storing code snippets. When an administrator deactivates a user account, the web login stops working, but any API keys that user created keep working. That means a deactivated user (or anyone who has their key) can still read, create, change, and delete all the snippets in that account. Version 1.6.2 fixes this by adding a single check to the database query.
What you should do: If you run ByteStash, install 1.6.2 now; if you only use code snippet tools as a regular user and do not host your own ByteStash server, you can ignore this.
What happened
ByteStash introduced API key authentication in version 1.5.4. The validateApiKey function in apiKeyRepository.js joins the api_keys and users tables but only checks whether the key itself is active (ak.is_active = 1). It never checks the users.is_active column. When an administrator deactivates a user via the PATCH /api/admin/users/:id/toggle-active endpoint, the system sets users.is_active to 0 but leaves all the user’s API keys in the database with is_active = 1. The JWT authentication path does enforce the account status check (in middleware/auth.js line 124), so web login correctly returns 403 for deactivated accounts. API key requests, however, short-circuit that middleware and go straight to validateApiKey, which has no equivalent check.
The GitHub security advisory GHSA-26m9-ww2j-3cr5 includes a proof of concept showing that after deactivation, a victim’s API key can still call GET /api/snippets, POST /api/snippets, DELETE /api/snippets/:id, and POST /mcp with full MCP tool access, while the same user’s JWT token correctly returns 403. The advisory notes that deleting a user does revoke keys (because the JOIN returns no row), but deactivation, the everyday offboarding action, does not.
What you should do
Upgrade to ByteStash 1.6.2. The release notes on GitHub state “This version introduces a couple of security patches, update immediately.” The fix adds AND u.is_active = 1 to the WHERE clause in validateApiKey (commit eb4ecdf) and also revokes all API keys when an administrator deactivates an account, so reactivation does not silently restore access to keys that may have leaked.
What it means
Account deactivation is a standard administrative control for offboarding users or responding to suspected compromise. When that control silently fails, administrators lose a key security boundary. In ByteStash, the gap existed for 18 months (version 1.5.4 through 1.6.1) and affected every installation that relied on deactivation to cut off access. The vulnerability requires an attacker to hold a valid API key, so the risk is highest in scenarios where keys were shared, logged, or exfiltrated before deactivation. The CVSS score of 5.3 reflects medium severity because the attacker needs low privileges (a valid key) but no user interaction, and the impact is limited to confidentiality and integrity of the deactivated account’s snippets, not the entire system.
