Skip to content
BIG Cart Energy
Hacked? Get emergency help
Critical

Emergency help

Store hacked or down? Magento emergency support.

Here's what to do first.

If your Magento store is hacked or down: don't wipe anything, lock the admin to your own IP, rotate admin, API and payment credentials, and send us your version through the priority form while you do. Priority submissions are read first in business hours, and a senior engineer replies in writing within one business day.

Get help now

Do this right now

  1. Don't wipe anythingLogs, uploads, the database: leave them all, and don't restore a backup over them yet. That evidence shows how the attacker got in and whether they're still there. If your host can snapshot the server, take one now. Write down what you change, and when.
  2. Take the admin offlineBlock the admin URL at the edge or in your WAF, allowing only your own IP. If it isn't /admin, check the backend frontName in app/etc/env.php and Stores > Settings > Configuration > Advanced > Admin. Keep the storefront taking orders unless cards are being skimmed. If they are, run bin/magento maintenance:enable --ip=<your IP> now: checkout stops for everyone but you, though a backdoor keeps working. Then tell your payment processor: Visa requires a suspected card compromise to be reported within three calendar days.
  3. Rotate what you canAdmin passwords, API and integration tokens, payment gateway keys (at the gateway, not just in Magento), the database password (change app/etc/env.php with it, or the store goes offline), hosting and SSH logins: after step 1, then again once the store is clean. Delete integrations nobody created: their tokens survive a crypt-key rotation. The crypt key too, with us: Magento keeps the old key so older data stays readable, and before 2.4.7-p2, 2.4.6-p7, 2.4.5-p9 and 2.4.4-p10, tokens forged with a stolen key keep working until it's removed.
  4. Send us the versionDon't wait for steps 2 and 3 to finish. Magento version and edition (or your platform), hosting, what you saw and when.

What happens after you hit send

What happens after you hit send
Within one business dayPriority submissions are read first, in business hours. A senior engineer replies in writing: what we make of what you sent, what to block now and the access we need.
With accessTriage: where the attacker most likely got in, what is still live and what to close first. It ends with the plan and the estimate in writing.
ContainmentWe block the entry point and shut down what is still live, then send a written summary of what we did and what comes next.
After thatForensics, patching, cleanup, a second credential rotation and hardening, plus help with disclosure if it's needed.

The first hour is triage, on us: we look at the store, tell you what's happening and put the plan and the estimate in writing. Emergency work beyond triage is billed by the day. No retainer required.

CriticalPriority flag: on

We reply by email. Don't paste passwords or keys here; we'll arrange access with you after we reply.

We use what you send to reply to you. We never sell it. Privacy policy

Signs your Magento store has been hacked

A hacked store doesn't always look broken: Magecart-style card skimmers copy payment details at checkout and stay out of sight. Check for:

  • Admin users nobody recognizes, under System > Permissions > All Users.
  • Script tags nobody added, in the HTML head and footer fields under Content > Design > Configuration, or in CMS blocks, where CosmicSting attackers injected their JavaScript (Sansec).
  • Integrations nobody created, under System > Extensions > Integrations.
  • Files that changed without a deploy, especially under pub/ and app/etc/, and anything new in pub/media/customer_address/, where SessionReaper attacks upload files even on patched stores (Sansec).
  • Cron jobs or server processes nobody set up: the StyleSmuggler implant (CVE-2026-75650) disguises itself as a system process (Sansec).
  • Customers reporting card fraud after buying from you.

One is enough: don't wait for proof of card theft. Adobe's free Security Scan Tool runs over 21,000 security tests from outside, so a clean result doesn't clear the store.

We handle Magento malware removal from containment to the post-incident fix: forensics, patching, cleanup and Magento security hardening, on supported and unsupported versions alike. Pen-test findings closed and retested against every bypass variant we could throw at them. Down, not taking orders or hit by another critical issue, with no sign of a hack? Urgent Magento support runs through the same form, with the same priority flag. Not urgent? Talk shop.

Store hacked on another platform?

