Introduction
Affected Product Summary
While reviewing the Appsmith Enterprise platform, Rhino Security Labs uncovered a series of critical vulnerabilities affecting default installations of the product. Most severe among them is CVE-2024-55963, which allows unauthenticated remote code execution due to a misconfigured PostgreSQL database included by default. Two additional vulnerabilities (CVE-2024-55964 and CVE-2024-55965) enable unauthorized access to sensitive data and application denial of service.
This post details each issue, including technical breakdowns, proof-of-concept exploits, and detection methods.
Vendor: Appsmith, Inc.
Product: Appsmith (Community, Business, and Enterprise Editions)
Confirmed Affected Version: 1.20 – 1.51
Vendor Advisory: Appsmith Github
What is Appsmith
Appsmith is an open-source developer tool designed to help organizations build internal applications, such as dashboards, admin panels, and customer support tools. Users can develop User Interface (UI) elements and connect various data sources to the User Interface such as databases and Large Language Models (LLMs).
The product ships out with three pricing plans: Free, Business and Enterprise. The vulnerable functionality referenced in this blog is available to all three pricing plans.
Appsmith Technical Background
User Roles
In Appsmith, there are three user roles:
- Administrator: Can modify all workspace settings including editing applications, inviting other users to the workspace and exporting applications from the workspace.
- Developer: Can edit and view applications along with inviting other users to the workspace.
- App Viewer: Can view applications and invite other users to view applications.
Workspaces
In Appsmith, all applications are developed within Workspaces. Users can create multiple Workspaces to organize projects and invite others to collaborate, allowing for shared development and access to resources within that workspace.
Datasources
Appsmith enables users to connect their applications to a wide range of data sources. These “Datasources” include traditional databases like PostgreSQL, MySQL, and MongoDB, cutting-edge Large Language Models (LLMs) such as OpenAI and Anthropic, external API Endpoints for integrating with other services, and various other data sources. These connections allow applications to dynamically retrieve and display data.
Applications vs Web App
To avoid confusion, it’s important to distinguish between two terms frequently used in this blog: “applications” and “web app.” Appsmith is a platform that enables users to create applications within workspaces. These applications encompass UI design, custom JavaScript, data source integrations, and more. Throughout this blog, the term “application” or “applications” will specifically refer to these user-created projects. “Web application” or “web app” will refer to the Appsmith platform itself as a whole.
CVE-2024-55963 - Unauthenticated Remote Code Execution as postgres user
Misconfigured Integrated Database
Appsmith provides the ability to connect a variety of datasources to create applications. Included are practice datasources to help new users learn. One of these practice datasources is a PostgreSQL database running locally on the Appsmith server.
The PostgreSQL authentication configuration file, pg_hba.conf, has the following entry:
This configuration allows any local user to connect as any PostgreSQL user.
This configuration allows any local user to connect as any PostgreSQL user (including superuser) without providing a password because the trust authentication method explicitly bypasses authentication.
This image shows the connection request using any arbitrary value for the Postgres User.
This image shows the successful response connecting to the postgresql database with an arbitrary value for the password.
When connecting the datasource to an application, the connection is made by the Appsmith server, not the user’s browser. This server-side connection allows access to the locally hosted PostgreSQL database.
Default Allow for Account Signup
Our next goal was to find a way as an unauthenticated user to gain access to the datasource’s functionality and connect to the locally run PostgreSQL database. The application specifies that only the Administrator and Developer roles can configure and interact with datasources, and only invited users given those roles can carry out that functionality.
While the app requires an invitation to access current Workspaces, its default configuration allows for user signup. Following signup, a user can then configure their own workspaces and applications, and connect datasources of their own to those applications.
Exploiting CVE-2024-55963
By combining the misconfigured database (included as part of the AppSmith installer) with default configuration that allows user signup, it is possible for an attacker to signup on the application, create an application, and connect to the misconfigured database. From there, it is possible to execute SQL queries that allow for system command execution.
A simple Proof of Concept is as follows:
CREATE TABLE PoC (column1 TEXT); COPY PoC FROM PROGRAM 'cat /etc/passwd'; SELECT * FROM PoC; DROP PoC; -- (This is to clean up the database after our exploit.)
Proof of Concept
Proof of concept
A detailed proof-of-concept exploit is available, demonstrating how an unauthenticated attacker can register a new account, create an application, connect to the misconfigured local PostgreSQL database, and execute arbitrary system commands via crafted SQL queries. The script includes usage instructions for testing and validation.
To support detection efforts, Rhino has also developed a custom Nuclei template targeting key indicators of the vulnerabilities. This allows security teams to quickly scan Appsmith instances for vulnerable versions. The exploit and nuclei template can be viewed in our CVE Github repository.
CVE-2024-55964: IDOR allowing “App Viewer” user Database SQL access
Exploring API Calls
While the App Viewer role user, which has very limited view-only permissions, cannot access the part of the application used to configure database connections and queries, we began to test the API endpoints related to datasources. We wanted to see if the authorization checks were set for all requests related to querying and retrieving data from databases. We discovered the following API request, which is made when a saved query for the datasource is loaded on the datasource’s home page:
/api/v1/datasources/[datasource-id]/schema-preview.
Examining ID Generation
The datasource ID consists of a 24-character hexadecimal value, a base-16 number system. Initially, these IDs appeared to be random, but further investigation revealed a predictable pattern.
- Characters 1-5 remain constant with each generated ID.
- Characters 6-8 are randomly generated.
- Characters 9-22 remain constant with each generated ID.
- Characters 23-24 are randomly generated.
- The static characters vary between self-hosted instances.
This image shows a diagram explaining the static and unique values of a generated ID.
This leaves an attacker with only 5 characters to brute force. Attackers can identify datasources following the steps below:
- Create a workspace and create an application within that workspace.
- Within the newly created application, configure a datasource.
- View the ID and identify the static 19 character values.
- Brute force the remaining 5 characters to identify valid datasource IDs. These can be identified by the varying content lengths and response time.
This image shows an example brute force attempt of valid datasource IDs.
Exploiting CVE-2024-55964
An attacker can then take the identified datasource IDs and use the API endpoint mentioned earlier to probe for any datasources involving a SQL database. The API request only is used with SQL databases. Once a compatible datasource is identified, an attacker can begin to make arbitrary SQL queries against the database using the API request. Example below:
Examples of arbitrary SQL queries being made against the database
Vulnerability Constraints
The impact of this IDOR vulnerability is mitigated by Appsmith’s workspace-level authorization. Datasource connectivity is strictly scoped to the workspace in which the datasource is defined. Therefore, an attacker’s ability to issue arbitrary SQL queries is limited to datasources residing within workspaces they have been authorized to access.
CVE-2024-55965: Denial of Service via Broken Access Control allowing “App Viewer” access to ‘Restart’ API request
Admin Settings
When an administrator modifies site-wide settings, such as authentication methods, appearance themes, or other general configurations, the Appsmith web application requires a restart. This restart is triggered by a POST request to a dedicated restart API endpoint, which briefly takes the application offline for approximately 30 seconds. As documented in Appsmith’s permissions documentation, only administrators are authorized to trigger this restart. Separately, we discovered that users’ session cookies remain active even after the application restarts, allowing them to continue using the application without re-authentication. This cookie persistence, while not a vulnerability on its own, was a critical gadget in the exploit chain.
This image shows the restart request.
Tracing the Restart Function
We logged in as an App Viewer user, a role with very limited view-only permissions, and began to test our access to the site-wide configuration settings. Nearly every request returned a standard ‘403 Access Denied’ error, indicating that access was properly restricted. However, the restart request, which triggers an application server restart, returned a distinct error message. This deviation from the expected ‘403’ response indicated a separate code path for this specific request, suggesting a critical flaw in the permission checks. This vulnerability was confirmed when the application unexpectedly restarted despite the user’s lack of administrative privileges.
This image shows the custom 403 error message when making the restart request as a non-admin user.
To understand why the application restarted despite the permission error, we examined the code responsible for the restart function. The relevant section of code was found within the Appsmith server’s code, specifically in the following location: app/server/appsmith-server/src/main/java/com/appsmith/server/solutions/ce/EnvManagerCEImpl.java.
The following code snippet shows the area responsible for checking user permissions before allowing a restart.
@Override
public Mono<User> verifyCurrentUserIsSuper() {
return userUtils.isCurrentUserSuperUser().flatMap(isSuperUser -> {
if (isSuperUser) {
return sessionUserService.getCurrentUser();
} else {
return Mono.error(new AppsmithException(AppsmithError.UNAUTHORIZED_ACCESS));
}
});
}
@Override
public Mono<Void> restart() {
return verifyCurrentUserIsSuper().then(restartWithoutAclCheck());
}
The code was designed to prevent users without administrator privileges from restarting the application server. However, due to a coding error, the application’s Global Exception Handler, which is responsible for managing errors, ignored the permission check.
Instead of preventing the restart for unauthorized users, it allowed the action to proceed. This effectively bypassed the intended permission check, allowing the restartWithoutAclCheck() function, which performs the restart without checking user permissions, to execute regardless of the user’s permissions.
public class GlobalExceptionHandlerTest {
/*
* test case to ensure that whenever there is appsmithPluginException on server,
* we never expose the plugin status code directly,
* instead we use generic 500 internal server error.
* The actual plugin status code is visible inside response.status
* https://github.com/appsmithorg/appsmith/pull/29009 for more context
*/
@Test
public void testCatchPluginException_onAppsmithPluginException_throwsInternalServerError() {
MockServerHttpRequest httpRequest = MockServerHttpRequest.get("").build();
MockServerWebExchange exchange = MockServerWebExchange.from(httpRequest);
GlobalExceptionHandler handler = new GlobalExceptionHandler(null, null, null, null);
Mono<ResponseDTO<ErrorDTO>> exceptionHandlerMono = handler.catchPluginException(
new AppsmithPluginException(AppsmithPluginError.PLUGIN_AUTHENTICATION_ERROR), exchange);
StepVerifier.create(exceptionHandlerMono)
.assertNext(response1 -> {
// This asserts internal status code of the response
assertEquals(response1.getResponseMeta().getStatus(), 401);
// This asserts main/external http status code of the response
assertEquals(exchange.getResponse().getStatusCode().is5xxServerError(), true);
})
.verifyComplete();
}
}
Exploitation of CVE-2024-55965
By exploiting the flawed exception handler, combined with the persistent session cookies, an attacker could automate repeated restart requests, resulting in a Denial-of-Service (DoS) attack, which prevents legitimate users from accessing the application.
To mitigate an active attack on an Appsmith Server, an administrator would need to delete the user account responsible for the restart requests. Currently, Appsmith does not provide administrators with the ability to revoke user sessions or force password changes.
Proof of Concept
A detailed proof-of-concept exploit, demonstrating how an attacker can repeatedly trigger the restart API endpoint, is available. The provided script includes usage instructions for testing and validation. To support detection efforts, Rhino has also developed a custom Nuclei template targeting key indicators of the vulnerability. This allows security teams to quickly scan Appsmith instances for vulnerable versions. The exploit and Nuclei template can be viewed in our CVE Github repository.
Remediation and Conclusion
We appreciate Appsmith’s collaboration in addressing these vulnerabilities. All three issues identified by Rhino Security Labs have now been patched across recent versions of the platform:
CVE-2024-55965 (Denial-of-Service via Restart): Patched in v1.48. PR #37227 added proper ACL checks to the restart endpoint, preventing non-admin users from abusing the server restart function.
CVE-2024-55964 (Datasource IDOR): Patched in v1.49. PR #37308 introduced role-based access control to the /schema-preview endpoint, blocking unauthorized users from querying datasource schemas via ID brute force.
CVE-2024-55963 (Unauthenticated RCE): Patched in v1.52. The fix, implemented in PR #37068, hardened the default pg_hba.conf and introduced password-based authentication for the internal PostgreSQL instance, preventing unauthenticated command execution.
Users running self-hosted Appsmith instances should upgrade to v1.52 or later to ensure full protection against these three vulnerabilities.
Twitter: https://x.com/rhinosecurity
LinkedIn: https://www.linkedin.com/company/rhino-security-labs/
Discord: https://discord.gg/TUuH26G5
Researcher/Author: https://x.com/un1tycyb3r
Disclosure Timeline
| Vulnerability Disclosure Timeline | |
| Date | Action Item |
| 10/8/24 | Rhino disclosed the vulnerabilities to Appsmith |
| 10/29/24 | Appsmith acknowledged vulnerability and began working on a fix |
| 11/8/24 | Vendor fix for CVE-2024-55965 was merged into Appsmith release (v1.48) |
| 11/20/24 | Vendor fix for CVE-2024-55964 was merged into Appsmith release (v1.49) |
| 12/10/24 | Vendor fix for CVE-2024-55963 was merged into Appsmith release (v1.52) |
| 1/10/25 | 3 CVEs issued by MITRE for the above vulnerabilities |
