Omnispace Agora Project EUVD-2026-100564

Exploitation requires the attacker to already possess a valid user's stored bcrypt password hash from the Agora Project credential store (e.g. obtained via database compromise, backup exposure, or SQL injection); with that hash the attacker sets the legacy AGORAP_LOG/AGORAP_PASS cookies to impersonate any user including administrators. The limiting factor is this prior hash-disclosure requirement - the flaw cannot be triggered against a fresh unauthenticated attacker with no access to stored credentials, which is why the vendor assigns AC:H. The affected deployment must be running a version before 26.10.0 that still uses the legacy hash-as-cookie mechanism; upgrading to 26.10.0 remediates it.

This is a genuine high-severity authentication bypass (CWE-836, using a password hash instead of a password), but its real-world risk is strongly gated by a prerequisite that the raw CVSS score obscures. The vendor CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:N/UI:N, score 9.1) scores PR:N because the attacker needs no application account, yet AC:H correctly reflects that exploitation is impossible without first obtaining a victim's stored bcrypt hash - the attack is pure pass-the-hash replay, not a standalone remote break-in. So the PR:N 'unauthenticated' label is accurate only in the narrow sense that no login is needed once the hash is held; practically, the attacker must already have achieved database/backup/SQLi-level access to the credential store. No EPSS score, no CISA KEV listing, and no public exploit code are present in the supplied data, so there is no signal of active or widespread exploitation. The signals are therefore internally consistent rather than conflicting: critical technical impact (full account/admin impersonation) combined with a meaningful precondition and no evidence of exploitation. This is a real must-patch issue for any exposed Agora Project instance, but it is a privilege-escalation/post-compromise amplifier rather than a wormable internet-facing flaw.

An attacker who has already extracted the user table (for example via a database backup leak, SQL injection, or filesystem access) takes an administrator's stored bcrypt hash and sets it directly as the AGORAP_PASS cookie alongside the matching AGORAP_LOG value. The legacy cookie mechanism treats the stored hash as a replayable bearer token, so the attacker is authenticated as that administrator without ever cracking the password. No public exploit code was identified in the supplied data, but the technique is trivial to reproduce once a hash is in hand.