Magento 2 Security: How Real Attacks Look (And How to Detect Them)

Most Magento 2 stores get attacked. Many never notice.

The attacks are rarely dramatic. They don't show up as obvious site defacement or ransom messages. They show up as unexplained server load, mysterious entries in your search terms, slow database performance, or suddenly failing security scans from Adobe. By the time someone connects the dots, the attack has been running for weeks or months.

This article walks through three real attack patterns we've encountered in production — what they look like, how to detect them, and what to do before they cost you customers. It's based on incidents we've actually responded to across 70+ Magento projects since 2018, and on the framework I presented at Magento Meet Ukraine 2025.

Before the technical detail — the version every store owner needs to read.

For Store Owners: What You Actually Need to Know

If you're running a Magento store and you're not the one writing the code, here's the honest situation.

Magento is a high-value target. Magento stores hold customer data, payment information, and process real money. That makes them attractive to attackers in ways that small WordPress blogs aren't. Automated tools constantly scan the internet looking specifically for Magento installations to test against known vulnerabilities.

Most attacks don't look like attacks at first. They look like server problems, performance issues, or weird analytics. A skilled attacker wants to stay hidden as long as possible — the longer they have access, the more they can extract. The visible "your site has been hacked" scenarios are the unsuccessful attacks; the dangerous ones are the ones nobody notices.

Three things determine whether your store is at risk:

1. Magento version and patch level. Every month you delay patching, your exposure to known vulnerabilities grows. There's no exception to this.

2. Active monitoring. Stores without monitoring don't catch attacks. They catch consequences months later.

3. Backup discipline. When something does go wrong — and eventually it will — your backup quality determines whether recovery takes hours or weeks.

If you don't know the answers to "what version of Magento are we on, when was it last patched, and do we have working monitoring" — that's the first conversation to have with your developer or agency.

For everyone else — let's look at what real attacks on Magento stores actually look like.

Attack Pattern 1: CMS Injection via API Vulnerability

This is the attack family that includes CVE-2024-34102 — the vulnerability that became known in the Magento community as "CosmicSting" when it was disclosed in mid-2024. We're not going into exploit details (that information helps attackers, not defenders), but the pattern is worth understanding because it represents a category of attacks that keeps showing up in different forms.

What the attack does at a high level

The attacker sends specially crafted requests to specific Magento REST API endpoints. These requests inject malicious content — usually obfuscated JavaScript — into CMS blocks, product descriptions, or other content surfaces that get rendered on customer-facing pages. The injected code then executes in customers' browsers, often capturing form submissions or redirecting payments.

What it looks like in your access logs

The signature pattern in Magento access logs is a high-frequency series of PUT requests to specific REST API endpoints, often arriving within seconds of each other from a single IP or small range of IPs. The exact endpoint varies depending on which CVE is being exploited, but the pattern of automated, high-frequency PUT requests to API endpoints is the consistent signal.

What you'll see is dozens or hundreds of API calls in a few minutes — far more than any legitimate use of the admin API would generate.

Detection signals

If you're wondering whether you've been hit by something in this attack family, look for:

• Sudden spikes in API endpoint traffic in your access logs

• Unexpected modifications to CMS blocks, product descriptions, or static pages — content that's there but nobody on your team added

• Suspicious JavaScript on your storefront that doesn't match anything in your codebase

• Customer reports of being redirected during checkout

• Failed Adobe Commerce security scans flagging "Compromise Injection" issues

The Adobe Commerce security scanner, which runs against stores connected to the Adobe Commerce account, is one of the more reliable detection signals because it's specifically tuned to catch these patterns. If your scan starts failing, take it seriously.

What to do

Step one is patching. CVE-2024-34102 was patched by Adobe in June 2024 (security patch APSB24-40). If you're not on a current patch level, that's the first action. The fix is in the official Adobe security patches — apply them.

Step two is investigation. If you suspect the attack already happened, audit your CMS blocks, product descriptions, email templates, and any other content surfaces for unexpected JavaScript. Compare against your last known clean backup.

Step three is monitoring. Set up automated alerts on API endpoint traffic anomalies. The attack pattern is loud — it's hard to miss if you're watching, and trivial to miss if you're not.

The broader lesson: every Magento version has known CVEs that get patched in subsequent releases. Stores running on older Magento versions are accumulating known unpatched vulnerabilities that automated scanners are actively looking for. The single most important security practice is staying current on patches.

Attack Pattern 2: Search Abuse for SEO Spam

