CVE-2026-19404

CVE-2026-19404 in 389 Directory Server exposes CleanAllRUV and AbortCleanAllRUV extended operations to any authenticated principal without authorization checks. The critical distinction this CVE actually represents is not anonymous access—it is authorization completeness. Replication bind credentials correctly establish who is connecting, but the CleanAllRUV code path never queries the ACL subsystem to verify whether that authenticated identity holds the specific privilege to purge RUV metadata. The vulnerability is a structural artifact: CleanAllRUV originated in infrastructure-layer code that predates 389 DS's modern ACL subsystem, and the operation was never retrofitted with authorization gates when it became exposed through the extended operation interface. The operational severity远超 CVSS 6.5. Corrupted replication metadata doesn't just cause one entry or replica to become unavailable—it fractures consistency guarantees across the entire multi-master topology. When replication state is compromised mid-cleanup, recovery is not a single-node fix. It requires halting the replication domain, reconciling state across all masters, and in worst cases rebuilding replicas from known-good backups. This recovery surface exists regardless of whether anyone exploits the vulnerability; every failed or interrupted cleanup creates an inconsistency window that future incidents must navigate. The primary compensating control is network segmentation—if replication ports are not network-accessible to untrusted actors, the attack surface is contained. However, if replication ports are exposed, the vulnerability is exploitable by any authenticated principal, not just anonymous users. This means compromised replication credentials or misconfigured service accounts become equivalent to full replication state manipulation privileges. Extended operations in directory servers function as a sediment layer: code paths written for plugin extensibility that persist because removing them might break something unknown. CleanAllRUV likely inherited trust from replication infrastructure where per-operation authorization was intentionally omitted for performance reasons. The productive question is not just whether this specific operation was audited, but whether other extended operations in the same subsystem share the identical gap. The remediation will require adding an authorization check, but the fix surface reveals architectural debt. If 389 DS's permission model is too coarse-grained—relying on a single 'authenticated user' bucket rather than fine-grained privileges—the fix may require role or ACL redesign that creates deployment friction. Organizations may disable the resulting restrictions or run with reduced security to maintain operational tempo, recreating the conditions for future incidents.

Reviewed through automated stages and approved by a human before publication.