Description

Peppermint through 0.5.5 contains an authorization bypass vulnerability in the GET /api/v1/auth/user/:id/logout endpoint that allows authenticated attackers to delete sessions for any user by supplying arbitrary user IDs. Attackers can forcibly log out any user including administrators by calling the logout handler with another user's ID, since the endpoint performs no authorization checks to verify the caller owns the target account.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-03T19:17:30.970Z",
  "pubdate": "2026-09-03T19:17:30.970Z",
  "executiveSummary": "Peppermint versions through 0.5.5 are affected by an authorization bypass vulnerability located within the session management API.\nThe vulnerability resides in the GET /api/v1/auth/user/:id/logout endpoint, which fails to implement server-side access control checks.\nThis flaw allows an authenticated attacker to perform a forced logout of any user, including administrative accounts, by manipulating the :id parameter in the request URI.\nThe impact is significant as it facilitates unauthorized session termination, leading to potential denial of service for targeted users and disruption of administrative operations.\nExploitation requires the attacker to possess a valid session on the application but does not necessitate elevated privileges, as the system does not validate the relationship between the session owner and the requested target ID.\nThe vulnerability represents a failure in horizontal and vertical authorization, where the API endpoint assumes that any authenticated request is authorized to modify the state of arbitrary user sessions.",
  "technicalDetails": "The root cause of this vulnerability is an insecure implementation of authorization logic within the backend handler for the GET /api/v1/auth/user/:id/logout endpoint. The application processes requests to terminate user sessions by taking an integer or string identifier provided in the URI path without verifying the requester's ownership of that specific identifier.\nIn a secure implementation, an API endpoint managing sensitive user resources must cross-reference the session token of the requester against the target resource ID stored in the backend database or session store. Peppermint fails to perform this verification, allowing an attacker with a low-privilege account to supply any arbitrary user ID (e.g., the ID of a platform administrator) to the endpoint.\nThe attack flow proceeds as follows: 1) An attacker authenticates to their own account to obtain a valid session cookie or token. 2) The attacker identifies the target user ID, which may be discovered through other endpoints or predictable enumeration. 3) The attacker crafts a request to GET /api/v1/auth/user/[target_id]/logout. 4) The application parses the request, identifies the endpoint as a session destruction trigger, and executes the associated cleanup function for the provided [target_id] without checking if the session context corresponds to the [target_id]. 5) The server destroys the session associated with the [target_id], effectively logging out the legitimate user.\nBecause the endpoint is a GET request, it is particularly susceptible to various exploitation vectors, including Cross-Site Request Forgery (CSRF). If an attacker can convince a user (or administrator) to visit a malicious site while logged into the Peppermint instance, the browser will automatically include the necessary session cookies in the background request to the logout handler, causing an involuntary session termination.\nThe scope of this vulnerability extends across all authenticated sessions within Peppermint through version 0.5.5. The lack of granular authorization checks at the API controller level allows for total session management manipulation. Post-exploitation, the victim is immediately disconnected from the application, which may disrupt active workflows, cause loss of unsaved state, or be used in conjunction with other attacks to prevent administrators from reacting to security incidents."
}