CVE-2026-77759 is an IDOR in a transaction endpoint that resolves entities by a single integer ID with no tenant context injected. This is the most natural way to write a RESTful lookup — you get an ID, you fetch the record — and that's precisely why it's dangerous in a multi-tenant context the framework neither scaffolds nor enforces. The developer wasn't thinking about authorization because nothing in the API design forced them to think about it.
The vulnerability persisted through versions 5.0.0 to 5.3.5. Four minor releases without catching this isn't a momentary slip during a refactor — it's evidence of a systematic gap in how the codebase treats tenant isolation. Either no one was testing cross-tenant read scenarios, or they were and the results were ignored. Either way, the testing and review process treated the happy path as sufficient.
But here's what makes this worse than a simple missing check: the sequential integer ID is a blast radius multiplier. Any unprotected endpoint is a latent vulnerability. One where the attacker can simply increment from 1 until something returns is weaponized. This is the difference between a theoretical exposure and a systematic data bleed of every tenant's transactions, enumerated on a predictable cadence.
The fix — adding WHERE company_id = ? to the query — is trivially short. That simplicity is itself evidence this wasn't a hard problem the developer couldn't solve. The real question is whether tenant scoping was already established elsewhere in the codebase. If invoices and contacts already had this pattern, then the developer had a working example to follow and simply didn't apply it — a local consistency failure code review should have caught. If no resources had it, then this was a framework-level gap that the entire team was walking into.
But patching this endpoint alone won't stop the next one. The actionable work is structural: add a lint rule or ORM base class that makes tenant scoping mandatory rather than optional, and treat sequential integer IDs on tenant-scoped resources as an enumeration risk — use UUIDs or opaque tokens by default. The vulnerability class has a fifteen-year genealogy across CRM systems. The fix that actually moves the baseline is the one that makes the same mistake structurally impossible, not the one that patches this specific endpoint.