InvoiceShelf CVE-2026-55384

Requires a valid authenticated InvoiceShelf account (PR:L) with access to the invoice, estimate, or recurring-invoice creation paths; the attacker sends client-supplied total, sub_total, tax, discount_val, and due_amount values that the pre-2.4.0 request handlers (InvoicesRequest::getInvoicePayload, EstimatesRequest, RecurringInvoiceRequest) accept without validating against line items. No special feature flag or non-default configuration is needed - default configurations of all versions prior to 2.4.0 are affected. Exploitation is limited strictly by the authentication requirement: an attacker must already possess credentials and document-creation permissions, so impact is bounded to what that user is allowed to create, and the recurring-invoice path is more impactful because tampered template totals propagate to every generated invoice.

This is a genuine but low-severity business-logic flaw, not a high-priority emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N) scores 5.3 (Medium) and is internally consistent with the description: network-reachable web API, low attack complexity, and crucially PR:L meaning a valid authenticated account is required - this is privilege abuse by a legitimate user, not remote unauthenticated compromise. The only impact is a limited integrity violation (VI:L): stored financial totals can be made to disagree with line items. There is no confidentiality or availability impact, no EPSS score provided, no CISA KEV listing, and no public POC - so all exploitation-probability signals are either absent or point to low real-world risk. The signals do not conflict on severity; they converge on 'real but minor.' The one metadata conflict worth flagging is the 'Authentication Bypass' tag, which contradicts both the CWE-284 (Improper Access Control) classification and the description - nothing in the data indicates authentication is bypassed; an attacker must already be authenticated. Real-world priority is low-to-moderate: patch in the normal cycle, prioritize only in multi-tenant or billing-sensitive deployments where total manipulation has financial/fraud consequences.

An authenticated InvoiceShelf user with invoice-creation rights submits a crafted API request where the total, sub_total, tax, or due_amount fields are set to values that do not match the submitted line items (e.g. line items worth $1,000 but a due_amount of $10). The server persists these attacker-controlled totals verbatim, producing a stored invoice, estimate, or recurring-invoice template whose displayed/charged amount diverges from its itemized contents. No public exploit code is identified, but the manipulation requires only ordinary API calls.