Camunda 7 EUVD-2026-104393

Two concrete preconditions must both hold: (1) the attacker possesses valid Camunda Cockpit credentials with at least minimal access (PR:L - no admin or data grants needed), and (2) the engine is running with a non-empty disabledPermissions configuration, which is the specific non-default setting the inverted isPermissionDisabled() logic misevaluates (this is the AT:P attack requirement). Deployments that never configured disabledPermissions are not exploitable. Exploitation limits: requires a pre-existing authenticated account and only yields read/confidentiality impact (no write or availability effect); however, it generates no logging, limiting detectability. Affected versions are Camunda 7.24.0 before 7.24.14 and 7.23.0 before 7.23.17.

This is a moderate, config-dependent authorization flaw rather than a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) scores 6.0 and tells a consistent story: network-reachable, low attack complexity, but requiring both a pre-existing low-privilege Cockpit account (PR:L) and a specific attack requirement (AT:P) - the non-empty disabledPermissions configuration that the inverted comparison logic in isPermissionDisabled() misinterprets. Impact is confidentiality-only (VC:H, VI:N, VA:N): an attacker can read all process instances, definitions, and incidents engine-wide but cannot modify or disrupt. Public exploit code exists (per the CodeAnt/VulnCheck research), which raises practical risk, but this is NOT in CISA KEV and no EPSS score was provided in the input, so there is no signal of mass or active exploitation. Two factors meaningfully constrain real-world risk: exploitation requires valid (if minimal) authentication AND a non-default disabledPermissions setting - environments that never configured disabledPermissions are not exploitable. The stealth aspect (no logging generated) is a genuine detection concern for environments that do meet the preconditions. Net: a credible insider/low-privilege-escalation data-disclosure issue for Camunda operators who use disabledPermissions, not a widespread unauthenticated RCE.

A low-privilege user (e.g., a support operator granted only minimal Cockpit visibility) in a Camunda deployment that has configured a non-empty disabledPermissions set logs into the Cockpit webapp and issues plugin-resource requests. Because the inverted isPermissionDisabled() logic treats the configured disabledPermissions as granting rather than restricting access, the user reads every process instance, process definition, and incident across the entire engine - including data for other tenants or business units - with no authorization enforcement and no audit log entry. Publicly available exploit code demonstrating this path exists, lowering the skill barrier.