Summary
Audiobookshelf contains a path-traversal flaw in its authentication-exemption handling for cover and author-image routes. An unauthenticated request may bypass the intended ownership check and read service-account-accessible files when encoded path separators are decoded before cache-path construction.
Affected context
The vulnerability occurs in Audiobookshelf's authentication routing and cover-cache processing when URL-encoded path data is handled differently by the route-matching check and the downstream request handler. It is relevant where unauthenticated cover or author-image routes are enabled, encoded separators are accepted by the router, and the resulting decoded value is incorporated into a filesystem path before an ownership or authorization check.
Exploit preconditions
- Attack surface: HTTP endpoints serving cover or author-image resources
- Required access: Network access to the Audiobookshelf service; authentication may not be required
- Trigger point: Processing of a route parameter that is URL-decoded before cache-path construction
- Why exploitation is possible: The authentication-exemption check evaluates the encoded request path, while later file handling uses the decoded parameter, allowing path validation and filesystem resolution to disagree
- Additional condition: The targeted file must be readable by the Audiobookshelf service account and conform to the cache-serving filename pattern
Why this happens
The underlying bug is inconsistent canonicalization between authorization logic and filesystem path handling. The route exemption checks one representation of the URL, while Express supplies a decoded route parameter to later code; the cache component then joins that value into a filesystem path without sufficiently constraining it to the intended cache directory.
This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'). The insecure pattern is validating or authorizing a non-canonical path representation and subsequently using a different, decoded representation for file access.
Potential impact
- An unauthenticated user may read selected files accessible to the service account
- Sensitive configuration, metadata, or application files could be disclosed
- Exposed credentials or tokens could enable further compromise
- Confidentiality of hosted audiobook and user data may be reduced
- Information gathered from readable files could support follow-on attacks
General mitigation guidance
Mitigation generally focuses on canonicalizing input once and applying the same canonical representation to routing, authorization, validation, and filesystem access.
Common defensive patterns include:
- Resolve requested paths against a fixed cache directory and reject results that escape that directory
- Prefer opaque identifiers or server-side mappings over user-controlled filesystem fragments
- Validate route parameters against a strict allowlist before constructing paths
- Perform authorization and ownership checks after canonicalization and before opening or streaming files
- Avoid relying on regex checks over raw URL paths as the sole access-control mechanism
- Run the service with the least filesystem privileges necessary and keep sensitive files outside its readable scope
- Use framework and platform path APIs that make canonicalization and containment checks explicit
How teams detect issues like this
Detection can combine static analysis, code review, runtime monitoring, and policy enforcement.
Useful signals include:
- Code that joins request-derived values with filesystem paths
- Authorization checks performed on raw URLs before framework decoding
- Regex-based route exemptions that do not account for encoded separators or dot segments
- File reads or streams occurring before ownership and containment checks
- Tests covering encoded separators, dot segments, repeated decoding, and alternate path representations
- Web application logs showing unusual encoded path components on image or cover endpoints
Automated security scanning and code-review tools may help identify request-to-filesystem data flows, but findings should be validated against the application's canonicalization and authorization order.
