Hacked Magento Store Recovery

The same business day you call. Containment does not wait for a contract: we agree the scope of the first week on the call, you grant access, and isolation, the snapshot and credential rotation begin within hours. The cleanup, the root cause and the report follow inside that first week for most stores. If the store is on an unsupported version, the upgrade is planned alongside rather than after.

Usually not for long. The first step puts the store behind a web application firewall or into maintenance mode while the snapshot is taken and credentials are rotated; that is hours, not days. A store actively skimming card data is the exception: it comes off checkout immediately, because every order placed while the skimmer runs is another leaked card. We tell you which case you are in on the first call.

Because we do not search for malware; we search for anything that differs from known-good. Every Magento core file and every extension file is compared with the vendor's published hashes, the database is read for injected scripts in CMS blocks, design configuration and the admin, cron jobs and the web server configuration are reviewed, and admin users, integration tokens and API keys are listed against the ones you can vouch for. What is left is what the attacker added, whether a signature exists for it or not.

It depends on where your customers are and what was exposed. Card data points to your acquirer and the card schemes, often through a forensic investigator they appoint; personal data of EU residents brings GDPR's 72-hour breach notification; every US state has its own breach notification law. The incident report gives you the dated facts those notices need. What it does not do is decide for you: that is a conversation with your lawyer, and this answer is not legal advice.

They can, and the way to avoid it is to be ahead of them. A processor that hears from you first, with a snapshot, a containment date and a forensic plan, generally works with you; one that finds out from the card schemes' common point of purchase alerts generally does not. The incident report is written in the terms their forensic team expects, and if they appoint an investigator we work with them rather than around them.

Scoped after containment, not before. The first hours are the same for every store; what follows depends on how long the attacker was inside, how many systems they reached and whether the version has to be upgraded before it can be patched at all. Once the snapshot is read we give you a fixed scope for the recovery, in writing. There is no price list on this site because no two incidents are the same size.

Yes, and most stores do. Patch cover applies every Adobe and extension security release inside an agreed window, tested on staging first, with a monthly report and an emergency line. The register of versions and extensions we build during recovery is the starting point, so there is no second onboarding. The Magento security patching page describes how the month runs.

Possibly, and the snapshot will say. SessionReaper, CVE-2025-54236, is a flaw in the Adobe Commerce REST API that let attackers upload PHP through the customer address endpoint; its traces are specific files in the media directories and specific request patterns in the web server logs. It was the most exploited Magento vulnerability of 2025, but older flaws, stolen admin passwords and compromised extensions still account for a large share of what we see, and the fix differs for each.

Patched is not the same as clean. The patch closes the door; it does not remove a webshell uploaded before it was applied, an admin user added through it or a skimmer already on the checkout. Sansec estimated that 16 to 18 percent of all Magento stores carried a backdoor by late October 2025, many of them patched by then. A store that was exposed for any period before patching needs its file system checked.

Both, and Mage-OS. On Cloud, the snapshot and the cleanup run through the project's environments and Adobe's own tooling, and some containment steps, such as the firewall rules, are configured on the CDN rather than on a server you own. On self-hosted stores we work on your infrastructure, with your hosting provider where needed.

We need access, not your passwords. Give us our own SSH key, our own admin user with two-factor and our own role on the hosting account, and revoke them when the work ends; that is how we rotate credentials without locking you out of your own store. For payment accounts we need read access to the dispute and fraud reports, nothing more.

We can tell you what could have been read, which is what the notification laws ask. The logs show which endpoints the attacker called and for how long, the skimmer's own code shows which fields it captured, and the database shows what the attacker had access to. Exact lists of affected customers depend on how much logging the store kept, and part of hardening is making sure that next time the answer is complete.

Then we say so and show you the numbers. A store with a compromised extension that no longer has a vendor, on a version that cannot be patched, is sometimes faster and safer to rebuild on a clean supported installation, with the catalog, customers and orders migrated across from a verified export. That is a rescue decision made with you, not a surprise invoice.