CVE-2026-72001 is a high severity (CVSS 8.1) authentication bypass in Pangolin before 1.22.0. A person holding one valid share link can authenticate to any other resource, across organizations, bypassing SSO, passwords, PINs and email allowlists. The fix is Pangolin 1.22.0.
What's affected
Pangolin versions before 1.22.0, fixed in 1.22.0, according to the record, VulnCheck and the project's release page.
The weakness is CWE-639, authorization bypass through a user-controlled key. The share-link authentication endpoint accepts a URL parameter chosen by the caller and calls token verification without the expected resource identifier. A valid token for one resource is therefore accepted for another. The advisory says this bypasses all configured authentication methods: SSO, resource passwords, PIN codes, email allowlists and header authentication.
Severity differs by source: the record scores 8.1 high, and VulnCheck lists 8.6, high, using CVSS 4.0.
The record's vector shows low privileges required, since the attacker needs one valid share link. VulnCheck describes the attacker as unauthenticated but holding a single valid share link, which is the same condition in different words.
How to check if you're exposed
Check your Pangolin version. On a Docker deployment, read the image tag:
docker ps --format '{{.Image}}' | grep -i pangolin
Anything before 1.22.0 is affected. Then look at how widely you use share links. Anyone who ever received a share link, from a customer, a contractor or a former employee, holds the starting condition for this attack.
Review access logs for the share-link authentication endpoint for requests that name resources the token holder was not given.
free in-browser dependency scan reads manifests and shows known vulnerabilities for the components in your stack.
What to do now
- Check your Pangolin version and upgrade to 1.22.0 or later.
- Inventory active share links, and revoke those that are not needed.
- Review access logs for share-link authentication requests that cross resource boundaries.
- Check which resources hold sensitive data and review who accessed them since the share link feature was in use.
- Rotate resource passwords and PINs where you suspect exposure.
Why it matters
CWE-639 describes a server that lets the caller choose which object to act on. Here the check is not missing entirely, which makes it subtle: the token is verified, but not against the resource it is being used for. A key that opens one door was accepted for every door.
Access proxies like Pangolin sit in front of private applications, so a bypass there removes every protection behind it, including SSO. That is why a bug in one small endpoint can undo the whole authentication model.
Quick check
Do I need to be a Pangolin user to exploit this?
The advisory says an attacker needs one valid share link for any resource. After that they can authenticate to resources across organizations.
Sources
Last reviewed: 18 October 2026.
