RHSA-2026:83843HighCVSS 8.8

Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update

Published
October 16, 2026
Last Modified
October 31, 2026

🔗 CVE IDs covered (3)

📋 Description

CVE-2026-107348 — pgbouncer: pgbouncer: Denial of Service via integer overflow in message buffer growth CVE-2026-107349 — pgbouncer: pgbouncer: Denial of Service via empty parameter name in startup options CVE-2026-107350 — pgbouncer: pgbouncer: Privilege escalation via secondary startup message during SCRAM authentication

🎯 Affected products5

  • Red Hat Hardened Images
  • pgbouncer-0:1.26.1-1.hum1@aarch64 as a component of Red Hat Hardened Images
  • pgbouncer-0:1.26.1-1.hum1@s390x as a component of Red Hat Hardened Images
  • pgbouncer-0:1.26.1-1.hum1@src as a component of Red Hat Hardened Images
  • pgbouncer-0:1.26.1-1.hum1@x86_64 as a component of Red Hat Hardened Images

✅ Remediation

For details on how to apply this update, which includes the changes described in this advisory, refer to: https://images.redhat.com/ Workaround: Ensure that `max_packet_size` is not configured above 2147483647 in the PgBouncer configuration file. 1. Edit `/etc/pgbouncer/pgbouncer.ini` and set `max_packet_size` to a safe value (or remove the directive to use standard defaults): ```ini [pgbouncer] max_packet_size = 2147483647 ``` 2. Reload the PgBouncer service to apply changes: ```sh systemctl reload pgbouncer ``` Warning: Reloading or restarting the service can disrupt ongoing administrative tasks or transient connections. Always schedule configuration reloads during standard maintenance windows. 3. Restrict network access: Apply firewall rules to ensure that the PgBouncer listening port (default 6432) is accessible only by trusted application hosts and not exposed to untrusted networks. Caveats: Setting `max_packet_size` to a lower threshold will reject legitimate queries or results exceeding that specified size. Workaround: Restrict network access to the PgBouncer service so that only trusted application hosts and administrative clients can connect. This can be accomplished by configuring firewall filtering using firewalld or by binding PgBouncer only to internal, isolated interfaces. For example, to restrict access to PgBouncer (default port 6432/TCP) to a trusted subnet (such as 192.168.1.0/24): 1. Add a rich rule allowing only the trusted source subnet: # firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port port="6432" protocol="tcp" accept' 2. Ensure the port is not exposed in public zones: # firewall-cmd --permanent --remove-port=6432/tcp 3. Reload firewalld to apply changes: # firewall-cmd --reload Caveats: Network-level restrictions reduce exposure to untrusted external clients but do not mitigate risks originating from compromised or untrusted hosts within the allowed network. Modifying firewall rules or listener configurations can momentarily disrupt active client sessions and connection pooling. Workaround: Limit network access to the PgBouncer daemon so that only trusted application hosts can establish connections. 1. Using firewalld, restrict traffic on the PgBouncer port (default 6432/tcp) to specific authorized client IP addresses: # firewall-cmd --permanent --zone=trusted --add-source=<TRUSTED_CLIENT_IP> # firewall-cmd --permanent --zone=trusted --add-port=6432/tcp # firewall-cmd --permanent --remove-port=6432/tcp --zone=public # firewall-cmd --reload Alternatively, if clients reside on the same host, bind PgBouncer exclusively to the loopback interface by configuring `listen_addr = 127.0.0.1` in `/etc/pgbouncer/pgbouncer.ini` and applying changes: # systemctl reload pgbouncer Caveats: Restricting network reachability prevents untrusted network hosts from connecting, but it does not protect against malicious or compromised clients residing within the permitted network range. Modifying firewall rules or reloading the PgBouncer service may briefly disrupt active client connections.

🔗 References (7)