Advisory · CVE-2026-77226
Camunda 7 setup gate can reopen and hand out admin accounts
Camunda 7's first-run setup check only counts members of the default camunda-admin group, so when admins exist through other routes the setup endpoint can become reachable again, letting an unauthenticated attacker create a new administrator.
- Vendor
- Camunda
- Product
- Camunda 7
- Identifier / CWE
- CVE-2026-77226
CWE-863 - Action timing
- Immediate
Explain it like I’m five
Camunda decides whether setup is finished by checking if the default admin group still has members. But Camunda can also grant admin rights through other settings it does not check. If an attacker finds an installation where those other settings are used and the default group is empty, the setup page treats it as brand new and lets them create an admin account.
- 01Admin routes diverge
The engine recognizes administrators through stored camunda-admin membership as well as configured adminUsers and adminGroups; the setup endpoint only counts stored members of camunda-admin.
- 02Default group emptied
Operators who manage admin access through configuration can leave the default group with zero stored members while real administrators still work.
- 03Setup gate reopens
An unauthenticated request to the Admin webapp's setup endpoint passes the setup-availability check and returns success.
- 04Admin created
The attacker registers a new administrator account without credentials.
- 05Code execution
The account can deploy a process containing a script task, which the engine executes as the Camunda service user.
What happened
Security researchers at CodeAnt AI found that Camunda 7’s first-run setup endpoint can become reachable again on an already-configured installation. The endpoint is meant to create the initial administrator and then close; its availability check asks whether the identity provider is read-only and whether the default camunda-admin group has any stored members. The engine, however, also grants administrator rights through configured adminUsers and adminGroups, which the setup check never reads.
The researchers reproduced the flaw on Camunda 7 Run 7.24.0: with the default group emptied and an administrator still working through another route, an unauthenticated setup request returned success and created a new administrator. NVD lists Camunda 7 releases from 7.24.0 up to but not including 7.24.15 as affected, and scores the issue critical at CVSS 9.2.
The exposure requires four conditions together: a writable identity provider, an empty camunda-admin group, a reachable Admin webapp, and network access to the setup endpoint. This is not the default state, and the researchers did not measure how common it is.
What to do
- Inventory Camunda 7 installations and check whether the Admin webapp’s setup endpoint is reachable from untrusted networks.
- Upgrade affected installations to the Camunda 7 release that fixes this issue, following Camunda’s download and upgrade guidance.
- While the setup endpoint must remain reachable for first-run provisioning, restrict it afterward so it is not exposed beyond administrators.
- Keep at least one legitimate stored member in the
camunda-admingroup while the setup endpoint is reachable, so the current availability check keeps working. - Audit administrator access for any change in how admins are recognized (group migrations, identity provider switches, removal of the default account) that could empty the default group.
- Review webapp logs for unexpected POST requests to the setup path on already-configured installations.
Management note
This is an unauthenticated path to a full administrator account on a business process automation platform, where a new admin can deploy processes and run scripts as the service user. The danger is quiet: nothing looks misconfigured to anyone using the system normally, because the engine’s own view of administrators stays intact. The fix belongs in product code (the setup gate must recognize every route to admin access), but until then the operational checks above close the gap.