Bludit CMS EUVD-2026-87207

Requires an authenticated account with the Author role on a Bludit CMS instance at version 3.22.0 or earlier; the attacker submits a normal page content-save request to the Pages::edit() handler with extra reserved parameters (notably 'type' and 'username') that are not per-field authorized. No administrator access, user interaction, or non-default configuration is needed beyond the existence of a self-registered or provisioned Author account, which is the primary limiting factor - sites that do not grant Author-level access to untrusted users are not exposed. Impact is confined to page metadata integrity (site-wide static navigation manipulation, page ownership transfer); there is no confidentiality or availability impact and no remote code execution.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N, score 5.3) describes an authenticated (PR:L, Author role), network-reachable, low-complexity flaw with integrity-only impact (VI:L) and no confidentiality or availability effect - consistent with the description of a mass-assignment privilege escalation. This is a real but bounded issue: it requires a valid Author account, so it is not a wormable or unauthenticated pre-auth vector, and its impact is limited to unauthorized modification of page metadata (making site-wide static navigation entries or reassigning page ownership) rather than code execution or data theft. No EPSS score, KEV listing, or SSVC decision data was supplied; one of the two references is a public gist (akinerkisa) that appears to contain exploit/PoC material, so publicly available exploit code likely exists, but this must NOT be conflated with active exploitation - there is no KEV confirmation. The 'Code Injection' tag conflicts with the actual weakness (CWE-915 mass assignment / privilege escalation); this is a labeling error, not a code-execution vulnerability. Overall this is a moderate, authenticated-user integrity issue in a niche CMS - a legitimate patch-worthy bug but not an emergency priority.

An attacker who holds (or registers/obtains) a low-privilege Author account on a Bludit site edits one of their pages and appends reserved parameters such as 'type' or 'username' to the content-save POST request. Because Pages::edit() in bl-kernel/pages.class.php iterates every field in dbFields without per-field authorization, the injected values are accepted, letting the Author promote the page to a site-wide static navigation entry or transfer ownership to an arbitrary account. A public gist reference appears to provide proof-of-concept material for this request manipulation.