Summary
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
Description
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:
- POST
/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 arbitraryprefsHttpfield) under a DB key keyed by that UUID. The UUID is returned. - GET
/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:
- No expiration check.
createdAtis written to the record on POST but never inspected on GET. A leaked transfer URL is redeemable indefinitely. - No single-use enforcement. The DB record is not deleted after a successful GET, so the same URL can be redeemed repeatedly, each redemption yielding a fresh cookie set on whoever issued the GET.
- Author token echoed in the response body. The GET handler ends with
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.
Severity rationale
- AV:N, exploitable over the network.
- AC:H, requires the attacker to learn the transfer UUID via some out-of-band channel; UUIDs are random.
- PR:N, no authentication required at the redemption endpoint.
- UI:R, the legitimate user must have issued the POST and the UUID must end up where the attacker can see it (QR code, screenshot, etc.).
- C:H / I:H, full author identity takeover (read + write everything that author can).
- A:N, no direct denial-of-service.
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.
Affected versions
ep_etherpad-lite >= 2.6.0, <= 3.0.0. The/tokenTransferendpoint pair was added in41cb680"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 throughv3.0.0.
Patched versions
ep_etherpad-lite >= 3.1.0, the fix is ondevelopHEAD as commit8c6104c. Update this field with the actual tagged release version when it ships.
Proof of concept
# 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.
Workarounds
- Disable any UI that surfaces the transfer URL (QR code, copy-button, etc.).
- Reverse-proxy block
/tokenTransfer/*if device-pairing is not in use. - Set short DB cleanup intervals (does not address the JS-readable body issue).
None of these workarounds are sufficient on their own, upgrade is the only complete fix.
Resources
- Patched in: https://github.com/ether/etherpad/pull/7784 (squash commit
8c6104c). - Vulnerable code introduced in: https://github.com/ether/etherpad/commit/41cb680 (PR #7228), released in v2.6.0.
- Background on the HttpOnly author-token migration: ether/etherpad PR #7548 (PR3 of #6701, released in v2.7.3). That earlier PR addressed two adjacent issues (the cookie was previously non-HttpOnly, and the POST handler previously trusted the request body for the token value). This GHSA covers only the three flaws that remained after that earlier patch.
Credits
Reported during an internal security audit by Claude (via @JohnMcLear).
Impact
CVE-2026-55088 has a CVSS score of 6.8 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.1.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Patched in 8c6104c (PR #7784):
- 5-minute TTL (
TRANSFER_TTL_MS). Records older than this return 410 Gone. Records with absent/non-numericcreatedAt(legacy records from older code paths) are treated as expired. - Single-use. The DB record is removed before the success response is written, so a parallel request that wins the race observes an already-redeemed transfer rather than a second usable copy.
- Body sanitised. The response body becomes
{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});
Frequently Asked Questions
- What is CVE-2026-55088? CVE-2026-55088 is a medium-severity security vulnerability in ep_etherpad-lite (npm), affecting versions >= 2.6.0, <= 3.0.0. It is fixed in 3.1.0.
- How severe is CVE-2026-55088? CVE-2026-55088 has a CVSS score of 6.8 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of ep_etherpad-lite are affected by CVE-2026-55088? ep_etherpad-lite (npm) versions >= 2.6.0, <= 3.0.0 is affected.
- Is there a fix for CVE-2026-55088? Yes. CVE-2026-55088 is fixed in 3.1.0. Upgrade to this version or later.
- Is CVE-2026-55088 exploitable, and should I be worried? Whether CVE-2026-55088 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-55088 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-55088? Upgrade
ep_etherpad-liteto 3.1.0 or later.