IBM is urging customers to quickly patch a critical vulnerability in its API Connect platform that could allow remote attackers to bypass authentication.

The company describes API Connect as a full lifecycle application programming interface (API) gateway used “to create, test, manage, secure, analyze, and socialize APIs.”

It particularly touts it as a way to “unlock the potential of agentic AI” by providing a central point of control for access to AI services via APIs. The platform also includes API Agent, which automates tasks across the API lifecycle using AI.

A key component is a customizable self-service portal that allows developers to easily onboard themselves, and to discover and consume multiple types of API, including SOAP, REST, events, ASyncAPIs, GraphQL, and others.

The flaw, tracked as CVE-2025-13915, affects IBM API Connect versions 10.0.8.0 through 10.0.8.5, and version 10.0.11.0, and could give unauthorized access to the exposed applications, with no user interaction required.

An architectural assumption is broken

“CVE-2025-13915 is not best understood as a security bug,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “It is better understood as a moment where a long standing architectural assumption finally breaks in the open. The assumption is simple and deeply embedded in enterprise design: If traffic passes through the API gateway, identity has been enforced and trust has been established. This vulnerability proves that assumption can fail completely.”

He noted that the classification of the weakness, which maps to CWE-305, is important because it rules out a whole class of what he called comforting explanations. “This is not stolen credentials. It is not role misconfiguration. It is not a permissions mistake,” he said. “The authentication enforcement itself can be circumvented.”

When that happens, he explained, downstream services do not simply face elevated risk, they lose the foundation on which their access decisions were built because they do not revalidate identity. They were never designed to; they inherit trust.

“Once enforcement fails upstream, inherited trust becomes unearned trust, and the exposure propagates silently,” he said. “This class of vulnerability aligns with automation, broad scanning, and opportunistic probing rather than careful targeting.”

Interim fixes provided

IBM said that the issue was discovered during internal testing, and it has provided interim fixes for each affected version of the software, with individual update details for VMware, OCP/CP4I, and Kubernetes.

The only mitigation suggested for the flaw, according to IBM’s security bulletin, is this: “Customers unable to install the interim fix should disable self-service sign-up on their Developer Portal if enabled, which will help minimize their exposure to this vulnerability.”

The company also notes in its installation instructions for the fixes that the image overrides described in the document must be removed when upgrading to the next release or fixpack.

This, said Gogia, further elevates the risk. “That is not a cosmetic detail,” he noted. “Management planes define configuration truth, lifecycle control, and operational authority across the platform. When remediation touches this layer, the vulnerability sits close to the control core, not at an isolated gateway edge. That raises both blast radius and remediation risk.”

This is because errors in these areas can turn into prolonged exposure or service instability. “[Image overrides] also introduce a governance hazard: Image overrides create shadow state; if they are not explicitly removed later, they persist quietly,” he pointed out. “Over time, they drift out of visibility, ownership, and audit scope. This is how temporary fixes turn into long term risk.”

Most valuable outcome: Learning

He added that the operational challenges involved in remediation are not so much in knowing what has to be done, but in doing it fast enough without breaking the business. And, he said, API governance now needs to include up to date inventories of APIs, their versions, dependencies, and exposure points, as well as monitoring of behavior.

“The most valuable outcome here is not closure,” Gogia observed. “It is learning. Enterprises should ask what would have happened if this flaw had been exploited quietly for weeks. Which services would have trusted the gateway implicitly? Which logs would have shown abnormal behavior? Which teams would have noticed first? Those answers reveal whether trust assumptions are visible or invisible. Organizations that stop at patching will miss a rare opportunity to strengthen resilience before the next control plane failure arrives.”