BlueSpice EUVD-2026-108651

Requires a valid authenticated BlueSpice account with no special privileges (PR:L) and network access to the BlueSpiceUserManager REST API, specifically /bs-usermanager/v1/block/create and /bs-usermanager/v1/block/delete; the BlueSpiceUserManager extension must be installed and enabled. No user interaction is needed (UI:N). The exploitation-limiting factors are the requirement to hold any registered account and that only versions 5.0.0-5.1.10 and 5.2.0-5.2.6 are affected - instances on 5.1.11, 5.2.7, or later are fixed. Where self-registration is open, the authentication barrier is effectively negligible; where accounts are tightly controlled, the realistic attacker set is insiders.

This is a broken-access-control flaw (CWE-862, Missing Authorization) in the BlueSpiceUserManager extension that is genuinely exploitable but bounded in impact. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable, low-complexity exploitation requiring only a low-privileged authenticated account - any registered user with no special rights. Impact is availability-weighted: VA:H reflects that an attacker can block every administrator and lock them out (denial of service), while VI:L reflects integrity damage to the access-control state (lifting admin-imposed blocks). There is NO confidentiality impact (VC:N). The vuln.today decision label is 'this_week', indicating prompt but not emergency prioritization. Signals are consistent rather than conflicting: this is not a KEV entry, no EPSS score was supplied, and no public exploit or PoC reference is provided - only the vendor advisory. So the elevated-looking 7.1 score is driven by the ease of abuse and the admin-lockout DoS, not by evidence of real-world exploitation. The main caveat is the required precondition of holding a valid account, which narrows the realistic attacker set to insiders or anyone who can self-register on a BlueSpice instance.

A low-privileged but authenticated user on a BlueSpice wiki sends a POST to the REST endpoint /bs-usermanager/v1/block/create targeting each administrator account; because UserManager::blockUser() never checks the caller's permissions, the blocks succeed and all admins are locked out of the wiki. The same actor can also call /bs-usermanager/v1/block/delete to lift legitimate blocks the administrators had previously imposed. No public exploit identified at time of analysis; exploitation is straightforward given the documented endpoints.