CVE-2026-15722

This CVE — a buffer overflow in 389-ds replication's RUV handling — is being classified as DoS because stack protectors caught the overflow. That's not a security boundary you should rely on. The real issue is what this vulnerability tells you about 389-ds's replication architecture. The function get_ruvelement_from_berval() copies BER-decoded replication payload data into a fixed 16-byte stack buffer using strcpy-style semantics. This happens before any authorization check processes the incoming replication message. The code treats authenticated replication peers as trusted at the protocol layer — once the initial SASL or certificate handshake completes, every subsequent BER payload is processed as if it were validated data. That distinction matters. Authentication verifies identity — it tells you which server you're talking to. It says nothing about whether that server's RUV payload is well-formed or bounded. A compromised replica in your replication topology has already passed authentication. It can send crafted BER messages that crash every peer in the circle. You don't need to bypass authentication to exploit this — you need one trusted peer to go malicious, which is exactly what a supply chain compromise or insider threat gives you. The fix will be a bounds-checked copy in this function. But ask whether your incident response stops there. Audit the rest of your RUV handling code and replication message parsers. If other functions in that subsystem share the same 'authenticated peer equals safe input' assumption, they have the same vulnerability — not because they're all strcpy bugs, but because they all live inside a trust boundary that was drawn in the wrong place. The doctrine that needs fixing isn't 'add snprintf' — it's 'authentication is identity, not integrity.'

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