CVE-2026-102596 in Nango
Summary
by MITRE • 10/13/2026
Nango is an open-source platform for connecting agents and products to third-party APIs. Prior to 0.70.9, on accounts with RBAC enabled through a plan with has_rbac=true, two private flow-read routes, GET /api/v1/integrations/:providerConfigKey/flows and GET /api/v1/flow/:flowName, apply webAuth but omit can({ action: 'read', resource: 'flow', scopedBy: envScope }). A same-team user with the development_full_access role can therefore request env=prod and read production integration flow metadata or named flow configuration despite being denied by guarded production routes. Both controllers use res.locals.environment from the authenticated account, so the issue bypasses the production role boundary but does not cross tenant boundaries. This issue is fixed in version 0.70.9 and managed-1.5.11-0.70.8-aae30d044d7e229807d51a3957c212f3fb689e1a
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability identified in Nango, an open-source platform designed to facilitate connections between agents and products via third-party APIs, represents a critical authorization flaw within its Role-Based Access Control implementation. This issue specifically affects deployments where RBAC is enabled through plans that include the has_rbac flag set to true. The core of the problem lies in two specific API endpoints: GET /api/v1/integrations/:providerConfigKey/flows and GET /api/v1/flow/:flowName. While these routes correctly implement web authentication, they fail to enforce proper authorization checks for resource-specific scopes. Specifically, the controllers do not invoke the necessary can check with the action set to read and the resource type defined as flow, scoped by the environment variable. This omission creates a significant gap in access control logic that allows users to bypass intended restrictions on production environments.
From a technical perspective, the flaw stems from how the application handles environmental context during request processing. Both affected controllers rely on res.locals.environment derived from the authenticated account's configuration rather than validating whether the user has explicit permission to read flow metadata or named flow configurations within that specific environment scope. Consequently, a user possessing the development_full_access role can manipulate the env parameter in their requests to target production environments. Although these users are explicitly denied access by guarded production routes elsewhere in the application architecture, this particular bypass allows them to retrieve sensitive integration flow metadata and configuration details from production without triggering standard denial mechanisms. The vulnerability effectively circumvents the intended separation between development and production roles within the same team boundary.
The operational impact of this vulnerability is substantial for organizations relying on Nango to manage API integrations securely. By exploiting this flaw, an attacker with legitimate but limited credentials can exfiltrate sensitive configuration data from production environments. This includes details about how third-party APIs are connected, potentially revealing authentication tokens, endpoint URLs, and other integration-specific parameters that could be leveraged for further attacks such as credential stuffing or service disruption. It is important to note that the vulnerability does not cross tenant boundaries; it is confined to users within the same team who have been granted development-level access but can escalate their privileges to read production resources due to this logic error. This scenario highlights a classic case of insecure direct object references combined with broken access control, where environmental context is manipulated to bypass security controls.
In terms of industry standards and threat modeling, this vulnerability aligns closely with CWE-284, which describes Improper Access Control, specifically involving the failure to enforce proper authorization checks for specific resources or scopes. Furthermore, it maps to MITRE ATT&CK technique T1078, Valid Accounts, as an attacker uses legitimate credentials but exploits a flaw in how those accounts are authorized to access different resource states. The ability to read production configurations from a development context also touches upon aspects of data exfiltration and reconnaissance within the internal network or application layer. Understanding these mappings helps security teams contextualize the severity and prioritize remediation efforts based on established frameworks for vulnerability management.
To mitigate this risk, organizations must immediately upgrade Nango to version 0.70.9 or later, which includes the necessary code changes to enforce proper authorization checks on the affected endpoints. For managed deployments, updating to version managed-1.5.11-0.70.8-aae30d044d7e229807d51a3957c212f3fb689e1a is required. In addition to upgrading, security teams should review their RBAC policies to ensure that role definitions strictly adhere to the principle of least privilege. It is advisable to implement automated testing for access control logic, particularly focusing on environmental scoping and resource-level permissions. Regular audits of API endpoint configurations can help detect similar oversights where authentication is present but authorization checks are incomplete or incorrectly scoped. Maintaining strict separation between development and production environments in both configuration and code deployment processes further reduces the attack surface associated with such vulnerabilities.