CVE-2026-77470 in Lychee
Summary
by MITRE • 10/15/2026
Lychee is a free, open-source photo-management tool. Prior to 7.7.1, the Supporter or Pro webshop POST /api/v2/Shop/Checkout/Process flow accepts an unrestricted additional_data array and CheckoutService::preparePurchaseParameters() merges it after server-computed purchase parameters. Because later string keys overwrite earlier keys, an unauthenticated buyer can replace amount, currency, returnUrl, cancelUrl, or transactionId before CheckoutService::processPayment() passes the parameters to a non-PayPal Omnipay gateway. An attacker can therefore make a gateway accept a successful payment for an attacker-selected amount and obtain auto-fulfilled goods while underpaying the merchant. The issue requires an enabled webshop, a purchasable item, and an affected Omnipay gateway. This issue is fixed in version 7.7.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
Lychee is a widely used free and open-source photo-management application that includes optional e-commerce functionality through its Supporter or Pro editions. These editions allow users to sell digital goods, such as high-resolution photos or albums, via an integrated webshop feature. The security integrity of this transactional flow relies heavily on the server-side validation and construction of purchase parameters before they are passed to external payment gateways. In versions prior to 7.7.1, a critical vulnerability exists within the POST /api/v2/Shop/Checkout/Process endpoint, which handles the finalization of shopping cart checkouts. This flaw stems from an improper handling of user-supplied input during the parameter preparation phase, specifically involving how additional data provided by the client is merged with server-computed values.
The technical root cause lies in the CheckoutService::preparePurchaseParameters() method, which accepts an unrestricted additional_data array sent by the client. Instead of strictly validating or whitelisting specific fields that are safe for user modification, the application merges this untrusted input directly into the purchase parameters object using a mechanism where later string keys overwrite earlier ones. This behavior creates a classic parameter pollution vulnerability. Because the server initially computes critical financial and routing parameters such as amount, currency, returnUrl, cancelUrl, and transactionId, one would expect these to be immutable or strictly controlled by the backend logic. However, due to the merge order and lack of input sanitization, an unauthenticated attacker can inject their own values for these keys in the additional_data payload. Since client-supplied keys are processed after server-computed ones, they effectively overwrite the legitimate values set by Lychee before the transaction is submitted to the payment processor.
This vulnerability has severe operational and financial implications for merchants using affected versions of Lychee with an enabled webshop and a purchasable item configured through an Omnipay gateway that does not perform its own independent validation of these parameters. An attacker can manipulate the amount field to set it significantly lower than the actual price of the goods, or alter other fields like returnUrl to redirect post-payment flows maliciously. When CheckoutService::processPayment() subsequently passes these tampered parameters to a non-PayPal Omnipay gateway, many such gateways rely on the data provided by the merchant application without cross-referencing it against internal order records for consistency checks during the initial request phase. Consequently, an attacker can initiate a transaction where they pay a minimal amount or zero while still triggering the auto-fulfillment mechanism of Lychee upon successful payment confirmation from the gateway. This results in unauthorized acquisition of digital goods and direct financial loss for the merchant who receives less than the agreed-upon price.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to restrict or validate untrusted input before using it to control critical system behavior. It also relates to CWE-915 Improper Modification of Object Attributes, specifically involving the modification of object properties that dictate financial transactions. In terms of attack vectors and tactics, this flaw facilitates exploitation consistent with MITRE ATT&CK technique T1190 Exploit Public-Facing Application, where an attacker leverages a vulnerability in software exposed to the internet to gain unauthorized access or cause harm. The lack of authentication requirement for this specific endpoint further exacerbates the risk, allowing any external actor on the network to attempt exploitation without needing valid credentials.
To mitigate this issue and prevent similar vulnerabilities in future development, it is imperative that applications implementing e-commerce features enforce strict input validation and use immutable data structures or explicit whitelisting when merging user inputs with server-side state. Developers should ensure that critical financial parameters such as amount, currency, and transaction identifiers are never overwritten by client-supplied data. Instead, these values must be derived exclusively from trusted internal sources like database records of the shopping cart contents. Additionally, implementing backend verification steps where the payment gateway request is validated against the original order details before submission can provide a secondary layer of defense. For users currently running affected versions, immediate upgrading to version 7.7.1 or later is required to resolve this flaw. Until an upgrade is performed, merchants should consider disabling the webshop functionality entirely if it is not actively in use, thereby removing the attack surface associated with these endpoints from their deployment environment.