Nango CVE-2026-102596

Exploitation requires ALL of: (1) the Nango account is on a plan with RBAC enabled (has_rbac=true); (2) the attacker already holds a valid authenticated session as a same-team user with the development_full_access role; and (3) the request targets the two unguarded private routes GET /api/v1/integrations/:providerConfigKey/flows or GET /api/v1/flow/:flowName with the query parameter env=prod. Limiting factors that reduce real-world risk: it demands a pre-existing authenticated in-tenant account (no anonymous access), affects only Nango versions prior to 0.70.9, is gated behind the RBAC plan feature, and does NOT cross tenant boundaries (res.locals.environment derives from the authenticated account) - the impact is confined to reading production flow metadata/configuration, with no write, no integrity, and no availability effect.

This is a genuine but modest-severity authorization flaw, and the available signals are internally consistent. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3) indicates a network-reachable, low-complexity attack requiring low privileges (an authenticated same-team user), with only a limited confidentiality impact and no integrity or availability effect - which matches the description of reading production flow metadata/configuration across a role boundary. No EPSS score, CISA KEV listing, POC reference, or SSVC decision data was provided in the input, so there is no signal of active exploitation or published exploit code. CWE-862 (Missing Authorization) aligns with the root cause: two private routes applied webAuth but omitted the can({action:'read', resource:'flow', scopedBy:envScope}) check. Treating this as a real but low-priority issue is appropriate: it is an insider/same-tenant privilege boundary bypass (dev role reading prod), not a cross-tenant breach and not remote-unauthenticated RCE. The classic 'high CVSS but low real risk' trap does not apply here because the CVSS is already low (4.3); conversely, do not over-prioritize it - exploitation requires an existing authenticated account with the development_full_access role on an RBAC-enabled plan. No key signals conflict; the main gap is the absence of EPSS/KEV/POC data, so exploitation likelihood cannot be quantified beyond noting none is evidenced.

On a Nango instance (self-hosted or managed) running a plan with has_rbac=true, a team member holding the development_full_access role - who is intended to be confined to development environments - sends an authenticated GET request to /api/v1/integrations/:providerConfigKey/flows or /api/v1/flow/:flowName with env=prod. Because these routes checked only webAuth and not the scoped 'read flow' permission, the server returns production integration flow metadata or named flow configuration that the user's role should not reach. No public exploit code is referenced in the input, and the attack requires a pre-existing authenticated same-team account, so it is an insider-style confidentiality bypass rather than a remote-unauthenticated compromise.