CodeAnt AI found a flaw in Camunda 7 where a completed first-run setup could become available again. Under a specific configuration, an unauthenticated attacker could create a new administrator account.

TL;DR

• Camunda 7’s first-run setup endpoint should refuse requests once an administrator exists. It decides this by counting stored members of the default camunda-admin group.

• Camunda’s engine can also recognize administrators through configured adminUsers and adminGroups. The setup check does not inspect those routes.

• If administrators exist through those other routes but camunda-admin has no stored members, the setup endpoint can become available again.

• In a local test on Camunda 7 Run 7.24.0, an unauthenticated request created an administrator. The account could deploy a process with a script task; a harmless marker confirmed execution as the Camunda service user.

• This requires a writable identity provider, an empty default admin group, and network access to the Admin webapp. It is not the default state tested, and its prevalence has not been measured.

At a Glance

Camunda needs an unauthenticated way to create the first administrator on a new installation. That access is supposed to end once an administrator exists.

Our research found a state where Camunda already has working administrators, but the setup endpoint cannot see them. The endpoint then treats an existing installation as if it still needs its first administrator.

The Reproduction, Up Front

We tested the difference between a setup gate that correctly closes and one that reopens.

With the default demo user still stored in camunda-admin, the setup request was refused with HTTP 403 and the message Setup action not available. After administrator access was provided through another route and the default group had no stored members, an unauthenticated setup request returned HTTP 204 and created a new administrator.

The new account could deploy a process containing a script task. In our local container, that task wrote the output of id to a marker file:

uid=1000(camunda) gid=1000(camunda) groups=1000(camunda)

uid=1000(camunda) gid=1000(camunda) groups=1000(camunda)

uid=1000(camunda) gid=1000(camunda) groups=1000(camunda)

The GIF shows the outcome. The rest of this article explains why Camunda reaches two different answers about whether an administrator exists.

The Security Boundary: First-Run Setup Must End

On a new Camunda installation, nobody has administrator credentials yet. The Admin webapp therefore exposes an endpoint to create the initial administrator:

POST /camunda/api/admin/setup/{engine}/user/create

POST /camunda/api/admin/setup/{engine}/user/create

POST /camunda/api/admin/setup/{engine}/user/create

That behavior is necessary for first-run setup. Its safety depends on refusing the action after an administrator exists.

The relevant check is in SetupResource.ensureSetupAvailable():

protected void ensureSetupAvailable(ProcessEngine processEngine) {
  if (processEngine.getIdentityService().isReadOnly()
      || processEngine.getIdentityService().createUserQuery()
            .memberOfGroup(Groups.CAMUNDA_ADMIN).count() > 0) {

    throw LOGGER.setupActionNotAvailable();
  }
}

protected void ensureSetupAvailable(ProcessEngine processEngine) {
  if (processEngine.getIdentityService().isReadOnly()
      || processEngine.getIdentityService().createUserQuery()
            .memberOfGroup(Groups.CAMUNDA_ADMIN).count() > 0) {

    throw LOGGER.setupActionNotAvailable();
  }
}

protected void ensureSetupAvailable(ProcessEngine processEngine) {
  if (processEngine.getIdentityService().isReadOnly()
      || processEngine.getIdentityService().createUserQuery()
            .memberOfGroup(Groups.CAMUNDA_ADMIN).count() > 0) {

    throw LOGGER.setupActionNotAvailable();
  }
}

The check asks two questions:

1. Is the identity provider read-only?

2. Does the identity store have at least one user with a stored membership in camunda-admin?

If either answer is yes, setup is refused. A read-only identity provider therefore blocks this path. When a stored member remains in the default admin group, the endpoint also closes as expected.

The problem is that the second question does not cover every way the engine recognizes an administrator.

Root Cause: Two Views of Administrator Access

Camunda’s engine can recognize administrators through configured adminUsers and adminGroups. For group-based access, it considers the groups associated with the current login.

