InvoiceShelf CVE-2026-55383

Exploitation targets the public customer routes GET /customer/invoices/{email_log:token}, GET /customer/estimates/{email_log:token}, and GET /customer/payments/{email_log:token} on InvoiceShelf versions prior to 2.4.0. The attacker must possess a valid EmailLog token (an email link issued to any customer); no account authentication is required (PR:N). Two concrete conditions enable abuse: (1) the JSON handlers resolve $emailLog->mailable_id without verifying mailable_type, so a token issued for one document type discloses a different company's document when numeric identifiers COLLIDE across tenants - this id collision is the limiting factor and is opportunistic, not attacker-controlled; (2) the JSON handlers did not enforce EmailLog::isExpired, so an EXPIRED token remains usable - this path needs only an old link and is fully reliable. The view handlers additionally require the target invoice/estimate to be in STATUS_SENT or STATUS_DRAFT to flip it to 'viewed' and send a notification. The flaw requires no special server configuration; it affects default deployments of vulnerable versions.

This is a genuine authorization flaw (CWE-285), not a high-CVSS-but-low-risk artifact, but the real-world priority is moderated by product footprint and exploitation prerequisites. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N, base 8.2) correctly reflects remote, unauthenticated, network-reachable access to the public customer JSON routes, with high confidentiality impact (cross-company document disclosure) and low integrity impact (a mismatched invoice/estimate can be marked 'viewed' and trigger a notification email). No availability impact. There is no EPSS score, no CISA KEV listing, and no public POC supplied in the input, so exploitation likelihood signals are absent - meaning no public exploit identified at time of analysis. One nuance to flag explicitly: the most impactful variant (disclosing a DIFFERENT company's document) requires the attacker's own valid EmailLog token's numeric mailable_id to collide with another company's document id across mailable types, which is opportunistic/targeted rather than reliably controllable - this makes AC arguably higher than AC:L for that path. The simpler, fully reliable path is reuse of an EXPIRED token on the JSON routes (the handlers did not enforce EmailLog::isExpired), which needs only possession of a now-expired link. Net: a real authorization/IDOR-class issue worth prompt patching, but absent KEV/EPSS/POC signals and given a niche self-hosted product, it is a moderate operational priority rather than an emergency.

An attacker who legitimately received an InvoiceShelf email link (an EmailLog token) replays it after expiry, or substitutes it against the customer JSON routes, and retrieves invoice, estimate, or payment data. Where the token's numeric mailable_id collides with another tenant's document id, the response discloses a different company's financial document; requesting an estimate/invoice can also flip its status to 'viewed' and dispatch a notification email. No public exploit code is referenced in the input, and the network-reachable, low-complexity, unauthenticated routes make the expired-token reuse path straightforward.