Skip to main content

Changelog

Updates, changes, and improvements at Retool.

Refer to the stable and edge release notes for detailed information about self-hosted releases.

Retool removed the preview release of Agents for self-hosted organizations since Agents is now in public beta with the 3.234.0 edge release and it will be available in 3.253 stable. This preview release was intended for deployment into a non-production environment, and was created as a mechanism to allow Self-hosted organizations the opportunity to create agents prior to their availability in an edge or stable release.

When setting up Source Control with Bitbucket, you can now use a Bitbucket access token instead of an app password. Access tokens provide a more secure authentication method than app passwords.

Authentication using app passwords is still supported, but Retool recommends using access tokens instead.

If you use Source Control to protect a workflow, you can now create and publish releases for that workflow. This allows you to safely test and build changes without disruption. Previously, protected workflows were automatically versioned and published, and you could not publish a specific version.

With this change, users must manually create a new release in order for their latest changes to be reflected in the live version of the workflow.

Once you merge a change into the main branch, navigate to the Releases tab in the left-hand menu. In this tab, you can create, manage, and publish versions of the workflow. Refer to Version and publish workflows for more information.

Retool made several UI changes to the workflow IDE and updated some terminology to improve clarity of workflow releases. Instead of deploying a workflow release, you now publish the release instead.

The functionality remains the same and you continue to publish a workflow release for it to be live. This change was made to more closely align the app and workflow IDEs.

When you are ready to finalize your workflow changes, click Publish release in toolbar of the workflow IDE. This button was previously labeled Deploy.

Create, publish, and revert releases from the Releases tab in the left panel. This tab was previously labeled Deploy History. You can also navigate to the Releases tab using the button in the status bar of the IDE, which also displays the currently published release version.

You can now view which users and permission groups have access to a workflow, resource, and agent. When on the listing page for one of these objects, click the ••• menu and select View access list. Use the tabs at the top of the list to show Users or Groups. The list shows the access level of each user or user group.

The access list for a workflow.

Resources display permissions on a per-environment basis if they are configured.

Access lists were already available for apps and app folders.

Modules now support typed data inputs. This change makes your modules more reliable by catching mismatched data types early.

Previously, modules offered only a Data input for passing in property values. Now, you can choose from the following options when configuring a module input:

  • Any
  • String
  • Number
  • Boolean
  • Enum

Choose from String, Number, Boolean, or Enum for type validation on your module input. Selecting a Type enforces stricter validation rules and displays a warning if the input type does not match what you selected. You can also define additional characteristics about the input, such as options for Enum, and default values for all types.

Changing the type of the module input does not alter the actual value passed into the module—invalid values are still passed through as-is. The validation only affects how the input fields behave and display warnings.

If you set the Type to Any, Retool performs no validation on the module input.

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:

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.

DisclosureDetails
Vulnerability TypeCWE-352: Cross-Site Request Forgery
Vendor of ProductRetool
Fixed VersionEdge: 3.212.0+; Stable: 3.148.14+, 3.196.4+
Affected Product Code BaseEdge: 3.123.0 to 3.207.0; Stable: 3.148.0 to 3.148.13, 3.196.0 to 3.196.3-stable
Affected ComponentSelf-hosted Retool organizations
Attack TypeRemote
ImpactEscalation of Privileges
CVSS 3.x Base Score4.8
CVSS 3.x VectorCVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:H/A:N/E:P/RL:O/RC:C
CVSS 4.x Base Score4.3
CVSS 4.x VectorCVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:A/VC:L/VI:L/VA:N/SC:L/SI:H/SA:N
Referencehttps://docs.retool.com/releases
DiscovererRobinhood Red Team and Doyensec

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.

Release branchRelease versions
Edge3.123.0 to 3.207.0
3.196-stable3.196.0 to 3.196.3
3.148-stable3.148.0 to 3.148.13

What versions contain the fix?

Self-hosted Retool only.

BranchVersions
Edge3.212.0+
3.196-stable3.196.4+
3.148-stable3.148.14+
Stable>=3.227

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.

Organizations on the Business or Enterprise plan can now restrict users from accessing specific app pages with per-page permissions. When configuring a permission group, you can now also specify permissions for each page.

Per-page permissions are generally available to cloud instances and in for self-hosted instances on version 3.219.0 and later.