Psono Server CVE-2026-117468

The attacker must already hold a valid authenticated Psono session derived from a restricted API key (a token intentionally limited in write scope and/or lifetime), and must be able to supply and claim a device code they control via the device-code claim flow. The underlying defect is that the permission class on the device-code claim path does not enforce the token's write scope. Limiting factors that reduce realistic risk: exploitation requires an existing authenticated restricted session (PR:L, not unauthenticated), it does NOT bypass two-factor authentication, and it does NOT directly disclose plaintext secrets; it affects Psono Server versions 5.3.5 through 7.2.3 only.

This is a genuine but moderate-priority privilege-escalation issue rather than a critical emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, base 6.5) shows network reach and low attack complexity, but PR:L is decisive: the attacker must already hold a valid authenticated session derived from a restricted API key before anything can happen, so this is a post-foothold scope-escalation, not an entry point. Impact is integrity-only (C:N/A:N) - the flaw grants an unrestricted read-write session but, per the description, does not bypass two-factor authentication or directly disclose plaintext secrets. Exploitation signals are consistently low-to-moderate and do not conflict: EPSS is 0.47% (40th percentile), there is no CISA KEV listing (not actively exploited), and no public exploit identified at time of analysis. The vuln.today decision label is 'this_month', consistent with a real fix that should be scheduled rather than rushed. Net: a legitimate privilege-management weakness (CWE-269) worth patching on a normal cycle, not a high-CVSS-but-illusory risk, but also not an emergency given the authentication prerequisite and absence of exploitation evidence.

An attacker who already possesses a deliberately restricted (e.g., read-only, scope- and lifetime-limited) API key-derived session claims an attacker-controlled device code. Because the permission class fails to enforce the token's write scope during the device-code claim, the attacker is issued a full read-write session valid for up to 365 days, escalating well beyond the original token's intended limits. No public exploit identified at time of analysis; the trigger is reachable remotely with low complexity but requires the pre-existing authenticated session.