Changelog

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.

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 cloud or a self-hosted instance on version 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.

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:

• The built-in chat experience in Retool Agents.
• Sending an email to the agent.
• The Agent Chat component in apps.
• The Invoke Agent block in workflows.

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

Retool recently made changes that make it easier to review changes in source control. Retool now separates system-generated updates related to version upgrades into their own migration commit, so your pull requests are cleaner and easier to understand.

This feature is generally available to cloud instances and self-hosted instances on version 3.203.0-edge or later, and will be generally available in an upcoming stable release. Self-hosted Retool organizations can reach out to support to enable this feature.

What's new​

Instead of bundling migration changes with user changes, they now appear in a dedicated commit.

No setup needed—this happens automatically when you make commits.

Retool now supports an integration to the Tavily Search API. Use this integration to perform either general or news-specific web searches. You can choose to provide your own Tavily API key if you do not want to be subject to Retool's rate limits (100 calls per 24 hours) on Tavily.

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​