Manyfold exposure starts with the multiuser switch

Manyfold is a self-hosted asset manager for 3D models. Its default deployment can be a private single-user library, which makes it easy to treat the application as a personal tool rather than a multi-user service. That assumption breaks when multiuser mode, OIDC, sharing, or API credentials are enabled.

On 9 November 2026 at 08:50 Asia/Shanghai, a ZoomEye query using sub_type=all, page 1, and page size 1 returned 51 assets for title="Manyfold" && http.body="Manyfold". The broader title query returned 52 and the body query returned 344. The application fingerprint returned zero, so the title-and-body intersection is the useful conservative measurement, not proof that every host is a public library.

The query is reproducible through the selected ZoomEye search.

The default is not a multiuser security model

Manyfold's configuration documentation says multiuser mode is off by default. In single-user mode, the application operates without a login. The same page recommends enabling multiuser if the instance is exposed to the public Internet, even when the operator intends to be the only user.

That recommendation is a useful starting point, not a complete answer. Enabling login changes the application from an unauthenticated utility to a service with accounts, roles, permissions, invitations, and OIDC trust. Each of those features needs an owner and a review.

The security page adds a container-focused control: a read-only root filesystem can prevent an attacker from changing the running application code. That is valuable, but it does not replace account review. A read-only container can still serve private data to an account with the wrong permission.

Sharing changes the object boundary

Manyfold supports per-object sharing and permissions for models, creators, and collections. The release notes describe permissions for viewing, editing, and ownership, with sharing to individual users, local groups, or the general public. A collection that looks internal can therefore have a public member or a user-specific grant.

Review the object graph from the outside in. Start with the site-wide public setting, then the collection, model, and creator grants. Check whether a public model is reachable through a collection that the operator believed was private. Check whether a group grant applies to a model that was later moved.

The public share is not a vulnerability by itself. The risk is an unintended combination of a public object, a discoverable link, and an account or group that no longer needs access. The permission review should record the effective grant for a test user, not only the intended role name.

OIDC and API keys extend the identity plane

Manyfold documents OIDC support for authentication. OIDC reduces password management, but it adds a trust relationship with the identity provider. Verify the issuer, client ID, redirect URI, and claim mapping. Confirm what happens when a user is removed from the identity provider but still has a local Manyfold session or API key.

Recent release notes describe OAuth application credentials and API keys for users with contributor permission or above. The API can access private data when it is authenticated with the right credentials. That makes token inventory part of the data-access review. List the tokens that exist, who owns them, what they can reach, and when they were last used.

Do not treat a contributor role as harmless. A user who can upload or edit models may also be able to create API credentials and share content. The effective permission is the combination of role, object grant, token scope, and site-wide setting.

A practical review for an owned instance

Open the public home page without a session and record what is visible. Sign in as a reader, a contributor, and an administrator. For each role, attempt to list collections, open a private model, create a share, and use an API credential. Then disable a test account at the identity provider and confirm that its existing API tokens stop working or are explicitly revoked.

Check the container's filesystem policy and the storage path for uploaded models. A public model library can contain large files and sensitive embedded metadata. A writeable code directory increases the impact of an application compromise. Neither issue is visible from the product banner.

The 51 title-and-body matches are an inventory signal. They do not establish that an instance is exposed without authentication. For each owned host, compare the intended audience with multiuser mode, public sharing, OIDC mapping, and API credentials. Manyfold is easiest to defend when the single-user assumption is either true by design or replaced with an explicit multi-user policy.

References

• Manyfold documentation, Configuration
• Manyfold documentation, Security
• Manyfold release notes, Release v0.132.0
• Manyfold release notes, Release v0.77.0