- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 14
- Public CVEs
- 7
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Replies within 1 day
- As the policy promises.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Response
-
Within 1 days
The policy commits to a response within one business day and guarantees no legal action against good-faith research
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
- Hall of fame
-
Yes
Credit in the fix is the acknowledgement on offer; there is no reward tier and no payment to negotiate
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
14 assets you may test, 6 excluded.
Web 1
- https://twenty.com
Products and areas 13
- Any mailbox or calendar integration configured on a workspace, together with the credentials and tokens stored to keep it syncing
- Authentication end to end: password login, Google and Microsoft sign-in, SAML and OIDC where configured, session issuance, refresh tokens and API keys
- File and attachment storage, both upload and the access check on retrieval
- The admin panel and whatever operations it exposes across workspaces
- The front end's rendering of user-supplied record content, including rich text fields and notes
- The GraphQL and REST API surface, covering every operation on both standard and custom objects
- The metadata engine that creates and alters objects, fields and relations at runtime from user-supplied definitions, along with the schema changes it makes underneath
- The policy takes private reports on Twenty at a dedicated address, commits to a response inside one business day and states no component carve-out. The whole application is in scope
- The role and permission model, including object-level and field-level permissions and whatever governs record visibility between members
- The workspace boundary, since one deployment serves several workspaces and a workspace is a whole company's CRM
- Webhooks and outbound requests the server makes to a destination a user supplies
- Workflows and their actions, including any server-side code execution the workflow engine offers
- Workspace invitations and member management, the path by which someone joins a workspace at all
Out of scope (6)
- A role or permission a workspace administrator granted deliberately
- Public disclosure before a fix ships, which the policy's coordinated-disclosure expectation rules out
- Self-hosting and deployment configuration, including an instance run without the documented environment variables or with a default secret
- Testing against instances holding other people's CRM data
- Third-party integrations' own systems, which are separate estates rather than Twenty code
- Upstream Node, NestJS and npm dependency issues, unless Twenty's own use of the dependency is what makes the defect reachable
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.
While testing
-
Report privately to the address published in SECURITY.md as "security at twenty.com", or through GitHub private vulnerability reporting on twentyhq/twenty, which is enabled
-
Twenty's data model is defined at runtime, so say which custom objects, field types and relations your reproduction needs.
-
Give the workspace role you started from and whether a second workspace was involved
-
Coordinated disclosure is the stated expectation. Hold publication until a fix ships
Not accepted
-
Upstream Node, NestJS and npm dependency issues, unless Twenty's own use of the dependency is what makes the defect reachable
-
Self-hosting and deployment configuration, including an instance run without the documented environment variables or with a default secret
-
A role or permission a workspace administrator granted deliberately
-
Public disclosure before a fix ships
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2026-46624 | Twenty is an open source CRM. From 1.7.7 through 1.16.7, a critical Remote Code Execution (RCE) vulnerability exists in Twenty CRM via a chained SQL Injection and PostgreSQL COPY TO PROGRAM attack. If Postgres user is a super user then any authenticated user can execute arbitrary OS commands on the database server by injecting SQL through the unsanitized timeZone parameter in the REST API groupBy | Critical 9.9 | 26 May 2026 |
| CVE-2026-44729 | Twenty is an open source CRM. In 1.18.0 and earlier, the file serving endpoints in Twenty CRM at /files/* and /file/:fileFolder/:id serve uploaded files using fileStream.pipe(res) without setting any Content-Type, Content-Disposition, or X-Content-Type-Options response headers. This allows an authenticated attacker to upload an HTML file containing JavaScript, which will be rendered by the victim' | High 8.7 | 26 May 2026 |
| CVE-2026-27023 | Twenty is an open source CRM. Prior to version 1.18, the SSRF protection in SecureHttpClientService validated request URLs at the request level but did not validate redirect targets. An authenticated user who could control outbound request URLs (e.g., webhook endpoints, image URLs) could bypass private IP blocking by redirecting through an attacker-controlled server. This issue has been patched in | Medium 5.0 | 5 Mar 2026 |
| CVE-2026-26720 | An issue in Twenty CRM v1.15.0 and before allows a remote attacker to execute arbitrary code via the local.driver.ts module. | Critical 9.8 | 2 Mar 2026 |
| CVE-2024-28434 | The CRM platform Twenty is vulnerable to stored cross site scripting via file upload in version 0.3.0. A crafted svg file can trigger the execution of the javascript code. | High 7.6 | 25 Mar 2024 |
| CVE-2024-28435 | The CRM platform Twenty version 0.3.0 is vulnerable to SSRF via file upload. | Medium 5.4 | 25 Mar 2024 |
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 7 Last 12 months 7 Lifetime Access control 38 % Auth/token handling 25 % Info disclosure 22 % Injection 15 % Latest advisories Loading the feed Overview Twenty is the open-source Salesforce alternative growing fastest right now, self-hosted by teams that want their pipeline and contact database on their own infrastructure. A CRM compromise hands over the customer list, the deal history and the notes people write assuming nobody outside the company will read them. The codebase is young and moving quickly: every advisory Twenty has ever published came out in the last twelve months, all seven of them. The policy is direct about money, saying there is no formal bounty programme because of the project's stage and offering a one-business-day response and credit instead. sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy takes private reports on Twenty at a dedicated address, commits to a response inside one business day and states no component carve-out. The whole application is in scope The workspace boundary, since one deployment serves several workspaces and a workspace is a whole company's CRM The metadata engine that creates and alters objects, fields and relations at runtime from user-supplied definitions, along with the schema changes it makes underneath The GraphQL and REST API surface, covering every operation on both standard and custom objects The role and permission model, including object-level and field-level permissions and whatever governs record visibility between members Authentication end to end: password login, Google and Microsoft sign-in, SAML and OIDC where configured, session issuance, refresh tokens and API keys Workspace invitations and member management, the path by which someone joins a workspace at all Workflows and their actions, including any server-side code execution the workflow engine offers Any mailbox or calendar integration configured on a workspace, together with the credentials and tokens stored to keep it syncing File and attachment storage, both upload and the access check on retrieval Webhooks and outbound requests the server makes to a destination a user supplies The admin panel and whatever operations it exposes across workspaces The front end's rendering of user-supplied record content, including rich text fields and notes Out of scope Third-party integrations' own systems, which are separate estates rather than Twenty code Upstream Node, NestJS and npm dependency issues, unless Twenty's own use of the dependency is what makes the defect reachable Self-hosting and deployment configuration, including an instance run without the documented environment variables or with a default secret A role or permission a workspace administrator granted deliberately Testing against instances holding other people's CRM data Public disclosure before a fix ships, which the policy's coordinated-disclosure expectation rules out Most-valued findings Anything crossing the workspace boundary, since one instance holds several companies' CRM data and a leak there is a leak of everything the product exists to hold The runtime metadata engine, where a user-controlled object or field name reaches SQL identifiers or a schema operation. This surface has no equivalent in a conventional CRM and it is where the most interesting bugs on this codebase will be Workflow and automation execution reachable by a low-privilege member, particularly any action that runs code on the server Stored integration credentials and OAuth tokens for connected mailboxes and calendars, which reach a user's mail rather than only their CRM API key scope and refresh token handling, including a key issued in one workspace acting in another Permission checks applied in the resolver rather than in the data layer, so a crafted query returns fields or records the role was never granted Authentication and SSO defects, identity binding above all, since attaching an attacker-controlled identity to an existing member account takes the workspace with it The invitation flow, where joining a workspace you were never invited to is the shortest route to the data inside it Stored cross-site scripting in a record field, note or custom field that later renders in another member's session Privilege escalation from member to workspace administrator, which reaches the metadata engine and every integration credential the workspace holds Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report privately to the address published in SECURITY.md as "security at twenty.com", or through GitHub private vulnerability reporting on twentyhq/twenty, which is enabled The policy commits to a response within one business day and guarantees no legal action against good-faith research Twenty's data model is defined at runtime, so say which custom objects, field types and relations your reproduction needs. A finding that depends on a particular field type is still a finding, and the maintainers cannot reproduce it without that detail Give the workspace role you started from and whether a second workspace was involved, since the workspace boundary is the product's main separation control Coordinated disclosure is the stated expectation. Hold publication until a fix ships Credit in the fix is the acknowledgement on offer; there is no reward tier and no payment to negotiate Disclosure Coordinated privately by email or GitHub advisory, with a one-business-day response commitment and an acknowledgement of the reporter's role when the fix goes out. The advisory record is short but entirely recent, so the process is demonstrably live and the turnaround visible. No fixed embargo length is published. Time disclosure to the release carrying the fix, and remember the project ships fast enough that self-hosted operators are frequently several versions behind the hosted service. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability