BookStack public libraries require upload and authentication review

BookStack organizes documentation into books, chapters, and pages. It can store internal procedures, customer notes, architecture diagrams, and uploaded files. A public BookStack instance may be a deliberate knowledge base or an internal service that was exposed by a proxy change. The difference matters more than the product name in the page title.

What ZoomEye returned

On 2026-11-03T04:15:40Z, a count-only query with page=1, pagesize=1, and sub_type=all returned 5,414 total matches for title="BookStack". The same run returned 29,254 for app="BookStack". The application clause is much broader, so the title observation is the more conservative discovery set for this batch. Neither count establishes that a library is anonymously readable.

The app count may reflect broad matching or a fingerprint shared by pages that are not production instances. The title count can also match documentation and custom sites. Use both as candidates, then validate against an internal deployment list and DNS ownership.

Find out what is public

BookStack's security documentation covers file uploads, secure cookies, and hosting behind a proxy. Start with the content model. Are books public, restricted to roles, or private to users? Can anonymous users search, export, or download attachments? Does an unlisted page remain accessible by URL?

Review authentication methods and administrative access. If SSO is used, confirm how local accounts behave and how a disabled directory user loses access. Check password policy, session lifetime, and the recovery process for the administrator account. A documentation tool can hold sensitive recovery procedures, so a weak admin path has a direct security effect.

Inspect file uploads separately. BookStack's upload options include local storage, protected image serving, and external storage. A public page may reference an image or attachment that is served without the same access check. Test direct file URLs with an unauthenticated session and with a user outside the owning role.

Set a safe reverse-proxy policy

The security page notes that a proxy can make all users appear to come from the proxy address, affecting audit logs and rate limiting. Configure trusted proxy handling and the application URL correctly. Review SESSION_SECURE_COOKIE and HTTPS settings for the deployment.

Restrict database and cache services to the application network. The public web server should not be able to reach an administrative database port directly from the internet. Backups should be encrypted and stored under a different access policy than the live pages.

Keep debug output off. Upload limits, file type restrictions, and image security settings should match the users who can publish content. If untrusted authors can upload files, review the storage backend and direct-serving path. Do not assume a login is required for an upload URL just because the page editor requires one.

Turn matches into owned records

Resolve each match to a domain, certificate, owner, and environment. Record the version, authentication mode, public-book count, and upload backend. For unknown hosts, stop at attribution. Do not enumerate pages or attempt account access.

Track new title or app matches under organization-owned domains. A new match may be a staging instance, a customer knowledge base, or a migration. Compare the change with deployment records. Alert on public access changes and new administrators, not just on the global count.

BookStack's risk comes from the information placed in it. ZoomEye can supply candidates that identify the product, but the decisive questions are local: which books are public, who can upload, where files are stored, and who can administer the instance. A count is only the start of that review.

References

• BookStack, Security
• BookStack, Configuring file uploads
• BookStack, Admin documentation