CVE-2019-14241
HAProxy through 2.0.2 allows attackers to cause a denial of service (ha_panic) via vectors...
HAProxy through 2.0.2 allows attackers to cause a denial of service (ha_panic) via vectors related to htx_manage_client_side_cookies in proto_htx.c.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Exploit likelihood
What each source reports
NVD Score used
7.5
HAProxy through 2.0.2 allows attackers to cause a denial of service (ha_panic) via vectors related to htx_manage_client_side_cookies in proto_htx.c.
- Record
CVE-2019-14241- CVSS 3.0
- 7.5 High
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - CVSS 2.0
- 5.0 Medium
AV:N/AC:L/Au:N/C:N/I:N/A:P - Weakness
- CWE-835
- Updated
- 2026-11-02
CVE List No score
HAProxy through 2.0.2 allows attackers to cause a denial of service (ha_panic) via vectors related to htx_manage_client_side_cookies in proto_htx.c.
- Record
CVE-2019-14241- Updated
- 2026-11-02
EUVDEUVD-2019-5483 No score
HAProxy through 2.0.2 allows attackers to cause a denial of service (ha_panic) via vectors related to htx_manage_client_side_cookies in proto_htx.c.
- Record
EUVD-2019-5483- Updated
- 2026-11-03
GitHub AdvisoriesGHSA-rwrj-rg8q-w32h No score
HAProxy through 2.0.2 allows attackers to cause a denial of service (ha_panic) via vectors...
HAProxy through 2.0.2 allows attackers to cause a denial of service (ha_panic) via vectors related to htx_manage_client_side_cookies in proto_htx.c.
- Record
GHSA-rwrj-rg8q-w32h- Updated
- 2026-11-02
OSV
7.5
HAProxy through 2.0.2 allows attackers to cause a denial of service (ha_panic) via vectors related to htx_manage_client_side_cookies in proto_htx.c.
- Record
CVE-2019-14241- CVSS 3.0
- 7.5 High
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Updated
- 2026-11-02
OSVopenSUSE-SU-2019:2555-1 No score
Security update for haproxy
This update for haproxy to version 2.0.5+git0.d905f49a fixes the following issues:
Security issue fixed:
- CVE-2019-14241: Fixed a cookie memory corruption problem. (bsc#1142529)
The update to 2.0.5 brings lots of features and bugfixes:
- new internal native HTTP representation called HTX, was already in 1.9 and is now enabled by default in 2.0
- end-to-end HTTP/2 support including trailers and continuation frames, as needed for gRPC ; HTTP/2 may also be upgraded from HTTP/1.1 using the H2 preface;
- server connection pooling and more advanced reuse, with ALPN protocol negotiation (already in 1.9)
- layer 7 retries, allowing to use 0-RTT and TCP Fast Open to the servers as well as on the frontend
- much more scalable multi-threading, which is even enabled by default on platforms where it was successfully tested ; by default, as many threads are started as the number of CPUs haproxy is allowed to run on. This removes a lot of configuration burden in VMs and containers
- automatic maxconn setting for the process and the frontends, directly based on the number of available FDs (easier configuration in containers and with systemd)
- logging to stdout for use in containers and systemd (already in 1.9). Logs can now provide micro-second resolution for some events
- peers now support SSL, declaration of multiple stick-tables directly in the peers section, and synchronization of server names, not just IDs
- In master-worker mode, the master process now exposes its own CLI and can communicate with all other processes (including the stopping ones), even allowing to connect to their CLI and check their state. It is also possible to start some sidecar programs and monitor them from the master, and the master can automatically kill old processes that survived too many reloads
- the incoming connections are load-balanced between all threads depending on their load to minimize the processing time and maximize the capacity (already in 1.9)
- the SPOE connection load-balancing was significantly improved in order to reduce high percentiles of SPOA response time (already in 1.9)
- the 'random' load balancing algorithm and a power-of-two-choices variant were introduced
- statistics improvements with per-thread counters for certain things, and a prometheus exporter for all our statistics;
- lots of debugging help, it's easier to produce a core dump, there are new commands on the CLI to control various things, there is a watchdog to fail cleanly when a thread deadlock or a spinning task are detected, so overall it should provide a better experience in field and less round trips between users and developers (hence less stress during an incident).
- all 3 device detection engines are now compatible with multi-threading and can be build-tested without any external dependencies
- 'do-resolve' http-request action to perform a DNS resolution on any, sample, and resolvers now support relying on /etc/resolv.conf to match the local resolver
- log sampling and balancing : it's now possible to send 1 log every 10 to a server, or to spread the logging load over multiple log servers;
- a new SPOA agent (spoa_server) allows to interface haproxy with Python and Lua programs
- support for Solaris' event ports (equivalent of kqueue or epoll) which will significantly improve the performance there when dealing with numerous connections
- some warnings are now reported for some deprecated options that will be removed in 2.1. Since 2.0 is long term supported, there's no emergency to convert them, however if you see these warnings, you need to understand that you're among their extremely rare users and just because of this you may be taking risks by keeping them
- A new SOCKS4 server-side layer was provided ; it allows outgoing connections to be forwarded through a SOCKS4 proxy (such as ssh -D).
- priority- and latency- aware server queues : it is possible now to assign priorities to certain requests and/or to give them a time bonus or penalty to refine…
- Record
openSUSE-SU-2019:2555-1- Updated
- 2026-11-02
Show 4 moreShow less
OSVopenSUSE-SU-2019:2556-1 No score
Security update for haproxy
This update for haproxy to version 2.0.5+git0.d905f49a fixes the following issues:
Security issue fixed:
- CVE-2019-14241: Fixed a cookie memory corruption problem. (bsc#1142529)
The update to 2.0.5 brings lots of features and bugfixes:
- new internal native HTTP representation called HTX, was already in 1.9 and is now enabled by default in 2.0
- end-to-end HTTP/2 support including trailers and continuation frames, as needed for gRPC ; HTTP/2 may also be upgraded from HTTP/1.1 using the H2 preface;
- server connection pooling and more advanced reuse, with ALPN protocol negotiation (already in 1.9)
- layer 7 retries, allowing to use 0-RTT and TCP Fast Open to the servers as well as on the frontend
- much more scalable multi-threading, which is even enabled by default on platforms where it was successfully tested ; by default, as many threads are started as the number of CPUs haproxy is allowed to run on. This removes a lot of configuration burden in VMs and containers
- automatic maxconn setting for the process and the frontends, directly based on the number of available FDs (easier configuration in containers and with systemd)
- logging to stdout for use in containers and systemd (already in 1.9). Logs can now provide micro-second resolution for some events
- peers now support SSL, declaration of multiple stick-tables directly in the peers section, and synchronization of server names, not just IDs
- In master-worker mode, the master process now exposes its own CLI and can communicate with all other processes (including the stopping ones), even allowing to connect to their CLI and check their state. It is also possible to start some sidecar programs and monitor them from the master, and the master can automatically kill old processes that survived too many reloads
- the incoming connections are load-balanced between all threads depending on their load to minimize the processing time and maximize the capacity (already in 1.9)
- the SPOE connection load-balancing was significantly improved in order to reduce high percentiles of SPOA response time (already in 1.9)
- the 'random' load balancing algorithm and a power-of-two-choices variant were introduced
- statistics improvements with per-thread counters for certain things, and a prometheus exporter for all our statistics;
- lots of debugging help, it's easier to produce a core dump, there are new commands on the CLI to control various things, there is a watchdog to fail cleanly when a thread deadlock or a spinning task are detected, so overall it should provide a better experience in field and less round trips between users and developers (hence less stress during an incident).
- all 3 device detection engines are now compatible with multi-threading and can be build-tested without any external dependencies
- 'do-resolve' http-request action to perform a DNS resolution on any, sample, and resolvers now support relying on /etc/resolv.conf to match the local resolver
- log sampling and balancing : it's now possible to send 1 log every 10 to a server, or to spread the logging load over multiple log servers;
- a new SPOA agent (spoa_server) allows to interface haproxy with Python and Lua programs
- support for Solaris' event ports (equivalent of kqueue or epoll) which will significantly improve the performance there when dealing with numerous connections
- some warnings are now reported for some deprecated options that will be removed in 2.1. Since 2.0 is long term supported, there's no emergency to convert them, however if you see these warnings, you need to understand that you're among their extremely rare users and just because of this you may be taking risks by keeping them
- A new SOCKS4 server-side layer was provided ; it allows outgoing connections to be forwarded through a SOCKS4 proxy (such as ssh -D).
- priority- and latency- aware server queues : it is possible now to assign priorities to certain requests and/or to give them a time bonus or penalty to refine…
- Record
openSUSE-SU-2019:2556-1- Updated
- 2026-11-02
OSVopenSUSE-SU-2024:10839-1 No score
haproxy-2.4.4+git0.acb1d0bea-1.2 on GA media
These are all security issues fixed in the haproxy-2.4.4+git0.acb1d0bea-1.2 package on the GA media of openSUSE Tumbleweed.
- Record
openSUSE-SU-2024:10839-1- Updated
- 2026-11-02
OSVSUSE-SU-2019:3001-1 No score
Security update for haproxy
This update for haproxy to version 2.0.5+git0.d905f49a fixes the following issues:
Security issue fixed:
- CVE-2019-14241: Fixed a cookie memory corruption problem. (bsc#1142529)
The update to 2.0.5 brings lots of features and bugfixes:
- new internal native HTTP representation called HTX, was already in 1.9 and is now enabled by default in 2.0
- end-to-end HTTP/2 support including trailers and continuation frames, as needed for gRPC ; HTTP/2 may also be upgraded from HTTP/1.1 using the H2 preface;
- server connection pooling and more advanced reuse, with ALPN protocol negotiation (already in 1.9)
- layer 7 retries, allowing to use 0-RTT and TCP Fast Open to the servers as well as on the frontend
- much more scalable multi-threading, which is even enabled by default on platforms where it was successfully tested ; by default, as many threads are started as the number of CPUs haproxy is allowed to run on. This removes a lot of configuration burden in VMs and containers
- automatic maxconn setting for the process and the frontends, directly based on the number of available FDs (easier configuration in containers and with systemd)
- logging to stdout for use in containers and systemd (already in 1.9). Logs can now provide micro-second resolution for some events
- peers now support SSL, declaration of multiple stick-tables directly in the peers section, and synchronization of server names, not just IDs
- In master-worker mode, the master process now exposes its own CLI and can communicate with all other processes (including the stopping ones), even allowing to connect to their CLI and check their state. It is also possible to start some sidecar programs and monitor them from the master, and the master can automatically kill old processes that survived too many reloads
- the incoming connections are load-balanced between all threads depending on their load to minimize the processing time and maximize the capacity (already in 1.9)
- the SPOE connection load-balancing was significantly improved in order to reduce high percentiles of SPOA response time (already in 1.9)
- the 'random' load balancing algorithm and a power-of-two-choices variant were introduced
- statistics improvements with per-thread counters for certain things, and a prometheus exporter for all our statistics;
- lots of debugging help, it's easier to produce a core dump, there are new commands on the CLI to control various things, there is a watchdog to fail cleanly when a thread deadlock or a spinning task are detected, so overall it should provide a better experience in field and less round trips between users and developers (hence less stress during an incident).
- all 3 device detection engines are now compatible with multi-threading and can be build-tested without any external dependencies
- 'do-resolve' http-request action to perform a DNS resolution on any, sample, and resolvers now support relying on /etc/resolv.conf to match the local resolver
- log sampling and balancing : it's now possible to send 1 log every 10 to a server, or to spread the logging load over multiple log servers;
- a new SPOA agent (spoa_server) allows to interface haproxy with Python and Lua programs
- support for Solaris' event ports (equivalent of kqueue or epoll) which will significantly improve the performance there when dealing with numerous connections
- some warnings are now reported for some deprecated options that will be removed in 2.1. Since 2.0 is long term supported, there's no emergency to convert them, however if you see these warnings, you need to understand that you're among their extremely rare users and just because of this you may be taking risks by keeping them
- A new SOCKS4 server-side layer was provided ; it allows outgoing connections to be forwarded through a SOCKS4 proxy (such as ssh -D).
- priority- and latency- aware server queues : it is possible now to assign priorities to certain requests and/or to give them a time bonus or penalty to refine…
- Record
SUSE-SU-2019:3001-1- Updated
- 2026-11-02
OSVSUSE-SU-2019:3002-1 No score
Security update for haproxy
This update for haproxy to version 2.0.5+git0.d905f49a fixes the following issues:
Security issue fixed:
- CVE-2019-14241: Fixed a cookie memory corruption problem. (bsc#1142529)
The update to 2.0.5 brings lots of features and bugfixes:
- new internal native HTTP representation called HTX, was already in 1.9 and is now enabled by default in 2.0
- end-to-end HTTP/2 support including trailers and continuation frames, as needed for gRPC ; HTTP/2 may also be upgraded from HTTP/1.1 using the H2 preface;
- server connection pooling and more advanced reuse, with ALPN protocol negotiation (already in 1.9)
- layer 7 retries, allowing to use 0-RTT and TCP Fast Open to the servers as well as on the frontend
- much more scalable multi-threading, which is even enabled by default on platforms where it was successfully tested ; by default, as many threads are started as the number of CPUs haproxy is allowed to run on. This removes a lot of configuration burden in VMs and containers
- automatic maxconn setting for the process and the frontends, directly based on the number of available FDs (easier configuration in containers and with systemd)
- logging to stdout for use in containers and systemd (already in 1.9). Logs can now provide micro-second resolution for some events
- peers now support SSL, declaration of multiple stick-tables directly in the peers section, and synchronization of server names, not just IDs
- In master-worker mode, the master process now exposes its own CLI and can communicate with all other processes (including the stopping ones), even allowing to connect to their CLI and check their state. It is also possible to start some sidecar programs and monitor them from the master, and the master can automatically kill old processes that survived too many reloads
- the incoming connections are load-balanced between all threads depending on their load to minimize the processing time and maximize the capacity (already in 1.9)
- the SPOE connection load-balancing was significantly improved in order to reduce high percentiles of SPOA response time (already in 1.9)
- the 'random' load balancing algorithm and a power-of-two-choices variant were introduced
- statistics improvements with per-thread counters for certain things, and a prometheus exporter for all our statistics;
- lots of debugging help, it's easier to produce a core dump, there are new commands on the CLI to control various things, there is a watchdog to fail cleanly when a thread deadlock or a spinning task are detected, so overall it should provide a better experience in field and less round trips between users and developers (hence less stress during an incident).
- all 3 device detection engines are now compatible with multi-threading and can be build-tested without any external dependencies
- 'do-resolve' http-request action to perform a DNS resolution on any, sample, and resolvers now support relying on /etc/resolv.conf to match the local resolver
- log sampling and balancing : it's now possible to send 1 log every 10 to a server, or to spread the logging load over multiple log servers;
- a new SPOA agent (spoa_server) allows to interface haproxy with Python and Lua programs
- support for Solaris' event ports (equivalent of kqueue or epoll) which will significantly improve the performance there when dealing with numerous connections
- some warnings are now reported for some deprecated options that will be removed in 2.1. Since 2.0 is long term supported, there's no emergency to convert them, however if you see these warnings, you need to understand that you're among their extremely rare users and just because of this you may be taking risks by keeping them
- A new SOCKS4 server-side layer was provided ; it allows outgoing connections to be forwarded through a SOCKS4 proxy (such as ssh -D).
- priority- and latency- aware server queues : it is possible now to assign priorities to certain requests and/or to give them a time bonus or penalty to refine…
- Record
SUSE-SU-2019:3002-1- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
haproxySUSE:Linux Enterprise High Availability Extension 15 SP1 |
before 2.0.5+git0.d905f49a-8.3.5 | 2.0.5+git0.d905f49a-8.3.5 |
haproxySUSE:Linux Enterprise High Availability Extension 15 |
before 2.0.5+git0.d905f49a-3.12.6 | 2.0.5+git0.d905f49a-3.12.6 |
haproxyopenSUSE:Leap 15.0 |
before 2.0.5+git0.d905f49a-lp150.2.13.1 | 2.0.5+git0.d905f49a-lp150.2.13.1 |
haproxyopenSUSE:Leap 15.1 |
before 2.0.5+git0.d905f49a-lp151.2.3.1 | 2.0.5+git0.d905f49a-lp151.2.3.1 |
haproxyopenSUSE:Tumbleweed |
before 2.4.4+git0.acb1d0bea-1.2 | 2.4.4+git0.acb1d0bea-1.2 |
History
| Recorded | Changed | Sources |
|---|---|---|
| aliases | EUVD | |
| first indexed | CVE List, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2019-14241 is a high vulnerability (CVSS 7.5) in Haproxy, published July 23, 2019. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 70.2%, the 99th percentile. Fixed in haproxy 2.0.5+git0.d905f49a-8.3.5.
References
github.com/haproxy/haproxy/issues/181
securityfocus.com/bid/109352
lists.opensuse.org/opensuse-security-announce/2019-11/msg00062.html
lists.opensuse.org/opensuse-security-announce/2019-11/msg00060.html
nvd.nist.gov/vuln/detail/CVE-2019-14241
github.com/advisories/GHSA-rwrj-rg8q-w32h
Show 15 moreShow less
suse.com/support/update/announcement/2019/suse-su-20193001-1
bugzilla.suse.com/1142529
suse.com/security/cve/CVE-2019-14241
bugzilla.suse.com/ECO-546
suse.com/support/update/announcement/2019/suse-su-20193002-1
lists.opensuse.org/archives/list/[email protected]/thread/GOCOZCGJIDUANW2OMYVRU77C6CGWQJUF
lists.opensuse.org/archives/list/[email protected]/thread/FUKOGLVYHSIG27DU7HAIRPPNF5XBHVDD
suse.com/security/cve/CVE-2018-11469
suse.com/security/cve/CVE-2018-14645
suse.com/security/cve/CVE-2018-20103
suse.com/security/cve/CVE-2018-20615
suse.com/security/cve/CVE-2019-18277
suse.com/security/cve/CVE-2020-11100
suse.com/security/cve/CVE-2021-39240
suse.com/security/cve/CVE-2021-40346
Left out here: the rest of 4 source descriptions. The JSON record has them.