CVE-2026-76837: Baserow before 2.3.0 Stored Cross-Site Scripting via Rich Text Mention Display Name

Published Aug 24, 2026
·
Updated

Baserow interpolates a user's display name into the rich-text mention markup without HTML encoding. PATCH /api/user/account/ stores the firstname value verbatim, and the mention renderer in web-frontend/modules/core/editor/mention.js builds its element with a template literal that places the name into a data-label attribute and the element body unescaped. A name containing a double quote closes that attribute and the opening tag, so following markup lands in the element content. The result is rendered through v-html by the rich-text field components, so any rich-text cell mentioning the account executes the stored script for every workspace member who views the table, without a click. Any workspace member, at the lowest permission level, can set the name and reach every other member of the workspace, and the payload persists until the name is changed or the mentioning row is removed. Version 2.3.0 escapes the value before interpolation.

Affected Software

1 affected component
Baserow<2.3.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Baserow to a version that resolves this vulnerability.

    Fixed in 2.3.0Patch Baserow before 2.3.0 Stored Cross-Site Scripting via Rich Text Mention Display Name

Event History

Aug 24, 2026
CVE Published
via MITRE·05:36 PM
Data Sourced
via MITRE·05:36 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Who can exploit this vulnerability, and who is exposed?

Any workspace member at the lowest permission level can set a malicious display name and create or use a rich-text mention. Every member of that workspace who views a table containing a rich-text cell that mentions the affected account can have the stored script execute without interaction.

2

What conditions are required for exploitation?

The attacker needs a workspace account and must be able to set its first_name through the account API. A rich-text cell must mention that account, and a victim must view the table containing that mention.

3

How long does a malicious payload remain active?

The payload persists until the attacker’s display name is changed or the rich-text row containing the mention is removed. It can execute each time workspace members view the affected table.

4

What can be done if upgrading is not immediately possible?

Change suspicious display names to remove malicious markup and remove rich-text rows that mention affected accounts. Restrict or review low-privilege workspace members’ display-name changes and rich-text mentions until the issue is remediated.

5

How can administrators identify possible exposure?

Review workspace accounts for display names containing quotes or HTML-like markup, particularly names that could break an HTML attribute. Inspect rich-text cells for mentions of those accounts, since those rows are the locations where the payload is rendered.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203