Critical SQL Injection in IBM Cloud Portal Infrastructure Allowed Database Exfiltration

A critical SQL injection vulnerability on an enterprise-facing IBM Cloud infrastructure management portal allowed unauthenticated remote adversaries to extract sensitive relational database records, administrative credentials, and cloud resource metadata. Documented in coordinated public disclosure via HackerOne (Report #3662095) by security researcher xetnus, the flaw stems from unsanitized parameter concatenation in dynamic database querying routines powering asset telemetry and resource status endpoints.

Enterprise Cloud Asset Management Architecture

Modern enterprise cloud platforms manage immense distributed environments comprising Kubernetes clusters, virtual private clouds (VPCs), storage buckets, and bare-metal server fleets. To provide operations teams and enterprise customers with visibility into system health, IBM operates centralized web management portals that aggregate telemetry, deployment logs, and resource inventories.

These portals communicate with backend relational database clusters (such as IBM Db2, PostgreSQL, and MySQL) storing sensitive operational topology: customer account affiliations, internal IP address mappings, hardware serial identifiers, authentication tokens, and user credentials. Maintaining absolute query isolation is critical to prevent cross-tenant information exposure.

Root Cause: Dynamic Parameter Concatenation in Filter APIs

The vulnerability was identified within an API endpoint responsible for filtering infrastructure asset telemetry by cluster identifier or environment tag. When an HTTP client dispatched a GET or POST request to the asset search service, the backend application handler extracted user-supplied query parameters directly from the request URI or JSON body:

// Vulnerable Query Construction Logic:
String clusterId = request.getParameter("cluster_id");

// VULNERABLE: Direct string interpolation into raw SQL without parameter binding!
String query = "SELECT asset_id, hostname, status, ip_address, cluster_name " +
               "FROM enterprise_assets WHERE cluster_id = '" + clusterId + "' " +
               "AND is_active = 1";

Statement statement = connection.createStatement();
ResultSet results = statement.executeQuery(query);

Because the application failed to utilize parameterized queries (e.g., PreparedStatement with ? placeholders) or enforce strict type validation (such as ensuring cluster_id conforms to a valid UUID format), user input broke out of the string literal, altering the query syntax executed by the database engine.

Step-by-Step Proof of Concept & Exploitation Mechanics

In his coordinated disclosure, researcher xetnus demonstrated how an unauthenticated attacker could verify the vulnerability and systematically exfiltrate database records.

Step 1: Detection via Time-Based Blind Injection

To confirm SQL injection without disrupting application stability, the researcher injected an asynchronous time-delay payload into the vulnerable parameter:

GET /api/v1/assets/telemetry?cluster_id=prod-east'+AND+(SELECT+1+FROM+(SELECT(SLEEP(10)))a)--+- HTTP/1.1
Host: infrastructure-portal.ibm.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: application/json

The database thread parsed the injected subquery, pausing execution for exactly 10 seconds before returning the HTTP response. Baseline queries returned in under 120 milliseconds, confirming that arbitrary SQL instructions were being interpreted directly by the database server.

Step 2: UNION-Based Schema Enumeration

Once the injection syntax and column count were mapped, the attacker utilized a UNION SELECT payload to extract the database engine version and table names:

GET /api/v1/assets/telemetry?cluster_id=-1'+UNION+SELECT+1,version(),user(),current_database(),5--+- HTTP/1.1
Host: infrastructure-portal.ibm.com

The API response returned the database server version banner, current service user context, and database catalog name directly inside the JSON response fields normally reserved for hostname and IP address data.

Step 3: Systematic Data Exfiltration

Leveraging database information schema tables (information_schema.tables and information_schema.columns), an adversary could construct automated extraction pipelines to dump:

• Portal User Credentials: Administrative usernames, corporate email addresses, and salted password hashes for enterprise portal accounts.
• Cloud API Tokens: Static service credentials used by the portal to communicate with underlying cloud orchestration endpoints.
• Infrastructure Topologies: Internal IP ranges, VLAN identifiers, and hostnames of private enterprise compute instances.

Threat Modeling & Multi-Tenant Exposure

SQL injection flaws on cloud infrastructure portals introduce catastrophic blast radius across multi-tenant ecosystems:

Remediation Playbook & Database Hardening

IBM PSIRT resolved the vulnerability across all production deployments by transitioning dynamic queries to parameterized prepared statements. Organizations developing enterprise web applications must implement the following controls:

1. Enforce Parameterized Queries Universally

Eliminate dynamic string concatenation across all database query layers. Parameterized statements treat user inputs strictly as literal values rather than executable code:

// Remediated Query Construction using Prepared Statements:
String query = "SELECT asset_id, hostname, status, ip_address, cluster_name " +
               "FROM enterprise_assets WHERE cluster_id = ? AND is_active = 1";

try (PreparedStatement pstmt = connection.prepareStatement(query)) {
    pstmt.setString(1, clusterId);
    try (ResultSet rs = pstmt.executeQuery()) {
        // Process records safely
    }
}

2. Restrict Database Service Account Privileges

Ensure web application database accounts operate under the principle of least privilege. Web services should not connect using superuser or database owner roles, and permissions should be restricted strictly to required tables.

3. Implement Web Application Firewall (WAF) Inspection Rules

Deploy WAF rules inspecting incoming URI parameters and request bodies for common SQL injection syntax patterns (e.g., UNION SELECT, SLEEP(, comment delimiters --), providing automated ingress filtering against automated scanning tooling.