Huly workspace links and private spaces need one policy
Huly combines chat, documents, projects, and team spaces in a workspace. An invite link can be convenient for a growing team and risky when it becomes a standing access path. Huly documents invite settings for link duration, email mask, and usage limit. It also documents workspace roles, global admin roles, and private spaces that require membership.
On 2026-11-04, ZoomEye count-only queries returned 0 for app="Huly" and 881 for title="Huly" with page 1, pagesize 1, and sub_type=all. The title value is large enough to contain unrelated sites and product references. It is not a count of exposed Huly workspaces.
A useful review begins with the invite link inventory. Check who can create links, how long they remain valid, whether an email domain mask applies, and whether the link has a usage limit. Disable or rotate links that were created for a project that has ended. Compare the invite policy with the organization's identity provider and domain ownership. A mask such as @yourcompany.com is a useful constraint only if the identity provider verifies the email domain.
Workspace roles need a separate review. Huly describes owners, maintainers, users, global space admins, space type roles, and individual space members. Owners can manage workspace settings and remove members. Maintainers can manage settings but cannot delete the workspace or remove owners and team members. Global space admins can archive and delete projects but cannot delete the workspace. Map these powers to real job responsibilities and review who holds each role.
Private spaces add a data-level boundary. Huly says a private space is restricted to selected members. It also warns that an auto join setting can add new workspace members to a private space even when they were not explicitly selected. That interaction should be tested before a hiring wave or a workspace migration. A space that looks private in a screenshot may admit new members through workspace settings.
Huly's self-hosting documentation separates the workspace from the hosting layer. A self-hosted deployment can configure OIDC, GitHub OAuth, and sign-up controls. Review the callback URL, redirect URI, signing secret, and account mapping for each integration. Disable email self-registration when the workspace is meant to be invite-only. Keep the management interface on a private network and verify that a public frontend does not expose another service.
Confirm the candidate before discussing exposure. The 881 title observations are a discovery signal, not a vulnerability statement. Use authorized product-specific checks, certificate ownership, and workspace-owner confirmation. Record the exact query, then review invite links, roles, auto-join behavior, and external integrations as configuration evidence. Those answers are more useful than the raw title count.
