Issue reported on the fulldisclosure list in 2010 https://seclists.org/fulldisclosure/2010/Dec/489 The OpenBSD CARP implementation (and all derivatives, such as FreeBSD and NetBSD) fails to include all fields contained in the "carp_header" structure[1] when calculating the SHA1 HMAC hash of the packet in the function carp_proto_input_c[2]. The two 8-bit fields not included in the hash generation are "carp_advskew" and "carp_advbase". Among other functions, the fields are both set to 255 by the master CARP node to indicate that it wants to step down from the master role. This behaviour can be exploited to force a backup member to assume the role of master by capturing a master CARP advertisement, updating the two fields in question to 255 and replaying the modified packet. A backup node will receive this packet and the hash check will be satisfied as the two modified fields are not included in the hash generation. A backup node will now assume the master role and the current master will step down to backup. At this point, the attacker can now capture an advertisement from the new master. By replaying both of the unmodified master advertisements, all CARP nodes assume the backup role. At this point, a Denial of Service (DoS) condition has been introduced as no device answers ARP requests for the Virtual IP (VIP). The attacker can now decide whether to start answering ARP for the VIP therefore performing a Man in the Middle (MitM) attack.