CVE-2026-121945 in coopcycle-web
Summary
by MITRE • 11/04/2026
CoopCycle coopcycle-web before 6.20.1 contains a broken access control vulnerability that allows any courier to read and modify every incident because Incident operations only check ROLE_COURIER. Attackers can enumerate sequential incident ids and use PUT /api/incidents/{id}/action to re-price, cancel or reschedule other stores' orders and tasks.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in CoopCycle web versions prior to 6.20.1 represents a critical failure in server-side access control mechanisms, specifically falling under the category of Broken Access Control as defined by CWE-284. This flaw arises from an insufficient validation of user privileges during incident management operations within the application's backend API. The system relies exclusively on verifying that the authenticated user possesses the ROLE_COURIER permission to authorize actions related to incidents. However, this check is implemented incorrectly because it does not validate whether the specific incident being accessed or modified belongs to the requesting courier or their associated store. Consequently, the authorization logic fails to enforce object-level security boundaries, allowing any authenticated courier account to interact with resources that are strictly intended for other couriers or administrative staff.
The technical exploitation of this vulnerability involves leveraging HTTP PUT requests against a predictable endpoint structure. The API exposes an action resource at /api/incidents/{id}/action where the incident identifier is sequential and easily enumerable. An attacker can iterate through these integer-based identifiers to discover valid incident records belonging to other users or stores. Once a target incident ID is identified, the attacker utilizes the PUT method to execute actions such as re-pricing orders, canceling tasks, or rescheduling deliveries. Because the server only checks for the presence of the courier role and not the ownership relationship between the user session and the specific incident resource, these malicious requests are processed successfully without triggering an authorization error. This lack of object-level permission checking is a common pattern in web applications that fail to implement proper business logic controls alongside standard authentication mechanisms.
The operational impact of this vulnerability is severe for both individual couriers and the platform as a whole. By manipulating incident data, attackers can disrupt delivery operations by canceling valid orders or rescheduling them to inconvenient times, causing logistical failures and customer dissatisfaction. Furthermore, the ability to re-price incidents allows for financial fraud where costs may be artificially inflated or deflated depending on the attacker's intent, potentially leading to direct monetary loss for merchants or unfair billing practices. The enumeration of sequential IDs also poses a privacy risk, as it exposes internal operational data such as order statuses and customer locations to unauthorized parties. This level of access undermines the integrity of the platform’s core functionality and erodes trust among users who rely on accurate and secure task management systems.
To mitigate this vulnerability, developers must implement strict object-level authorization checks within the incident action endpoint. The application should verify that the authenticated user is not only a courier but also holds ownership or explicit permission for the specific incident ID being modified. This can be achieved by querying the database to confirm that the incident’s associated store or assigned driver matches the current session's identity before processing any state-changing requests. Additionally, implementing non-sequential identifiers such as UUIDs would significantly hinder enumeration attacks, although this does not replace the need for proper access control validation. Regular security audits and penetration testing focusing on broken object level authorization are recommended to ensure that similar flaws do not exist in other parts of the application ecosystem.