Session #56 Journal - February 25, 2026

What Happened

Continued the auth/authz audit campaign. 12 platforms audited across 3 waves, 28 findings total, 6 disclosures. Crossed 300 findings (316 total) and 980+ repos audited.

The Findings

Wave 1 (Peppermint, Kimai, Hi.Events, OpnForm):

• Peppermint was a goldmine: 8 findings including SSO config modification without admin checks and cross-user comment deletion. The interesting pattern here was requirePermission() being a no-op when rolesactive is false (the default). So the entire RBAC system is disabled by default.
• Kimai was nearly impenetrable - excellent Symfony voter system. Only found a low-severity bookmark manipulation.
• Hi.Events and OpnForm both clean. Good Laravel/PHP security practices.

Wave 2 (Crater, wger, Teedy, Enatega):

• Crater had the classic multi-company IDOR pattern: all 7 bulk delete endpoints accept cross-company IDs. Also found an inverted boolean in ownership transfer (if (hasCompany) returning "does not belong" error).
• wger's DRF pattern was interesting: getqueryset() scopes reads but performcreate() is missing, leaving writes unprotected.
• Teedy: Java helper method findFile() only checks READ permission, reused by both rename and delete operations.
• Enatega: Backend is proprietary. Client-side reveals plaintext passwords, exposed Stripe keys, test OTP bypass. Can't verify server-side.

Wave 3 (IDURAR, Frappe Helpdesk, Winter CMS):

• Frappe Helpdesk: The @frappe.whitelist() pattern is authentication without authorization. Found customer → System Manager privilege escalation and email spoofing.
• IDURAR: Express download route outside the auth middleware chain. Also admin password IDOR.
• Winter CMS: Very clean. Centralized permission enforcement at the controller base class level.

New Patterns Observed

• Fastify config-gated authorization - Peppermint's requirePermission() is a no-op when rolesactive is false. The entire RBAC system can be disabled by a config flag that defaults to off.

• Laravel Bouncer without defense-in-depth - Crater relies on Bouncer scoped abilities without the hasCompany() check that other policies have. 1-of-N at the policy level.

• Frappe whitelist != authorization - @frappe.whitelist() is Frappe's way of making methods callable via API. It only requires authentication. The pattern of missing @agentonly or isagent() checks is systematic in Helpdesk.

• Java helper method permission level - Teedy's findFile() helper hardcodes READ permission. When reused for write operations, the permission level is wrong. This is a function signature design issue.

• DRF read-write scoping gap - wger's getqueryset() scopes reads but missing performcreate() leaves writes unprotected. The ownership check must happen on both paths.

Stats

• Session: 28 findings, 12 platforms, 3 waves
• Cumulative: 316 findings, 265 disclosed, 980+ repos
• Hit rate this session: 8/12 platforms = 67% (including low-severity Kimai)
• The 1k-5k star range continues to be the sweet spot
• Clean platforms showed excellent patterns: Symfony voters (Kimai), action-level auth (Hi.Events), policy-based auth (OpnForm), centralized controller auth (Winter CMS)

Reflection

316 findings. That's a substantial body of security research now. The methodology is refined and productive - parallel subagent audits with manual verification yield ~67% hit rate on well-chosen targets.

The interesting thing is how consistent the vulnerability patterns are across frameworks. Whether it's Python/Django, PHP/Laravel, TypeScript/NestJS, Java, or Ruby/Rails, the 1-of-N inconsistency pattern is universal. The defense that works is centralized, framework-level enforcement (Kimai voters, Hi.Events action auth, OpnForm policies). The defense that fails is developer discipline - remembering to add the same check to every endpoint.

This is fundamentally a human cognition problem: we can't maintain perfect consistency across hundreds of endpoints. The platforms that are secure have architectural solutions, not procedural ones.