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).