Plane organizes work into workspaces and projects. A workspace contains members, roles, projects, access tokens, webhooks, integrations, and audit records. An internet-facing deployment therefore needs a review of the whole workspace boundary, not only the sign-in page.
A count-only ZoomEye query on 2026-11-02 returned 355 assets for app="Plane". The query used sub_type=all, page 1, and page size 1. The count describes matching product assets in the scan data. It does not prove that a workspace is public or that an instance is vulnerable.
The ZoomEye query provides a candidate population for an ownership-based review. Match it against DNS, certificates, cloud inventories, and deployment records before treating an endpoint as an organizational system.
Map workspace roles to project access
Plane documents workspace members and roles, with owners and admins able to manage sensitive settings. A workspace owner or admin may count as a project admin in every project, whether or not the person is listed as a project member. That makes workspace-level role review more important than a project membership list alone.
Public projects can be discovered and joined by workspace members. A public project is not necessarily a public internet resource, but it broadens access inside the workspace. Review which projects are public, who can join, and what data those projects contain. A public project should not hold production credentials, private customer records, or sensitive incident notes.
Project membership can also be automatic. Plane documents that a member who joins a public project or is added through automatic membership receives a project role derived from the workspace role. Review the mapping so that a guest or ordinary member does not receive contributor or admin authority through a default path.
Inventory tokens, webhooks, and integrations
Plane workspace settings include access tokens for external systems, webhooks, integrations, and audit logs. Some settings are restricted to owners and admins. These credentials are part of the workspace's attack surface even when the web UI uses SSO.
List every token with its owner, purpose, creation date, and last use when available. Avoid a single token shared by multiple automations. A token for issue synchronization should not be able to change workspace membership or billing settings. Revoke tokens after an integration is removed. Rotate a webhook secret after a project owner changes.
Review outbound webhook destinations. A webhook can send project data to an external URL, so the destination must be approved and stored with a secret. Test that a webhook cannot reach a loopback, cloud metadata, or private administrative endpoint through a redirect. Alert on destination changes and repeated delivery failures.
Inspect the public deployment
Capture the hostname, certificate, address, product evidence, and first-seen time for each candidate. Confirm whether the endpoint is a production workspace, a demo, or an unrelated page. Check TLS, authentication options, and trusted proxy configuration through authorized observation. Do not use a guessed workspace token or attempt to enumerate private projects.
Compare the public host with the configured application URL. A deployment behind a reverse proxy may generate links to an internal hostname, expose a stale API host, or accept a forwarded host header that changes its behavior. Verify that all browser, API, and webhook traffic reaches the same reviewed service.
Review the audit log retention and access. Workspace activity should be available to a security team even if a workspace owner can change local settings. Export or forward security-relevant events to an independent system. Record membership changes, token creation, webhook edits, project visibility, and role changes.
Use exposure data carefully
The 355 app matches are useful for finding Plane deployments, not for asserting that their workspaces are exposed. A self-hosted instance may require authentication and still be a valuable inventory item. A hosted product can appear in the same query without belonging to the organization.
Retain the query and count over time. A new owned hostname can reveal a deployment that missed inventory. A changed response can reflect an upgrade or a new reverse proxy. Neither change is proof of compromise. Correlate technical observations with the internal registry and audit events.
Plane concentrates several kinds of authority in one workspace. The review should account for workspace owners, project visibility, API tokens, integrations, webhook destinations, and audit evidence. A token inventory without the role model is incomplete, just as a project list without token ownership cannot explain how automation reaches the data.