Peppermint EUVD-2026-56025

Exploitation requires a valid authenticated session in Peppermint (any user account, including the lowest-privilege tier). The vulnerable condition is present on all default installations because Config.roles_active defaults to false - no special operator misconfiguration is needed; the insecure state ships out of the box. Exploitation is limited to: (1) network-reachable Peppermint instances (AV:N per CVSS), and (2) possession of at least one valid user credential or session token (PR:L per CVSS). No elevated privileges, specific configuration, or non-standard deployment mode is required beyond default installation. The sole limiting factor is the authentication barrier: unauthenticated attackers cannot exploit this without first obtaining or creating a valid account.

The CVSS 3.1 base score of 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) is broadly consistent with the described impact, though the A:N metric appears to underweight the deletion capability - the ability to delete any ticket, client, or user record constitutes at least low availability impact. Attack complexity is genuinely low because the vulnerable state is the default installation posture, not a misconfiguration an operator must make. The only friction is the PR:L requirement: an attacker must hold any valid account, which in a helpdesk context (often customer-facing or open-registration) may be easily obtained. No EPSS score was provided in the input data and no CISA KEV listing exists, meaning active exploitation is unconfirmed. No public POC has been identified at time of analysis. Real-world risk is highest in multi-tenant Peppermint deployments where users from different organizations or privilege tiers share a single instance - in that scenario, horizontal privilege escalation (accessing other customers' tickets and PII) is trivially achievable with zero special tooling.

An attacker registers or is provisioned a low-privilege helpdesk account on a default Peppermint installation. Because Config.roles_active is false, the attacker directly calls the ticket, client, or user API endpoints referencing arbitrary record IDs - no ownership check is enforced. The attacker can enumerate all tickets and client records (confidentiality breach), modify ticket contents or reassign ownership (integrity breach), or delete user accounts and client records belonging to other organizations (integrity and partial availability breach). No public POC has been identified, but exploitation requires only knowledge of the API structure, which is publicly documented in the open-source repository.