npm · ep_etherpad-lite
ep_etherpad-lite: Device-to-device author-token transfer endpoint is replayable, never expires, and exposes the cleartext author token
Etherpad's device-to-device author-token transfer endpoint is replayable, never expires, and exposes the cleartext author token in the GET response body
Etherpad ships an endpoint pair under /tokenTransfer (src/node/hooks/express/tokenTransfer.ts) that lets a logged-in user move their HttpOnly author token to a different browser (typically by scanning a QR code containing the transfer URL). The flow is:
/tokenTransfer — the source device sends a request whose own author cookie is read off the server-side cookie jar. The server mints a random UUID and stores the author token (and arbitrary prefsHttp field) under a DB key keyed by that UUID. The UUID is returned./tokenTransfer/{uuid} — the destination device GETs the URL containing the UUID. The server reads the stored record and sets the HttpOnly author cookie on the response.The original implementation has three serious flaws:
createdAt is written to the record on POST but never inspected on GET. A leaked transfer URL is redeemable indefinitely.res.send(tokenData), which serializes the full record — including the raw author token — into the JSON response. Any JavaScript on the page that issued the GET can read the token, defeating the HttpOnly cookie design that exists specifically to keep the token out of JS reach.Combined, these mean that any disclosure of a transfer UUID (browser history, mis-shared QR code, screenshot, server log, third-party plugin that proxies the request, an unencrypted intermediate hop) results in persistent authorship impersonation of the originating account — the attacker doesn't just get one cookie, they can re-redeem and they get the raw token in cleartext for storage / replay against other endpoints.
CVSS lands at 7.5 (High). Some operators may reasonably score this lower (UI:R + AC:H) if their threat model assumes the transfer URL never leaves the user's own device pair.
ep_etherpad-lite >= 2.6.0, <= 3.0.0. The /tokenTransfer endpoint pair was added in 41cb680 "let user maintain a single session across multiple browsers" (#7228), first tagged in v2.6.0 (2025-11-18). All three flaws (no TTL, no single-use, token in response body) were present from the introducing commit and persisted through v3.0.0.ep_etherpad-lite >= 3.1.0 — the fix is on develop HEAD as commit 8c6104c. Update this field with the actual tagged release version when it ships.# 1. Victim posts a transfer from their device.
curl -X POST https://pad.example/tokenTransfer \
-H 'Cookie: token=t.victim-author-token' \
-H 'Content-Type: application/json' \
-d '{"prefsHttp": ""}'
# -> {"id": "1f0b2a3c-..."}
# 2. UUID leaks (browser history, intercepted QR, etc.).
# 3. Attacker redeems it from a totally different machine:
curl -i https://pad.example/tokenTransfer/1f0b2a3c-...
# Headers include:
# Set-Cookie: token=t.victim-author-token; Path=/; HttpOnly; ...
# Body contains:
# {"token":"t.victim-author-token", "prefsHttp": "", "createdAt": ...}
#
# Attacker now owns the victim's identity. They can also re-redeem the
# same UUID (no single-use), and the body gives them the cleartext token
# even if the HttpOnly cookie isn't useful to their tooling.
/tokenTransfer/* if device-pairing is not in use.None of these workarounds are sufficient on their own — upgrade is the only complete fix.
Patched in 8c6104c (PR #7784):
TRANSFER_TTL_MS). Records older than this return 410 Gone. Records with absent/non-numeric createdAt (legacy records from older code paths) are treated as expired.{ok: true, prefsHttp} — the raw author token is no longer included. The HttpOnly cookie set in the same response is the only delivery channel.- const tokenData = await db.get(`${tokenTransferKey}:${id}`);
+ const key = tokenTransferKey(id);
+ const tokenData: TokenTransferRequest | undefined = await db.get(key);
if (!tokenData) {
return res.status(404).send({error: 'Token not found'});
}
+ await db.remove(key);
+ const createdAt = typeof tokenData.createdAt === 'number'
+ ? tokenData.createdAt : 0;
+ if (Date.now() - createdAt > TRANSFER_TTL_MS) {
+ return res.status(410).send({error: 'Token expired'});
+ }
...
- res.send(tokenData);
+ res.send({ok: true, prefsHttp: tokenData.prefsHttp});
8c6104c).Reported during an internal security audit by Claude (via @JohnMcLear).
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.