Mixpost Workspaces Hold Social Authority; Inventory the Roles and Tokens
Mixpost Workspaces Hold Social Authority; Inventory the Roles and Tokens
A social publishing platform is valuable to an attacker because it can speak with the organization's voice. Access to connected accounts can affect public posts, scheduled campaigns, analytics, and approval workflows. Mixpost organizes that authority into workspaces and user roles, which makes the join between account, workspace, role, and token the primary review object.
The measurement
On 2026-11-06 08:46:38 +08:00, ZoomEye count-only queries used sub_type=all, page 1, and pagesize 1. app="Mixpost" returned 0, title="Mixpost" returned 434, and http.body="Mixpost" returned 515,331. The body result is too broad to treat as a product population. The title count is a more useful candidate set, while the absent application fingerprint shows the value of field comparison.
Workspaces and roles
Mixpost documentation describes workspaces as isolated environments with their own social accounts, posts, media, members, and permissions. The API exposes workspace roles such as admin, member, and viewer. The MCP server documentation says the token owner's workspace role determines which tools are available.
That means a personal token is not just an integration secret. It is a delegated identity with a workspace role. Review long-lived tokens created by administrators, tokens belonging to users who changed roles, and integrations that can approve or publish posts. A token created for analytics should not be able to manage social accounts or publish content if those actions are outside its purpose.
Inventory the full path
For each workspace, record the owner, members, roles, approval rights, connected social accounts, inbox access, and active personal keys. Then identify who can publish without approval and who can add a new social account. A broad role can turn a stolen session or token into an authoritative post on every connected channel.
Check the reverse proxy, authentication, MFA, and session policy. Review the OAuth consent path for MCP clients and the user-facing token creation path. Confirm that revoking a token or removing a workspace member takes effect at the next request.
Test outside production
Use non-production social accounts and a test workspace. Verify that a viewer cannot schedule a post, a member cannot administer the workspace, and a token cannot act outside the owner's workspace. Test approval boundaries and account removal. Preserve the result without posting to a real public channel.
The external count is only a discovery aid. If an owned instance is found, compare its public hostname with internal records and review the social accounts it controls. The important question is who can turn workspace access into a public statement, and how quickly that authority can be stopped.