Serious security issue in HAProxy 1.6.8


Hello. It looks like there is serious security issue with HAProxy version 1.6.8. We are using same configuration for long time, and till yesterday (before we updated version from 1.6.7 to 1.6.8), everything worked just fine.

Small overview on simplified version of our environment. Let’s say that we have one frontend, and multiple backends. Routing to correct backend is based on host header of request (‘acl host1 hdr_beg(host) -i’, ‘use_backend backend1 if host1’, …). Each backend has only one server. We have set ‘errorfile 503 /some/maintenance/screen.http’.

When backend is up - everything works just as expected.
When backend is down - everything works just as expected.

The magic happens, when backend is going down, in this small time window, when HAProxy checks are performed.
Till yesterday, trying to connect to immediately after turning off service on one and only server of backend1 resulted in displaying our custom maintenance screen.
Now trying to connect to results in serving content from random backend. :wink: So, in this short time period, when HAProxy is performing checks to ensure that backend1 is really DOWN, we can enter ‘’ in browser, and hold F5 to get quick overview of all services available in our config (not sure if only backends accessible from frontend1, or all of them). After checks, when backend1 in ‘haproxy?stats’ is red, everything works fine - entering results in displaying our custom maintenance screen.

Regarding the security… In frontend1, we also have some ACLs, that allow access to some backends only from one IP address. When backend is going down, anyone trying to browse can bypass these ACLs, and randomly get access to restricted services. :wink:

Downgrading to 1.6.7 resolves the issue, upgrading to 1.6.8 brings the issue back. For now, we are forced to use HAProxy 1.6.7.

Best regards,
Bartosz Koniński


For the record: this is fixed in Haproxy 1.6.9 in commit bd89584bb ("BUG/MAJOR: stream: properly mark the server address as unset on connect retry).