Description

IBM API Connect 10.0.8.0 through 10.0.8.12 and 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to gain unauthorized administrative access to other tenants due to LDAP injection. User-supplied input is not properly neutralized in directory queries, which could change the query and grant access beyond the user's own tenant.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-11-07T05:18:54.113Z",
  "pubdate": "2026-11-07T05:18:54.113Z",
  "executiveSummary": "This vulnerability involves an LDAP injection flaw in IBM API Connect, specifically impacting versions 10.0.8.0 through 10.0.8.12 and 12.1.0.0 through 12.1.1.2.\nThe vulnerability occurs due to improper sanitization of user-supplied input within directory queries, allowing an attacker to manipulate the structure of LDAP queries.\nA remote authenticated attacker can exploit this flaw to bypass tenant isolation boundaries, resulting in unauthorized administrative access to other tenants.\nThe risk is high, as the ability to traverse organizational boundaries grants the attacker elevated privileges and unauthorized administrative control over external environments.\nSuccessful exploitation requires the attacker to be authenticated, after which they can leverage malicious LDAP payloads to inject additional query parameters, effectively altering the logic of backend directory service lookups.\nThis represents a significant failure in access control, compromising the multi-tenant architecture of the affected systems.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient neutralization of input data processed by the directory service component within IBM API Connect. In the affected versions (10.0.8.0–10.0.8.12 and 12.1.0.0–12.1.1.2), the application fails to properly escape or sanitize user-supplied input before incorporating it into LDAP filter strings.\nWhen a user performs an action that triggers a directory search, the application dynamically constructs an LDAP query. If an authenticated user submits input containing special characters or LDAP control characters (such as parentheses, ampersands, or wildcards), they can terminate the intended filter and inject new logic. This is a classic LDAP injection pattern where the application's query logic is redirected by the attacker.\nThe attack flow proceeds as follows: First, the attacker establishes a legitimate session as an authenticated user. Second, the attacker interacts with a feature that performs an LDAP lookup, supplying a crafted payload designed to alter the query logic. Third, the manipulated query is sent to the backend directory service. Because the input is unsanitized, the directory service interprets the injected characters as valid query syntax, potentially bypassing the scope constraints intended to limit the user's search to their own tenant.\nBy manipulating the LDAP filter, the attacker can force the backend to return unauthorized entries. In the context of multi-tenant IBM API Connect environments, this manipulation allows the attacker to query objects belonging to other tenants. If the query parameters control administrative visibility or access tokens, the attacker may escalate their privileges to assume administrative control over these foreign tenants.\nThe vulnerability stems from the use of unsafe string concatenation when building filters, rather than utilizing parameterized LDAP queries or proper API-level character escaping routines. Because the system relies on the integrity of these directory queries to enforce tenant separation, the injection effectively breaks the logical isolation of the multi-tenant architecture. Post-exploitation, an attacker gains the ability to view, manage, or manipulate administrative resources across the platform, depending on the breadth of the directory's schema and the specific query context targeted by the injection."
}