O2OA EUVD-2026-103042

Requires an authenticated session as any low-privileged O2OA user (PR:L) plus knowledge of a specific target attachment's UUID, which is not sequentially enumerable (this is the AT:P attack requirement and the primary factor limiting mass exploitation). The attacker must also supply a work or draft they can legitimately visit or own as the {workId} parameter. The flaw is present because ActionDownloadWithWork and ActionDownloadWithWorkStream in x_processplatform_assemble_surface never confirm the requested attachment id belongs to the referenced work/draft. Affects O2OA through 10.0.2-ce. Limiting factors: valid credentials needed, UUID must be known or leaked, impact is read-only confidentiality (no integrity/availability effect, no code execution), and reach is bounded by O2OA's small deployment base.

This is a moderate-severity authenticated IDOR (CWE-639), not a drop-everything priority. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N) is internally consistent with the description: network-reachable but requiring a valid low-privileged account (PR:L) and knowledge of a non-enumerable attachment UUID (reflected as AC:H plus AT:P - a genuine attack requirement, since UUIDs cannot be brute-forced at scale). Impact is confidentiality-only (VC:H, VI:N, VA:N), matching a read-only attachment-disclosure flaw. No CISA KEV listing and no explicit POC flag were provided, so exploitation is not confirmed in the wild; however, a detailed public technical writeup (HackMD) and a VulnCheck advisory exist, lowering the barrier to weaponization. There are no conflicting signals in the data - CVSS, description, and CWE all align on authenticated, confidentiality-impacting authorization bypass. The main uncertainty is real-world reach: O2OA is a niche platform, so this is a credible insider/lateral-movement data-leak risk rather than a mass-exploitation event. EPSS was not provided and cannot be commented on.

A low-privileged but authenticated O2OA user who has obtained a valid attachment UUID (e.g., leaked in logs, shared links, or prior access) sends a request to jaxrs/attachment/download/{id}/work/{workId} supplying a work they can legitimately visit. Because ActionDownloadWithWork/ActionDownloadWithWorkStream never verify that the attachment belongs to the referenced work, the server returns another user's process document. No public exploit code is flagged, but a step-by-step technical writeup is publicly available.