File Browser is archived, but its internet footprint and self-registration defaults remain

File Browser provides a web interface over a filesystem. It can upload, delete, preview, edit, and share files within a configured root. That makes it useful for small teams and also easy to attach to directories that contain more authority than the web page suggests.

The project's official site says File Browser was archived on 2026-09-01 and will receive no further releases or security fixes. Existing releases and container images remain online. That is a lifecycle problem before it is a query problem, because an internet-visible file manager with no upstream patch path needs an owner, a replacement decision, and a network boundary.

ZoomEye returned 168,959 matches for app="File Browser" on 2026-11-10 at 00:51 UTC. The title="File Browser" query returned 152,504, the alternate title="Filebrowser" returned 2,214, and the broad http.body="File Browser" returned 613,282. The application and title counts describe large product-marker populations, not confirmed vulnerable installations. The body count is much broader and should not be treated as a product total.

View the application measurement in ZoomEye. The query used page 1, page size 1, and sub_type=all.

Self-registration can grant the server root

The deployment documentation warns that self-registered users inherit configured user defaults, including scope. With the factory default CreateUserDir=false, the user scope can be the server's root. The documentation tells operators to create a per-user directory or set a non-root default scope before enabling signup.

A GitHub security advisory described the same risk in concrete terms: a registrant could receive the server root and default create, modify, delete, rename, share, and download permissions. A separate advisory described a configuration where signup and default admin permission could create a full administrator account. These are configuration-dependent paths, but they show why signup is an administrative control, not a convenience toggle.

Any File Browser instance that still permits signup should be checked before the public count is used to infer anything about exposure. Inspect the user defaults, the configured root, the default permissions, and the signup setting. If the deployment cannot prove that self-registration is off or safely scoped, public reachability is a data-boundary issue.

Shares outlive permission changes

Another advisory described existing share links that remained accessible after an administrator revoked a user's Share and Download permissions. The administrator could reasonably expect the revocation to stop new sharing and existing access. The advisory showed that those are separate lifecycle operations.

Review the share inventory, not only the user list. Record each link's owner, target path, password state, expiry, download permission, and creation time. Test revocation with an unauthenticated browser session. If the old link still works, rotate or delete it at the storage or application layer and do not rely on the user-permission change alone.

The archived status raises the cost of every unpatched behavior. A current fork or replacement may have fixes that the archived release does not. Treat a replacement migration as a security project with a data inventory and a rollback plan, not a simple package update.

What to do with the measurement

The ZoomEye application count is a reason to find the actual deployments. Start with the app query, compare it with the title variants, and confirm each candidate in a small authorized sample. A product page can be a public file browser, a login screen, an error page, or a stale image with no live data.

For each owned instance, record the version, deployment image, service account, filesystem root, signup setting, default user permissions, share policy, and replacement status. Verify that the web process can read only the files it needs and that the root does not contain credentials, backups, or application source.

The product count alone does not justify contacting hosts or scanning content. The useful output is a prioritized inventory of systems that should be removed, isolated, migrated, or given an explicit exception. Archival is the deadline; the external count is the reminder that the old surface is still present.

References

• File Browser official site and archive notice
• File Browser deployment and self-registration guidance
• File Browser advisory: self-signup users inherit the server root
• File Browser advisory: shares remain after permission revocation
• File Browser advisory: signup can grant admin
• ZoomEye application measurement for File Browser

Measurement metadata: 2026-11-10 00:51 UTC, sub_type=all, page 1, pagesize 1; app 168,959, title 152,504, alternate title 2,214, broad body 613,282.