InvoiceShelf EUVD-2026-101611

Requires a multi-company (multi-tenant) InvoiceShelf deployment running a version prior to 2.4.0, and an authenticated account that holds the create-invoice ability (PR:L), reaching POST /api/v1/estimates/{estimate}/convert-to-invoice in ConvertEstimateController. The specific prerequisite is that route-model binding resolves the bound Estimate from ANY company while the controller authorizes only the create-invoice ability and omits authorization of access to the estimate itself. Limiting factors: exploitation is irrelevant on single-company instances, needs valid authenticated credentials with the create-invoice ability, and the destructive effect on the source estimate depends on the victim company's configured conversion action reaching checkForEstimateConvertAction. No special network position or user interaction is required.

This is a credible, moderate-priority authorization flaw (CWE-639, IDOR / broken object-level authorization) rather than an overblown high-CVSS issue. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, base 7.1) is internally consistent with the description: network-reachable API, low complexity, and only low privileges (any authenticated user holding the create-invoice ability) are needed, with no user interaction. The high confidentiality rating is justified because an attacker can exfiltrate another company's full estimate contents (line items, prices, totals, taxes, notes, currency, and customer data), and the low integrity rating reflects that the victim company's configured conversion action can also change or delete the original estimate. No EPSS score, CISA KEV entry, or public POC is present in the provided data, so there is no evidence of active or widespread exploitation; the signals point to an exploitable-but-not-yet-weaponized tenant-isolation bug. The key limiting factor is multi-tenancy: the flaw only matters where one InvoiceShelf instance hosts multiple companies and the attacker already holds a valid account with create-invoice ability, which keeps real-world risk below what the 7.1 score alone might suggest. Note the input tag 'Authentication Bypass' is imprecise - authentication is not bypassed; authorization/tenant isolation is.

An authenticated user in a multi-company InvoiceShelf deployment who holds the create-invoice ability enumerates estimate IDs and sends POST /api/v1/estimates/{id}/convert-to-invoice referencing an estimate belonging to a different company. Because the controller authorized only the create-invoice ability and not access to the route-bound Estimate, the foreign estimate's data is copied into an invoice in the attacker's company and the victim's configured conversion action may alter or delete the original. No public exploit code is identified at time of analysis, but the single-request nature makes exploitation trivial once a low-privileged account is available.