Magento 2 hacked: the warning signs and what to do next

The signs of a hacked Magento 2 store

A hack rarely shows on the shop front. The attacker prefers to stay out of sight: the longer they stay, the more they collect. The signs are often small. One alone proves nothing, but two or three together call for an immediate check.

What your customers see

• Redirects to another site (gambling, pharmacy, fake shop), sometimes only from Google or only on mobile.
• A payment form that looks different, an extra payment step, or a payment that fails and then goes through on the second attempt.
• Customers reporting fraud on their card after buying from you.

What you see in the admin panel

• An admin account nobody recognises, or an existing account that has been given full admin rights. See our guide: spot a suspicious admin account.
• An integration or API access you did not create.
• Unusual orders: many small declined orders, a string of failed payments, customer accounts created in bulk.
• A content block or header setting changed for no reason, with a script you do not recognise.

What others tell you

• Google shows a warning in its results or in the browser. The Search Console “Security issues” report then tells you what it found: hacked content, malware or social engineering.
• Your hosting provider writes to you: spam sent from the server, malicious file detected, unusual load, account suspended.
• Your bank or payment provider tells you that your store is the common point between several fraudulent cards. This is often the sign of a card skimmer.

How attackers get in in 2026: StyleSmuggler, SessionReaper, PolyShell

Most recent Magento store hacks go through a known flaw, exploited at scale in the days after it is published. If your store did not get the right patch in time, that is the first lead to check. Here are the three most exploited flaws this year, with the traces to look for (situation as of 26 October 2026).

StyleSmuggler (APSB26-146, CVE-2026-75650)

• What it allows: an attacker with no account can run code on the server through the GraphQL API. Adobe gives it the most severe score (10 out of 10). It has been exploited since early September 2026; Adobe published an emergency hotfix on 7 September.
• Affected versions: Magento 2.4.4 to 2.4.9, up to and including the August 2026 releases. No Magento release includes the fix yet: you need to apply the isolated VULN-39341 hotfix. The October security update (APSB26-153) does not replace it: Adobe asks you to apply both.
• The traces: in the web server logs, requests containing styles[generatorClass] or styles[first]; in var/log/exception.log, errors such as Map file provided does not exist or Type Error occurred when creating object: Aws\S3\S3Client.
• After an exploitation: the attacker may have read the encryption key. Adobe asks you to change it, along with every credential (see the passwords, keys and tokens to change).

SessionReaper (APSB25-88, CVE-2025-54236)

• What it allows: taking over customer accounts through the REST API and, depending on the configuration, running code.
• Fixed versions: 2.4.8-p3, 2.4.7-p8, 2.4.6-p13, 2.4.5-p15 and 2.4.4-p16 (October 2025), or the isolated VULN-32437 hotfix. A store left on an older version is still exposed.
• The traces: PHP files dropped in pub/media, which should only hold images and documents.

PolyShell

• What it allows: uploading a file with no account, through the custom options of a cart. A .phtml or .phar file dropped in pub/media/custom_options/ can then be run.
• Affected versions: when Sansec disclosed it in March 2026, it was only fixed in the 2.4.9 branch. On an older version, block PHP execution in pub/media at web server level, and check with whoever manages the store where the patches stand for your version.
• The traces: many uploads to guest carts (guest-carts) from the same address, .phtml or .phar files in pub/media, an accesson.php file in an images folder, an unknown script in a CMS block or page.

To find out whether your store is up to date, see also Adobe security patches for Magento.

Hacked Magento: what not to do in the first hours

The first instinct is often to wipe everything so the problem goes away. It is the worst thing you can do.

