openSUSE has issued an advisory on April 21: https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/message/B3PXHUYDTDFG5IIQSPNJLLIEQV4Z5WK6/ Fixed by: https://git.haproxy.org/?p=haproxy-3.2.git;a=commit;h=7ab4ae974c434e62896b3c68b7b485b9dceb7a25 (v3.2.15) Fixed by: https://git.haproxy.org/?p=haproxy-2.8.git;a=commit;h=ac75e1863c9dc965a9f7f9e87cdf8c22442ed9cd (v2.8.21)
Status comment: (none) => Fixed upstream in 3.2.15 and 2.8.21 and patches available from upstreamFlags: (none) => affects_mga9+CVE: (none) => CVE-2026-33555Source RPM: (none) => haproxy-3.2.10-1.mga10.src.rpm, haproxy-2.8.18-1.mga9.src.rpmWhiteboard: (none) => MGA9TOO
Assigning to our registered haproxy maintainer.
Assignee: bugsquad => mageiaCC: (none) => marja11
For Cauldron, I asked for a freeze move. Suggested advisory: ======================== The updated packages fix a security vulnerability: The HTTP/3 parser does not check that the received body length matches a previously announced content-length when the stream is closed via a frame with an empty payload. This can cause desynchronization issues with the backend server and could be used for request smuggling. (CVE-2026-33555) References: https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/message/B3PXHUYDTDFG5IIQSPNJLLIEQV4Z5WK6/ ======================== Updated packages in core/updates_testing: ======================== haproxy-2.8.18-1.1.mga9 haproxy-noquic-2.8.18-1.1.mga9 haproxy-quic-2.8.18-1.1.mga9 haproxy-utils-2.8.18-1.1.mga9 from SRPM: haproxy-2.8.18-1.1.mga9.src.rpm
Status: NEW => ASSIGNEDSource RPM: haproxy-3.2.10-1.mga10.src.rpm, haproxy-2.8.18-1.mga9.src.rpm => haproxy-2.8.18-1.mga9.src.rpmStatus comment: Fixed upstream in 3.2.15 and 2.8.21 and patches available from upstream => (none)Flags: affects_mga9+ => (none)Assignee: mageia => qa-bugsVersion: Cauldron => 9Whiteboard: MGA9TOO => (none)
Keywords: (none) => advisory
Ref bug 30364 but ]# systemctl enable haproxy.service Created symlink /etc/systemd/system/multi-user.target.wants/haproxy.service → /usr/lib/systemd/system/haproxy.service. [root@mach3 ~]# systemctl start haproxy.service Job for haproxy.service failed because the control process exited with error code. See "systemctl status haproxy.service" and "journalctl -xeu haproxy.service" for details. At first May 14 16:33:37 mach3.hviaene.thuis systemd[1]: Failed to start haproxy.service. ░░ Subject: A start job for unit haproxy.service has failed ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ A start job for unit haproxy.service has finished with a failure. ░░ ░░ The job identifier is 8008 and the job result is failed. Made sure all ports mentioned in 35064 are open in firewall, but to no avail.
CC: (none) => herman.viaene
Updated in a Virtualbox Plasma guest with no issues. Referenced Herman's test in bug 34186 comment 5 : [root@localhost ~]# systemctl start haproxy.service [root@localhost ~]# systemctl status haproxy.service ● haproxy.service - HAproxy Loadbalancer Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; preset: disabled) Active: active (running) since Fri 2026-05-15 18:07:09 EDT; 5min ago Main PID: 11546 (haproxy) Status: "Ready." Tasks: 9 (limit: 65000) Memory: 17.1M CPU: 560ms CGroup: /system.slice/haproxy.service ├─11546 /usr/sbin/haproxy -f /etc/haproxy/haproxy.conf -Ws └─11548 /usr/sbin/haproxy -f /etc/haproxy/haproxy.conf -Ws May 15 18:07:09 localhost.localdomain systemd[1]: Starting haproxy.service... May 15 18:07:09 localhost.localdomain systemd[1]: Started haproxy.service. [tom@localhost ~]$ curl -I http://127.0.0.1:8000 HTTP/1.1 302 Found content-length: 0 location: https://127.0.0.1:8000/ cache-control: no-cache [tom@localhost ~]$ curl -I -k https://127.0.0.1:8000 HTTP/2 503 cache-control: no-cache content-type: text/html Results are consistent with the previous test. Unknown why Herman's test produced an error this time.
CC: (none) => andrewsfarm
LC_ALL=C urpmi haproxy In order to satisfy the 'haproxy-server[== 2.8.18-1.1.mga9]' dependency, one of the following packages is needed: 1- haproxy-noquic-2.8.18-1.1.mga9.x86_64: Reliable High Performance TCP/HTTP Load Balancer (to install) 2- haproxy-quic-2.8.18-1.1.mga9.x86_64: Reliable High Performance TCP/HTTP Load Balancer (to install) What is your choice? (1-2) 1 To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "QA Testing (64-bit)") haproxy 2.8.18 1.1.mga9 x86_64 haproxy-noquic 2.8.18 1.1.mga9 x86_64 4.8MB of additional disk space will be used. 1.5MB of packages will be retrieved. Proceed with the installation of the 2 packages? (Y/n) y installing haproxy-2.8.18-1.1.mga9.x86_64.rpm haproxy-noquic-2.8.18-1.1.mga9.x86_64.rpm from //home/katnatek/qa-testing/x86_64 Preparing... ################################################################################################### 1/2: haproxy-noquic ################################################################################################### 2/2: haproxy ################################################################################################### ---------------------------------------------------------------------- More information on package haproxy-2.8.18-1.1.mga9.x86_64 Haproxy is now installed. Configuration file is /etc/haproxy/haproxy.conf The server listen on any:8000, 8080 and 8443 by default. Add to /etc/shorewall/rules.haproxy these shorewall rules for a transparent proxy: # Redirect tcp traffic from net on port 80 to 8000 REDIRECT net 8000 tcp 80 # Redirect tcp traffic from net on port 443 to 8000 REDIRECT net 8000 tcp 443 # Redirect udp traffic from net on port 443 to 8443 #REDIRECT net 8443 udp 443 Enable the service with: # systemctl enable haproxy.service Start the service with: # systemctl start haproxy.service ---------------------------------------------------------------------- Service looks good here systemctl enable haproxy.service Created symlink /etc/systemd/system/multi-user.target.wants/haproxy.service → /usr/lib/systemd/system/haproxy.service. systemctl start haproxy.service systemctl status haproxy.service ● haproxy.service - HAproxy Loadbalancer Loaded: loaded (/usr/lib/systemd/system/haproxy.service; enabled; preset: disabled) Active: active (running) since Fri 2026-05-15 17:59:51 CST; 13s ago Process: 43725 ExecStartPre=/usr/sbin/haproxy-check (code=exited, status=0/SUCCESS) Main PID: 43731 (haproxy) Status: "Ready." Tasks: 9 (limit: 65000) Memory: 17.5M CPU: 335ms CGroup: /system.slice/haproxy.service ├─43731 /usr/sbin/haproxy -f /etc/haproxy/haproxy.conf -Ws └─43733 /usr/sbin/haproxy -f /etc/haproxy/haproxy.conf -Ws may 15 17:59:50 jgrey.phoenix systemd[1]: Starting haproxy.service... may 15 17:59:51 jgrey.phoenix systemd[1]: Started haproxy.service.
With the last two tests I'd normally send this on, but the failure in comment 3 concerns me. I'd like to know a reason why. Bad .conf file, perhaps?
Checked that I didn't change anything in the config file. Then run the commands again and all is OK. Strange is that history does not show any previous commands. At that time I had two M9 and three M10 instances installed on this laptop (all M10's since then deleted and 2 fresh ones installed). It's not impossible I picked a wrong installation at that time. So I agree on the OK.
Whiteboard: (none) => MGA9-64-OKFlags: (none) => test_passed_mga9_64+
Thank you, Herman. Validating.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2026-0146.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED