databasement CVE-2026-103534

Requires a valid authenticated low-privileged account (PR:L) on a running databasement instance up to and including version 1.7.1; the attacker then abuses the improperly scoped SnapshotPolicy.viewAny/view authorization on the /api/v1/snapshots endpoint (Snapshot Model) to reach snapshots outside their authorized organization/scope. Remote exploitation over the network is possible with no user interaction. Limiting factors: exploitation depends on multi-user/multi-organization deployments where an attacker can obtain an account, and is fully remediated by upgrading to v1.7.2, which hardens organization scoping.

Signals point to a modest, authenticated access-control flaw rather than a high-priority emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) with the 'E:P' (Proof-of-Concept) exploit-maturity metric and a base score of 5.3 (Medium) aligns with the reported facts: a publicly disclosed PoC exists (vendor GitHub Security Advisory GHSA-vx6q-v2gv-5fhv), but there is no CISA KEV listing and no EPSS score supplied. This means publicly available exploit code exists, yet there is no evidence of active exploitation in the wild - these are distinct signals and should not be conflated. The PR:L requirement is the key risk limiter: an attacker must already hold a valid low-privileged account, so this is cross-tenant/cross-privilege data exposure, not an unauthenticated internet-facing breach. The vendor-assigned equal VC:L/VI:L/VA:L triad looks slightly generous given the affected functions SnapshotPolicy.viewAny/view are read-path authorization policies, which argues for a confidentiality-leaning impact. The 'Authentication Bypass' tag overstates the issue - CWE-284 Improper Access Control and PR:L confirm this is a broken-authorization flaw affecting authenticated users, not an authentication bypass. Overall: a real but low-to-medium issue, best treated as a routine patch (upgrade to v1.7.2) rather than an urgent incident.

An attacker registers or obtains a low-privileged account on a shared databasement instance, then sends a crafted request to the /api/v1/snapshots endpoint referencing snapshots belonging to another user or organization. Because the SnapshotPolicy.viewAny/view authorization checks are improperly scoped, the server returns snapshot data the attacker should not be able to see. A proof-of-concept is publicly available via the vendor's GitHub Security Advisory.