CVE-2026-121620 in coopcycle-web
Summary
by MITRE • 11/04/2026
CoopCycle coopcycle-web 5.6.0 before 6.20.0 contains a missing authentication vulnerability that allows unauthenticated attackers to forge Zelty webhook events because the x-zelty-hmac-sha256 HMAC signature is never verified. Attackers can POST forged dish, menu, option and order-status events to /api/zelty/webhook/* endpoints to toggle restaurant products and alter order preparation states.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in CoopCycle web versions prior to 6.20.0 represents a critical failure in access control mechanisms within the application's webhook integration layer. Specifically, this is classified as a missing authentication or authorization flaw where the system fails to validate the integrity and origin of incoming data from external services. The affected endpoints are located at /api/zelty/webhook/* which serve as entry points for receiving event notifications regarding dish updates, menu changes, option modifications, and order status transitions from the Zelty delivery platform. Under normal operational procedures, these webhook requests should be authenticated using a cryptographic signature to ensure that the data originates from the legitimate Zelty service provider and has not been tampered with during transit.
The technical root cause of this vulnerability lies in the application's failure to verify the x-zelty-hmac-sha256 header value against a shared secret key known only to CoopCycle and Zelty. This HMAC-SHA256 signature is designed to provide message authentication, ensuring both data integrity and source authenticity. By neglecting to perform this verification step, the application treats any POST request sent to these endpoints as valid regardless of its origin or content validity. An unauthenticated attacker can exploit this oversight by crafting arbitrary HTTP POST requests containing forged payload data that mimics legitimate webhook events from Zelty. This lack of cryptographic validation effectively bypasses all intended security controls associated with external API integrations, allowing the application to process maliciously crafted inputs as if they were authorized system commands.
The operational impact of this vulnerability is severe due to the high-privilege nature of the actions that can be triggered through these endpoints. Attackers who successfully exploit this flaw can manipulate core business logic by forging dish and menu events, which allows them to add, remove, or modify products available for sale on the platform. Furthermore, the ability to forge order-status events enables attackers to alter the preparation state of orders without any actual customer interaction or payment processing. This capability disrupts normal restaurant operations, potentially leading to financial loss through fraudulent order cancellations or modifications, confusion in kitchen workflows due to false status updates, and a degraded user experience for legitimate customers whose orders may be incorrectly processed or cancelled. The integrity of the entire ordering system is compromised because the application blindly trusts external inputs without verifying their provenance.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication as well as CWE-345 Insufficient Verification of Data Authenticity within the context of webhook integrations. In terms of offensive security frameworks such as MITRE ATT&CK, this exploitation technique falls under T1190 Exploit Public-Facing Application and specifically relates to techniques involving web application attacks where an attacker leverages misconfigured access controls to execute unauthorized actions. The attack vector is remote and requires no prior authentication, making it particularly dangerous in production environments exposed to the internet.
To mitigate this vulnerability, immediate remediation involves upgrading the CoopCycle installation to version 6.20.0 or later, which includes patches for this specific security flaw. For organizations unable to upgrade immediately due to compatibility constraints, a temporary workaround should be implemented at the network perimeter level. This can involve configuring web application firewalls or reverse proxies to strictly validate incoming requests on /api/zelty/webhook/* endpoints by checking for the presence and correctness of the x-zelty-hmac-sha256 header against the expected shared secret key before allowing the request to reach the application backend. Additionally, implementing strict IP allowlisting for known Zelty server addresses can provide an additional layer of defense in depth, although this should not be relied upon as a sole security control since source IP spoofing is possible with HTTP-based attacks if no cryptographic verification is performed. Regular auditing of webhook implementations across all integrated services to ensure consistent application of HMAC signatures or OAuth2 token validation is recommended to prevent similar issues in other parts of the system.