DoraCMS EUVD-2026-115208

Requires a valid authenticated low-privileged DoraCMS account (PR:L) with an existing API key on versions through 3.1.0; the attacker issues a PUT to /api/v1/user/api-keys/:id for a key they own and includes a userId field whose value is the victim's user id. No non-default configuration is needed - the pre-patch updateApiKey copied the entire request body (including userId/key/secret) into the update, so default deployments are affected. Limiting factors: the attacker must be authenticated and must know or obtain the target victim's user id; there is no availability impact and no unauthenticated path. The patch neutralizes this by writing only an explicit allow-list of fields, so updating is the effective fix per the vendor commit.

This is a genuine near-term priority, though not an emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) describes a network-reachable, low-complexity attack needing only a low-privileged authenticated account and no user interaction, with high confidentiality and integrity impact (VC:H/VI:H) and no availability impact - consistent with an account-takeover/mass-assignment flaw. The source-code diff independently confirms the mechanism: the pre-patch updateApiKey spread the entire request body into updateData, so a client-supplied userId overwrote key ownership. Signals partially align and partially are absent: the vuln.today Decision label is 'this_week' and the vendor patch is available, but there is NO CISA KEV listing and NO EPSS score in the input, so exploitation-probability cannot be quantified here. The exploit reference is a PoC link only and is not verified as working exploit code, so this should not be treated as confirmed active exploitation. Net: a real, easily-exploitable privilege/integrity bug that any authenticated user can trigger, warranting prompt patching, but current evidence points to opportunistic/targeted rather than confirmed mass exploitation.

A low-privileged but authenticated DoraCMS user sends a crafted PUT request to /api/v1/user/api-keys/:id for their own API key, adding a userId field set to a target victim's id. Because the server copied the whole request body into the update, the key is rebound to the victim, and the attacker can then act as that victim to modify profiles and publish or delete content. A public PoC reference exists; it is not verified as working exploit code.