The Maze: Magento merchants face a security problem that routine updates did not prevent. StyleSmuggler, disclosed September 5 by ecommerce-security firm Sansec, lets outsiders run code on store servers without logging in. An early victim had installed the July and August security patches. With attacks underway and a new backdoor variant identified September 6, operators face two urgent tasks: block further entry and check whether somebody is already inside.
A clean update record is not a clean bill of health. Sansec reproduced attacks on fresh Magento Open Source 2.4.7, 2.4.8 and 2.4.9 installations; the first victim used 2.4.6-p15. Its investigation describes current Magento and Adobe Commerce versions as affected. That puts this on the agenda for teams that have followed their patch schedule, too. The evidence concerns software installations, with no confirmed breakdown of victims by country.
Code runs before anyone reads the payment email. Malicious content reaches the store's template system and executes while a failed-payment notification is being generated. Nobody needs to open it. Even unsuccessful email delivery does not establish safety. This makes staff vigilance an incomplete answer: the relevant work sits with the team running the commerce server. The investigation found a persistent backdoor, but had not established that attackers used it for subsequent harm.
The temporary response can reach the buying journey. Sansec recommends temporarily disabling GraphQL for merchants without its Shield protection. GraphQL is an interface that lets a storefront communicate with its commerce backend. Adobe's checkout tutorial shows it handling purchases for guests and registered customers. For stores using that route, shutting it down can interrupt trade. The size of that disruption depends on the implementation; it is not a prediction that every Magento checkout stops.
The deployment details matter more than the platform label. Adobe's architecture guide distinguishes installation-based Commerce schemas from its separate Commerce as a Cloud Service offering. The incident evidence should not be stretched across every Adobe service. For affected merchants, the practical question is which customer journeys depend on the interface under review. Security, development and trading teams need the same dependency picture before judging the business cost of a temporary restriction.
Blocking entry and clearing a compromise are separate jobs. A rule that stops new attempts does not establish that earlier access has been removed. Sansec sells mitigation and scanning tools, so its product recommendation needs that context. Its September 6 investigation did not establish payment-card theft or a total number of compromised stores. At our September 7 check, Adobe's bulletin index still led with August's update; a StyleSmuggler fix was not verified. A scheduled release date is no guarantee of coverage.
Why it matters: This is a trading decision as well as a security incident. Merchants need to understand exposure, any evidence of existing compromise and the sales paths a temporary control could interrupt. Treating “fully patched” as sufficient assurance leaves a gap; treating every mitigation as operationally harmless creates another. The next useful milestone is a verified fix for this flaw, followed by checks that both the store and its purchase journey are ready to run.
Sources: Sansec investigation | Adobe checkout | Adobe architecture | Adobe security index