We fix those too. Hacked website repair starts the same way on every platform: keep the evidence, lock down admin access, rotate credentials and use the same form. What changes is where the attacker hides:

  • Shopify. Shopify runs the servers and the platform code, so a break-in usually comes through what you control: staff and collaborator accounts, apps and theme code. Remove accounts you don't recognize, require two-step authentication for each staff account, uninstall apps nobody approved and read the theme for scripts nobody added.
  • WooCommerce and WordPress. Plugins and themes that missed updates, admin users nobody created, and edited files: .htaccess, index.php and the theme's header.php, footer.php and functions.php. Snapshot the site first, infected or not, then set new secret keys in wp-config.php to log everyone out (WordPress.org). Change every password again once it's clean.
  • BigCommerce. Control panel users, apps, store-level API accounts and Script Manager scripts, which can run on every page, checkout included (BigCommerce). Deleting an API account is the only way to revoke it, and it deletes that account's webhooks too: list them first (BigCommerce).
  • Custom stacks and headless builds. Treat them like Magento: the server, its logs, every credential the code holds and the API behind the storefront.

"This site may be hacked" and blacklist warnings

Google shows "This site may be hacked" in search results when it believes a hacker changed some of a site's existing pages or added spam pages (Google Search Help). Malware can also trigger Safe Browsing warnings, which depend on browsing context: you may not see what customers see. Both are cleared in Search Console's Security issues report:

  1. Verify the site in Search Console and open Security issues for sample URLs.
  2. Clean every affected page and close the hole the attacker used, or the site may be reinfected.
  3. Request a review only when every page is fixed. Google is explicit: "requesting a review if the problem still exists will only prolong the period of time that your site is flagged as dangerous" (web.dev). Google says most reviews can take several days or weeks (Search Console Help).

Website redirecting to another site, but not for you? Check on a phone: Google documents hacker scripts that redirect only mobile users (Search Console Help). A site can be blacklisted beyond Google, too: Bing and desktop antivirus products keep their own lists, and a server that sent spam can land on email blocklists (WordPress.org).

On a Magento version Adobe no longer patches?

An upgrade can wait. We close the entry point first, with Adobe's hotfix or a backport where one exists or a block where none does, then clean the store; you upgrade when you're ready.

Adobe's lifecycle policy decides which release lines still get security fixes, and it's written for Adobe Commerce. Adobe's October 2026 article adds: "Open Source merchants can only download patches for version 2.4.7 or later." Monthly isolated patches are "tested exclusively against" the newest -p release of each line and applied "cumulatively, in release order", with emergency hotfixes applied separately. Miss one and the store is exposed, whatever its line. Three examples:

  • CVE-2026-75650, StyleSmuggler. CVSS 10.0, attacked as a zero-day from September 4, 2026. Hotfix VULN-39341 (APSB26-146) came on September 7 and requires rotating the encryption key. It gives unauthenticated attackers code execution on every version from 2.4.4 to 2.4.9, and Adobe publishes nothing for 2.4.3 and older (Adobe, Sansec). October's isolated patch (APSB26-153) closes a CVSS 10.0 bypass of that hotfix (CVE-2026-103849), so a store needs both (Sansec).
  • CVE-2025-54236, SessionReaper. CVSS 9.1, fixed in APSB25-88 on September 9, 2025. It allows customer account takeover and, under certain conditions, unauthenticated remote code execution (Sansec).
  • CVE-2024-34102, CosmicSting. An XXE flaw, CVSS 9.8, fixed in APSB24-40 on June 11, 2024, with a July 17 hotfix that's needed too. It lets an attacker read files on the server, the crypt key in app/etc/env.php included, so after patching it's rotated and the old one retired (Sansec).

All three are in CISA's Known Exploited Vulnerabilities catalog: CVE-2026-75650, CVE-2025-54236, CVE-2024-34102. When a backport is public, it's listed on free Magento security patches with the exact versions it was tested on.

Store hacked or down? Get help now.

FAQ

How do we know if our store has been hacked?

Check for admin users nobody recognizes, scripts nobody added to the HTML head, footer or CMS blocks, integrations, cron jobs or server processes nobody set up, files changed without a deploy, and customers reporting card fraud after buying from you. Skimmers stay hidden, so one sign is enough to act on.

What does "This site may be hacked" mean?

Google adds that label to search results when it believes a hacker changed some of a site's existing pages or added spam pages. It stays until the site owner acts: clean the whole site, then request a review in Search Console's Security issues report.

