What Is Magecart? How to Detect and Monitor E-Commerce Skimming Attacks

Magecart is an umbrella term for criminal groups and the web-skimming attacks associated with them. In a typical attack, malicious JavaScript reaches an e-commerce payment page directly or through a compromised third-party script, captures information shoppers enter, and stores or sends it to attackers. Checkout can continue to look normal, so a successful transaction does not prove the page was safe.

Detecting Magecart requires several layers: know which scripts are authorized, monitor payment-page changes and integrity, scan and test the application, review relevant HTTP headers, and investigate unexpected changes quickly. No single scan or control guarantees detection.

1. What Magecart means

Magecart does not refer to one malware family or one unified organization. It is a broad label for multiple criminal groups and the client-side payment-page skimming pattern they use. The shared risk is that code running in a shopper’s browser can observe checkout data even while the merchant’s payment flow appears to work. PCI Security Standards Council (PCI SSC) and Retail & Hospitality ISAC bulletin.

2. How an e-commerce skimming attack works

An entry point is compromised. Attackers may exploit vulnerable plugins or applications, obtain credentials through brute-force or credential stuffing, or use phishing and other social engineering. A third-party supplier can also be compromised.
Malicious code reaches the payment page. It may be added directly to the merchant’s site or delivered by a shared library or service the page loads. Advertising, live chat, and customer-rating scripts are examples of third-party functions that can create exposure.
The code observes checkout activity. A skimmer may activate when a shopper enters or submits payment information. Depending on the actor and code, collected data can include card details, name, billing address, email, phone number, username, or password.
Data is stored or exfiltrated. The code may log information on the compromised site or send it to attacker-controlled infrastructure. A compromised shared service can expose multiple merchants using it.
The transaction may still complete. Because the skimmer runs in the browser, a payment can appear successful even as data is copied. A clean-looking checkout or successful authorization is not a reliable integrity check.

3. What to monitor on payment pages

Build an inventory before an incident. For every script that can execute on a payment page, record its purpose, source, business owner, approval status, and how changes are authorized. Include first-party code and third-party libraries, tags, widgets, and embedded payment components.

What to monitor	What it helps reveal	Operational action
Authorized script inventory and ownership	Unrecognized or newly introduced code and unowned dependencies	Require an owner and documented reason for every payment-page script; review additions and removals.
Script integrity and file or page changes	Unexpected edits to application files, loaded scripts, or rendered payment pages	Alert on changes, identify the deployment or supplier responsible, and verify integrity against approved versions.
Browser-rendered payment page	Changes that only become visible after the page loads its scripts, including third-party changes	Inspect the actual page and its loaded resources from a browser context, and investigate unexplained differences.
Security-impacting HTTP headers	Changes to headers that affect payment-page security	Define expected values, detect unauthorized changes, and review them as part of payment-page monitoring.
Application weaknesses and access	Potential entry routes such as unpatched software, excessive privileges, or weak authentication	Scan, patch, restrict access to what is needed, and use strong authentication for system components.
Third-party suppliers	Risk introduced by scripts or services outside the merchant’s direct deployment	Know which pages load each supplier, who owns the relationship, and how an emergency disable or replacement is handled.

Browser inspection can help teams see the rendered page and loaded content at intervals, but a screenshot is only a visual observation at one moment. It does not establish that every script is safe, prove script integrity, inspect all shopper sessions, or replace purpose-built change monitoring and security controls. Keep evidence from monitoring systems that observe code, integrity, and headers directly.

4. Detection and prevention layers

PCI SSC’s 2019 bulletin recommends several complementary practices. Apply them as a defense-in-depth program rather than treating any one as a guarantee:

Use vulnerability assessment tools against web applications.
Use file-integrity monitoring or other change-detection software.
Perform internal and external vulnerability scans.
Perform periodic penetration testing.
Keep malware protection current and apply software security patches.
Restrict access to the minimum needed and use strong authentication for access to system components.

Operationally, connect these controls to a response path: route alerts to an accountable team, preserve the relevant page and change evidence, identify whether the source is first-party or supplier code, contain the exposure, remove malicious code, and fix the weakness that allowed it. Verify the page and systems after remediation. Cleaning code without closing the entry point can leave a route for reinfection.

5. PCI payment-page guidance and scope

In a March 10, 2025 announcement, PCI SSC described a supplement concerning PCI DSS Requirements 6.4.3 and 11.6.1. The announcement says these requirements focus on authorizing payment-page scripts, checking their integrity, monitoring for tampering, and managing security-impacting HTTP headers. It describes applicability to entities processing payments through e-commerce or using webpages with embedded iframes that can affect payment security. PCI SSC announcement and guidance.

The announcement identified PCI DSS v4.0.1 as the current standard at that time, and said the supplement does not add to or replace PCI DSS requirements. Standards and merchant obligations can change; confirm the currently applicable edition, validation method, and reporting responsibilities with the organizations responsible for your compliance program. PCI compliance is not proof that an attack cannot occur.

6. Incident response and recovery

