Bugzilla can look like a public issue tracker from the outside while protecting whole products, individual bugs, attachments, comments, and time records through groups. A count of Bugzilla titles is therefore not a count of readable security reports. The access review begins with group membership and product defaults.
The count-only query app="Bugzilla" returned zero matches in this observation. title="Bugzilla" returned 4,022 with sub_type=all, page 1, and pagesize 1. The zero application fingerprint may reflect customization, deployment variation, or fingerprint coverage. The title result can include documentation, mirrors, and unrelated references. It is a discovery lead, not a vulnerability claim.
Map groups to products
Bugzilla documentation describes groups as the mechanism that controls which users can see or edit which bugs. A bug in a group is visible only to members of the allowed group or groups, depending on the configured group behavior. Product-level defaults can place new bugs into a group automatically.
Review the groups that protect sensitive products, security advisories, partner-only bugs, and embargoed releases. Then inspect the users and service accounts in those groups. An account that inherits an administrator role or broad group membership can see more than its daily workflow requires.
Group names are not a security proof. Use the administrative interface or a supported API to inspect the effective membership and configuration. Check default groups for new products, mandatory groups, and whether users can add themselves to groups. A temporary exception can become a permanent silence if no owner reviews it.
Inspect API access
Bugzilla APIs expose bugs, comments, attachments, products, and user information according to the same authorization model as the web interface. Test the API with a limited account and confirm that a bug outside its groups returns an authorization error or an appropriate redaction rather than the record.
API keys and tokens need a separate lifecycle. A user's key should stop working when the account is disabled, and group changes should take effect according to the deployment's session and cache behavior. Search the API configuration for public interfaces that bypass normal group checks.
Attachments and comments can carry credentials, crash dumps, or customer details. A public bug summary may be intentional while an attachment remains restricted. Test each object type rather than assuming the bug-level permission covers every file.
Review the public tracker surface
Anonymous access may be useful for support, documentation, or public projects. If anonymous users can create bugs, upload files, or receive notifications, configure rate limits, anti-automation controls, and moderation workflows. Public email addresses and names can become a data source even when the technical issue is not sensitive.
Check whether the installation has a maintained version, current security fixes, and a supported database and mail configuration. Record the version where the page or owner provides it. Do not infer a vulnerability from the product name alone.
Monitor group membership changes, administrator account changes, product defaults, API key creation, and access to restricted attachments. The audit should show who changed the policy and which subsequent requests were affected.
The 4,022 title matches can help owners find candidate installations, but the useful evidence is a group map tied to real products and users. A Bugzilla deployment is not exposed merely because it answers on the internet. It is exposed when a principal can read a bug, comment, or attachment outside its intended group. That is the boundary the review must test.