The ep_etherpad-lite plugin versions up to and including 3.0.0 generate temporary import/export file paths using Math.random(), which is not cryptographically secure and produces predictable values within the same Node.js process. These temporary files are placed in the system's shared temporary directory (typically /tmp on Linux), which is world-writable. A local attacker who can observe or guess the temporary filenames can create symbolic links at those paths pointing to arbitrary files writable by the Etherpad process. When Etherpad writes to these temp files, it follows the symlink and overwrites the linked target file. This can lead to arbitrary file overwrite if Etherpad runs with elevated privileges, such as root in some Docker or snap environments. The import handler is particularly impactful as the attacker can influence the content written. The vulnerability requires local access and the ability to predict filenames but does not require user interaction. The issue is fixed in ep_etherpad-lite version 3.1.0 by switching to a cryptographically secure random filename generation using crypto.randomBytes(). Workarounds include running Etherpad with a private /tmp directory or ensuring it does not run as root.

An attacker with local access to the host running vulnerable versions of ep_etherpad-lite can predict temporary file paths used during import/export operations and create symbolic links to arbitrary writable files. This leads to arbitrary file overwrite by the Etherpad process, potentially compromising system integrity or sensitive data. The impact is limited by the privileges of the Etherpad process and requires local access. Confidentiality and integrity impacts are low to moderate depending on the writable files targeted. There is no remote exploitation vector or user interaction required.

A patch is available in ep_etherpad-lite version 3.1.0 that replaces the insecure Math.random() usage with crypto.randomBytes() to generate unpredictable temporary file names. Users should upgrade to version 3.1.0 or later. Workarounds include running Etherpad in a container or environment with a private /tmp directory (e.g., Docker --tmpfs or systemd PrivateTmp=true), ensuring the Etherpad process does not run as root, and setting TMPDIR to a directory private to Etherpad. These mitigations reduce the risk of symlink attacks by isolating temporary file creation.