PolyShell: The Magento 2 Vulnerability That Hands Attackers Your Server - No Login Required

A critical vulnerability in Magento 2 is under active exploitation right now. It does not require authentication. It does not need a privileged account. It does not need your credentials, your admin panel, or your cooperation.

All it needs is your store to be running an unpatched version of Magento 2.

The vulnerability – first identified and named by ecommerce security firm Sansec and now widely referred to as PolyShell – allows attackers to upload malicious files to your server and achieve full remote code execution. Injected checkout scripts are already appearing across the ecosystem. Stores are being compromised before their teams know there is anything to act on.

This is not a theoretical risk. This is active, widespread, and being exploited at scale.

If your store is running an unpatched version of Magento 2, it is not a question of whether you are at risk. It is a question of whether you have already been compromised.

What is the PolyShell vulnerability?

The symptoms are familiar. Releases that take weeks longer than they should. A Black Friday campaign approached with anxiety rather than confidence. An agency invoice that grows every month while the list of unresolved issues grows alongside it. Core Web Vitals that slip quietly while the team firefights something more urgent.

These symptoms feel like a Magento problem. They are not. They are symptoms of a support model that was never designed to take ownership of outcomes — only to respond to tickets.

The agency model works by scope: you define a task, they complete it, you pay for the time. There is no structural incentive for an agency to prevent the next incident, because the next incident is also billable. There is no mechanism for a junior developer — which is who handles most tickets at most agencies — to understand the broader architecture well enough to protect it.

The agency model is optimised for output. What a scaling Magento brand actually needs is ownership — someone who holds the platform accountable between projects, not just during them.

What a Magento migration actually costs

PolyShell is a critical unauthenticated remote code execution vulnerability affecting Magento 2 and Adobe Commerce. The flaw exists in Magento’s file upload handling. An attacker can craft a malicious file that bypasses server-side validation – exploiting how certain file types are processed – and upload it directly to the target store without authentication.

Once a malicious file is on the server, the attacker has what amounts to full control: the ability to read data, modify files, execute server-side code, and persist access indefinitely.

The name PolyShell reflects the technique used: a polyglot file – a file that is simultaneously valid as two different file types – is used to bypass upload restrictions and deliver a web shell to the target server

What attackers can do once inside

Inject malicious JavaScript into checkout flows – capturing card data, credentials, and PII directly from your customers
Access and exfiltrate your customer database, order history, and payment data
Modify product prices, redirect transactions, or silently intercept payment processing
Install persistent backdoors that survive patches and platform updates
Use your server infrastructure as a base for further attacks on other systems

The damage from a PolyShell compromise is not just technical. It is reputational, regulatory, and commercial – often simultaneously.

Why this vulnerability is particularly dangerous

Most security vulnerabilities require some form of attacker access – a valid user account, admin credentials, or at minimum a specific configuration to exploit. PolyShell requires none of these. The attack surface is any Magento 2 store running a vulnerable version, accessible from the public internet.

That covers a significant portion of the global Magento ecosystem.

The second reason this vulnerability is dangerous is the nature of the damage it enables. A compromised checkout page is not immediately visible. Injected scripts can be designed to load only under specific conditions – certain browsers, certain user journeys, certain times of day. Stores can remain compromised for days or weeks without any visible sign of disruption, all while customer data is being silently exfiltrated.

By the time most teams notice something is wrong – through customer complaints, a PCI DSS audit, or a payment processor flag – the damage has already been done.

The pattern we keep seeing

Across the stores we work with and the broader Magento ecosystem, the same conditions keep appearing in stores that are successfully exploited:

What changes in the first 90 days

Magento versions that have not been updated in 12+ months
Security patches treated as optional, or deferred to the next sprint that never arrives
No active monitoring of server behaviour, file integrity, or unusual traffic patterns
No process for reviewing checkout page changes against a known-good baseline
Incident response that begins with customer reports rather than internal detection

Security patches are not optional maintenance. They are the minimum viable protection against attacks that are already happening.

Not sure if your store has the latest security patches applied?

A free 20-minute technical audit will confirm your patch status, identify exposed endpoints, and tell you exactly where your risk lives. Senior engineers only. No account managers, no sales pitch. Book your free technical audit below:

What happened when PolyShell surfaced: what proactive ownership looks like

At Foxycom, we treat security updates with the same urgency we apply to production incidents – because failing to act on a critical vulnerability is itself an incident waiting to happen.

The moment PolyShell was publicly identified, we did not wait. We did not schedule it for the next sprint. We did not add it to a backlog.

What we did immediately

Applied mitigations across all platforms we manage – before exploitation could occur
Secured vulnerable file upload endpoints and hardened the relevant attack surface
Deployed active monitoring for the specific indicators of compromise associated with PolyShell
For the handful of affected cases we encountered – investigated immediately, isolated, and resolved

