Misago is a newer forum application than many platforms in a typical asset inventory. That can make the product harder to find with a fingerprint and easier to overlook after a departmental deployment. A small count is not a reason to skip the access review.
A bounded ZoomEye SDK probe on 2026-11-12 between 00:48:56 and 00:49:00 UTC used sub_type=all, page 1, and a page size of one. The application query app="Misago" returned 0. The exact title query title="Misago" returned 32, and http.body="Misago" returned 115. The title count is a candidate inventory. The body count includes pages that may mention the project, and the zero application result does not prove that no deployment exists.
Start with the permission framework
Misago documents an ACL framework for permissions. Roles and categories contribute permission attributes, and code checks those decisions when an action runs. That design is powerful enough to separate ordinary members, moderators, and administrators, but it depends on a clean mapping from organizational roles to forum permissions.
Inventory roles and category visibility. Determine which role can see private categories, moderate content, manage users, or enter the administration panel. Check that a user removed from a role loses the related permissions on the next request or session refresh. Test a category with restricted read access from an account that is not a member.
The forum frontend uses a Django API and React components, while the admin panel is a separate administrative surface. Review both. A public thread endpoint should not reveal a restricted category through a search result, notification, or quote preview. A management endpoint should require the permission check even when the UI normally hides the action.
Verify deployment identity
The setup documentation states that the first account created during installation has administrator access. That account is a critical bootstrap identity. Confirm who owns it, where the password or recovery path is stored, and how it is removed or renamed after routine administrators are established. A generic installer account left in place can become a shared administrative secret.
Record the deployment version and update path. Determine whether the site uses the Docker setup or another supported installation. Check the database and media storage boundaries. A forum may serve uploaded avatars, attachments, or static assets from the same host. Review file type handling, access control, and backup scope as part of the platform inventory.
Email, registration, and password recovery are part of the identity boundary. Confirm that registration can be disabled where it is not needed, that email verification matches policy, and that a moderator cannot change an account into a higher role without an audit trail.
Use the count as a lead
The 32 title candidates should be checked for owner, domain, version, and deployment purpose. Some may be project pages or demonstration sites. The 115 body matches can identify documentation and references that the title search misses. Keep the query scope and observation time so a later count can be compared without mixing in a new fingerprint.
For each owned site, collect the roles, categories, registration policy, administrative entry point, installed version, storage configuration, and backup owner. Then review the actions that cross tenant boundaries. A forum that hosts public support discussions alongside private customer categories has a higher consequence if a permission check is missed.
ZoomEye helps locate a small population of forum services that may not be in a central inventory. It cannot determine whether each site has a correct role mapping. The useful output is an owner-confirmed list with tested category and administrative boundaries.