CVE-2025-22248: Broadcom Bitnami Auth Bypass Vulnerability

CVE-2025-22248 Overview

CVE-2025-22248 is a critical insecure default configuration vulnerability affecting the Bitnami Pgpool Docker image and the Bitnami postgres-ha Kubernetes Helm chart. Under default configurations, these deployments include a repmgr user that permits unauthenticated access to the PostgreSQL database within the cluster. The PGPOOL_SR_CHECK_USER environment variable configures the user that Pgpool uses to perform streaming replication checks against nodes. In vulnerable configurations, this user is set to trust-level authentication, allowing any attacker with network access to authenticate to the database without credentials.

If Pgpool is exposed externally or accessible from adjacent networks, an attacker can leverage the repmgr user to gain unauthorized access to the PostgreSQL service, potentially leading to data exfiltration, modification, or complete database compromise.

Critical Impact

Unauthenticated database access allows attackers to read, modify, or delete sensitive data, potentially leading to complete database compromise across Kubernetes clusters running affected Bitnami PostgreSQL HA deployments.

Affected Products

• Broadcom Bitnami/pgpool Docker image (all versions under default configuration)
• Broadcom Bitnami postgres-ha Kubernetes Helm chart
• Broadcom Bitnami PostgreSQL deployments using Pgpool with default streaming replication check settings

Discovery Timeline

• 2025-05-13 - CVE-2025-22248 published to NVD
• 2025-07-18 - Last updated in NVD database

Technical Details for CVE-2025-22248

Vulnerability Analysis

This vulnerability stems from CWE-1188 (Insecure Default Initialization of Resource), where the default configuration of the Bitnami Pgpool Docker image and postgres-ha Helm chart establishes a trust-based authentication model for the repmgr user. Pgpool-II is a middleware component that sits between PostgreSQL clients and servers, providing connection pooling, load balancing, and high availability features. The streaming replication check functionality requires a database user to verify the replication status of backend nodes.

In vulnerable deployments, the repmgr user—designed for internal replication management—is configured without password authentication requirements. This configuration oversight allows direct database connections using this privileged user from any system that can reach the Pgpool service on the network.

Root Cause

The root cause of CVE-2025-22248 lies in the insecure default authentication configuration for the repmgr user in the pg_hba.conf file or equivalent authentication settings. The PGPOOL_SR_CHECK_USER configuration defaults to a trust authentication level, which explicitly permits connections without password verification. This design assumes the database cluster operates in a fully isolated and trusted network environment—an assumption that frequently does not hold in containerized and cloud-native deployments where network boundaries are more permeable.

Attack Vector

The attack vector for this vulnerability is classified as Adjacent Network, requiring the attacker to have network access to the Pgpool service. Exploitation follows this general pattern:

1. Reconnaissance: The attacker identifies an exposed Pgpool instance, typically listening on port 5432 or a custom PostgreSQL port
2. Connection Attempt: The attacker initiates a PostgreSQL connection specifying the repmgr username
3. Bypass Authentication: Due to trust-level authentication, no password is required
4. Database Access: Once connected, the attacker gains access to the PostgreSQL database with the privileges assigned to the repmgr user

The repmgr user typically has elevated privileges for managing replication, which may include the ability to read data across multiple databases, modify replication settings, or potentially escalate to superuser access depending on the specific configuration.

Since no verified exploit code examples are available for this vulnerability, organizations should refer to the GitHub Security Advisory for detailed technical information on affected configurations and remediation steps.

Detection Methods for CVE-2025-22248

Indicators of Compromise

• Unexpected database connections from the repmgr user originating from external or unauthorized IP addresses
• PostgreSQL authentication logs showing successful repmgr user logins without corresponding legitimate replication activity
• Unusual query patterns or data access from the repmgr user account
• Database connections to Pgpool from network segments that should not have access to the database cluster

Detection Strategies

• Monitor PostgreSQL pg_stat_activity for connections using the repmgr user from non-replication hosts
• Implement network flow analysis to detect connections to Pgpool ports (typically 5432 or 9999) from unauthorized sources
• Configure PostgreSQL logging to capture all authentication attempts and review for anomalous repmgr access patterns
• Deploy database activity monitoring solutions to alert on privilege misuse or data exfiltration attempts

Monitoring Recommendations

• Enable detailed PostgreSQL authentication logging by setting log_connections = on and log_disconnections = on
• Implement network segmentation monitoring to detect any cross-boundary access attempts to database services
• Set up alerts for any repmgr user connections that do not originate from known replication member nodes
• Regularly audit pg_hba.conf configurations across all PostgreSQL and Pgpool deployments for trust-based authentication entries

How to Mitigate CVE-2025-22248

Immediate Actions Required

• Audit all Bitnami Pgpool Docker containers and postgres-ha Helm chart deployments for default configurations
• Restrict network access to Pgpool services using Kubernetes NetworkPolicies or equivalent firewall rules
• Change the repmgr user authentication from trust to password-based authentication (md5 or scram-sha-256)
• Review database access logs for any suspicious repmgr user activity that may indicate prior compromise

Patch Information

Organizations should consult the GitHub Security Advisory GHSA-mx38-x658-5fwj for official remediation guidance from Broadcom Bitnami. Updates to the Helm chart and Docker images that address this insecure default configuration should be applied when available. Until patches are applied, implement the workarounds detailed below to secure affected deployments.

Workarounds

• Configure the PGPOOL_SR_CHECK_USER to use a dedicated user with password authentication by setting PGPOOL_SR_CHECK_PASSWORD
• Modify pg_hba.conf to require password authentication for the repmgr user from all hosts
• Implement Kubernetes NetworkPolicies to restrict Pgpool service access to only authorized pods within the cluster
• Use service mesh technologies (Istio, Linkerd) to enforce mutual TLS between database clients and Pgpool

The following example demonstrates securing Pgpool in a Kubernetes environment by configuring password authentication for the streaming replication check user:

# Configuration example for Bitnami postgres-ha Helm chart values.yaml
# Ensure password authentication for repmgr user

# Set explicit password for streaming replication check user
postgresql:
  pgHbaConfiguration: |-
    local all all scram-sha-256
    host all all 0.0.0.0/0 scram-sha-256
    host replication all 0.0.0.0/0 scram-sha-256

pgpool:
  srCheckUser: repmgr
  srCheckPassword: "<strong-password-here>"
  customUsersSecret: ""