Etherpad EUVD-2026-62737

Exploitation requires the Etherpad instance to be running the OAuth2 authorization_code flow (src/node/security/OAuth2Provider.ts) and the attacker to possess a valid, correctly signed token for a configured non-admin user - i.e., the attacker must be an authenticated, provisioned account, not anonymous. Given that token, no admin role, no user interaction, and no special client configuration are needed to call the administrative /api/2/* endpoints (setHTML, setText, appendText, deletePad, copyPad, movePad, restoreRevision, anonymizeAuthor, listAllPads, listAuthorsOfPad). What limits exploitation: instances that do not enable the OAuth authorization_code path, or that provision no non-admin OAuth users, are not exposed; the requirement to first hold a legitimately issued token is the primary barrier and is why PR is Low rather than None.

Signals are mostly aligned toward high priority but with one important caveat. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L, 9.9) indicates a remote, low-complexity, low-privilege attack with a scope change, which fits: any valid non-admin OAuth token holder crosses a trust boundary to control the entire instance. The critical prerequisite the raw 9.9 obscures is PR:L - the attacker must first hold a legitimate signed token, meaning the OAuth2 authorization_code path must be configured and the attacker must be a provisioned (if unprivileged) user, not an anonymous internet actor. No EPSS score, KEV listing, or POC was provided, so there is no evidence of active exploitation; this is a de-prioritizing signal relative to the CVSS number. However, the fix is a public GitHub commit and PR, so weaponization effort is low. Net: treat as an urgent internal-privilege-escalation issue for any Etherpad instance using OAuth with non-admin users, and lower priority for instances that do not expose the OAuth authorization_code flow.

An organization runs Etherpad with OAuth login for staff. A rank-and-file employee (or an attacker who has phished any low-privilege account) obtains their normal signed access token and sends it to /api/2/listAllPads and /api/2/getText, then to setHTML and deletePad. Because the API only checks that the admin claim exists, the non-admin token is accepted and the attacker reads, rewrites, or deletes every pad on the instance. No POC was provided, but the public fix commit makes the exploit trivial to derive.