Twenty CRM CVE-2026-105763 runbook: patch, rotate exposed mailbox passwords

A runbook for a cleartext credential leak

A remediation guide published on dev.to walks operators of Twenty CRM through closing CVE-2026-105763, a vulnerability that left mailbox passwords readable in cleartext by any workspace member. The runbook's central argument is that the software fix is only half the job: credentials that were readable during the exposure window remain valid until someone rotates them at the mail provider.

Who is affected

According to the runbook, affected installations span Twenty 1.20.10 up to but not including 2.7.0, which covers every 2.6.x release. Builds at 1.20.9 or older are not affected.

How mail is connected matters as much as the version number. Workspaces that linked mail exclusively through Google or Microsoft OAuth stored no mailbox password and were not exposed. Instances using IMAP, SMTP or CalDAV with a stored credential were.

Patch and verify

The fix is an upgrade to Twenty 2.7.0 or later. The dev.to guide notes that the release conceals the exposed field, limits connected-account lookups to the requesting user, and encrypts stored credentials. Because it changes how connected accounts are stored, the guide recommends treating the upgrade as a migration: take a database backup, review the connected-account portion of the release notes, and plan a maintenance window.

Verification should confirm three behaviours once the upgrade lands. 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. The guide also recommends an end-to-end test, sending through a connected SMTP account and reading via IMAP or CalDAV, to prove the migration preserved working connections.

Rotate what leaked

No patch can revoke a password that has already been read. For every mailbox connected to an affected workspace, the runbook says to change the password at the mail host rather than inside Twenty, and to invalidate app-specific passwords and long-lived SMTP credentials tied to those mailboxes at the same time.

Each rotated mailbox should then be treated as a possible compromise vector. The guide suggests listing the services that use the mailbox as a password recovery address, reviewing those accounts for reset notifications and sessions that cannot be explained, and coordinating with the owning team if the mailbox is shared.

Who could have read the data

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

Detecting past reads is awkward. Because GraphQL requests share a path and verb, URL-based logging rules will not have flagged anything, according to the guide. If operation names or query bodies were retained, review requests for connectedAccounts; if they were not, the guide says to record that limitation honestly in the incident record.

Sizing the exposed footprint

For context, the runbook reports ZoomEye results: an app fingerprint query for Twenty returned 7,405 assets, a title match returned 7,100, and a query against the CVE identifier returned zero. The author cautions that these are fingerprint matches on reachable assets, not counts of vulnerable builds, and that the zero reflects CVE indexing rather than proof that nothing is exposed.

Why it matters

This vulnerability combined a low bar, any member with no elevated role, with high-value data: mailbox passwords that often double as recovery routes into other services. The runbook's sequence works as a template for any incident where a patch stops the disclosure but cannot undo the leak: patch, verify, rotate at the provider, audit recovery paths, then shrink who can reach the system. For teams running Twenty with IMAP or SMTP credentials, rotation is not optional, because a password any colleague could read should be treated as read.