This is not production software. It has not been deployed anywhere, and it should not be the thing standing between your traffic and an outage. If you are looking for a VRRP daemon to run, run keepalived.
That said, the code parses attacker-supplied bytes off the network — VRRP advertisements, BFD control packets, health-check responses from backends — so reports are welcome and will be taken seriously.
Open a GitHub security advisory on this repository ("Security" → "Report a vulnerability"), which keeps the report private until there is a fix.
If that is not available to you, email the address on the commits in this repository. Please do not open a public issue for anything exploitable.
There is no bounty and no formal response-time commitment. This is a personal project; you will get an honest answer rather than a fast one.
Anything reachable from data this daemon does not control:
- The VRRP and BFD packet parsers, and the state machines behind them.
- The configuration parser and preprocessor. A configuration file is trusted
input, but
$DEFINE/~SEQexpansion has produced a stack overflow and an out-of-memory before now, and those are worth knowing about. - The health-check clients, which read whatever a backend sends: HTTP bodies, SMTP banners, DNS answers.
- The D-Bus and SNMP/AgentX surfaces. keepalived's shipped D-Bus policy allows
any local user to send to
org.keepalived.Vrrp1, so the decoder there is reachable by an unprivileged process on the same machine. - Anything that writes kernel state — netlink, nftables, sysctls — going wrong in a way another process can influence.
- Denial of service through a configuration file you wrote yourself.
- The absence of authentication on VRRPv3. That is the protocol: RFC 9568 §9 removed it, and says the only defence is the TTL/hop-limit check, which this port enforces on receive.
- Behaviour that is wrong but faithfully reproduces keepalived. This port deliberately copies the C daemon, so a report that a reproduced behaviour is wrong is correct and will be closed as intended. If you think the port diverges from keepalived in a way that matters, that is very much in scope.
If you believe you have found a vulnerability in keepalived itself, report it to the keepalived maintainers rather than here.