CVE-2026-79317: Session Invalidation Flaw in x-ui 0.3.2

Summary

CVE-2026-79317 describes a session invalidation vulnerability in x-ui version 0.3.2. The application stores the full user object inside a client-side signed cookie and performs authentication by merely verifying that a user object can be retrieved from that cookie. Because the system does not re-validate the user against the database or check any session version, previously issued session cookies remain valid even after an administrator changes the username or password. An attacker who obtained an administrative session cookie before the credential rotation can continue operating the management interface indefinitely.

Technical Analysis

The vulnerability is classified under CWE-613, which covers insufficient session expiration. In a properly designed authentication system, a server-side session store maintains authoritative records of who is logged in, and credential changes such as a password reset or username modification should invalidate all outstanding sessions. x-ui 0.3.2 deviates from this model by delegating session state entirely to a signed cookie that contains the complete user object.

When a user authenticates, the application serializes the user object, signs it, and places it in a cookie returned to the client. On subsequent requests, the server checks whether the cookie signature is valid and whether a user object can be deserialized from it. If both checks pass, the request is treated as authenticated. There is no lookup against the database to confirm that the user still exists with the same credentials, and there is no session version or token rotation mechanism that would allow the server to distinguish a pre-change cookie from a post-change cookie.

The CVSS 3.1 vector for this vulnerability is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, resulting in a base score of 4.8 and a MEDIUM severity rating. The network attack vector means the flaw can be exploited remotely, but the high attack complexity reflects that an attacker must first obtain a valid session cookie through some other means, such as prior compromise, cookie theft, or access to a logged-in browser. No privileges are required and no user interaction is needed, but the impact is limited to low confidentiality and low integrity changes with no availability impact.

The core problem is that the signed cookie functions as both a session identifier and an identity proof, but it is never tied to a server-side revocation list or a monotonically increasing session version. Signing the cookie guarantees integrity, but it does not guarantee freshness. Once a cookie is issued, it remains cryptographically valid until the signing key itself is rotated, which is an operational action outside the normal credential-change workflow.

Affected Software and Versions

Vendor: (not specified in NVD data)
Product: x-ui
Affected version: 0.3.2

The NVD entry does not list a specific vendor name or identify other affected versions. Only x-ui 0.3.2 is confirmed as affected by the description.

Impact

The primary impact of CVE-2026-79317 is persistent unauthorized administrative access following a credential rotation. In incident response scenarios, administrators commonly change passwords and usernames believing that doing so will evict any attacker who has gained access. This vulnerability defeats that remediation step for x-ui 0.3.2.

Specific impacts include:

Confidentiality (Low): An attacker with a pre-change cookie can continue viewing management interface data, configuration details, and user information after credentials are rotated.
Integrity (Low): The attacker can continue making changes through the management interface, including modifying settings or performing administrative actions, because the old cookie is still accepted as a valid session.
Availability (None): The vulnerability does not directly cause denial of service.

The practical severity is higher than the CVSS score might suggest in situations where an attacker has already compromised an administrative account and the defender relies on password rotation as the primary containment measure. In those cases, the attacker retains access silently, undermining incident response and prolonging the exposure.

Exploitation Scenario

Consider a deployment of x-ui 0.3.2 used to manage a proxy or VPN panel. An attacker gains access to an administrator’s session cookie, perhaps through XSS on a related subdomain, a compromised browser extension, log file exposure, or physical access to a workstation. The attacker can now operate the management interface.

The legitimate administrator detects suspicious activity and responds by changing the admin username and password. Under normal expectations, this action should invalidate the attacker’s session and force re-authentication. However, because x-ui 0.3.2 stores the full user object in a signed cookie and never checks a server-side session store or session version, the attacker’s previously issued cookie continues to be accepted.

The attacker, still holding the old cookie, can continue to access the management interface, view configurations, and perform administrative actions. The defender believes the incident has been contained, but the attacker retains persistent access. This scenario is particularly dangerous because the defender’s remediation actions create a false sense of security.

Exploitation does not require any special tooling beyond the ability to send HTTP requests with the stolen cookie attached. The attack complexity rated as high in the CVSS vector reflects the prerequisite of obtaining a valid cookie, not the difficulty of using it after credential rotation.

Detection and Mitigation

Detection

Detecting exploitation of this vulnerability is difficult because the attacker uses a cookie that was legitimately issued. Standard authentication logs may show the original login but will not necessarily flag continued use of a pre-change cookie as anomalous. Defenders should look for:

Administrative actions performed after a credential change by sessions that should have been invalidated.
Requests bearing session cookies that do not correspond to any current server-side session record, if such records are logged.
Unusual access patterns from IP addresses or user agents that differ from the legitimate administrator’s typical behavior.
Configuration changes or administrative actions occurring after a known password rotation event.

Mitigation

Because the vulnerability is in the application’s session handling design, the most effective mitigations involve changes to how sessions are managed. Recommended steps include:

Rotate the cookie signing key: Changing the signing key invalidates all existing signed cookies, including those held by an attacker. This should be performed immediately after any credential change as a compensating control.
Restart the x-ui service: If session state is held in memory and cookies are validated against in-memory records, restarting the service may clear outstanding sessions. Verify whether this is effective for the specific deployment.
Deploy a reverse proxy with session management: Placing x-ui behind a reverse proxy that enforces its own server-side sessions can prevent stale cookies from being accepted, provided the proxy does not simply forward the original cookie.
Restrict network access: Limit access to the management interface to trusted IP ranges or VPN-only networks to reduce the window of opportunity for an attacker holding a stale cookie.
Monitor for post-rotation activity: After changing credentials, closely monitor the management interface for any activity. If activity continues, assume the session invalidation flaw is being exploited and take additional containment steps.
Upgrade or patch: Check for updated versions of x-ui that implement server-side session validation or session versioning. The NVD data does not specify a fixed version, so consult the project repository for updates.

Bug Bounty Angle

For bug bounty hunters and security researchers, CVE-2026-79317 illustrates a class of vulnerability that is often overlooked: session lifecycle flaws where credential changes do not invalidate existing sessions. When testing applications that use signed cookies or JWTs for authentication, researchers should investigate what happens to existing tokens after a password change, username change, or account merge.

Key testing approaches relevant to this vulnerability class include:

Authenticate as a user and capture the session cookie or token.
Change the password or username for that account.
Attempt to use the original cookie or token after the credential change.
If the old token is still accepted, the application has a session invalidation flaw similar to CVE-2026-79317.

This vulnerability also highlights the risk of storing full user objects in client-side tokens. Even when the token is signed or encrypted, it can become stale if the server does not maintain a revocation mechanism. Researchers should examine whether the application performs any server-side validation of the token contents against current database records.

Bug bounty programs that cover authentication and session management should explicitly include test cases for post-credential-change session invalidation. This vulnerability demonstrates that such flaws can have real security impact, particularly in incident response scenarios where defenders rely on password rotation for containment.

Frequently Asked Questions

What is CVE-2026-79317?

CVE-2026-79317 is a session invalidation flaw in x-ui 0.3.2 where signed client-side cookies containing the full user object are not revoked after an administrator changes the username or password, allowing continued access with pre-change session cookies.

What is the CVSS score and severity?

The vulnerability has a CVSS 3.1 base score of 4.8 with MEDIUM severity. The vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, indicating network-based exploitation with high attack complexity and low confidentiality and integrity impact.

How can I mitigate this vulnerability?

Rotate the cookie signing key after any credential change, restrict network access to the management interface, monitor for post-rotation administrative activity, and check for patched versions of x-ui that implement server-side session validation or session versioning.