Certain versions of self-hosted deployments of Retool are vulnerable to cross-site request forgery (CSRF/XSRF) attacks via manipulated Retool Apps. HTML forms embedded in Retool Apps by properly permissioned users can, when interacted with by other users, be used to change that users' email address and take over their account.

This issue has been fixed in the following Retool versions:

• 3.212.0-edge (released on May 29, 2025 at 9:07 am),
• 3.148.14-stable (released on May 28, 2025 at 3:40 pm),
• 3.196.4-stable (released on May 28, 2025 at 3:38 pm).

See the complete list of affected and fixed versions below.

We have no indications of this vulnerability being known publicly before this disclosure, nor any attacks or attempted attacks using the vulnerability. This vulnerability was reported to us privately first.

We will communicate further updates here, should such become necessary.

Am I affected?​

Customers who run self-hosted deployments of vulnerable Retool versions are affected. To mount an attack using this vulnerability an attacker needs to have (a user account with) permission to create or edit a Retool App, embed a malicious HTML form, and get a victim user to interact with it.

We have no indications of this vulnerability being known publicly before we fixed it, nor any attacks or attempted attacks using the vulnerability.

What are the mitigations?​

The only available fix is to upgrade the Retool deployment to a fixed version. No other customer-controllable mitigations are available.

What is the impact?​

Authenticated users under some circumstances (as described above) are able to take over other users' accounts if such users have interacted with a manipulated Retool App. Other account changing actions can be taken, but are generally less severe.

What are indicators of compromise (IOCs)?​

Successful attacks will result in the email address of taken over accounts to be changed. Besides confirming that no user account in a Retool deployment has an unexpected email address, customers can also check for

• unexpected email change notifications being sent (to the previous email address), and
• email change events in the Retool audit logs.

What versions are affected?​

Self-hosted Retool only.

What versions contain the fix?​

Self-hosted Retool only.

Retool Cloud was vulnerable to an unauthenticated account takeover via the "Passwordless Login" feature. This could have been used to take over Retool user accounts in organizations using this feature. We successfully patched our cloud deployment for all customers on June 17th, 2025, at 2:26 PM PDT with no further action being required by customers. All potentially affected customers have been notified as of July 2nd, 2025.

There are no indications of this vulnerability being publicly known nor any attempts to exploit it before being patched. Thanks to Rens van der Linden from QUAYOUNG for responsibly and privately disclosing the vulnerability to us.

We will communicate further updates here, should such become necessary.

Overview​

• Who is affected?: Cloud customers whose users successfully used passwordless login without MFA enabled.
• What are the mitigations?: No action required from you; we have deployed a fix to our cloud environment already. For an added layer of security, consider also enforcing MFA in your Retool organization.
• What is the impact?: Potential account takeover in your Retool organization by unauthenticated outside users.
• What are indicators of compromise?: Suspicious login events in audit logs, email notifications about suspicious logins from new IP addresses, unexpected magic login link emails.

Was my organization affected?​

Organizations with passwordless login enabled and MFA enforcement disabled, or with individual accounts that did not have MFA activated, were vulnerable. Enforcing MFA on the organization level prevented this vulnerability from being exploitable, as did enabling MFA for individual accounts.

We were able to narrow down further which customers this was possible for and notified all customers that were potentially affected. Specifically, organizations with at least one user who successfully logged in using the passwordless login feature, and whose account at the time of such login did not have MFA enabled.

We have no indications of this vulnerability being known publicly before we fixed it, nor any attacks or attempted attacks using the vulnerability.

What steps has Retool taken to address the vulnerability?​

A patch has already been deployed to Retool's Cloud environment. No action is required from you at this time, but we recommend enforcing MFA in your Retool organization for an extra layer of security.

What is the impact?​

Prior to our fix, this vulnerability enabled unauthenticated users to take over accounts in your organization through the passwordless login feature.

What are indicators of compromise (IOCs)?​

Retool audit logs will contain events for successful passwordless logins, which will always be emitted for any successful attack with this vulnerability. An unexpected successful passwordless login event after April 22, 2024 can indicate a compromise.

Additionally, malicious logins may be identified by correlating email notifications for logins from new IP addresses. Attempted attacks would be indicated by unexpected passwordless login request emails from Retool. Matching the timing of the emails to login event timestamps in Retool Cloud and checking with your users who received the email can be used to determine if the login is unexpected. Utilizing your email provider's search or vault functionality to bulk search for these IOCs is advised.

A vulnerability in an open-source library, samlify, which Retool uses for SAML login implementation, allowed for account takeovers through forged SAML identity provider (IdP) assertions. In the worst case, an external threat actor could forge arbitrary assertions for a SAML IdP, potentially leading to full account takeovers within an organization. An attacker would need a signed XML document by the identity provider. Version 2.10.0 fixes the issue. This exploit requires no user interaction and an attacker could gain unauthorized access to an organization with escalated privileges.

Fixed release versions​

Affected release versions​

Self-hosted deployments of Retool missing the BASE_DOMAIN environment variable may in some cases be vulnerable to host header injections. All vulnerable versions can be remediated immediately by properly setting the BASE_DOMAIN environment variable to the full URL of the deployment, such as https://retool.example.com. Beginning with 3.196.0, this environment variable will be required for an instance on boot.

Is my version of Retool affected?​

All current Retool on-prem instances that have not yet disabled password based authentication may be vulnerable (this is easily checked by verifying that there is no form to login with a password when opening up Retool.) If password auth has not been disabled, your Retool instance is potentially vulnerable if all of the following apply to you:

• You do not have the BASE_DOMAIN environment variable set.
• Your Retool instance is reachable without any request filtering based on the Host header. This is likely the case if you’re not using a reverse proxy or that reverse proxy forwards requests for all domains.
• A user in your instance solely relies on password based authentication. This is the case when all of the following apply
  • You have the Disable Login with Email and Password setting disabled
  • You have not enforced Two Factor Authentication
  • A user in your instance does not have a second factor authentication configured.

Affected release versions​

Notification Update: 2025-05-09​

An email to customers sent on 2025-05-09 incorrectly described which Retool instances are affected. The section on affected versions should instead be Is my version of Retool affected?.

A vulnerability in an open-source library, xml-crypto, which Retool uses for SAML login implementation, allowed for account takeovers through forged SAML identity provider (IdP) assertions. In the worst case, an external threat actor could forge arbitrary assertions for a SAML IdP, potentially leading to full account takeovers within an organization.

Certain versions of Self-hosted Retool for Enterprise between 3.18.1 and 3.40.0 insert resource authentication credentials into sent data. This could allow remote authenticated attackers to access resource authentication credentials for users with Use permissions via the /api/resources endpoint.

Affected release versions​

Retool is aware of CVE-2024-3094, a backdoor affecting versions 5.6.0 and 5.6.1 of xz-utils. Self-hosted Retool images are not affected, and no action is required. Retool Cloud infrastructure and services are not impacted.

If you have any questions or concerns, please reach out to security@retool.com.