• Do not delete files, accounts or logs. They are the evidence. They show how the attacker got in, what they took and since when. Without them, you cannot close the right door, or answer your bank, the data protection authority or your insurer.
• Do not restore a backup without understanding what happened. If the flaw is still there, the attacker comes back. And a backup may already contain their backdoor.
• Do not switch the server off. Isolate it if needed, but leave it running: its memory also holds traces. Visa recommends disconnecting the machine from the network without shutting it down, and the French government’s Cybermalveillance.gouv.fr service advises unplugging it from the internet.
• Do not log in to the compromised machine to change passwords there: Visa advises against it. Change the passwords of exposed accounts quickly, but from a clean computer. The full change of every access comes afterwards, once the door is closed.
• Do not handle it alone. Bring in someone who knows Magento.

Who to notify when your Magento store is hacked

In every case, record the breach in your internal documentation: the facts, their effects and the action taken. The GDPR requires this even when you do not notify the authority.

You manage the server: first checks on a hacked Magento 2

These commands change nothing on the site. They are used to preserve the evidence and assess how far the intrusion goes. Replace /var/www/store with your Magento folder.

Regaining control of a hacked Magento 2: with or without a clean backup

Once you understand how the attacker got in, there are two cases.

You have a clean backup

A backup is clean if it dates from before the intrusion. Only the investigation can give you that date: one more reason to keep the traces.

• The code can safely be restored from the backup or, better still, from the Git repository and Composer.
• The database is trickier: restoring it wipes the orders and customers recorded since. It is often better to clean it by hand (accounts, integrations, blocks, configuration), then compare it with the backup.
• Then apply the security patches before reopening the store. Otherwise, the same flaw gets used a second time.

You have no clean backup

You need to clean up. Adobe recommends removing unnecessary files, reinstalling the ones the store needs from a clean source, quarantining suspicious code and redeploying all the code. In practice:

• the Magento core and the extensions are reinstalled from Composer;
• the store’s own code (theme, custom modules) is compared line by line with its repository, or reviewed;
• the database is reviewed: admin accounts, integrations, CMS blocks and pages, HTML configuration, store URLs.

When to start again on a new server

Cleaning the Magento folder is not always enough. If the attacker was able to run commands on the server, they may have left traces outside the store: a scheduled task, an SSH key, a system account, a modified program, a file in another site hosted on the same machine. Nobody can then guarantee that everything has been removed.

Start again on a new server, installed from scratch, in any of these cases:

• the attacker gained access to the server itself (command line, SSH, hosting account), not just to the Magento admin panel;
• files were changed outside the store folder, or unknown scheduled tasks, SSH keys or accounts have appeared;
• other sites on the same server are affected;
• the investigation cannot tell how far the attacker went.

On the new server, the code is redeployed from the Git repository and Composer, never copied from the old one. The database is imported after being reviewed, and every access is changed (see below). The old server stays isolated, without being wiped, for the duration of the investigation: it holds the evidence. Your hosting provider can supply a new machine; it is often quicker and safer than a long clean-up.

The passwords, keys and tokens to change

Once the door is closed, change everything the attacker may have read. If you do it before, they may see the new credentials go by:

• the passwords of all admin accounts, and delete the accounts you do not need;
• the database password, stored in app/etc/env.php;
• SSH and SFTP access, and access to the hosting control panel;
• Magento’s encryption key: Adobe asks you to change it as soon as it may have been compromised, which is the case after a StyleSmuggler exploitation (the bin/magento encryption:key:change command, the only method since Magento 2.4.8). Changing the key is not enough: credentials already read must be changed too;
• the API keys of the payment provider, the carrier and the email service;
• the integrations: delete the ones you do not recognise, recreate the others.

After the clean-up: avoid another Magento 2 hack

Adobe points it out: many sites are compromised again within hours of an incident. The PCI Security Standards Council makes the same observation for skimmers: if the flaw is not fixed, or if a piece of the attacker’s code stays in place, the infection comes back.

Application screens with example values.

Cédric Michel

Cédric has been building Magento stores for 18 years and holds the Adobe Commerce Developer Expert certification. He created Tocsin24 to monitor the security and health of Magento 2 stores and WordPress sites.

Adobe Commerce Developer Expert
Verify the certification on Adobe’s website