Activepieces 工作流程暴露：自動化憑證的標題與正文線索

Activepieces workflow exposure: title and body evidence around automation credentials

Activepieces runs automation flows that connect to external services with API keys, OAuth tokens, and other pieces of authentication. A workflow builder is a control plane for those credentials and for actions that may create tickets, send messages, modify files, or call internal APIs. A public management page deserves more scrutiny than a static documentation site.

The ZoomEye count-only measurements on November 6, 2026 used sub_type=all, page 1, and page size 1. app="Activepieces" returned 0, title="Activepieces" returned 1,408, and http.body="Activepieces" returned 2,446. The app field did not classify the product in this scope. Title and body matches need ownership review and page classification.

The product string is not the control plane

A title match can identify a self-hosted instance, a hosted workspace, a tutorial, or a service page. A body match can come from a JavaScript bundle, an integration catalog, or an embedded documentation frame. Security teams should not infer that every match is a workflow editor with credentials.

For owned hosts, classify the page as a login screen, an authenticated workspace, a public documentation page, or an error page. Do not try to create an account or execute a flow on an unknown system. A bounded page review can establish the likely application category without touching workflow state.

API keys and integration credentials

Activepieces documentation describes API keys generated from a platform dashboard and Bearer-token use. It also describes piece authentication for services such as API keys, OAuth, Basic authentication, and custom authentication. The management plane therefore has two credential classes: keys that authorize access to Activepieces and secrets stored for connected pieces.

An administrator should be able to enumerate connected accounts, owning flows, granted scopes, last use, and revocation status. A contributor who can edit a flow should not automatically be able to read every stored secret. When a piece connection is removed, revoke the upstream credential as well.

Network and execution boundaries

Workflows can make outbound requests. Restrict destinations with an approved egress policy where the environment supports it. Protect internal APIs from arbitrary URL actions, and do not let an untrusted flow choose a hostname that resolves into the management network. Review webhook endpoints, retries, and payload logging for data exposure.

Separate the web UI, API, worker, and database network paths. A public API key should not grant administrative user management unless the integration requires it. Protect background workers with the same secret-management policy as the web application. Review debug logs for tokens and full request bodies.

The MCP and automation path

Current Activepieces documentation describes OAuth-based MCP access and protected-resource metadata. Any new automation interface expands the set of clients that can act on the workspace. Record each MCP client, OAuth issuer, permission, and revocation path. Treat an agent as another user with explicit scope, not as an invisible extension of an administrator.

A measured response

Begin with known Activepieces deployments and compare them with the title and body leads. Verify login and SSO settings, user roles, API-key inventory, piece connections, egress policy, worker isolation, audit logs, backup encryption, and update control. Review which flows can reach sensitive internal systems.

The absence of an app match does not mean the product is absent. It means the application fingerprint was not observed in this query. The operational focus should be the workflow editor, its stored credentials, and its outbound authority. The external counts support discovery, not a conclusion about exposure.