Open Object EUVD-2026-112551

Requires a valid non-superuser API token that holds a read grant on at least one ObjectType; no special product configuration, feature flag, or non-default deployment mode is needed, and it works against default configurations via the standard history-detail route GET /api/v2/objects/{uuid}/{index}. The attacker must also know or enumerate the target object's UUID. Exploitation is LIMITED by the requirement to already possess a legitimate low-privilege API token (so it is not fully unauthenticated), by being read-only (no data modification), and by the product's government-sector deployment scope; superuser tokens are unaffected because they already have broad access. Fixed versions 2.5.1, 3.6.2, 4.0.2, and 4.1.1 remediate it by routing history_detail through the same per-object permission check as retrieve.

This is a genuine but moderate-priority authorization flaw, not a high-CVSS paper tiger nor an emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5 Medium) is well-supported by the evidence: it is network-reachable, low-complexity, and requires a low-privilege API token (PR:L), with high confidentiality impact (full cross-ObjectType object data disclosure) and no integrity or availability impact - consistent with a read-only IDOR. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with a fixable-but-not-frantic posture. No CISA KEV listing and no EPSS score were supplied, so there is no signal of active or widespread exploitation; the advisory itself states no prior CVE/GHSA/OSV record existed, indicating this is a freshly reported issue rather than one seen in the wild. The GHSA advisory contains a concrete, author-reproduced proof of concept against the official 4.1.0 image, so exploitability is well-demonstrated even though no weaponized exploit code is published. The signals are internally consistent - there is no CVSS-vs-description conflict here; the description, source diff, and advisory all agree on mechanism and preconditions. The one input discrepancy is the 'Authentication Bypass' tag, which mischaracterizes an authorization (per-object-type grant) bypass. Net: a real data-disclosure priority for operators of this product, warranting prompt patching, but its blast radius is bounded by the need for a valid API token and the product's narrow deployment base.

An attacker (or a legitimate but limited integration partner) holding a valid non-superuser API token with a read grant on only one ObjectType requests GET /api/v2/objects/{uuid}/{index} for an object belonging to an ObjectType the token has no grant for. Because history_detail skips the per-object permission check, the endpoint returns 200 with the object's full versioned data - including fields the normal retrieve endpoint would 403 on. A detailed proof of concept reproduced against the official open-object:4.1.0 image is documented in the GHSA advisory (full packet captures offered on request), though it is not published as standalone working exploit code.