CVE-2026-17405 in API Connect
Summary
by MITRE • 11/07/2026
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 obtain sensitive information due to broken object-level authorization. Access checks on keystore objects do not confirm that the requesting user is permitted to read them, which could expose keystore information.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/07/2026
The vulnerability identified in IBM API Connect versions 10.0.8.0 through 10.0.8.12 and 12.1.0.0 through 12.1.1.2 represents a critical failure in access control mechanisms, specifically categorized under Broken Object Level Authorization (BOLA). This class of vulnerability is widely recognized as CWE-639 within the Common Weakness Enumeration framework, indicating that the application fails to properly verify whether the authenticated user has permission to perform actions on specific data objects. In this instance, the flaw resides in the handling of keystore objects, which are critical components used for storing cryptographic keys and certificates essential for secure communications. The core technical issue is a lack of rigorous validation during access requests, where the system accepts input from an authenticated user without confirming that the user owns or has explicit rights to view the targeted keystore resources.
From an operational perspective, this deficiency allows any remote attacker who possesses valid credentials for the API Connect platform to enumerate and retrieve sensitive cryptographic material belonging to other users or administrative accounts. By manipulating object identifiers in their requests, a malicious actor can bypass intended isolation boundaries between tenants or user profiles. The exposure of keystore information is particularly severe because these assets often contain private keys used to sign tokens, encrypt data, or establish mutual TLS connections. Compromise of such material does not merely result in the leakage of static secrets but potentially enables further attacks including session hijacking, impersonation of other users, and decryption of intercepted communications that were assumed to be secure due to encryption.
The impact extends beyond simple information disclosure as it undermines the fundamental trust model of the API management platform. Attackers leveraging this vulnerability can achieve unauthorized access to sensitive business logic protected by these keys or facilitate man-in-the-middle attacks against internal services relying on compromised certificates. This aligns with MITRE ATT&CK technique T1530, Data from Information Repositories, and potentially T1552, Unsecured Credentials, as the attacker extracts credentials that are not stored in a standard password database but rather within cryptographic stores. The ability to read arbitrary keystores effectively breaks multi-tenancy security guarantees if present, allowing lateral movement across different organizational units or customer environments hosted on the same infrastructure.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary solution is to apply the vendor-provided patches that update the access control logic for keystore endpoints to enforce strict ownership verification before granting read permissions. Administrators should ensure all instances are updated to versions beyond 10.0.8.12 or 12.1.1.2 where this flaw has been resolved. In addition to patching, organizations should implement robust input validation and authorization checks at the application layer for any API endpoint handling sensitive resources. Regular security audits focusing on object-level permissions are recommended to detect similar patterns in other modules of the platform. Furthermore, adopting a principle of least privilege ensures that even if such vulnerabilities exist, the scope of potential damage is limited by restricting user access rights to only those keystores strictly necessary for their specific operational roles.