GHSA-92HR-GMR6-H8CP: Cryptographic Weaknesses, Parameter Pollution, Path Traversal, and Timing Flaws in Etherpad

Etherpad (etherpad-lite) versions prior to 3.3.0 contained a group of six distinct architectural weaknesses and security vulnerabilities. These flaws exposed deployments to risk across multiple vectors, including session hijacking, timing-based credential harvesting, and local file access. The affected components span the core token generator, the OAuth2 authentication module, the REST API router, the local plugin manager, and the administration file server.

By chaining these architectural weaknesses, an attacker could potentially execute targeted attacks. For instance, predictable session tokens can compromise authentication boundaries. Meanwhile, unvalidated path parameters in plugins allow local privilege escalation or arbitrary directory traversal. This report provides a detailed examination of the root causes, patch modifications, and defense-in-depth strategies to secure Etherpad installations.

The root causes of these vulnerabilities stem from standard programming omissions across different modules of the codebase. First, the core token generator in src/static/js/pad_utils.ts relied on the non-cryptographic Math.random() PRNG. Because this engine is mathematically predictable, consecutive outputs allow reconstruction of the internal generator state, facilitating token forecasting.

Second, the OAuth2 provider implemented standard, variable-time string comparisons to validate user passwords. This created an observable timing side channel. The absence of strict verification on configuration lookups also left the application vulnerable to prototype pollution. Finally, the REST API interface automatically merged arbitrary HTTP request headers directly into input parameter dictionaries. This enabled API parameter pollution because incoming headers could override intended parameters.

The security vulnerabilities were resolved in commit 7ea99706483443239bbbc0f2df9aff8ab5de4805. The patch replaced unsafe random string generation with a cryptographically secure implementation using globalThis.crypto.getRandomValues(). Rejection sampling was added to eliminate modulo bias when mapping raw byte values to the target character set.

Below is the comparison of the vulnerable and patched randomString implementations:

// Vulnerable Implementation
export const randomString = (len?: number) => {
  const chars = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz';
  let randomstring = '';
  len = len || 20;
  for (let i = 0; i < len; i++) {
    const rnum = Math.floor(Math.random() * chars.length);
    randomstring += chars.substring(rnum, rnum + 1);
  }
  return randomstring;
};

// Patched Implementation with Cryptographic Entropy and Bias Correction
export const randomString = (len?: number) => {
  const chars = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz';
  len = len || 20;
  const maxUnbiased = 256 - (256 % chars.length); // 248
  let randomstring = '';
  while (randomstring.length < len) {
    const bytes = new Uint8Array(len - randomstring.length);
    globalThis.crypto.getRandomValues(bytes);
    for (const b of bytes) {
      if (b >= maxUnbiased) continue; // Drop biased samples
      randomstring += chars[b % chars.length];
      if (randomstring.length === len) break;
    }
  }
  return randomstring;
};

Additionally, the OAuth2 module was hardened. It now utilizes crypto.timingSafeEqual for constant-time comparisons, enforces configuration lookups via Object.prototype.hasOwnProperty.call, and enforces an explicit 1000ms delay on failed login events.

An attacker aiming to exploit the token generator must first gather a sequence of generated tokens, such as public author IDs or session keys. By feeding these tokens into a solver designed for the V8 engine's PRNG, the attacker can determine the internal state of the generator. With this state, the attacker predicts subsequently generated admin tokens, session identifiers, or pad IDs.

For the plugin-based path traversal, an attacker with local file system write capabilities or the ability to upload a custom plugin constructs a malicious package.json file. By defining a dependency path that points to a relative target outside the plugin's working directory, the mounting logic creates a symbolic link to critical system configuration files. This results in arbitrary file read capability when the application attempts to load the dependency structure.

The security impact of these chained vulnerabilities is substantial. Cryptographic predictability allows unauthenticated attackers to hijack active user or administrative sessions without possessing valid credentials. In environments where Etherpad handles confidential documents, this compromise directly leads to unauthorized data exposure and information disclosure.

Furthermore, API parameter pollution and timing side-channels provide unauthorized actors with mechanisms to brute-force authentication portals and manipulate internal API parameters. The local directory traversal via the plugin framework enables path manipulation, which can lead to system-wide file access under the privileges of the executing Node.js process. Finally, raw filesystem error messages returned by the administrative module disclose full path hierarchies, simplifying secondary exploitation phases.

The primary remediation path is upgrading the Etherpad deployment to version 3.3.0 or later, which incorporates the comprehensive patch set. For systems where immediate upgrading is not viable, specific defensive controls can mitigate the exposure vectors.

Deploying a reverse proxy or Web Application Firewall to sanitize incoming request headers prevents API parameter pollution at the network boundary. Additionally, the administrative interface must be restricted to trusted, internal IP addresses using strict network access control lists. Access permissions on the Node.js process must also be audited to prevent unauthorized file system modifications, thereby neutralizing local directory traversal vectors.