OctoCloud EUVD-2026-94852

Exploitation requires an authenticated session on OctoCloud: per CVSS PR:L the attacker must already hold a valid low-privilege account, so this is not remote-unauthenticated. Given CWE-639, the concrete prerequisite is a request parameter that carries a user-controlled key (object/resource/account identifier) which the application trusts for access decisions without an ownership/ACL check; the attacker must be able to observe and alter that key. Limiting factors: the account requirement bounds exposure (most severe where OctoCloud is internet-facing or permits self-registration), no user interaction is needed (UI:N), and only versions 1.12.06 through pre-1.12.07 are affected - upgrading to 1.12.07 removes the condition. The exact vulnerable endpoint/parameter is not disclosed in the available data.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 8.8) describes a network-exploitable, low-complexity authorization bypass requiring only low-level privileges (PR:L) and no user interaction, with high impact to confidentiality, integrity, and availability. This maps cleanly to CWE-639 (authorization bypass through a user-controlled key), i.e. a classic IDOR/BOLA where an authenticated user manipulates an object identifier to reach data or functions they should not. The real-world risk signals are incomplete: no EPSS probability was provided, the CVE is NOT listed in CISA KEV, and no proof-of-concept is referenced - so by the precision rules this is 'no public exploit identified at time of analysis.' The 8.8 score is driven by the broad C/I/A impact rather than by any evidence of active exploitation; IDOR flaws are historically easy to weaponize once an authenticated foothold exists, but the PR:L requirement (an attacker must first hold a valid, if low-privilege, account) meaningfully limits mass, unauthenticated exploitation. Net assessment: a genuine and easily-exploited flaw for anyone who can register or obtain an account, but current telemetry shows no confirmed in-the-wild activity, so prioritize patching where the product is internet-facing or allows self-service account creation rather than treating it as an active emergency.

An attacker authenticates to OctoCloud with a normal low-privilege account, then alters a user-controlled identifier (such as an object ID, account key, or resource reference) in an API or web request to reference records or functions belonging to other tenants or higher-privilege users. Because the application fails to enforce ACLs on that key, the attacker reads or modifies data and invokes functionality outside their authorization. No public exploit code is referenced, but IDOR of this type is trivial to exploit manually with an intercepting proxy once a valid session exists.