TencentCloud Octop CVE-2026-108581

Requires a valid authenticated low-privileged Octop account/JWT (PR:L) - not exploitable by fully unauthenticated attackers - and requires that one or more LLM or voice provider API keys have actually been configured and stored in the instance. The practical exposure applies to multi-user or multi-tenant deployments where low-privileged users exist who should not have access to provider credentials; in a single-operator install the data is only readable by its legitimate owner. The limiting factor is that the two endpoints still enforce JWT validity (authentication succeeds) but perform no per-role or per-owner authorization check, so any authenticated session is sufficient. No special non-default configuration, platform, or user interaction is needed beyond holding a token.

This is a genuine, moderately-high-priority confidentiality flaw rather than a CVSS-inflated non-issue, but its real-world urgency is tightly bounded by the authentication requirement. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N, 7.1 High) is internally consistent with the description: network-reachable endpoints, no user interaction, low attacker effort, and high confidentiality impact (plaintext API key disclosure) with no integrity or availability impact. The key limiting signal is PR:L - exploitation requires a valid authenticated low-privileged account, so this is not a pre-auth mass-exploitable bug. No EPSS score, CISA KEV listing, or formal exploit code is present in the input, so there is NO evidence of active or widespread exploitation; the vulnerability is best treated as an insider/post-compromise privilege-and-data-exposure issue. A detailed public technical writeup (hackmd) and a VulnCheck advisory exist, which raises the practical likelihood that a working reproduction is or will become available even though packaged exploit code is not confirmed. SSVC-style read: exploitation = none observed, automatable = yes (simple authenticated GET requests, no special preconditions beyond a token), technical impact = partial-to-total for the exposed credentials. Net: prioritize for multi-user/multi-tenant Octop deployments where low-privileged accounts exist and provider keys are stored; de-prioritize for single-operator installs.

An attacker who holds or phishes any low-privileged Octop account (or an authorized but untrusted tenant user) sends authenticated GET requests to /api/providers and /api/voice/providers; because these endpoints validate only the JWT and not the caller's role or ownership, they return the stored LLM and voice provider API keys in plaintext. The attacker then uses those upstream credentials to run up charges, exfiltrate data, or pivot into the connected provider accounts. No packaged public exploit is confirmed, but a public technical writeup describing the cross-role read exists.