Table of Contents

What is happening
Why this works
What to check in audit
Basic hygiene checks often missed
Key takeaway

SVG-Based Attacks in Magento: The Shift After Polyglot Exploits

Most Magento security checks still revolve around a familiar pattern looking for injected JavaScript, modified core files, or suspicious third-party scripts. For a long time, that approach worked well enough to catch the majority of compromises. But that assumption is no longer safe.

There is a noticeable shift in how attackers operate. Instead of directly modifying checkout scripts or injecting visible malicious code, they are now leveraging SVG files as an execution vector especially after gaining initial access through polyglot uploads. This change makes traditional detection methods far less effective.

What is happening

The attack flow has evolved in a way that blends into normal Magento behavior, making it harder to detect during routine audits.

Instead of directly tampering with checkout logic, attackers follow a more subtle path:

They first upload a polyglot file. This file appears to be a valid SVG image but contains hidden executable script content.
The file is stored in the /pub/media/ directory, which is typically considered safe and trusted.
The uploaded SVG is then referenced through CMS blocks, pages, or other frontend content.
When the SVG is rendered in the browser, the embedded script executes.

This execution does not immediately break anything. In fact, that is what makes it dangerous.

Once triggered, the attacker-controlled script can:

Render a fake payment interface on top of the real checkout
Capture sensitive data such as card details
Allow the original checkout process to continue normally

From a customer’s perspective, everything appears legitimate. The order goes through, confirmation is received, and there are no obvious signs of compromise. Meanwhile, sensitive data has already been exfiltrated.

Why this works

This approach is effective not because of a single vulnerability, but because it exploits a combination of assumptions and blind spots in typical Magento setups.

1. SVG supports embedded scripts

SVG is not just an image format it is XML-based and can include scripts and interactive elements. This makes it a perfect carrier for hidden logic when not properly sanitized or restricted.

2. Media files are trusted and rarely audited

The /pub/media directory is generally treated as a storage location for harmless assets like images and videos. Security audits often skip deep inspection of this directory, assuming it does not contain executable logic.

3. No direct changes in checkout or JS files

Traditional security checks look for modifications in:

Core Magento files
JavaScript bundles
Checkout-related scripts

In this case, none of those are altered. The malicious logic is executed at runtime via a referenced file, which keeps the codebase looking clean.

What to check in audit

Given this shift, audit strategies need to expand beyond code-level inspection and include file-based execution paths.

1. /pub/media/ directory

Review this directory for:

Recently added SVG files
Files with unusual naming patterns
SVGs that do not align with business usage

Even a single malicious file in this location can be enough to compromise the storefront.

2. CMS blocks and pages

Check for:

Inline SVG usage
References to media files that seem out of place
Any embedded content that could render SVGs dynamically

Since attackers often rely on CMS-driven rendering, this becomes a key inspection point.

3. Upload entry points

Trace how files can enter the system:

Admin uploads
API-based uploads
Third-party extensions handling media

Any upload mechanism that does not strictly validate file content (not just file type) can be abused.

4. Checkout behavior

Even if no code changes are visible, observe:

Unexpected overlays
UI elements that do not match the theme
Unusual DOM manipulations during payment steps

These subtle signs can indicate that something is being injected at runtime rather than stored in code.

Basic hygiene checks often missed

While focusing on advanced attack patterns, it is equally important not to overlook foundational issues that can weaken the system.

Unresolved Git conflicts
Search the codebase for markers like:

<<<<<<<
=======
>>>>>>>

Example:

<<<<<<< HEAD
$current_code
=======
$incoming_code
>>>>>>> feature-branch

Here’s what each part means:

<<<<<<< HEAD HEAD → Your current branch’s code
======= → Separator between the two versions
>>>>>>> feature-branch → Code coming from the branch you’re merging

So Git is basically saying:

“I found two different versions of this code and I don’t know which one is correct.”

These indicate incomplete merges and can lead to unpredictable behavior or even expose unintended logic.

.gitignore misconfigurations
Ensure that critical .php files are not being excluded from version control. If important files are ignored, malicious changes can go unnoticed and untracked.

Admin 2FA enforcement
A significant number of these attacks begin with compromised admin access. Enforcing two-factor authentication reduces the risk of unauthorized entry points being exploited.

Content Security Policy (CSP)
Although implementing CSP can be complex and resource-intensive, it is increasingly becoming a necessary layer of defense. Without it, browsers have fewer restrictions on what external or embedded content can execute.

At the same time, relying on:

Content-Security-Policy-Report-Only is not sufficient. Report-only mode helps in monitoring but does not actively block malicious behavior. For real protection, enforcement mode is required.

Key takeaway

This is not just a new technique it represents a broader shift in attack strategy.

The focus has moved from direct code injection to file-based execution, where malicious logic is hidden inside seemingly harmless assets and triggered during runtime.

If security audits continue to focus only on: