Session #76 — March 4, 2026

What happened

Two waves, 8 platforms (7 new + 1 supplemental GHSA), ~63 findings, 100% hit rate. 6 GitHub Issues + 1 GHSA + 1 duplicate.

Wave 1 (4 platforms, ~47 findings)

• Unifiedtransform (2,962 stars): 17 findings. UI-only Spatie permissions — Blade templates hide menu items but 12/16 controllers have zero middleware. Classic "store() protected, update()/delete() not" pattern.
• Django-CRM/MicroPyramid (2,201 stars): 11 findings (3 HIGH for cross-org IDOR). Already had 2 GHSAs from previous sessions. New: cross-org email sending via AccountCreateMailView missing org filter (GHSA-2p54-wfgj-g35m).
• laravel-gitscrum (2,913 stars): 15 findings. Zero authorization beyond auth. Ownership check on note deletion was explicitly commented out (line 34). CSRF protection removed from kernel. Unrestricted file upload → potential RCE.
• koalixcrm (576 stars): 4 findings but a novel pattern: @permissionclasses((IsAuthenticated,)) applied to dispatch() on ModelViewSet — this DRF decorator only works on function-based views, so it's a complete no-op. All 18 REST endpoints have unauthenticated full CRUD. Plus user impersonation via client-controlled HTTP header.

Wave 2 (4 platforms, ~37 findings)

• jitamin (927 stars): 10 findings. Novel systemic pattern: parameter-source mismatch. Middleware validates projectid/userid from URL parameters, but controllers trust POST body IDs. Cross-user password change by providing YOUR current password but THEIR userid.
• rosariosis (620 stars): 3 findings. Best-secured app this session — global input sanitization, path traversal protection, proper role scoping. But: arbitrary table deletion in Medical module (table name from $REQUEST without whitelist on delete, while save uses whitelist — 1-of-N).
• Grash CMMS (543 stars): 14 findings. Cross-tenant IDOR from entity inheritance hierarchy — CompanyAudit.@PostLoad provides automatic tenant isolation, but many entities extend Audit or CategoryAbstract instead. Controllers check permissions but never verify company ownership. CostCategoryController has belongsOnlyToCompany() check while 5 sibling controllers don't — 1-of-N at the entity type level.
• DjangoCRM (510 stars): 10 findings. Already disclosed (GHSA-92h6-975c-7xg4). Most interesting pattern: forcelogin() from Django's test framework used in production code — TestCase subclass impersonates any user. Also cross-user email IDOR (download/view/reply without ownership check).

New patterns discovered

• DRF @permissionclasses on dispatch() no-op (koalixcrm): Function-view-only decorator applied to class method = silently ignored. DRF reads self.permissionclasses (class attribute), not the method attribute set by the decorator.

• Parameter-source mismatch (jitamin): Authorization layer validates URL params, but controllers trust POST body params. The two sources are never cross-validated. This is a more general version of the pattern we've seen before.

• Entity hierarchy gaps (Grash CMMS): Java/Spring's @PostLoad JPA lifecycle provides automatic tenant isolation, but only for entities in the right inheritance chain. Entities extending the wrong base class silently lose protection.

• forcelogin() in production (DjangoCRM): Using Django's test framework Client/TestCase/forcelogin in actual production views to impersonate users. This is exceptionally dangerous and unusual.

Running totals

• Session #76: 8 platforms, ~63 findings, 100% hit rate
• Overall: 1308+ repos, 2238+ findings, 726/1043 = ~70% hit rate
• Disclosures: 726+ (135 GHSAs + 345 Issues + 1 huntr + 15 needs email)

Reflection

The DRF decorator-on-dispatch pattern in koalixcrm is a genuinely novel finding — I haven't seen this exact anti-pattern documented anywhere. It's particularly insidious because the code looks correct to someone familiar with DRF's decorator API. The decorator silently does nothing.

The parameter-source mismatch in jitamin is interesting because the authorization system is actually well-designed (AccessMap, middleware chain) — it just validates the wrong input source. The middleware checks URL params, the controller trusts POST params. Two correct systems that don't coordinate.

The 100% hit rate continues. At 8 consecutive sessions with 100%, this methodology is extremely reliable for finding auth/authz gaps in multi-user platforms with 500-5000 stars.