x-ui CVE-2026-79317

Exploitation requires the attacker to already possess a valid admin session cookie issued by x-ui 0.3.2 BEFORE the administrator rotated the username or password; the vulnerability's entire value is that this stale cookie remains accepted afterward. The specific defect is that the full user object is stored in a client-side signed cookie and authentication only confirms a user object can be retrieved from it, with no re-validation against the database and no session-version/token-invalidation check. Limiting factors: the attacker must have obtained the cookie by some prior means (theft, leaked backup, shared session), and the flaw only matters where credential rotation was relied upon as remediation - hence CVSS AC:H. It does not enable a fresh unauthenticated login by an attacker with no cookie.

This is a genuine but modest-severity issue best characterized as post-rotation session persistence (CWE-613 insufficient session expiration), not the 'Information Disclosure' its tag implies. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N = 4.8 Medium) reflects the real constraint: while nominally 'unauthenticated' (PR:N) and network-reachable (AV:N), successful exploitation requires the attacker to already hold a valid pre-change admin cookie, which is exactly why AC:H is assigned - this is a stolen/retained-credential persistence flaw, not a fresh remote break-in. EPSS is low at 0.19% (8th percentile), there is no KEV listing, and no confirmed public exploit code (one reference is a third-party CVE writeup on TraceLoom, which is analysis rather than a verified weaponized POC). Signals are internally consistent: low EPSS + no KEV + niche product + precondition of prior cookie possession all point to a low-priority, non-widespread issue rather than an urgent threat. The main caveat is a metric tension - PR:N combined with AC:H is defensible only because the 'privilege' (a leaked admin cookie) is modeled as an attack precondition rather than an authentication requirement; teams treating credential rotation as their compromise-recovery control should note this flaw specifically defeats that control.

An admin's session cookie is captured (e.g., via prior compromise, shared workstation, or leaked backup) and later the admin rotates the username/password believing this evicts the attacker. Because x-ui 0.3.2 validates only that a user object can be deserialized from the signed cookie - never re-checking the database or a session version - the attacker replays the old cookie and retains full access to the management panel. No public exploit code is confirmed at time of analysis; exploitation requires no special tooling beyond replaying the retained cookie.