https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 04:57:58 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-357629 EUVD-2026-357629 https://cve.radiocsirt.org/vuln/euvd-2026-357629 https://cve.radiocsirt.org/vuln/fkie_cve-2026-55088 <p>Etherpad is a real-time collaborative editor. From 2.6.0 until 3.1.0, Etherpad&#39;s src/node/hooks/express/tokenTransfer.ts uses POST /tokenTransfer to store an author token for transfer between browsers and exposes it through GET /tokenTransfer/{uuid}. Although the record includes createdAt, the transfer has no expiration check, is not removed after successful redemption, and is returned by res.send(tokenData), including the raw author token. An unauthenticated attacker who obtains a transfer UUID can repeatedly redeem it, receive fresh author cookies, read the cleartext token, and impersonate the originating author for pad read and write operations. This issue is fixed in version 3.1.0.</p> <p>Etherpad is a real-time collaborative editor. From 2.6.0 until 3.1.0, Etherpad&#39;s src/node/hooks/express/tokenTransfer.ts uses POST /tokenTransfer to store an author token for transfer between browsers and exposes it through GET /tokenTransfer/{uuid}. Although the record includes createdAt, the transfer has no expiration check, is not removed after successful redemption, and is returned by res.send(tokenData), including the raw author token. An unauthenticated attacker who obtains a transfer UUID can repeatedly redeem it, receive fresh author cookies, read the cleartext token, and impersonate the originating author for pad read and write operations. This issue is fixed in version 3.1.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-55088 https://cve.radiocsirt.org/vuln/ghsa-vqfp-p66c-xrp9 <p><strong>Affected:</strong> npm: ep_etherpad-lite</p> <p>Etherpad&#39;s device-to-device author-token transfer endpoint is replayable, never expires, and exposes the cleartext author token in the GET response body</p> <p>## Description</p> <p>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:</p> <p>1. **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 arbitrary `prefsHttp` field) under a DB key keyed by that UUID. The UUID is returned. 2. **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.</p> <p>The original implementation has three serious flaws:</p> <p>1. **No expiration check.** `createdAt` is written to the record on POST but never inspected on GET. A leaked transfer URL is redeemable indefinitely. 2. **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. 3. **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 JavaSc…</p> <p><strong>Affected:</strong> npm: ep_etherpad-lite</p> <p>Etherpad&#39;s device-to-device author-token transfer endpoint is replayable, never expires, and exposes the cleartext author token in the GET response body</p> <p>## Description</p> <p>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:</p> <p>1. **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 arbitrary `prefsHttp` field) under a DB key keyed by that UUID. The UUID is returned. 2. **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.</p> <p>The original implementation has three serious flaws:</p> <p>1. **No expiration check.** `createdAt` is written to the record on POST but never inspected on GET. A leaked transfer URL is redeemable indefinitely. 2. **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. 3. **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 JavaSc…</p> https://cve.radiocsirt.org/vuln/ghsa-vqfp-p66c-xrp9