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.

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 on Retool Cloud and in on Self-hosted Retool versions 3.219.0 and later.

Retool has rolled out unique identifiers (UUID) for app pages. If you use Source Control, Retool recommends that you create a new branch with no changes and push it to Source Control. If you use Retool Cloud or self-hosted Retool 3.191-edge or later, Retool automatically creates a migration commit to add UUIDs to each page. Once you merge this commit, you can successfully configure per-page permissions on your protected app.

If you are working on more than one branch before the UUID addition in version 3.191-edge, Retool runs the migration on each of those branches, and the branches will end up with different UUIDs. Make sure add UUIDs only once, do not override the UUIDs on the main branch after adding them. Doing so results in the inability to set per-page permissions, because the IDs initially set on main are the ones that Retool will use.

Retool added two new configuration settings that enable you to customize the layout of modules:

  • Height: Whether the default height of the module is automatic or fixed.
  • Overflow: Whether overflow content in the module is hidden or accessible via scroll.

When you configure these settings inside the module editor, the settings apply as the default values only to new module instances. Existing module instances are unchanged. You can also override these settings for a single module instance by changing them in the Inspector of the app that contains the module.

A preview release of Retool Agents is currently available to self-hosted organizations for deployment into a non-production environment. This preview release is intended to allow customers to preview and create proof-of-concepts that show how agents may work in their environment.

As Retool is continuously working to develop and improve Retool Agents to meet the high standards required for production environments, this preview release is not intended for production use and this build should not be deployed in an existing Retool installation or deployment. Retool recommends that self-hosted organizations create a new deployment in a private network alongside resources to which you intend to connect. Retool reserves the right to make changes to the agents preview without notification.

Retool Agents makes it simple for builders to automate work using large-language models (LLMs) by creating agents. Agents are systems that can complete or delegate tasks based on LLM reasoning.

Agents call tools—for example, workflows, functions, or other agents—to gather information and complete or delegate actions. When invoked, an agent:

  1. Receives a task, or input, as natural language. Tasks are provided as input to agents via written instructions.
  2. Uses an LLM to decide whether to respond to the input, get more information, or take action in another system.
  3. Provides the result of the tool call back to the LLM, and the LLM reasons in an open-ended cycle called an agentic loop without a pre-defined stopping point.
  4. Finally, the agent responds to your original message or question once it reaches a conclusion.

You can invoke an agent using any of the following trigger methods:

You can then test, deploy, evaluate, and monitor your agent directly from Retool.

Retool Agents is not currently available to Self-hosted Retool organizations.