RHSA-2026:21182HighCVSS 8.8

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

Published
May 26, 2026
Last Modified
September 7, 2026

🔗 CVE IDs covered (8)

CVE-2026-6637 →CVE-2026-6638 →CVE-2026-6472 →CVE-2026-6475 →CVE-2026-6477 →CVE-2026-6478 →CVE-2026-6479 →CVE-2026-6575 →

📋 Description

CVE-2026-6472 — postgresql: PostgreSQL CREATE TYPE does not check multirange schema CREATE privilege CVE-2026-6475 — postgresql: PostgreSQL: Operating system account hijack via symlink following in pg_basebackup and pg_rewind CVE-2026-6477 — postgresql: PostgreSQL libpq: Buffer overflow allows server superuser to overwrite client stack memory CVE-2026-6478 — postgresql: PostgreSQL: Credential recovery via covert timing channel in MD5 password comparison CVE-2026-6479 — postgresql: PostgreSQL: Denial of Service via uncontrolled recursion in SSL/GSS negotiation CVE-2026-6575 — postgresql: PostgreSQL: Information disclosure via buffer over-read in pg_restore_attribute_stats() CVE-2026-6637 — postgresql: PostgreSQL: Arbitrary code execution vulnerability in 'refint' module CVE-2026-6638 — postgresql: PostgreSQL: Arbitrary SQL execution via SQL injection in logical replication

🎯 Affected products5

  • Red Hat Hardened Images
  • postgresql17-main@aarch64 as a component of Red Hat Hardened Images
  • postgresql17-main@noarch as a component of Red Hat Hardened Images
  • postgresql17-main@src as a component of Red Hat Hardened Images
  • postgresql17-main@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: Red Hat is not aware of a practical temporary workaround that fully mitigates this issue or meets Red Hat Product Security's standards for usability, deployment, applicability, or stability. Workaround: Only connect to trusted PostgreSQL servers. Avoid using psql or pg_dump against untrusted or potentially compromised database servers. Workaround: To mitigate this vulnerability, ensure that all PostgreSQL user passwords are not hashed using MD5. Users should migrate to stronger hashing algorithms such as `scram-sha-256`. This can be achieved by altering user passwords, which will automatically update their hash to the currently configured default. For example, to change a user's password: `ALTER USER username WITH PASSWORD 'new_password';` This action will require users to re-authenticate. If a service relies on these credentials, it may require a restart to pick up the new authentication details. Workaround: Upgrade to PostgreSQL 18.4, 17.10, 16.14, 15.18, or 14.23 (matching your major version) or later. Restricting network/socket access to trusted clients reduces exposure but does not eliminate the vulnerability. Workaround: To mitigate this information disclosure vulnerability, restrict network access to the PostgreSQL server to only trusted clients. Configure firewall rules to limit inbound connections to the PostgreSQL port (default 5432) from authorized hosts only. For example, using `firewall-cmd` on Red Hat Enterprise Linux: `sudo firewall-cmd --permanent --add-source=<TRUSTED_IP_ADDRESS>/32 --zone=public` `sudo firewall-cmd --permanent --add-port=5432/tcp --zone=public` `sudo firewall-cmd --reload` Alternatively, configure PostgreSQL to listen only on the localhost interface by setting `listen_addresses = 'localhost'` in `postgresql.conf` and restarting the PostgreSQL service. `sudo systemctl restart postgresql` This reduces the attack surface by preventing unauthorized network access to the database. Note that restarting the PostgreSQL service will temporarily interrupt database operations. Workaround: Upgrade to PostgreSQL 18.4, 17.10, or 16.14 (matching your major version) or later, which corrects the identifier quoting used when the subscriber's apply worker sends the REFRESH PUBLICATION SQL to the publisher. Versions prior to PostgreSQL 16 are not affected. As a temporary mitigation, restrict CREATE TABLE / table-ownership privileges on subscriber databases to trusted roles only, avoid configuring logical replication subscriptions for untrusted subscriber-side users, and scope the subscription's publication-side credentials to the minimum privileges necessary.

🔗 References (12)