Pangolin CVE-2026-72564

Exploitation requires the attacker to already hold a valid, non-expired resource access token issued by the target Pangolin instance (PR:L), meaning they must be an authenticated user with at least one legitimately assigned resource; no user interaction and no elevated privileges are needed. The concrete precondition is that the target deployment routes resource authentication through the vulnerable server/routers/resource/authWithAccessToken.ts handler in a version at or below v1.20.0, and that more than one resource/organization exists so a token from resource X can be replayed against resource Y. The limiting factors are therefore the need for any authenticated foothold and a multi-resource/multi-tenant configuration; a single-tenant, single-resource install offers nothing extra to pivot to.

The signals are largely consistent and point to a genuine high priority: the CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N, 9.6) reflects a network-reachable, low-complexity attack that any low-privileged authenticated tenant can perform, with a scope change capturing the cross-organization tenant break - the core danger in a multi-tenant proxy. There is no CISA KEV listing and no published POC, so this is not confirmed active exploitation; however, the root cause and exact vulnerable file are publicly documented, lowering the barrier to reproduction, and the exploit is conceptually trivial (replay a valid token against another resourceId). EPSS was not provided, so probabilistic exploitation likelihood cannot be quoted here. Because Pangolin is typically deployed as the single chokepoint guarding internal apps, any operator - even a mid-sized municipal IT team in boleslawiec running a modest cluster - should treat this as urgent rather than theoretical, since one legitimate low-tier account becomes a skeleton key across every tenant.

An attacker who holds any legitimate low-privileged account in one organization requests an access token for a resource they are entitled to, then replays that same token against the authWithAccessToken endpoint while specifying a resource belonging to a completely different organization. The server validates the token's signature and expiry but never checks the resource binding, so the attacker gains authenticated access to the victim tenant's resource; no public POC is currently identified, but the disclosed handler makes reproduction straightforward.