InvoiceShelf CVE-2026-55610

Requires a multi-company InvoiceShelf installation (single-company deployments are not exploitable cross-tenant) AND the attacker must already be authenticated as an Owner of at least one company on that installation (PR:H). Given those conditions, exploitation is remote, low-complexity, and needs no user interaction: the /api/v1/users/{user} endpoints resolve the target by global primary key while UserPolicy validates only the requester's own header-company, so an Owner can read and overwrite any user in any other company. The limiting factors are the multi-tenant deployment requirement and the Owner-level privilege prerequisite; there is no anonymous/unauthenticated path.

This is a genuinely high-severity multi-tenant authorization flaw, not a padded high-CVSS number. The vendor CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N, 8.7) is internally consistent with the description: network-exploitable via a REST API, low complexity (a single crafted GET/PUT to /api/v1/users/{user}), scope change (S:C) because a compromise crosses from the attacker's tenant into other companies' data, and high confidentiality/integrity impact (cross-tenant disclosure plus full account takeover). The one caveat is PR:H - exploitation requires the attacker to already hold an Owner role in at least one company on the installation, so this is an insider/authenticated-tenant escalation rather than a fully anonymous internet attack; that materially lowers real-world reach versus a PR:N flaw. No EPSS score, no CISA KEV listing, and no confirmed public POC are present in the input, so there is no evidence of active or automated exploitation - the risk is real but conditional on multi-company deployments and a hostile/compromised Owner account. Priority is high specifically for shared/SaaS-style InvoiceShelf installations hosting multiple independent companies; single-company deployments are effectively unaffected. Tag 'Authentication Bypass' is inaccurate - CWE-639 and the description describe an authorization (IDOR) failure, not authentication bypass.

An attacker who legitimately holds (or has compromised) an Owner account for one company on a shared InvoiceShelf installation sends GET /api/v1/users/{id} iterating global user IDs to read other tenants' user records, then issues PUT /api/v1/users/{id} to overwrite a victim's email and password and reassign their company - taking over accounts belonging to entirely different companies. No POC is referenced in the advisory, but the attack requires only ordinary API calls and is low-complexity (AC:L) once the attacker has any Owner role.