The setup endpoint does not read those configuration lists. It counts stored members of one specific group: camunda-admin.

The group case needs care. An administrator group can be present on a person’s login without creating a stored membership in the default camunda-admin group. The engine can recognize that administrator, while the setup query still counts zero members in the group it examines.

The two functions are not identical. The engine asks whether a particular caller is an administrator; setup asks whether an administrator exists at all. But both decisions rely on a consistent definition of administrator access. Here, that definition has diverged.

How the Endpoint Reopens

The setup check runs for each request. It does not permanently record that first-run setup has finished.

An operator can therefore reach this state after the installation has been running:

1. Administrator access exists through a configured user, another administrator group, or direct authorization.

2. The last stored member of camunda-admin is removed.

3. The engine continues to recognize its administrators.

4. The setup endpoint counts zero stored members of camunda-admin and permits the setup action, provided the identity provider is writable.

Camunda’s administrator authorization plugin can add configured administrator users and groups to the settings the engine reads. The source path examined in this research does not create the default-group membership that the setup check relies on.

This does not make every use of that plugin vulnerable. In particular, a read-only identity provider causes the setup check to refuse administrator creation. The writable-provider condition matters.

Controlled Reproduction

The test used camunda/camunda-bpm-platform:run-7.24.0 with authentication and authorization enabled.

The negative control came first. While demo remained in camunda-admin, a setup request returned HTTP 403:

{"message":"Setup action not available"}

{"message":"Setup action not available"}

{"message":"Setup action not available"}

We then kept a working administrator through another authorization route while leaving camunda-admin without stored members. The engine recognized the administrator, but the setup check no longer found one through its group query.

An unauthenticated caller obtained a CSRF token available to anonymous requests and sent a request to the setup endpoint. It returned HTTP 204, creating a new administrator.

The account’s ability to deploy a process established the next part of the impact. We used a script task only to write a harmless marker inside the local test container. The marker showed execution as uid=1000(camunda).

That result demonstrates the capability gained in the tested environment. It does not establish that every Camunda deployment is exposed or that execution crossed into another system.

Which Deployments Could Be Exposed?

Four conditions must hold together:

This is not the default state in our test. We did not scan deployments or measure how often operators use this configuration. We confirmed the behavior on Camunda 7 Run 7.24.0; we have not established the complete affected-version range.

Mitigation and Fix Direction

Operators should review administrator access after identity-provider changes, group migrations, or removal of the default account.

• Keep a legitimate stored member in camunda-admin while the setup endpoint is reachable. This maintains the condition on which its current check relies.

• Restrict /camunda/api/admin/setup/ after initial provisioning. New installations still need first-run setup, so provisioning workflows should account for that restriction.

• Investigate unexpected POST requests to the setup path after an installation has been configured.

These are operational mitigations. We have not independently verified a vendor patch for this finding.

A durable product fix must make the setup decision consistent with the engine’s administrator model. Checking membership in additional stored groups alone would not necessarily account for administrator group membership supplied at sign-in by an external identity provider.

Why This Matters

The failure is a mismatch between two security decisions. The engine has several supported routes to administrator access. The setup gate observes one of them.

When the default group becomes empty, a legitimate administrator can still use the engine while the gate concludes that no administrator exists. In our local test, that disagreement reopened administrator creation to a caller without credentials.

The general lesson is that a first-run gate must continue to recognize every supported way the system can represent an administrator. Otherwise, changes to access configuration can reopen an action that was meant to be temporary.

Research Scope

The CodeAnt AI Security Research Team identified the discrepancy, analyzed the relevant code paths, and reproduced the administrator-creation and benign execution chain on a locally provisioned Camunda 7 Run 7.24.0 instance. No third-party system was tested.

The supplied research notes state that the finding was reported through VulnCheck as a CNA and that CVE-2026-77226 was reserved. At the time of drafting, we could not independently verify a public CVE record, CVSS vector, complete affected-version range, or vendor fix.