Summary
A credential exposure vulnerability in Twenty's metadata GraphQL API could disclose plaintext IMAP, SMTP, and CalDAV passwords belonging to other connected accounts in the same workspace. A normal workspace member could retrieve these credentials and potentially access external mail or calendar services or reset related third-party accounts when account visibility and caller identity were not properly enforced.
A credential exposure vulnerability in Twenty's metadata GraphQL API could disclose plaintext IMAP, SMTP, and CalDAV passwords belonging to other connected accounts in the same workspace. A normal workspace member could retrieve these credentials and potentially access external mail or calendar services or reset related third-party accounts when account visibility and caller identity were not properly enforced.
Affected context
The issue occurs in Twenty workspaces that use connected external accounts with stored connection parameters and expose the /metadata GraphQL connectedAccounts query. Risk is present when connection credentials are included in API responses without field-level protection and account lookups do not consistently restrict results to resources visible to the requesting user. Workspaces using Google or Microsoft OAuth-only connections were not affected by the plaintext password disclosure described here.
The issue occurs in Twenty workspaces that use connected external accounts with stored connection parameters and expose the /metadata GraphQL connectedAccounts query. Risk is present when connection credentials are included in API responses without field-level protection and account lookups do not consistently restrict results to resources visible to the requesting user. Workspaces using Google or Microsoft OAuth-only connections were not affected by the plaintext password disclosure described here.
Exploit preconditions
- Attack surface: The
/metadataGraphQL API and itsconnectedAccountsquery - Required access: A valid normal member account in the affected workspace
- Trigger point: Requesting connected-account metadata through GraphQL
- Why exploitation is possible: Sensitive
connectionParameterswere returned for accounts outside the caller's authorized scope, and the response included plaintext external-service credentials
- Attack surface: The
/metadataGraphQL API and itsconnectedAccountsquery - Required access: A valid normal member account in the affected workspace
- Trigger point: Requesting connected-account metadata through GraphQL
- Why exploitation is possible: Sensitive
connectionParameterswere returned for accounts outside the caller's authorized scope, and the response included plaintext external-service credentials
Why this happens
The underlying flaw combines insufficient protection of credentials with an authorization boundary failure. A sensitive field in ConnectedAccountDTO was exposed through a metadata response, while the account lookup did not reliably enforce the requesting user's identity or account visibility. This maps to CWE-522: Insufficiently Protected Credentials, because reusable authentication secrets were disclosed in plaintext to an unauthorized workspace member.
The underlying flaw combines insufficient protection of credentials with an authorization boundary failure. A sensitive field in ConnectedAccountDTO was exposed through a metadata response, while the account lookup did not reliably enforce the requesting user's identity or account visibility. This maps to CWE-522: Insufficiently Protected Credentials, because reusable authentication secrets were disclosed in plaintext to an unauthorized workspace member.
Potential impact
- An attacker could access other users' connected mail or calendar services
- Exposed credentials may allow mailbox or calendar data disclosure and manipulation
- Attackers could send messages or alter external account data
- Reusable credentials could enable password resets or broader third-party account compromise
- The incident could lead to phishing, impersonation, or lateral access across integrated services
- An attacker could access other users' connected mail or calendar services
- Exposed credentials may allow mailbox or calendar data disclosure and manipulation
- Attackers could send messages or alter external account data
- Reusable credentials could enable password resets or broader third-party account compromise
- The incident could lead to phishing, impersonation, or lateral access across integrated services
General mitigation guidance
Mitigation should center on minimizing credential exposure and enforcing authorization at both query and field levels.
Common defensive patterns include:
- Excluding passwords, tokens, and connection secrets from general-purpose DTOs and metadata responses
- Returning only the minimum fields required by the requesting workflow
- Enforcing server-side identity, tenant, ownership, and visibility checks for every connected-account lookup
- Storing external credentials in protected secret-management systems and avoiding plaintext persistence where practical
- Prefering short-lived, narrowly scoped OAuth tokens over reusable passwords when supported
- Applying least privilege to integration accounts and limiting access to administrative operations
- Redacting secrets from logs, traces, error responses, caches, and client-side state
Mitigation should center on minimizing credential exposure and enforcing authorization at both query and field levels.
Common defensive patterns include:
- Excluding passwords, tokens, and connection secrets from general-purpose DTOs and metadata responses
- Returning only the minimum fields required by the requesting workflow
- Enforcing server-side identity, tenant, ownership, and visibility checks for every connected-account lookup
- Storing external credentials in protected secret-management systems and avoiding plaintext persistence where practical
- Prefering short-lived, narrowly scoped OAuth tokens over reusable passwords when supported
- Applying least privilege to integration accounts and limiting access to administrative operations
- Redacting secrets from logs, traces, error responses, caches, and client-side state
How teams detect issues like this
Detection can combine API testing, code review, and data-handling policy checks:
- Review GraphQL schemas and DTOs for credential-bearing fields exposed through metadata or listing queries
- Test queries with ordinary member identities to verify tenant, ownership, and visibility boundaries
- Use static analysis to flag password or token fields serialized into API responses
- Inspect resolver and repository patterns for missing caller-identity filters or authorization checks
- Monitor unusual connected-account enumeration and access to metadata endpoints
- Enforce policies that prohibit plaintext credentials in general API payloads and require secret redaction
- Automated security review tools can help identify sensitive-field exposure and missing authorization guards
Detection can combine API testing, code review, and data-handling policy checks:
- Review GraphQL schemas and DTOs for credential-bearing fields exposed through metadata or listing queries
- Test queries with ordinary member identities to verify tenant, ownership, and visibility boundaries
- Use static analysis to flag password or token fields serialized into API responses
- Inspect resolver and repository patterns for missing caller-identity filters or authorization checks
- Monitor unusual connected-account enumeration and access to metadata endpoints
- Enforce policies that prohibit plaintext credentials in general API payloads and require secret redaction
- Automated security review tools can help identify sensitive-field exposure and missing authorization guards
