DEV Community

jeffrey
jeffrey

Posted on

CVE-2026-105763 remediation runbook: patching Twenty CRM and rotating what leaked

#security #vulnerability #twentycrm

CVE-2026-105763 remediation runbook: patching Twenty CRM and rotating what leaked

This is a working sequence for teams that run Twenty CRM and need to close CVE-2026-105763. The flaw exposed mailbox passwords in cleartext to any workspace member, so the runbook covers both the software fix and the credential work that the software fix cannot do for you.

Step 1: confirm scope

Determine the installed version. Twenty 1.20.10 up to, but not including, 2.7.0 is affected, and that includes all 2.6.x releases. Versions 1.20.9 and earlier are not affected.
Then check how mail is connected. Workspaces using only Google or Microsoft OAuth for mail stored no mailbox password and were not exposed. Instances using IMAP, SMTP or CalDAV with a stored credential were.

Step 2: patch

Upgrade to Twenty 2.7.0 or later. The release hides the exposed field, scopes connected account lookups to the caller and encrypts credentials at rest. Because it changes how connected accounts are stored, treat it as a migration: back up the database, read the connected account section of the release notes, and schedule a window.

Step 3: verify the fix

After the upgrade, confirm three behaviours. The /metadata connectedAccounts response should no longer carry credential material. Lookups should return only the caller's own connections. Stored credentials should be encrypted at rest.
Then test end to end. Send through a connected SMTP account and read through IMAP or CalDAV to prove the migration preserved working connections.

Step 4: rotate at the provider

Rotate the password for every mailbox that was connected to an affected workspace. Perform the change at the mail host, not inside Twenty, because the CRM change does not invalidate a password that has already been read. Revoke app-specific passwords and long-lived SMTP credentials issued for those mailboxes at the same time.

Step 5: follow the recovery path

For each rotated mailbox, list the services that use it as a password recovery address. Review those accounts for reset notifications and sessions that cannot be explained. If the mailbox is a shared one, coordinate the review with the team that owns it.

Step 6: narrow the reader population

The flaw required only the default Member role, so the set of potential readers equals the workspace membership during the exposure window. Remove accounts that no longer need access, and decide whether the instance should be reachable from the internet at all.

Step 7: capture the evidence you have

GraphQL operations share a path and a verb, so URL-based rules will not have flagged anything. If you retained operation names or query bodies, review requests for connectedAccounts. If you did not, record the limitation honestly in the incident record.

Exposure context

A ZoomEye query for app="Twenty" returned 7,405 assets and title="Twenty" returned 7,100; vul.cve="CVE-2026-105763" returned zero. These are fingerprint matches on reachable assets, not counts of vulnerable builds, and the zero reflects CVE indexing rather than absence of exposure.

References

Top comments (0)