This IDOR in the ModifyEmailNotifications view (vinny/views.py) lets a vendor admin manipulate another vendor's VinceCommEmail contact records by supplying a raw primary key from the URL. The view fetches the object directly with a queryset like VinceCommEmail.objects.get(pk=pk) and proceeds to business logic without verifying that the contact belongs to the requesting vendor's group. That's the failure mode: ownership verification was treated as implicit rather than enforced.

What makes this urgent is that it's a write-capable IDOR, not a read-only leak. An attacker can toggle email_function and name fields on contacts belonging to other vendors. If VinceCommEmail records feed into downstream notification routing, mailing lists, or reporting systems, you're not just looking at cross-tenant data leakage—you're looking at potential data poisoning in systems that consume this configuration. Audit what else touches these records.

The deeper problem: Django's ORM abstraction creates a cognitive trap. The queryset syntax is syntactically identical to an authorized query—there's no surface signal that says 'authorization required here.' Developers trust the ORM to be operating within application semantics when it's really just a database cursor. This is why IDORs persist across Django versions and codebases: the abstraction feels safe.

Your immediate actions: First, verify the ownership check is actually missing by examining the view code—look for filter clauses that scope to the requesting vendor's group_id or contact_group. Second, grep vinny/views.py for other endpoints that fetch models by pk from URL parameters and ask the same ownership question. If ModifyEmailNotifications has this gap, others likely do too. Third, trace what VinceCommEmail records feed into downstream—notification systems, mailing lists, reporting—and assess whether poisoned data in those consumers creates more risk than the direct manipulation.

The CVSS 5.3 score likely undersells this. Cross-tenant write operations that persist in downstream systems are exactly the kind of impact that compounds over time and makes forensics difficult. Prioritize the fix, but treat it as a pattern audit, not a one-off patch.