Bugsink EUVD-2026-31862

Exploitation requires the attacker to be an authenticated Bugsink user (CVSS PR:L) with at least member-level access to any project on the target instance. Critically, the attacker must already possess a valid UUID for a target issue in a different project - the application provides no issue enumeration path, and UUIDs are randomly generated and not guessable in practice. The attack targets the bulk action endpoint on the issue list view and is limited to state modifications (resolve, mute) with no confidentiality or availability impact. Hosted Bugsink deployments are not cross-tenant vulnerable, as each tenant receives a separate instance; exploitation is strictly cross-project within a single shared instance. The CVSS AC:H rating directly encodes the UUID-knowledge prerequisite as the limiting complexity factor.

Real-world risk is low and consistent across all available signals. CVSS 3.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N) reflects network accessibility but high attack complexity, no confidentiality or availability impact, and limited integrity effect. The AC:H rating is directly justified by the requirement to possess a valid UUID from a target project - UUIDs are non-enumerable and not practical to brute-force. EPSS at 0.03% (8th percentile) and SSVC classification of Exploitation:none, Automatable:no, Technical Impact:partial all converge on the same assessment. The CVE is absent from CISA KEV and no POC has been identified. The self-hosted, single-tenant deployment model common to Bugsink further constrains blast radius, as Hosted Bugsink isolates tenants to separate instances - cross-project impact is bounded within a single organization's instance. This is a genuine but low-priority authorization flaw: worth patching promptly but not a crisis.

An authenticated Bugsink user with legitimate membership in Project A obtains the UUID of an issue in Project B - for example, from a previously shared link, a notification, or prior elevated access. The attacker submits a bulk resolve or mute request through the Project A issue list interface, supplying the Project B issue UUID in the payload. The backend processes the bulk action against the Project B issue without verifying project ownership, silently changing its state and potentially hiding active errors from the Project B team.