The Amasty disclosure: Why third-party extensions are Magento's biggest security risk

In August 2026, Sansec disclosed that Amasty, one of the largest Magento extension vendors, had patched vulnerabilities across dozens of extensions, including two critical remote code execution flaws, confirming that third-party extensions are the primary attack surface for Magento and Adobe Commerce stores. Audit every third-party extension on your store now, prioritising those that touch checkout, payment processing, and customer accounts, and verify that no unauthorised scripts or file modifications are already present.

Third-party extensions, not the core platform, are the primary attack vector for Magento and Adobe Commerce stores. Sansec's August 2026 disclosure that Amasty, one of the largest Magento extension vendors, patched vulnerabilities across dozens of extensions, including two critical remote code execution flaws, confirms what forensics data has shown for years: the average Magento store's extension stack of 20 to 100 modules is its most dangerous and least monitored surface area. If your store runs third-party extensions, you need to audit every one of them now.

What are the symptoms of a compromised extension?

Extension-level compromise rarely looks like a platform-level breach. Instead, merchants typically see:

• Unexpected scripts loading on checkout pages, injected JavaScript that captures payment card data (Magecart-style skimmers) appearing only intermittently or only for certain customer segments
• Customer accounts behaving strangely, password reset emails that customers did not request, shipping addresses changed without explanation, or account data accessed from unfamiliar locations
• New or modified files in your Magento installation that do not match the extension vendor's official release
• Storefront behaviour changes, redirects to phishing pages, pop-ups or overlays appearing on product or checkout pages, or unusually slow page loads caused by external resource loading
• Payment processing anomalies, increased chargeback rates, customer complaints about duplicate charges, or payment gateway errors that appear and disappear

Likely alert or error variants:

• Content Security Policy (CSP) violation reports for domains you do not recognise
• Browser console warnings about mixed content or blocked scripts
• Google Search Console manual action or security issue notification
• PCI scan failures identifying unauthorised external connections

Why extensions are the real attack surface

Sansec's research has consistently shown that bad extensions are now the main source of Magento hacks. The economics are straightforward:

1. The scale of the extension ecosystem is enormous. Amasty alone offers over 260 Magento extensions. The broader ecosystem includes thousands of vendors, and the average Magento store runs 20 to 100 third-party modules according to Sansec analysis. Each extension is an independent codebase maintained by an independent team with its own security practices.

2. Vulnerability disclosure is fragmented. When Adobe patches the core platform, it publishes a security bulletin (like APSB26-92 on August 11, 2026). Extension vendors have no equivalent coordinated disclosure mechanism. Amasty's mass security update was disclosed through Sansec's research and Amasty's own blog, not through any centralised security advisory system. Many merchants never learn about extension vulnerabilities until after exploitation.

3. Extension updates do not follow platform patch cycles. Adobe Commerce moved to monthly security patches starting January 2026. Extension vendors patch on their own schedules. The Amasty Order Attributes vulnerability (CVE-2026-53787, CVSS 9.8) was patched in June 2026, but the mass disclosure covering dozens of additional extensions came in August, meaning many merchants who patched the critical CVE may still have vulnerable extensions they do not know about.

4. Extension code runs with full platform privileges. Magento extensions have access to the database, file system, and customer data. A vulnerability in a single extension, even one as seemingly benign as "Order Attributes", can give an attacker the same access as a full platform compromise.

What the Amasty mass disclosure reveals

Sansec's research, updated through August 13, 2026, identified vulnerabilities across dozens of Amasty extensions spanning critical, high, medium, and low severity ratings. The two critical vulnerabilities include the previously disclosed CVE-2026-53787 (unauthenticated file upload in Order Attributes, CVSS 9.8) and additional critical flaws discovered during a broader audit.

What makes this disclosure significant for every Magento merchant:

1. It was not a single vulnerability; it was a systematic audit. The breadth of the disclosure suggests that when a security researcher examines an extension vendor's full catalogue, vulnerabilities are found across many products, not just one.

2. Amasty is a major, reputable vendor. If a leading vendor with 260+ extensions and significant market presence has dozens of vulnerabilities across its catalogue, the situation at smaller or less-resourced vendors is likely worse.

3. The vulnerabilities span severity levels. Low and medium severity issues are often ignored by merchants but can be chained together or used as stepping stones to more severe exploitation.

How to audit your extension stack

Step 1: Inventory every installed extension. Run composer show on your Magento installation to generate a complete list of installed packages. Cross-reference this against your extension license records. Extensions that appear in the file system but not in your purchase records are a red flag.

