Fedora Account System
Red Hat Associate
Red Hat Customer
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. A flaw was found in 389 Directory Server. The LDAP extended-operation handlers that start (multisupplier_extop_cleanruv) and abort (multisupplier_extop_abort_cleanruv) the CleanAllRUV replication-maintenance task in ldap/servers/plugins/replication/repl_extop.c perform no check on the connection's bind DN or authentication state, unlike the analogous multisupplier_extop_StartNSDS50ReplicationRequest handler in the same file, which explicitly verifies the connection is an authorized replication updatedn via replica_is_updatedn(). Under the default nsslapd-allow-anonymous-access configuration, a fully anonymous network client that can reach a supplier's LDAP listener and knows the target suffix and replica ID can start or abort CleanAllRUV; if anonymous access has been restricted, any client that has completed a successful bind (regardless of privilege level) can do the same, since the handlers themselves perform no further authorization check. This lets the client cause unauthorized removal of a replica ID from replication metadata, purge related changelog records, and interrupt administrator-initiated cleanup operations, potentially leaving replication inconsistent or unavailable. Reported by Andrew Rukin (Arenadata), who verified the issue against 389-ds-base-3.3.0-5.fc45.x86_64 with both a single supplier and two replicating suppliers, and confirmed the abort handler likewise lacks the check by source review. Independently reproduced live in an isolated sandbox against the same NVR: the anonymous start request was accepted and genuinely executed (RUV entry removed, changelog purged), a well-formed request to the sibling, protected StartNSDS50ReplicationRequest handler was correctly rejected under the same unauthenticated precondition, and cross-supplier propagation was confirmed (a second supplier independently completed the identical cleanup via its replication agreement with the targeted supplier, without ever receiving a direct request from the client).
This bug appears to have been reported against 'rawhide' during the Fedora Linux 45 development cycle. Changing version to 45.
Fixed in https://github.com/389ds/389-ds-base/commit/03729b25d
FEDORA-2026-b16c9cbc0f (389-ds-base-3.2.3-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-b16c9cbc0f
FEDORA-2026-c1e25a4642 has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-c1e25a4642` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-c1e25a4642 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-b16c9cbc0f has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-b16c9cbc0f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-b16c9cbc0f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-0b8bc362b1 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-0b8bc362b1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-0b8bc362b1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.