💻 AppSec

Magento Extension Supply Chain Risk: CVE-2026-45247 and the Third-Party Plugin Attack Surface

CVE-2026-45247 in the Mirasvit Full Page Cache Warmer illustrates a structural security problem in the Magento ecosystem: eCommerce site security is determined not just by the core platform version, but by every third-party extension installed. This guide covers how to assess and reduce the Magento extension attack surface.

4 min read
#magento#php#supply-chain#cve-2026-45247#extension-security#ecommerce#dependency-management#deserialization

Magento 2 is the world’s most widely deployed open-source eCommerce platform. The core Magento platform receives regular security patches from Adobe (which acquired Magento in 2018) and has a structured Security Patch release programme. The extension ecosystem — the several thousand third-party modules available through Magento Marketplace and direct vendor distribution — does not.

CVE-2026-45247 in the Mirasvit Full Page Cache Warmer is the fourth Magento ecosystem extension vulnerability to reach the CISA Known Exploited Vulnerabilities catalogue in the past 18 months. The pattern is consistent: a third-party extension handles user-supplied data (cookie values, request parameters, form inputs) using the same PHP deserialization mechanisms as the core Magento codebase, but without the security scrutiny that Adobe applies to core components. The extension is exploitable. The core platform version is irrelevant.

The Extension Inventory Problem

Most Magento site operators know their core Magento version. Fewer maintain an accurate inventory of installed extensions, their versions, and their security update status. A Magento installation with 30 installed extensions has 30 potential additional attack surfaces, each with their own security patch cadence and disclosure process — or, in many cases, no formal security process at all.

Build a current extension inventory:

# List installed Magento modules with their versions
bin/magento module:status --enabled | grep -v "^List of" | sort

For a more detailed view including version numbers:

php -r "
  \$om = \Magento\Framework\App\ObjectManager::getInstance();
  \$data = \$om->get('\Magento\Framework\Module\FullModuleList')->getAll();
  foreach (\$data as \$name => \$module) {
    echo \$name . \" v\" . (\$module['setup_version'] ?? 'unknown') . PHP_EOL;
  }
" | sort

Cross-reference the output against:

  • The Magento Marketplace for each vendor’s current version and security bulletin
  • The vendor’s own website or release notes
  • The MageReport.com vulnerability database (covers known vulnerabilities in popular Magento extensions)

Security Criteria for Extension Selection

Before installing a new extension, assess its security posture:

Vendor security track record:

  • Does the vendor have a documented security disclosure process?
  • Has the vendor issued security patches promptly when vulnerabilities were reported?
  • Does the vendor maintain a security changelog separate from the feature changelog?

Code quality indicators:

  • Does the extension use Magento’s official ACL and authentication framework, or implement its own?
  • Does it handle user input (form data, cookies, URL parameters) with Magento’s input validation utilities, or directly?
  • Does the extension have automated tests and a CI/CD pipeline?

Marketplace vetting:

  • Adobe vets extensions submitted to Magento Marketplace for basic code quality, but not comprehensively for security. Marketplace listing does not imply security review.
  • Extensions sold directly by vendors (outside Marketplace) have no third-party vetting at all.

PHP Deserialization: The Recurring Vulnerability Class

CVE-2026-45247 is a PHP deserialization vulnerability — the same vulnerability class as numerous prior Magento extension exploits. PHP’s unserialize() function, when applied to attacker-controlled data, allows an attacker to instantiate arbitrary PHP objects in the server process, and to trigger magic methods (__wakeup, __destruct, __toString) that can produce code execution.

Magento’s codebase includes numerous PHP classes with exploitable gadget chains, making any unsanitised deserialization of user-supplied data in a Magento context a potential RCE.

Extension code review for deserialization:

When reviewing a third-party extension’s security, scan for uses of unserialize() on potentially user-controlled data:

# Search for unserialize calls in extension code
grep -rn "unserialize(" vendor/Mirasvit/ vendor/Vendor2/ app/code/

Any unserialize() call that processes data from request cookies, GET/POST parameters, session data, or database fields that store user-supplied values should be reviewed for input validation.

Modern alternative: json_decode() is safe for user-supplied data where structured data is needed — JSON decoding does not invoke PHP magic methods and does not enable gadget chain exploitation.

Extension Update Management

Unlike the Magento core, which is updated via Composer and Adobe’s security patch process, third-party extension updates require active management:

  • Subscribe to vendor security mailing lists for every installed extension vendor — this is the only reliable early warning for security patches
  • Quarterly extension audit: Review installed extension versions against current vendor releases. Any extension more than two major versions behind should be flagged for urgent review
  • Composer version constraints: Pin extension dependencies in composer.json to specific versions (~1.11.0) rather than broad constraints (* or >=1.0), so that updates are deliberate rather than accidental

A Magento deployment’s security is only as strong as the least-maintained extension in its stack.

Share this article