Summary
Docmost versions before 0.80.1 allow authenticated users to save attacker-controlled avatar URL values that are later used by avatar cleanup operations without sufficient directory confinement. On local-storage deployments, a low-privileged user may cause the Docmost service account to delete files or directories outside the intended avatar storage location.
Affected context
The issue occurs in Docmost deployments that use local storage for avatars and perform cleanup based on user-controlled avatar URL values. It becomes risky when the cleanup logic resolves those values as filesystem paths without reliably restricting the result to the designated avatar directory.
Exploit preconditions
- Attack surface: Authenticated avatar management and cleanup functionality
- Required access: A valid Docmost user account with permission to create or update avatar-related data
- Deployment condition: Local-storage mode must be enabled
- Trigger point: Avatar cleanup processes a stored attacker-controlled URL or path
- Why exploitation is possible: The resolved path may escape the intended storage directory and target filesystem objects accessible to the Docmost service account
Why this happens
The underlying bug is insufficient validation and confinement of a user-controlled path before it is used in a filesystem deletion operation. A value presented as an avatar URL is treated as a trusted local path without consistently verifying that its canonical form remains within the permitted storage directory. This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory, commonly known as path traversal.
Potential impact
- An attacker may delete arbitrary files accessible to the Docmost service account
- An attacker could remove application data, uploaded content, or operational files
- Deletion of directories could disrupt application functionality or availability
- The incident may cause data loss and complicate recovery or forensic analysis
General mitigation guidance
Mitigation generally focuses on treating avatar references as untrusted data and enforcing filesystem boundaries before any cleanup operation.
Common defensive patterns include:
- Store opaque identifiers rather than user-controlled filesystem paths
- Resolve and canonicalize candidate paths before use
- Require the final path to remain within a fixed, dedicated avatar directory
- Reject absolute paths, traversal segments, unexpected schemes, and path forms
- Use allowlisted storage keys and server-generated filenames
- Run the service with the least filesystem privileges required
- Separate user-upload storage from application code, secrets, and operational data
- Prefer storage abstractions that do not expose arbitrary filesystem paths
How teams detect issues like this
Organizations can look for:
- Static analysis findings where request-derived values reach file deletion or recursive removal APIs
- Code review signals involving path joining without canonicalization and directory-boundary checks
- Tests using absolute paths, traversal sequences, symbolic links, and alternate path representations
- Runtime policy alerts for deletion attempts outside approved upload directories
- File-integrity monitoring for unexpected removals by the Docmost service account
- Automated security review tools that identify user-controlled filesystem operations
