APIPark CVE-2026-108862

Exploitation requires a valid authenticated APIPark account that holds authorization-view permission on at least one application (PR:L), plus possession or enumeration of a foreign application's authorization UUID that the attacker supplies to the request (this is the AT:P attack requirement). The flaw is triggered against the /api/v1/app/authorization endpoint or its details route and exposes credentials regardless of the HideCredential setting, so no special non-default configuration is needed. Limiting factors: the attacker cannot be fully unauthenticated, must already hold the authorization-view permission, and must learn or guess another application's UUID - UUIDs are not sequentially enumerable, which meaningfully constrains opportunistic mass exploitation.

This is a genuine but moderate-severity authorization flaw, not a drop-everything emergency. The vendor/NVD CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H) scores 6.0 (MEDIUM) and is internally consistent with the description: network-reachable API endpoint, low attacker privileges (an authenticated user with authorization-view permission on one application), no user interaction, and high confidentiality impact (plaintext API keys) with zero integrity or availability impact. The AT:P (attack requirements present) metric is the key tempering signal - the attacker must supply a *foreign* authorization UUID, so successful exploitation depends on obtaining or enumerating another application's UUID rather than a trivially-indexed object ID. No EPSS score, CISA KEV listing, or explicit SSVC decision data was provided in the input, so exploitation-probability and automatability cannot be quantified here. The references include a public HackMD write-up and a direct link to the vulnerable source code (iml.go lines 451-511), which document the bug in detail but do not clearly constitute packaged exploit code; treat this as a well-documented vulnerability rather than confirmed weaponization. Net priority: a real, legitimate data-exposure issue warranting patching, but the authentication requirement, the need for a foreign UUID (AT:P), and the lack of integrity/availability impact place it well below critical remote-unauthenticated RCE class issues.

A low-privileged but authenticated APIPark user who holds authorization-view permission on their own application calls the /api/v1/app/authorization endpoint (or its details route) while supplying another application's authorization UUID. Because the server does not verify that the requested authorization belongs to the caller's application, it returns the other application's plaintext API keys even when HideCredential is set. No public packaged exploit was identified, but the vulnerable code path and technique are publicly documented in the referenced HackMD advisory and GitHub source.