CVE-2026-111680 is a high severity (CVSS 8.3) authorization bypass in APIPark through 1.9.7-beta. An authenticated team manager can supply their own team ID and then read, change or delete other teams' services and applications. The record names no fixed version.
What's affected
APIPark 1.9.7-beta and earlier, per the record and VulnCheck. The record points to the service and app endpoints, including the simple listing routes that expose IDs and the service info and app endpoints that act on them. I could not confirm a fixed release from the pages I fetched, so check the project's releases and issue tracker before you rely on one.
Any deployment with more than one team is affected, because the flaw crosses the team boundary.
Scoring note: the record's 8.3 is a CVSS 3.1 base score. VulnCheck's advisory also lists 7.2 under CVSS 4.0. Both describe the same flaw, and the two versions weigh the factors differently.
How to check if you're exposed
Check your APIPark version. Review which teams exist and who holds the manager role. Then audit changes to services and applications in the last weeks, looking for edits or deletions made by a manager from a different team.
If your platform keeps audit logs, filter by the acting user's team versus the team that owns the changed resource.
What to do now
- Find every APIPark deployment and its version.
- List team managers and remove the role where it is not needed.
- Audit recent service and app changes for cross team activity.
- Restore any service or app that was modified or removed without cause.
- Upgrade when a confirmed fix is released.
- Scan your dependencies with the free in-browser scan and look the CVE up in the Gold directory to see where else it appears.
Do not stop at one host. Write down every place the affected software runs, including test servers, forgotten containers and copies bundled inside other products. Then rank them by exposure: anything reachable from the internet comes first, internal systems next. A short inventory now saves hours when the next advisory lands.
Why it matters
This is CWE-639, authorization bypass through a user-controlled key. The server trusts a team identifier supplied in the request instead of deriving it from the signed in user. Anyone who can change the value can act as a different team.
The record notes attackers learn target IDs from listing endpoints, so the lookup step is easy. In a shared API gateway, losing tenant isolation means one team can break another team's live services. It is not listed in CISA KEV.
Quick check
Is this a multi-tenant issue?
Yes. The record describes managers of one team reaching another team's services and apps.
What fixes this class of bug?
Derive the tenant from the session on the server and check ownership on every object access.
Sources
Last reviewed: 18 October 2026.
