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.
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 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.
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.
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.
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.
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.
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:
The GIF shows the outcome. The rest of this article explains why Camunda reaches two different answers 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:
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() :
The check asks two questions:
Is the identity provider read-only?
Is the identity provider read-only?
Does the identity store have at least one user with a stored membership in camunda-admin ?
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:
Administrator access exists through a configured user, another administrator group, or direct authorization.
Administrator access exists through a configured user, another administrator group, or direct authorization.
The last stored member of camunda-admin is removed.
The last stored member of camunda-admin is removed.
The engine continues to recognize its administrators.
The engine continues to recognize its administrators.
The setup endpoint counts zero stored members of camunda-admin and permits the setup action, provided the identity provider is writable.
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:
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 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.
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.
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.
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.
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.
CVE-2026-77226 (reserved; record pending at the editorial cutoff)
CVE-2026-77226 (reserved; record pending at the editorial cutoff)
Confirmed on camunda/camunda-bpm-platform:run-7.24.0 , source commit ee4826e5e7
Confirmed on camunda/camunda-bpm-platform:run-7.24.0 , source commit ee4826e5e7
CWE-863: Incorrect Authorization · CWE-306: Missing Authentication for Critical Function
CWE-863: Incorrect Authorization · CWE-306: Missing Authentication for Critical Function
Research conducted against locally-provisioned instances for coordinated disclosure. Line numbers refer to commit ee4826e5e7 (7.24.0). Every code excerpt is quoted from that tree; every number is from a measured lab run. The CVE record is reserved and its published description may differ from this analysis.
This research is part of an ongoing effort by CodeAnt AI Security Research to audit the trust boundaries in widely deployed infrastructure. Want a deployment or an authorization boundary reviewed? Reach us at [email protected]
What is CVE-2026-77226?
Does this affect every Camunda 7 installation?
Can this happen after Camunda has already been set up?
Does an attacker need an account?
What could an attacker do with the new administrator account?
How can I check my deployment?
What should I do while a fix is unverified?
CVE-2026-29000: pac4j-jwt Auth Bypass PoC With a Public Key
CVE-2026-29000: pac4j-jwt Auth Bypass PoC With a Public Key
CVE-2026-28292: simple-git RCE via Case-Sensitivity Bypass
CVE-2026-28292: simple-git RCE via Case-Sensitivity Bypass
CVE-2026-31988: jszip DoS via Malformed ZIP File
CVE-2026-31988: jszip DoS via Malformed ZIP File
Find out what's already
exploitable in your codebase.
Find out what's already
exploitable in your codebase.
355 Bryant St, San Francisco, CA 94107
Report a Vulnerability
Report a Vulnerability
355 Bryant St, San Francisco, CA 94107
Report a Vulnerability
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
