CVE-2026-111353 in Peppermint
Summary
by MITRE • 10/16/2026
Peppermint through 0.5.5 contains a missing authorization vulnerability that allows any authenticated user to create time entries and attachments as other users by supplying a user id in the request body. Attackers can send POST requests to /api/v1/time/new or /api/v1/storage/ticket/:id/upload/single to attach files and time records to any ticket under another user's identity.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified within Peppermint versions up to 0.5.5 represents a critical failure in access control mechanisms, specifically categorized as an insecure direct object reference or missing authorization flaw. This issue stems from the application server failing to validate whether the authenticated user initiating a request possesses the necessary permissions to perform actions on behalf of other users. In a properly secured system, every state-changing operation must verify that the requester is authorized for the specific resource and identity being manipulated. However, in this instance, the backend API endpoints accept a user identifier within the request body without cross-referencing it against the session credentials or permission scopes associated with the active authentication token. This architectural oversight allows any authenticated account to bypass role-based access controls by simply injecting the target victim's unique identifier into the payload of an HTTP POST request.
The technical exploitation vector involves interacting with two specific API endpoints: /api/v1/time/new and /api/v1/storage/ticket/:id/upload/single. When a malicious actor sends a POST request to these endpoints, they can include a JSON body containing a user_id field corresponding to another legitimate user within the system. The server processes this identifier as authoritative for ownership purposes, thereby attributing the newly created time entry or uploaded file attachment to the specified victim rather than the actual requester. This mechanism effectively allows an attacker to impersonate other users at the data layer without needing their credentials, session tokens, or multi-factor authentication factors. The flaw is particularly insidious because it operates silently within standard API traffic patterns, making detection through basic logging difficult unless specific anomaly detection rules are in place.
The operational impact of this vulnerability extends beyond simple identity spoofing and introduces significant risks to data integrity, auditability, and compliance. By creating time entries under another user's identity, an attacker can manipulate billing records, distort project management metrics, or create false alibis for their own activities while framing others. Similarly, the ability to upload attachments as other users compromises the chain of custody for documents within ticketing systems. This could lead to legal complications if forged evidence is submitted in support tickets, or it could facilitate social engineering attacks by making malicious files appear to originate from trusted colleagues. From a compliance perspective, this undermines non-repudiation guarantees required by standards such as ISO 27001 and SOC 2, as the system can no longer reliably attribute actions to specific individuals based on authentication logs alone.
From a classification standpoint, this vulnerability aligns with CWE-862, which describes Missing Authorization, where an application fails to enforce proper access controls for API endpoints or resources. It also maps closely to MITRE ATT&CK technique T1078, Valid Accounts, specifically the sub-technique of using legitimate credentials to perform unauthorized actions within a system's logical boundaries. Although the attacker uses valid credentials, they are leveraging those credentials to execute functions reserved for higher privileges or different identities, which is a common pattern in privilege escalation via API abuse. The lack of server-side validation against the authenticated user context creates an environment where horizontal and vertical privilege escalation can occur seamlessly through standard web requests.
Mitigation strategies must focus on implementing strict authorization checks at the application logic layer rather than relying solely on client-side restrictions or network-level security controls. Developers should modify the affected API endpoints to extract the identity of the currently authenticated session from the secure token or cookie, and strictly enforce that this identity matches any user_id provided in the request body for ownership-related operations. If the system architecture requires users to manage resources for others, explicit permission checks must be performed against a role-based access control database before processing the request. Additionally, implementing API rate limiting and anomaly detection can help identify unusual patterns of cross-user activity. Regular security code reviews focusing on object-level authorization logic are essential to prevent similar flaws in future development cycles.