This attack is less dramatic than API exploitation but more common. Almost every Magento store with a public search function and search results pages indexed in Google has experienced some version of it.

What the attack does

Attackers run automated queries against your store's internal search, injecting URLs and content designed to get indexed by Google. The goal is to use your domain's search authority to rank spam content in search results — usually for adult services, illegal pharmaceuticals, gambling, or questionable financial products in markets the attacker is targeting.

The spam doesn't show up on your homepage or product pages. It shows up in your search results pages, which Google can index if they're not properly excluded.

What it looks like in your data

The most visible symptom is your "Last Search Terms" report in the Magento admin filling with bizarre queries — often in languages your customer base doesn't speak. Korean characters, Cyrillic spam, Chinese ad copy.

The performance impact is the secondary symptom. Search queries that match thousands of irrelevant rows force the database to do unnecessary work. We've seen search_query tables grow to hundreds of thousands of rows from spam alone, with individual queries taking 7+ seconds to execute. That weight slows down legitimate customer searches too.

The third symptom is in Google Search Console — your indexed page count starts growing in ways that don't match the actual size of your catalog. Search results pages get indexed. Pagination of search results gets indexed. Tens of thousands of low-quality URLs accumulate in Google's view of your site, dragging down rankings.

Detection signals

• Search terms in your admin that don't match your product catalog or customer base

• Indexed page count in Search Console growing faster than your product catalog

• Search-related URLs (catalogsearch/result/...) appearing in Search Console reports

• Slow database queries against search_query table in your slow query log

• Sudden traffic spikes from search engines for nonsensical queries

What to do

Three layers of defense:

Block the abuse at the edge. Use Cloudflare, Sucuri, or another WAF to add rate limiting on search endpoints and pattern-based blocking of known spam queries. Most spam follows recognizable patterns that can be filtered with custom WAF rules. We typically configure rules that block requests matching obvious spam signatures (specific character ranges, length anomalies, known spam keywords).

Prevent indexing of search results. Add proper directives in robots.txt to prevent crawling of search result URLs. Add noindex meta tags to search result pages so anything that does get crawled isn't indexed. This is configuration that should be in place by default, but we frequently audit stores where it isn't.

Clean up the database. If the abuse has been running, the search_query table likely needs cleanup. Records older than 30 days are usually safe to delete. After cleanup, add an index on the relevant columns if it's missing — search query lookup performance suffers without it.

The combination of edge filtering, indexing prevention, and database cleanup typically eliminates the problem within a week. Without all three, you're either blocking the spam but still serving slow searches, or speeding up searches but still getting indexed.

Attack Pattern 3: Failed Security Scans as Early Warning

This isn't an attack pattern — it's a detection pattern that's worth covering separately because it's the way many stores discover they have a problem.

Adobe Commerce includes automated security scanning that runs against stores registered with the Magento marketplace. The scanner checks for known vulnerability patterns, suspicious code, and signs of compromise. When it fails, it gives you specific information about what it found.

What a failed scan tells you

A failed Adobe security scan typically returns one of several flags:

• Compromise Injection — the scanner detected scripts in your codebase that match patterns of known malware. This is the most serious flag and means investigation is required immediately.

• Outdated software — your Magento version is missing patches for known vulnerabilities. Less urgent than active compromise but still requires action.

• Suspicious resources — external scripts being loaded that match known malicious patterns.

• Configuration issues — settings that increase attack surface but aren't direct compromises.

When you see a failed scan, the recommended response is structured:

1. Don't panic, but don't ignore it. Failed scans aren't always actual compromises (false positives happen), but they're never something to dismiss without investigation.

2. Read the scan details. Adobe provides specific information about what was detected and where. That's your starting point.

3. Compare against backups. If files have been modified, comparing against a clean backup tells you what changed and when.

4. Patch and rescan. If the issue is outdated software, patch first and run the scan again. If files were modified, restore from clean backups, patch, and rescan.

We've worked through Adobe security scan failures in client projects. The pattern is consistent — the stores that catch issues early through automated scanning recover quickly. The stores without active monitoring discover problems much later, and recovery is harder.

What Active Security Looks Like in Practice

The three attack patterns above are what gets caught when security is treated as ongoing work. Here's the practical baseline we apply on Magento projects we maintain.

Patch discipline. Every Adobe security patch gets applied within a defined window — usually two weeks of release for non-critical patches, days for critical ones. This isn't optional or "when we have time." Patches are scheduled work.

