Discuz! is a long-running community forum platform, and its pages often contain the product name in templates, footer text, plugin output, and cached content. That makes a body search a poor proxy for the number of deployed sites. A security inventory should start with the product fingerprint and keep broader text matches in a separate candidate pool.
A bounded ZoomEye SDK probe on 2026-11-12 between 00:48:44 and 00:48:48 UTC used sub_type=all, page 1, and a page size of one. The application query app="Discuz!" returned 39,915 matches. The title query title="Discuz!" returned 45,280, and http.body="Discuz!" returned 960,249. The body count describes pages containing the string, not confirmed forum deployments. The application and title counts are closer to the inventory question, although each still needs ownership and access verification.
Separate discovery from administration
The public forum is only one part of the operating surface. An administrator typically manages members, roles, forums, plugins, themes, and integration settings through a control plane. A forum that looks like an ordinary community site can therefore support a much broader administrative role than its visible front page suggests.
Start with the owner and the deployment model. Is the site a hosted community, a standalone installation, or part of a larger content network? Which version is in use? Which plugins and themes are installed, and who approves their updates? A product count can find candidate sites. It cannot determine whether a site is patched or whether a third-party extension is present.
Discuz! documentation describes an OAuth 2.0 based REST API in its newer product line. That integration layer deserves the same review as the web administrator. Inventory registered applications, callback domains, token lifetimes, and the permissions granted to each integration. Check that a disabled community account cannot continue using an application token after removal.
Review the community boundary
Forum roles can expose more than discussion content. Moderators may edit posts, move threads, manage attachments, or see restricted boards. Administrators may change templates and plugins that execute in the site context. A public registration path can create accounts even when the site appears read-only to anonymous visitors.
Review registration, email verification, password recovery, and account approval together. Confirm which roles a new account receives and whether a moderator can promote another user. Check attachment and media handling, because uploaded content may be served from the same origin as the administration interface. A support forum with public posts and a private staff board should not rely on hidden navigation for the private boundary.
Plugins are a supply-chain decision. Record the source, maintainer, version, and update path for every extension. Remove plugins that are no longer maintained or that require broad database or file access. A plugin inventory is also useful after an incident because it identifies code that may process content outside the main application review.
Turn the count into a verification queue
Use the application query as the primary discovery set and the title query as a recall check. Treat body-only matches as unconfirmed references until the page or owner provides product evidence. Deduplicate domains, hosts, and tenants. Record the observation time and query scope so the next review compares the same measure.
For each owned site, verify the exposed routes, administrative entry points, registration policy, role model, API clients, plugin inventory, and update status. Check whether the site sends security headers and whether an administrative interface is reachable from an approved network. Do not attempt unauthorized access to prove that a page is sensitive.
ZoomEye is useful for finding candidate forums that are missing from an asset catalogue. The next step is a small, owned list with evidence. A 960,249 body match is not a deployment count, and a 39,915 application match is not a list of vulnerable sites. The inventory becomes actionable when a named owner confirms the product, version, access policy, and patch state.