CVE-2026-77466 in Lychee
Summary
by MITRE • 10/15/2026
Lychee is a free, open-source photo-management tool. Prior to 7.7.0, Lychee hides the Omnipay Dummy test provider from the checkout options in production through OmnipayFactory::get_supported_providers(), but CreateSessionRequest validates only that the submitted provider is an OmnipayProviderType and does not enforce OmnipayProviderType::isAllowed(). A buyer, including a guest when webshop_allow_guest_checkout is enabled, can submit Dummy directly and complete the test gateway flow without a real payment. When webshop_auto_fulfill_enabled is enabled, OrderCompletedListener::fullfillOrder() can then release the purchasable item. The issue requires access to the Supporter or Pro webshop and an enabled purchasable item. Testing bypassed the closed-source license middleware, so whether the real license layer performs additional payment-provider validation remains unverified. The payment finalize status check itself is not the root cause. This issue is fixed in version 7.7.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Lychee prior to version 7.7.0 represents a critical authentication and authorization bypass within its integrated webshop functionality, specifically targeting the payment processing workflow. Lychee is an open-source photo-management platform that includes optional e-commerce features allowing users to sell digital or physical goods through built-in support for various payment gateways via the Omnipay library. The core of this flaw lies in a discrepancy between how supported providers are filtered and how they are validated during transaction creation. In production environments, the application utilizes the OmnipayFactory::get_supported_providers() method to hide specific test providers, such as the Dummy provider, from user-facing checkout options. This mechanism is designed to prevent end-users from selecting non-production payment methods that do not handle real financial transactions. However, this filtering logic was not applied consistently across all code paths involved in processing payments.
The technical root cause resides within the CreateSessionRequest class, which handles the initialization of a payment session. While the user interface correctly omits test providers based on environment configuration, the backend validation logic only checks if the submitted provider string corresponds to an instance of OmnipayProviderType. It fails to enforce the additional constraint provided by OmnipayProviderType::isAllowed(), which is responsible for verifying whether a specific provider is permitted in the current execution context. This oversight allows any user with access to the webshop interface, including guests when guest checkout is enabled via the webshop_allow_guest_checkout setting, to manually submit requests specifying the Dummy test gateway as the payment method. By directly manipulating the request payload or exploiting API endpoints if accessible, an attacker can bypass the intended restriction on production environments and select a provider that simulates successful payments without requiring actual financial credentials or processing through a real banking institution.
The operational impact of this vulnerability is severe because it enables unauthorized acquisition of purchasable items with zero cost. Once the payment session is created using the Dummy provider, the system proceeds to finalize the transaction under the assumption that valid payment authorization has occurred. If the webshop_auto_fulfill_enabled configuration option is active, the OrderCompletedListener::fullfillOrder() method automatically triggers the release or delivery of the purchased item immediately upon order completion. This means an attacker can effectively steal digital goods, such as high-resolution photo packs, premium features, or other licensed content offered by Lychee users who have enabled their shops to sell these items. The vulnerability specifically affects Supporter and Pro webshop tiers where purchasable items are defined, allowing for direct economic loss to the shop owners relying on this functionality for revenue generation.
This issue also highlights a broader security concern regarding license middleware bypass. Testing demonstrated that the closed-source license validation layer could be circumvented through this payment provider manipulation technique. While it remains unverified whether the actual proprietary license enforcement mechanisms perform additional independent checks on the payment provider, the ability to trigger order completion flows using test gateways suggests potential weaknesses in the overall integrity of the transaction pipeline. The vulnerability is not related to a failure in checking the final payment status itself but rather stems from insufficient input validation at the session creation stage. This aligns with CWE-284 Improper Access Control, as the application fails to restrict access to functionality that should be limited by environment configuration and provider type constraints. Furthermore, it relates to CWE-915 Improper Modification of Object Attributes because the state of the order is altered based on unvalidated input regarding the payment method.
From a threat modeling perspective using the MITRE ATT&CK framework, this vulnerability facilitates unauthorized resource consumption and potentially impacts availability for legitimate customers if inventory limits are reached through automated exploitation. It can be categorized under techniques involving client-side manipulation or API abuse where an actor modifies parameters to bypass security controls. The attack vector is primarily remote but requires initial access to the webshop interface, which may range from public guest access to authenticated user accounts depending on the shop's configuration.
To mitigate this vulnerability and prevent similar issues in future development, it is imperative that all code paths interacting with payment providers enforce consistent validation rules. Specifically, the CreateSessionRequest class must be updated to call OmnipayProviderType::isAllowed() or an equivalent security check before proceeding with session creation. This ensures that even if a user attempts to submit a test provider like Dummy in a production environment, the request will be rejected at the backend logic level regardless of what is displayed in the frontend interface. Additionally, developers should implement strict allow-listing for payment providers based on the current application mode rather than relying solely on UI hiding mechanisms. Input validation must occur as early as possible in the request lifecycle to prevent state manipulation. Upgrading Lychee to version 7.7.0 or later resolves this issue by correcting these validation discrepancies and ensuring that test gateways are strictly prohibited in production deployments, thereby restoring trust in the webshop's payment processing integrity.