Active monitoring. Real-time error tracking (Sentry or similar) integrated with deployments so we see exception patterns immediately. Server-level monitoring for traffic anomalies. Adobe security scan running on its scheduled cadence with alerts.

Edge protection. Cloudflare or similar WAF in front of every store. Custom rules tuned to the specific patterns the store sees. Rate limiting on sensitive endpoints (admin login, password reset, search, API).

Configuration hardening. Two-factor authentication on every admin account, no exceptions. Content Security Policy configured properly. Admin URL changed from default. Restricted IP access to admin where the business permits it.

Backup verification. Backups aren't just configured — they're tested. We restore the most recent backup to staging monthly and verify the restored store actually works. An untested backup is a hopeful guess.

Regular audits. Quarterly review of access logs, traffic patterns, indexed pages, and search terms. Not waiting for a problem to surface — looking for early signals before they become problems.

This baseline isn't expensive or complicated. It's discipline. Most stores that get badly compromised aren't compromised because the attack was sophisticated — they're compromised because none of these basics were in place.

How to Audit Your Store's Security Right Now

If you want to assess your store's current security posture today, here are the practical checks.

Check your Magento version and patch level. Run php bin/magento --version or check Stores → Configuration in admin. Compare against the latest Magento releases. If you're more than two patch versions behind, that's the first thing to fix.

Run the Adobe security scan. If your store is registered with Adobe, run the scan and review results. If you're not registered, register and run it.

Audit admin access. List your admin accounts. Disable any that aren't actively used. Verify two-factor authentication is enforced. Check the admin_user table for accounts you don't recognize.

Review your search terms. Open Reports → Marketing → Search Terms in admin. If you see significant volumes of queries in languages your customers don't speak, you're likely being abused.

Check Search Console for unexpected indexing. Compare indexed page count to your sitemap. Look for catalogsearch URLs in indexed pages.

Verify backups exist and work. Locate your most recent backup. Confirm it includes both database and files. Test restore to a staging environment if you have one. If you can't do these three things, you don't have working backups.

Review access logs for anomalies. Look for spikes in traffic to API endpoints, repeated requests to login or admin URLs, unusual user agents, requests from suspicious IP ranges.

This isn't a complete security audit, but it covers the most common signals. If you find issues in any of these checks, that's where to focus first.

For the broader audit framework, see our 12-point Magento audit checklist — security is one category, alongside performance, SEO, and code health.

When Security Issues Are Symptoms of Bigger Problems

Sometimes a security incident is the visible symptom of underlying neglect rather than an isolated event. The signals that suggest deeper issues:

Multiple unrelated security failures in a short period. If you've had a CMS injection issue and a malware scan failure and an admin compromise in the same year, the issue isn't bad luck. The issue is missing security baseline.

Patches consistently lag releases. If your patch cadence is "we apply them when something breaks," you're operating in reactive mode. Reactive security loses to proactive attackers.

No clear ownership of security. When something happens, who responds? If the answer is "we'd figure it out," that's the problem to fix before the next incident.

Compounding technical debt. Stores with significant performance issues, outdated dependencies, and accumulated code debt are also stores with security exposure — these problems share root causes. A store rescue that fixes performance and code quality usually fixes most of the security exposure as a side effect.

For stores where security is one symptom of broader technical debt, the right response isn't a security project — it's a structured rescue. We cover that framework in How to Rescue a Magento 2 Store Without Rebuilding It.

What to Do Next

If you've read this far, you're either dealing with a current security concern or you're trying to get ahead of one. Both are good positions to be in.

Three immediate actions:

1. Verify your patch level. This is the single most impactful thing you can do today. Run the version check, compare against current releases, schedule patching for anything outdated.

2. Confirm monitoring is active. Sentry or equivalent for application errors. Adobe security scan if you're registered. Server monitoring for traffic anomalies. If any of these aren't running, that's your week one priority.

3. Test your backups. Don't trust that they exist. Verify they exist, include the right data, and can actually be restored.

For more structured assessment:

Want a structured Magento health check? Download our Practical Magento 2 Reanimation Plan — the same checklist we use internally, including security checks.

Or talk to us directly. Book a 30-minute discovery call — we'll review your current security posture and tell you whether you have urgent issues or routine maintenance items. No alarmism, just honest assessment.

Magento security isn't about being paranoid. It's about being current on patches, watching the right signals, and having recovery options when something does go wrong. The stores that handle security well aren't the ones with the biggest security budgets — they're the ones where the basics are consistently in place.

The attackers are automated and relentless. The defense is also automated and disciplined. Match the pattern.