Steedos Platform EUVD-2026-102957

Requires an authenticated account on a multi-tenant Steedos Platform instance (version through 3.0.15-beta.51); any low-privilege tenant user suffices (PR:L), with no admin rights and no user interaction needed. The specific trigger is that the 'reports' object is declared enable_space_global in reports.object.yml, and objectql's callAdapter (object.ts lines ~2899-2913) skips the space/tenant filter on find/findOne for such objects, so a plain GET /api/v1/reports returns other tenants' definitions. Limiting factors: the attacker must already possess valid credentials in the deployment, the instance must be genuinely multi-tenant for cross-tenant leakage to matter, and only metadata (report names, descriptions, object and field API names) is exposed - not report results or underlying records.

This is a genuine but moderate-severity information-disclosure issue, not a top-priority emergency. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N, 5.3 Medium) is internally consistent with the description: network-reachable, low complexity, but requiring an existing authenticated low-privilege account (PR:L) and yielding only low confidentiality impact with no integrity or availability impact. That PR:L requirement is the single biggest risk-reducer - an attacker must already hold a valid tenant account, so this is not anonymous/pre-auth exploitation. There is no EPSS score, no CISA KEV listing, and no vendor-claimed active exploitation in the provided data, so exploitation status is 'no public exploit identified at time of analysis'; note, however, that one reference is a detailed third-party HackMD technical write-up, which lowers the bar for an attacker to reproduce the bug even though it is not packaged exploit code. The impact ceiling is metadata only (report names, descriptions, object and field API names), not underlying records, so the practical consequence is reconnaissance/schema disclosure across tenants rather than direct data theft. One point to verify: cross-tenant data exposure in a multi-tenant SaaS could arguably justify a CVSS scope change (S:C / SC not N), but the input encodes no scope change - defenders treating this as a boundary-crossing issue should weigh it slightly higher than the raw 5.3 suggests. Overall: real and worth patching, but a targeted, authenticated, low-impact issue rather than a wormable critical flaw.

An attacker who has signed up for or already holds a low-privilege account in one tenant of a shared Steedos deployment sends GET /api/v1/reports. Because the reports object is marked enable_space_global and objectql's callAdapter omits the space (tenant) filter on find/findOne, the response returns report definitions belonging to other tenants, leaking report names, descriptions, and the object and field API names that reveal those tenants' data model. No weaponized exploit is published, but a public HackMD write-up documents the exact request and root cause.