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 perform unauthorized actions and obtain sensitive information due to missing authorization. Certain operations do not verify that the user is permitted to act on the targeted resource, which could allow other users' API keys to be deleted.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-11-07T05:18:33.240Z",
  "pubdate": "2026-11-07T05:18:33.240Z",
  "executiveSummary": "IBM API Connect versions 10.0.8.0 through 10.0.8.12 and 12.1.0.0 through 12.1.1.2 are susceptible to an improper authorization vulnerability. This flaw arises because specific operations fail to enforce mandatory access control checks on target resources. Consequently, a remote authenticated attacker can perform unauthorized actions, including the deletion of API keys belonging to other users. The vulnerability poses a significant security risk, as it permits unauthorized state changes and potential information disclosure within the API management environment. Exploitation requires the attacker to possess authenticated access to the system, after which they can bypass intended authorization constraints to manipulate resources outside their authorized scope.",
  "technicalDetails": "The vulnerability originates from a missing authorization check within the API management framework of IBM API Connect. In standard secure operation, the application should validate that the authenticated user identity possesses the requisite permissions to perform specific CRUD (Create, Read, Update, Delete) operations on a targeted resource. However, in the affected versions, the application fails to verify the subject's authorization context before executing requests against sensitive resources.\nThe attack flow proceeds as follows: 1) The attacker establishes a legitimate, authenticated session within the IBM API Connect platform. 2) The attacker identifies a target resource identifier (e.g., another user's API key ID) through enumeration or prior knowledge. 3) The attacker crafts a malicious request targeting the management API endpoint responsible for resource deletion. 4) The application processes the request; because the internal logic lacks the necessary authorization verification logic, the system assumes the caller is authorized to modify the target resource. 5) The backend database or resource manager executes the deletion command, resulting in the successful removal of a third-party API key.\nThe vulnerable component involves the internal API authorization layer that manages administrative or resource-specific operations. Because the validation logic is omitted, the system cannot distinguish between a legitimate request from an owner and an unauthorized request from a peer user. This breach of broken access control (BAC) allows an attacker to manipulate the API lifecycle of other users, potentially leading to widespread service disruption or the invalidation of security credentials.\nThe scope of impact is restricted to authenticated users, meaning the platform must allow user access for the vulnerability to be triggered. However, since the system does not enforce isolation between user contexts, an attacker with low-level privileges can escalate their impact by manipulating system resources. The lack of authorization checks essentially bypasses the multi-tenant or multi-user isolation mechanisms expected in an enterprise API gateway environment."
}