Step 2: Check every extension against known vulnerabilities. Use Sansec's MageVulnDB (publicly available on GitHub), which maintains a list of Magento extensions with known security issues. Check each installed extension against this database and against the vendor's own security advisories.

Step 3: Verify extension integrity. Sansec's composer-integrity-plugin checks installed Composer packages against known correct checksums. Any modified file that does not match the vendor's official release indicates either tampering or an untracked patch.

Step 4: Remove unused extensions. Every extension you are not actively using is an attack surface with no business value. Disabling an extension in the Magento admin is not sufficient; it must be fully removed via Composer and its database tables cleaned up.

Step 5: Monitor your storefront for exploitation symptoms. Extension vulnerabilities that have been present for weeks or months may have already been exploited. Look for the storefront-level symptoms listed above, injected scripts, unexpected external resources, CSP violations, and payment anomalies.

Verification: How to confirm your store is clean

After auditing and updating extensions:

1. Run a full server-side malware scan using a tool like Sansec eComscan
2. Check your Magento database for unfamiliar admin users, modified customer records, or new cron jobs
3. Review your web server access logs for suspicious POST requests to extension-specific endpoints
4. Verify that your checkout pages load only the scripts and external resources you expect
5. Run a PCI external vulnerability scan to confirm no unauthorised network connections are present
6. Monitor customer complaints and chargeback rates for 30 days post-remediation

Prevention: Building extension security into operations

The Amasty disclosure is not an isolated event; it is the latest evidence that ecommerce extension security requires continuous operational attention:

• Subscribe to vendor security advisories for every extension you use. If a vendor does not publish security advisories, that is itself a risk signal.
• Monitor Sansec's threat research at sansec.io/research for new extension vulnerability disclosures.
• Implement Content Security Policy (CSP) on your storefront to detect and block unauthorised script injection, the most common exploitation outcome of extension vulnerabilities.
• Establish a regular extension audit cadence, quarterly at minimum, and immediately after any vendor advisory.
• Monitor your live storefront for the symptoms that indicate exploitation has already occurred. Server-side scanning catches file-level malware; storefront monitoring catches the customer-facing symptoms that file scanning misses.

Continuous storefront monitoring is the layer that catches what extension audits and server-side scans cannot: the real-time, customer-facing symptoms of a compromised extension that only manifest intermittently and only in the browser. AuditIQ is an eCommerce monitoring platform built specifically for stores where the extension stack is the highest-risk surface area. Rather than relying on server-side logs that extension-level compromise routinely bypasses, AuditIQ monitors your live storefront from the outside, the same perspective a Magecart skimmer or injected redirect operates from.

For Magento and Adobe Commerce stores managing extension risk, AuditIQ provides:

• Checkout script monitoring: continuously detects unexpected third-party scripts loading on payment pages, including skimmers that only appear for specific customer segments or at specific times
• File and DOM change detection: flags when page structure, external resource requests, or form behaviour changes in ways that indicate extension-level tampering
• Real-user session capture: records what customers actually experience during checkout, catching injected overlays, redirects, and payment form modifications that server logs never see
• Extension behaviour baseline: compares your live storefront against a known-clean state after every extension update, so regressions surface within hours rather than weeks
• Revenue impact correlation: connects anomalies in storefront behaviour to changes in conversion rate and order volume, so you know immediately if an extension issue is costing you money

So instead of discovering a compromised extension through chargebacks, customer fraud reports, or a PCI scan failure weeks after the fact, you see the anomaly on your checkout page within hours of it appearing, when containment is still straightforward.

FAQs

1. How do I know if an extension has been compromised versus just having a vulnerability?

A vulnerability means the code contains a flaw that could be exploited. Compromise means an attacker has already exploited it. Signs of compromise include modified files, unexpected database entries, injected scripts on your storefront, and customer-facing symptoms like checkout skimmers. Always check for both.

2. Should I stop using Amasty extensions?

No, Amasty has patched the disclosed vulnerabilities. The disclosure actually demonstrates responsible security practices. The risk applies equally to all extension vendors; Amasty is simply the one that got systematically audited publicly.

3. Does updating the Magento core platform fix extension vulnerabilities?

No. Platform patches and extension updates are completely independent. Updating to the latest Magento or Adobe Commerce version does not patch vulnerabilities in third-party extensions.

4. How often should I audit my extension stack?

At minimum, quarterly, plus immediately after any vendor security advisory. Stores processing high transaction volumes or handling sensitive data should audit monthly.