How do we remove "This site may be hacked"?

Open Search Console's Security issues report for sample URLs, clean every affected page and close the hole the attacker used, or the site may be reinfected. Then request a review. Google warns that requesting one while the problem still exists only prolongs the flag.

What should we do first if our store is hacked?

Don't wipe or restore anything: the logs and files show how the attacker got in. Lock the admin to your own IP; if cards are being skimmed, turn on maintenance mode and tell your payment processor. Send us the version through the priority form while you rotate admin, API and payment credentials.

Should we take the store offline?

Usually not the whole store. Block the admin at the edge or in your WAF and keep the storefront taking orders, unless card data is being skimmed. If it is, take it down: on Magento, run bin/magento maintenance:enable with your own IP exempt.

How fast do you respond?

A senior engineer replies in writing within one business day, and priority submissions are read first in business hours. The reply covers what you sent, what to block now and the access we need. Then comes triage, which ends with the plan and the estimate in writing.

Do you clean up stores on versions Adobe no longer supports?

Yes. Adobe's lifecycle policy decides which release lines still get security fixes; it's written for Adobe Commerce, and Open Source patches cover 2.4.7 and later only. We close the entry point first, with Adobe's hotfix or a backport where one exists or a block where none does, then clean the store.

What does emergency help cost?

The first hour is triage, and it's on us: we look at the store, tell you what's happening and put the plan and the estimate in writing. Emergency work beyond triage is billed by the day, with no retainer required.

Sources

Last reviewed

  1. Sansec: SessionReaper, unauthenticated RCE in Magento & Adobe Commerce (CVE-2025-54236) · Checked
  2. Sansec: CosmicSting attack & defense overview · Checked
  3. Sansec: StyleSmuggler, Magento and Adobe Commerce 0-day RCE (CVE-2026-75650) · Checked
  4. Sansec: BlockStrap: Magento and Adobe Commerce RCE (CVE-2026-103849) · Checked
  5. Sansec: Magento crypt key rotation · Checked
  6. Adobe KB: Action Required: Critical Security Update Available for Adobe Commerce (APSB25-88) · Checked
  7. Adobe KB: Security update available for Adobe Commerce - APSB24-40 · Checked
  8. Adobe KB: Urgent Action Required: Critical Security Update Available for Adobe Commerce (APSB26-146) · Checked
All 35 sources
  1. Adobe KB: Security update available for Adobe Commerce - APSB26-153 (October 2026 isolated patch) · Checked
  2. NVD: CVE-2026-75650 · Checked
  3. NVD: CVE-2026-103849 · Checked
  4. NVD: CVE-2025-54236 · Checked
  5. NVD: CVE-2024-34102 · Checked
  6. CISA Known Exploited Vulnerabilities: CVE-2026-75650 · Checked
  7. CISA Known Exploited Vulnerabilities: CVE-2025-54236 · Checked
  8. CISA Known Exploited Vulnerabilities: CVE-2024-34102 · Checked
  9. Adobe: Lifecycle policy · Checked
  10. Adobe: Patch release schedule · Checked
  11. Adobe: Encryption key · Checked
  12. Adobe: Guidance on securing your store and rotating encryption keys: CVE-2024-34102 · Checked
  13. Magento source: JwtUserToken SecretBasedJwksFactory.php at 2.4.7-p2 (newest key only) · Checked
  14. Adobe: Enable or disable maintenance mode · Checked
  15. Adobe: env.php reference (backend frontName) · Checked
  16. Adobe: Store URLs (custom Admin path) · Checked
  17. Adobe: Security scan · Checked
  18. Visa: What To Do If Compromised, Visa Supplemental Requirements, Version 10.0 (effective 25 June 2026) · Checked
  19. Google Search Help: This site may be hacked · Checked
  20. Google Search Console Help: Security issues report · Checked
  21. web.dev: Request a review · Checked
  22. Google Search Console Help: Manual actions report (sneaky mobile redirects) · Checked
  23. WordPress.org: FAQ My site was hacked · Checked
  24. Shopify Help Center: Two-step authentication for users · Checked
  25. Shopify Help Center: Collaborator accounts · Checked
  26. BigCommerce: Scripts API (Script Manager) · Checked
  27. BigCommerce: API Accounts · Checked