CVE-2025-4644: Payload's SQLite adapter Session Fixation vulnerability

The vulnerability, described as a Session Fixation issue in Payload's SQLite adapter, stems from the reuse of identifiers for newly created accounts after an old account is deleted. The core of the problem was the application's use of stateless JSON Web Tokens (JWTs) for authentication. These JWTs were tied only to a user ID. When an attacker created an account, obtained a JWT, and then deleted that account, the JWT remained cryptographically valid. Due to the ID reuse in SQLite, when a new user registered, they could be assigned the same ID as the deleted user. The attacker could then use their old, still-valid JWT to authenticate as this new, unrelated user.

The security patch addresses this fundamental design flaw by transitioning from stateless JWTs to a stateful, session-based authentication mechanism. My analysis of the commit 26d709dda6e512ce347557eaa2057db6e0cbf809 reveals the following key changes:

1. Session Creation on Login: The loginOperation is updated to create a unique, server-side session for the user upon successful login. This session has its own unique ID (sid), which is then embedded into the JWT.

2. Session Validation during Authentication: The JWTAuthentication strategy, which validates incoming requests, is modified to not only verify the JWT's signature but also to check that the sid within the token corresponds to an active session stored in the user's database record. If no active session is found for that sid, authentication fails, even if the token's signature is valid.

3. Session Invalidation on Logout: The logoutOperation is enhanced to actively delete the session from the database. This server-side invalidation ensures that even if a JWT is compromised, it becomes useless the moment the user logs out.

This new session management system effectively mitigates the vulnerability. Even if a user ID is reused, an old JWT is useless because its associated session ID (sid) would have been deleted from the database either upon logout or when the original user account was deleted. The identified vulnerable functions (loginOperation, JWTAuthentication, logoutOperation) are the core components of the authentication flow whose previous, stateless logic enabled this vulnerability.