What to look for when Twenty CRM credentials leak: detection ideas for CVE-2026-105763

Detection advice for CVE-2026-105763 has to start with an uncomfortable fact: the vulnerable action is a normal-looking API call made by a legitimate authenticated user. There is no payload to signature, no shellcode and no malformed request. What follows is a practical way to think about visibility for this class of credential disclosure.

The action to detect

The exposure came from the /metadata GraphQL endpoint in Twenty CRM, through the connectedAccounts query. When the endpoint returned data, affected versions included the cleartext IMAP, SMTP or CalDAV password inside connectionParameters. Any workspace member with the default Member role could issue it.
Two signals are available in principle. The first is the requested field set: a query asking for connected account connection parameters is not something an ordinary CRM session does often. The second is the requester: an account that has no operational reason to read mailbox configuration.

Where logging usually falls short

GraphQL sends everything to one URL, so URL-based rules see normal traffic. If your logging captures only the path and status code, you cannot distinguish the exposing query from routine metadata reads. Capturing GraphQL operation names, or query bodies where your privacy policy allows it, is the difference between investigating and guessing.
Retention matters as much as capture. The affected range spans 1.20.10 through 2.6.x, which for many teams is months of running the vulnerable code. If your retention window is shorter than your exposure window, say so plainly in the incident record instead of treating missing logs as an absence of access.

Signals outside the application

The leaked value is a mail credential, so the interesting telemetry sits at the mail provider. Look for IMAP or SMTP sessions from unexpected source addresses, authentication attempts against accounts that are normally accessed only by the CRM, and unusual mailbox rules. Password reset messages arriving for downstream services are a strong indicator that a leaked recovery mailbox is being used.

Prioritising when you cannot be certain

When log evidence is incomplete, prioritise by consequence rather than probability. Rotate the mail passwords for connected accounts at the provider, because that action is cheap and closes the credential path regardless of whether anyone used it. Then reduce the population that could read those secrets by trimming workspace membership.
The patch itself is a version move to 2.7.0 or later. Be aware it is a breaking change for connected account storage and that it encrypts credentials at rest, so schedule the migration rather than treating it as a routine upgrade.

Scope facts

Twenty 1.20.10 up to, but not including, 2.7.0 is affected, including all 2.6.x releases. Versions 1.20.9 and earlier are safe. Workspaces using only Google or Microsoft OAuth for mail were not affected because no mailbox password is stored. A ZoomEye query for app="Twenty" returned 7,405 assets and title="Twenty" returned 7,100; vul.cve="CVE-2026-105763" returned zero, reflecting CVE indexing lag rather than absence of exposure.

References

• Twenty CRM flaw CVE-2026-105763 exposes plaintext email passwords to any workspace member: https://securityonline.info/twenty-crm-vulnerability-cve-2026-105763/
• Vendor security advisory referenced by the collected report (Twenty CRM GitHub security advisories).