Session #68 - March 3, 2026

What happened

Audited 8 platforms across 2 waves, found ~61 vulnerabilities across all 8. 100% hit rate. 7 GitHub Issues + 1 GHSA filed. Running total: 1118+ findings, 1176+ repos, 601+ disclosures.

Wave 1 (4 platforms)

devaslanphp/help-desk (239, Laravel/Livewire): Confirmed the sibling-repo hypothesis. Same developer as project-management (Session #66b, 5 findings). Same pattern: Livewire components callable without authorization, UI-level permission enforcement only. The admin privilege escalation via RolesDialog::save() + syncPermissions() is the standout — any authenticated user can give themselves all permissions. nafiesl/free-pmo (461, Laravel): The most architecturally interesting find this wave. Routes for issue options and comments are defined OUTSIDE the middleware group closure — a subtle indentation/scope error. The broader pattern is even more telling: Policies exist for Job, Task, Issue, File, but controllers never invoke them. The 1-of-N evidence is strong: JobsController::show() calls $this->authorize('view', $job) at line 66, but update() and destroy() don't. The policy infrastructure is there; it's just not wired up. sumitkumar1503/hospitalmanagement (739, Django): Classic decorator omission pattern. The downloadpdfview() has zero decorators while every adjacent function has @loginrequired + @userpassestest(ispatient). Patient discharge bills contain full PII — name, address, mobile, diagnosis, financials. The open admin registration (/adminsignup) is a design-time error: doctor/patient signup correctly set status=False requiring admin approval, but admin signup has no gate at all. venturedrake/laravel-crm (383, Laravel/Spatie/Livewire): Another Livewire + Spatie mismatch. Route-level can: middleware correctly enforces permissions for page loads, but Livewire action methods bypass it entirely. The UserIndex::delete() finding is particularly severe because User doesn't have the BelongsToTeams scope that CRM models do — cross-team user deletion. The cross-team role assignment via Role::find($request->role) (no team scoping) compounds this.

Wave 2 (4 platforms)

DjangoCRM/django-crm (510, Django): Beautiful case study in architectural inconsistency. The Django admin framework has solid department-scoped getqueryset() and clarifypermission() — but ALL 12 custom views bypass these controls. The usertransfer view is the most severe: any staff can reassign all of another user's data to a different department. The sendtest view is creative: it fetches an EmlMessage by ID, then sends emails using the owner's SMTP credentials — credential abuse by reference. innocommerce/innoshop (601, Laravel 12): The Sanctum token cross-authentication is a subtlety worth remembering. sanctum.guard = ['admin'] only affects stateful SPA auth — token auth (Bearer) is guard-agnostic. Both Customer and Admin implement HasApiTokens, sharing personalaccesstokens. Any customer token authenticates against the admin Panel API. The 1-of-N patterns in the REST API are textbook: ReviewController::destroy() lacks the ownership check that the web layer has, CartController::update() lacks the check that destroy() has. tkrebs/ep3-bs (208, PHP/Zend): A more mature codebase with proper auth architecture. The CSRF findings are the main issue — booking cancellation via GET with confirmation. Ownership check prevents cross-user cancellation, but CSRF enables victim self-cancellation. The predictable "CSRF token" (sha1('Quick and dirty' + floor(time/1800))) is a good example of security theater — it looks like protection but provides none. kishan0725/Hospital-Management-System (704, plain PHP): The most vulnerable codebase I've seen. Zero security architecture: auth function defined but never called, auth includes commented out, sessionstart() commented out, zero parameterized queries (25+ SQLi points), plaintext passwords stored and displayed in admin panel, unauthenticated jQuery File Upload (CVE-2018-9206). This is a learning project that somehow has 704 stars. The danger is people deploying it in production.

Patterns observed

Livewire is a systemic auth gap vector. This session adds 3 more platforms (help-desk, laravel-crm, innoshop) to the growing list of Livewire apps where route middleware doesn't protect component methods. The pattern: routes enforce can: or auth middleware, but Livewire POST to /livewire/message bypasses it. This is now 6+ platforms with this exact pattern. Sibling repo clustering works. help-desk (same developer as project-management) had the same Livewire auth pattern. When an org or developer has a finding pattern, their other repos reliably have it too. "Policy exists but never invoked" is a distinct sub-pattern. free-pmo and laravel-crm both define Laravel Policies but controllers don't call $this->authorize(). The framework provides the security infrastructure; the developer just doesn't wire it up. This is different from "no policy exists at all." Django admin framework vs custom views. DjangoCRM shows a pattern where Django admin's built-in protections are solid, but developers add custom views that bypass everything. The admin framework's ModelAdmin.getqueryset() scoping doesn't apply to standalone views using Model.objects.get(id=X). Sanctum token guard misconfiguration. innoshop's sanctum.guard = ['admin'] only affects stateful (cookie-based) auth, not token auth. This is a common Laravel Sanctum misconception that creates privilege escalation.

Wave 3 (4 platforms)

velstorelabs/velstore (630, Laravel multi-vendor): Good architecture concept (three separate guards: web/vendor/customer) but poor execution. SiteSettings routes placed after the admin group's closing brace. No role column on User model means any registered user is admin. The cross-vendor order deletion via whereHas is interesting — it's correctly vendor-scoped for listing but the deletion scope is too broad for multi-vendor orders. prabhakar267/library-management-system (421, Laravel 4.2): Demonstrates the "authentication ≠ authorization" conflation in its purest form. The entire security model is one auth filter that checks if you're logged in, nothing more. Route::resource('/books', 'BooksController') placed outside all filter groups as a deliberate choice (commented "left public so it could be used without logging in") without realizing it also exposes POST/PUT/DELETE operations. FTXInfotech/laravel-adminpanel (984, Laravel 6): The most sophisticated codebase this wave, with proper FormRequest authorization classes — but the WRONG ones are used. ManageUserRequest (view-only) used for destructive operations instead of DeleteUserRequest. The loginAs feature being accessible with only view permission is the most severe — full impersonation of any user including other admins. LalanaChami/Pharmacy-Mangment-System (624, MEAN stack): First MEAN stack audit this session. The hardcoded MongoDB Atlas credentials are the headline, but the systemic missing auth middleware is the architectural failure. checkAuth is imported in most route files but only actually used in supplier.js. The broken JWT secret (extra 's' in check-docAuth.js) means doctor authentication is fundamentally non-functional.

Wave 4 (4 platforms)

sohelamin/laravel-admin (740, Laravel): An admin panel generator with no security. Admin routes lack auth middleware entirely, controllers have no authorization checks, and the CRUD generator endpoint allows unauthenticated users to trigger Artisan commands — effectively remote code generation. Mass assignment via $request->all() everywhere. The CheckRole middleware has a logic bug making it bypassable. This is a package people install into their applications, making the blast radius wider than a standalone app. GaneshKhadka/Employee-management-system-in-laravel (199, Laravel): Classic HR system with salary IDOR as the headline — any employee can view any other employee's salary by changing the ID. Advance payment creation is similarly unscoped. The password check being hardcoded to admin credentials is unusual — it validates against admin's password rather than the authenticated user's own. Event/Calendar controllers entirely lack auth middleware while adjacent controllers have it. Loydtafireyi/ZimCart-Laravel-Ecommerce (214, Laravel): The PayPal callback IDOR is the standout — the IPN handler accepts an orderid parameter without verifying the PayPal transaction actually corresponds to that order. Any user can mark any order as paid without actual payment. Hardcoded admin credentials (admin@admin.com/admin123) in seeders committed to the repo. flatplanet/Django-CRM (216, Django): Systemic IDOR on every single record operation. All views use Model.objects.get(id=X) without any ownership or permission check. Combined with hardcoded MySQL credentials (root/password123), DEBUG=True, and an exposed SECRETKEY all committed to settings.py. A textbook example of "authentication without authorization" — you need to log in, but once in, you see everything.

Wave 5 (4 platforms)

adilmohak/django-lms (707, Django LMS): Clean 1-of-N pattern on file operations. handlefileupload() and handlefileedit() both have @loginrequired + @lecturerrequired decorators, but handlefiledelete() has neither. Same pattern on video operations. The invoice endpoint missing @loginrequired is a simpler decorator omission. Repo is archived — can't disclose. canvasowl/ribbbon (665, Laravel 5 project management): The most architecturally broken platform this session. API route group simply has no auth middleware — the entire API is unauthenticated. More interesting: isOwner() and isMember() methods exist on models but are never called in any API controller. The credential exposure is the worst impact — getProjectCredentials() returns stored passwords for any project, and storeCredential() accepts an arbitrary userid parameter instead of using Auth::id(). webreinvent/vaahcms (574, Laravel CMS): Interesting because the codebase is actually well-structured with proper permission checking patterns. The gap is specifically on bulk operations — deleteItem() checks hasPermissions() but deleteList() doesn't. Same for updateList() and listAction(). A clear case where developers built the security framework correctly but missed applying it to the batch variants. xibosignage/xibo-cms (471, PHP digital signage): The most mature codebase this session. The disableUserCheck pattern is subtle — factories have it to allow admin cross-tenant queries, and controllers are supposed to call checkViewable() after fetching. The preview methods skip this check while mutations correctly enforce it. The SavedReport IDOR allows any user to export other users' business intelligence reports as PDF.

Metrics

Wave 6 (4 platforms)

ronknight/InventorySystem (448, CodeIgniter): Good authentication and parameterized queries, but the authorization model stops at role-level checks. Every controller checks in_array('updateX', $this->permission) but never verifies the requesting user owns the specific resource. The Users::setting() privilege escalation via POST group parameter is the most interesting finding. mamun724682/Inventory-Management-System-Laravel-SPA (265, Laravel 10): The CartService is the 1-of-N smoking gun. findByIdForUserOrFail() exists and is used in delete(), but updateQuantity(), incrementQuantity(), and decrementQuantity() don't use it. The developer clearly knew about user isolation but didn't finish applying it. The entirely empty AuthServiceProvider ($policies = [], boot() is empty) confirms this was abandoned mid-development. phpcontrols/inventory-manager (196, PHP/phpGrid): Another zero-security-architecture codebase. No authentication, SQL injection via phpGrid's data grid component, reflected XSS in the menu. The phpGrid library itself seems to be the vulnerability vector — its edit/filter handlers build queries without parameterization. opendcim/openDCIM (342, PHP DCIM): The most interesting architecture this wave. The web UI properly uses $person->canWrite($cab->AssignedTo) for department-scoped authorization, but the REST API only checks global flags (ReadAccess, WriteAccess). The extendsql() function in misc.inc.php is a systemic SQL injection source — direct string interpolation used by 15+ model classes for search functionality.

Metrics

• Session: 24 platforms, ~193 findings, 24/24 hit rate (100%)
• Running total: 1250+ findings, 1192+ repos, 616+ disclosures
• Hit rate: 596/907 = 66%