Skip to content

Magento and eCommerce Platform Security: Knowing What You Run and What You Owe Customers

CVE-2026-45247's CISA KEV status means organisations running Mirasvit Full Page Cache Warmer are now under a federal mandate to remediate — and should be asking whether their eCommerce platform inventory is accurate enough to comply. Magento deployments often span multiple versions, extension states, and customisation layers that make attack surface visibility a genuine challenge.

Article asset-security

The CISA KEV addition of CVE-2026-45247 creates a specific compliance problem for organisations that operate Magento eCommerce infrastructure: CISA’s Binding Operational Directive 22-01 requires federal civilian agencies to remediate KEV-listed vulnerabilities within the specified timeframe (24 June for CVE-2026-45247). For commercial organisations, the KEV is not directly binding, but it is widely used as a basis for contractual and regulatory remediation requirements, including PCI DSS vulnerability management controls.

The remediation is technically straightforward — update the Mirasvit Full Page Cache Warmer extension. The challenge is that many organisations cannot confidently answer whether the vulnerable extension is installed, which version is running, and whether the update has been successfully applied.

The Magento Inventory Challenge

Magento deployments are complex assets. Unlike a single-vendor SaaS platform where the vendor controls the version state, a Magento deployment combines:

  • Adobe Commerce / Magento Open Source core (version controlled via Composer)
  • Adobe-published security patches (applied separately from full version upgrades)
  • Third-party extensions (installed via Composer or manual file installation)
  • Custom code (modifications to core or extension behaviour)
  • Theme customisations

This stack means a Magento deployment’s effective security posture is determined by the intersection of all these components. The core platform version is a necessary but insufficient security data point — an up-to-date core platform running a compromised extension is vulnerable.

Building a Comprehensive Magento Asset Record

An accurate Magento asset record for security purposes includes:

1. Core version:

php bin/magento --version

2. Applied patches (for Adobe Commerce):

# Adobe Commerce only
php bin/magento patch:list --status=Installed

3. All installed modules and versions:

php bin/magento module:status --enabled

For version information:

composer show | grep "mirasvit\|vendor-name" | awk '{print $1, $2}'

4. Extension installation method: Extensions installed via Composer are tracked in composer.lock — use composer show --no-dev for a complete list with version pinning. Extensions installed by manual file copy are not tracked in Composer and must be discovered by directory enumeration in app/code/ and vendor/.

5. PHP version and web server:

php --version
nginx -v 2>&1 || apache2 -v 2>&1

PHP version affects which deserialization mitigation options are available.

PCI DSS Implications

Organisations that accept payment cards via Magento are subject to PCI DSS requirements for their cardholder data environment (CDE). CVE-2026-45247’s CVSS 9.8 score and active exploitation status have direct PCI DSS implications:

PCI DSS 6.3.3 requires that all software components are protected from known vulnerabilities by installing applicable security patches. For a CVSS 9.x vulnerability with a patch available, the maximum remediation period under PCI DSS 6.3.3 is one month for critical vulnerabilities.

PCI DSS 6.4.1 requires an inventory of bespoke and custom software and their associated authentication. Third-party extensions installed in a Magento CDE should be included in this inventory.

PCI DSS 11.3 requires internal and external vulnerability scanning. The extension inventory audit described above should be part of a quarterly internal scan scope review.

For PCI DSS compliance purposes, the effective date of awareness of CVE-2026-45247 as actively exploited is the CISA KEV addition date (3 June 2026). Remediation documentation should record the date of awareness, the date the patch was applied, and the person responsible for the remediation decision.

Magento Platform End-of-Life Tracking

Beyond the current CVE, organisations should track their Magento platform’s end-of-life status:

VersionAdobe Commerce EoLOpen Source EoL
Magento 2.4.6April 2026April 2026
Magento 2.4.7April 2027April 2027
Magento 2.4.8April 2028April 2028

Magento installations on end-of-life versions no longer receive security patches from Adobe — including for future critical vulnerabilities. The Magento end-of-life status is a material asset security risk that should be tracked in the asset record and included in the vulnerability management programme’s remediation backlog.

Share this article

Related Intelligence

🗄️ Assets

iRhythm Cardiac Monitoring Breach Exposes Patient PHI for 12 Million Zio Patch Wearers

iRhythm Holdings disclosed a data breach after social engineering granted attackers access to third-party systems hosting protected health information for approximately 12 million patients. A ransom demand was received on 9 June, and HIPAA breach notification timelines are now active for any covered entity whose patient data iRhythm processes.

#healthcare +5
🗄️ Assets

Novo Nordisk Discloses Breach of Clinical Trial Participant Data — Ozempic and GLP-1 Research Records Exposed

Danish pharmaceutical giant Novo Nordisk has disclosed a cybersecurity incident in which attackers gained unauthorised access to IT systems holding personal data of clinical trial participants, including individuals enrolled in GLP-1 receptor agonist trials for Ozempic and Wegovy. The breach raises significant regulatory concerns under EU clinical trial data protection requirements and the ICH GCP framework governing trial participant data handling.

#pharmaceutical +7
🗄️ Assets

Dell DSA-2026-239: CVE-2026-23856 Privilege Escalation in iDRAC9 Exposes PowerEdge Server Management Plane

Dell has patched a high-severity privilege escalation vulnerability in the iDRAC9 remote management controller affecting PowerEdge servers across multiple generations. CVE-2026-23856, rated CVSS 8.8, allows a low-privileged authenticated attacker to escalate to Administrator rights on the iDRAC management plane — granting control over server power, firmware, BIOS settings, and virtual console access outside the scope of the host operating system.

#dell +7