Confirm and scope. Establish which payment pages, scripts, suppliers, deployments, and time periods may be affected. Preserve available logs and change records.
Contain exposure. Remove or disable suspect code and, where appropriate, pause or replace a compromised third-party integration while preserving the checkout safely.
Investigate the entry point. Review application weaknesses, credentials, access events, deployment history, and supplier changes. Determine whether other pages or systems share the same weakness.
Remove the malicious code and remediate. Patch affected software, close the access route, rotate credentials where indicated by the investigation, and restore only verified code.
Check for persistence and reinfection. Recheck files, scripts, rendered pages, and headers after cleanup. Continue monitoring after recovery and verify the original weakness is resolved.
Coordinate notifications and compliance steps. Follow applicable incident, legal, payment-brand, and compliance processes with the responsible parties.

Historical figures should not be mistaken for current prevalence. PCI SSC’s 2019 bulletin cited a researcher’s finding that one in five Magecart-infected stores were reinfected within days; this is an attributed historical statistic, not a current industry-wide rate. CERT-EU’s 2020 memo reported persistence of at least five months in the longest-lived cases it reviewed. Its memo also described historical changes to hosting, infrastructure, code, and encoding. These observations illustrate why signature-only and one-time checks can age, but they do not describe today’s global rate or every current actor. The reviewed sources do not establish a representative current estimate of Magecart prevalence. CERT-EU memo.

7. Browser-based visual checks with ScreenshotNeo

A periodic browser capture can help a team compare how a payment page appears over time and spot visible changes, such as an unexpected overlay or altered checkout layout. It is a supplementary observation, not a skimmer detector or PCI control. Review the page’s scripts, integrity signals, and headers through the appropriate security monitoring as well.

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. It can capture the page as PNG, JPEG, WebP, or PDF; use its documentation for request parameters and response details: ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://shop.example.com/checkout -o checkout.webp

For a visual comparison workflow, schedule captures at controlled intervals, keep the viewport and options consistent, and route unexpected differences to a human reviewer. Avoid putting real customer payment data into a capture workflow; use a safe checkout state and follow your organization’s access and data-handling policies. A capture shows only the page state returned for that request.

Or skip the browser setup

Use ScreenshotNeo’s one-call API if you need a browser-rendered page capture without managing browser infrastructure. Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://shop.example.com/checkout -o checkout.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://shop.example.com/checkout"},
    timeout=90,
)
open("checkout.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://shop.example.com/checkout'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('checkout.webp', Buffer.from(await res.arrayBuffer()));

These calls return visual captures; they do not determine whether a page is compromised. Use security monitoring for script authorization, integrity, tamper changes, and headers. Sign up for 1,000 free screenshots a month with no card.

8. Reliability, performance, and cost considerations

Reliability: A monitoring plan should define alert ownership, escalation, and a way to verify recovery. Pair page observations with code and integrity monitoring, since any single check has blind spots.
Performance: Browser-rendered captures load a page and its resources, so capture timing and results can vary with site readiness and third-party behavior. Keep comparison conditions consistent and use purpose-built monitoring for security-critical change detection.
Cost: Prioritize coverage of payment pages and high-risk changes. PCI SSC lists vulnerability assessment, scanning, monitoring, and testing as layers; assess their cost against the scope of payment data and your compliance responsibilities. For ScreenshotNeo, the free tier is 1,000 shots monthly; paid plans are Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan.

9. Troubleshooting monitoring gaps

Symptom	Likely cause	Practical fix
A checkout capture looks normal, but there is concern about skimming	A visual capture cannot establish script safety or integrity, and the skimmer may not change visible layout.	Review authorized scripts, file or change alerts, loaded resources, and security-impacting headers; investigate the relevant time window.
An unexpected script change has no clear owner	The inventory is incomplete or a supplier dependency is untracked.	Trace the script source and deployment, identify the business and technical owner, and require documented approval for future changes.
Alerts recur after code cleanup	The original vulnerability, credential exposure, or compromised supplier remains active, or residual code was missed.	Reopen incident scope, fix the entry weakness, inspect related pages and systems, and verify cleanup with repeated monitoring.
Scans show no issue, but the page may still be exposed	Different checks observe different layers and times; a scan is not a guarantee of client-side integrity.	Combine vulnerability assessment with file/change monitoring, rendered-page review, script integrity checks, and penetration testing.
Payment-page requirements are unclear	Applicability and validation depend on the current standard and the entity’s payment implementation.	Consult the current PCI DSS materials and the organizations responsible for your compliance program; confirm edition and reporting responsibilities.
A browser screenshot request fails or returns an unexpected page	The target may time out, block automation, or present a blank/error state; captures also reflect one request’s conditions.	Check the target URL and response, retry under controlled conditions, and use the screenshot service’s response headers and documentation. Do not treat a successful capture as a security verdict.

10. Frequently asked questions

Does Magecart only target sites built with Magento?

No. The name is used for multiple groups and the broader browser-based e-skimming pattern; the described risk applies to e-commerce pages that load compromised code.

Can a payment provider’s iframe eliminate the risk?

The cited PCI SSC guidance explicitly includes webpages with embedded iframes that can affect payment security. An iframe does not by itself settle the page’s scope or risk; confirm applicability with your compliance stakeholders.

Does PCI compliance mean a merchant cannot be skimmed?

No. The sources support layered controls and remediation, not a guarantee that compliance prevents compromise.

Is a historical Magecart percentage a current risk estimate?

No. The reinfection and persistence observations cited here are dated and bounded. The reviewed sources do not provide a representative current global prevalence estimate.