This is what proactive ownership looks like. Not luck. Not speed. A commitment to treating security as an ongoing operational responsibility – not a periodic project.

The difference between a store that was patched before exploitation and a store that was compromised is almost always one thing: whether a senior engineer was actively monitoring and maintaining the platform, or whether the store was running on autopilot between agency tickets.

Every store we manage was protected before PolyShell became a widespread problem. Not because we moved fast. Because we were already watching.

How to assess whether your store is exposed

If you are running Magento 2 or Adobe Commerce and you are not certain your platform is on the latest security patch level, you should treat your store as potentially exposed until you have confirmed otherwise.

Uncertainty here is not a neutral position. The cost of assuming you are safe when you are not is dramatically higher than the cost of a rapid architecture review.

Immediate steps

Confirm your Magento version and compare against Magento’s published security patch log. If you are not on the current patch level, treat this as urgent.
Review your server’s file upload directories for unexpected files – particularly in pub/media and var/. Polyglot web shells often look like innocuous image or document files.
Audit your checkout page JavaScript against a known-good baseline. Any script that has been added or modified recently and was not explicitly deployed by your team requires immediate investigation.
Review access logs for unusual POST requests to file upload endpoints. PolyShell exploitation leaves recognisable patterns in server logs – a senior engineer can identify them quickly.
Apply the relevant Magento security patch as a matter of urgency. This is not optional and it is not something to schedule for next quarter.

A thorough architecture review takes 20 minutes. Recovering from a checkout script compromise – with the regulatory, reputational, and technical consequences – takes significantly longer.

Why this keeps happening: the structural problem behind recurring Magento vulnerabilities

PolyShell is not a one-off. It is part of a pattern that has played out across the Magento ecosystem repeatedly: a critical vulnerability is disclosed, active exploitation begins quickly, and a significant percentage of stores remain unpatched weeks or months later.

The reason is structural. Most Magento brands are supported by an agency model that is optimised for project delivery – features built, tickets resolved, sprints completed. Security patches exist outside this model. They are not features. They are not billable milestones. They are the quiet, unglamorous maintenance that keeps a platform safe between projects.

An agency with no standing accountability for your platform’s security posture has no structural incentive to apply a patch the same day it is released. There is no alert. There is no obligation. There is no consequence – for them – until something goes wrong.

The agency model is designed for output. Security requires ownership. Those are not the same thing, and the gap between them is exactly where exploits like PolyShell find their footing.

Architecture ownership – a model where senior engineers hold ongoing accountability for your platform’s health, security, and stability – closes this gap by design. Not because ownership teams are more capable in the abstract, but because they have the context, the monitoring, and the accountability that reactive agency relationships structurally cannot provide.

Frequently asked questions

What is the PolyShell Magento vulnerability?

PolyShell is a critical unauthenticated remote code execution vulnerability in Magento 2 and Adobe Commerce. It allows attackers to upload malicious polyglot files – files engineered to bypass server-side validation – to a target Magento server without authentication. Once uploaded, these files can be executed to gain full server access, inject checkout scripts, and exfiltrate customer data.

Does my Magento store need to be on a specific version to be vulnerable?

PolyShell affects Magento 2 installations that have not been updated to the relevant security patch level. If you are running an older Magento 2 version and have not applied recent security patches, your store is likely vulnerable. The safest course of action is to confirm your patch status immediately and apply outstanding security updates as a matter of urgency.

How do I know if my Magento store has already been compromised?

Indicators of compromise include unexpected files in upload directories, unexplained changes to checkout page JavaScript, unusual server activity or POST requests in your access logs, and customer reports of suspicious behaviour during checkout. Many compromised stores show no visible signs initially – which is why active monitoring and file integrity checking are essential, not optional.

What is a polyglot file and how does it bypass Magento's upload restrictions?

A polyglot file is a file crafted to be simultaneously valid under two different file type interpretations. In the context of PolyShell, an attacker creates a file that appears to be a legitimate image or document but is also valid as executable server-side code. When Magento’s upload handling validates the file, it reads it as the legitimate type – but when the server subsequently executes it, it runs as a web shell.

How quickly should I apply the Magento security patch for PolyShell?

Immediately. Active exploitation is already underway at scale. Every day a vulnerable store remains unpatched is a day it is actively exposed to compromise. If your current agency or development team does not have the capacity to apply the patch within 24 hours, you should escalate this as a critical incident.

What does proactive security ownership look like for a Magento store?

Proactive security ownership means security patches are applied the same day they are released – not scheduled into the next sprint. It means file integrity monitoring is in place and alerting on unexpected changes. It means checkout page scripts are monitored against a baseline and any deviation triggers an immediate investigation. It means a senior engineer holds ongoing accountability for the platform’s security posture – not just when an incident has already occurred.

PolyShell: The Magento 2 Vulnerability