CVE-2026-73085 Overview
CVE-2026-73085 is an authentication flaw in Audiobookshelf, a self-hosted audiobook and podcast server. Versions prior to 2.36.0 improperly handle JSON Web Tokens (JWTs) in the jwtAuthCheck function inside server/auth/TokenManager.js. The function accepts JWTs with the refresh token type as bearer access tokens on API and WebSocket endpoints such as /api/me, instead of restricting them to the /auth/refresh endpoint. As a result, refresh tokens can authenticate requests as the associated user, weakening the intended token-type separation. The issue is fixed in version 2.36.0. The vulnerability is classified under [CWE-287: Improper Authentication].
Critical Impact
Attackers holding a refresh token can authenticate to API and WebSocket resource endpoints as the token owner, bypassing the intended access-token boundary.
Affected Products
- Audiobookshelf versions prior to 2.36.0
- Component: server/auth/TokenManager.js (jwtAuthCheck function)
- Fixed in Audiobookshelf 2.36.0
Discovery Timeline
- 2026-08-11 - CVE-2026-73085 published to NVD
- 2026-08-11 - Last updated in NVD database
Technical Details for CVE-2026-73085
Vulnerability Analysis
Audiobookshelf issues two distinct JWT types: short-lived access tokens for API and WebSocket calls, and refresh tokens intended solely for the /auth/refresh endpoint. The jwtAuthCheck function in server/auth/TokenManager.js validates the JWT signature and user association, but does not inspect the token type claim before granting access. This allows any valid JWT associated with a user, including a refresh token, to authenticate protected resource endpoints such as /api/me. The fix introduces isBearerAccessTokenPayload, which rejects payloads where decoded.type === 'refresh' on resource endpoints.
Root Cause
The root cause is missing token-type validation during authentication. The token manager verified the JWT signature and userId claim but never enforced the semantic distinction between refresh tokens and access tokens. This is a classic token confusion pattern under [CWE-287].
Attack Vector
An attacker who obtains a refresh token, through client-side compromise, log exposure, or theft from persistent storage, can call any authenticated API or WebSocket endpoint using the refresh token as a bearer credential. Exploitation requires low privileges (an existing account context) and no user interaction. Impact is limited to confidentiality of user-scoped data exposed through the API.
})
}
+ /**
+ * Whether a decoded JWT payload may authenticate API/socket requests (not refresh-only credentials).
+ *
+ * @param {Object} decoded
+ * @returns {boolean}
+ */
+ static isBearerAccessTokenPayload(decoded) {
+ if (!decoded?.userId) return false
+ if (decoded.type === 'refresh') return false
+ return true
+ }
+
/**
* Function to validate a jwt token for a given user
* Used to authenticate socket connections
Source: GitHub Commit 8ec547e. The patch adds a helper that rejects decoded JWTs whose type claim equals refresh, ensuring refresh tokens can no longer authorize resource endpoints.
Detection Methods for CVE-2026-73085
Indicators of Compromise
- Requests to /api/me or other /api/* endpoints presenting a JWT whose payload contains "type":"refresh".
- WebSocket handshake events authenticated with a refresh-typed JWT.
- Simultaneous use of the same JWT against /auth/refresh and standard API endpoints from the same or different source addresses.
Detection Strategies
- Decode JWTs in reverse-proxy or application logs and alert when the type claim is refresh on any endpoint other than /auth/refresh.
- Correlate refresh token identifiers (jti) against access patterns to identify tokens used outside their intended endpoint.
- Compare running Audiobookshelf version against the fixed release 2.36.0 in asset inventory.
Monitoring Recommendations
- Ingest Audiobookshelf HTTP and WebSocket logs into a centralized log platform and retain JWT metadata for review.
- Baseline normal /auth/refresh call frequency per user and alert on refresh tokens observed at /api/* paths.
- Monitor authentication anomaly patterns such as new user-agents or IPs presenting refresh tokens to resource endpoints.
How to Mitigate CVE-2026-73085
Immediate Actions Required
- Upgrade Audiobookshelf to version 2.36.0 or later, which contains the isBearerAccessTokenPayload check.
- Invalidate all outstanding refresh tokens after upgrade to force re-authentication and eliminate pre-existing exposure.
- Rotate the JWT signing secret to invalidate any tokens that may have been captured before patching.
Patch Information
The fix is delivered in Audiobookshelf 2.36.0. See the GitHub Release v2.36.0, the GitHub Security Advisory GHSA-798w-wv6c-2c3h, and the GitHub Pull Request 5387 for full technical context. The corrective commit is 8ec547e.
Workarounds
- If upgrade is not immediately possible, restrict Audiobookshelf access to trusted networks using a reverse proxy or VPN.
- Configure the reverse proxy to inspect JWT payloads and reject requests carrying type=refresh to any path other than /auth/refresh.
- Shorten refresh token lifetimes and rotate signing secrets more aggressively to reduce the exposure window.
# Example: upgrade Audiobookshelf Docker deployment to the fixed version
docker pull ghcr.io/advplyr/audiobookshelf:2.36.0
docker stop audiobookshelf
docker rm audiobookshelf
docker run -d --name audiobookshelf \
-p 13378:80 \
-v <config>:/config \
-v <metadata>:/metadata \
-v <audiobooks>:/audiobooks \
-v <podcasts>:/podcasts \
ghcr.io/advplyr/audiobookshelf:2.36.0
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

