A flaw was found in 389-ds-base's Cockpit 389 Console (cockpit-389-ds), specifically in the LDAP editor's utils.jsx (getBaseLevelEntryAttributes() and runGenericSearch(), the latter reached via retrieveAllAcis()). These functions build an ldapsearch command line by concatenating a raw LDAP entry DN into a double-quoted string passed to `/usr/bin/sh -c`, executed via Cockpit's privileged (`superuser: true`) channel, which runs as unrestricted root with no capability restriction or SELinux confinement (verified directly against Cockpit's own superuser.py implementation and the absence of any Cockpit-specific SELinux policy module).

Double-quoted shell strings do not block `$(...)` command substitution, and LDAP DN syntax does not require `$`, `(`, or `)` to be escaped. An LDAP account holding a delegated create/rename privilege over some subtree (e.g. a `user_admin`- or `group_admin`-scoped role, or full Directory Administrators -- confirmed against 389-ds-base's own default sample-entries ACI templates in lib389) can create or rename an entry whose DN contains a shell command substitution, e.g. `uid=$(id > /tmp/pwned),ou=people,dc=example,dc=com`. When a separate, more-privileged Cockpit operator subsequently views that entry (or opens "Manage ACIs" on it) in the 389 Console, the injected command executes as root on the underlying host, independent of whether the ldapsearch call itself succeeds.

This has been confirmed via source-level analysis, an isolated command-execution sandbox test using the real upstream code, and a full end-to-end reproduction against a running ns-slapd + Cockpit stack using the actual shipped cockpit-389-ds package (Fedora build, confirmed to contain the identical vulnerable pattern), triggered through the real browser UI.

This is a Red Hat Directory Server-only issue. Plain RHEL does not build the cockpit-389-ds subpackage (independently verified via build manifests across RHEL 9 and RHEL 10) and is not affected.

Reported by Andrew Rukin (Arenadata) via PSIRTSUPT-21156. Confirmed as a genuine bug by 389-ds-base maintainers.