← Back to Feed CACHED · 2026-09-27 03:24:16 · CACHE_KEY CVE-2026-45247
CVE-2026-45247 · CWE-502 · Disclosed 2026-05-26

Mirasvit Full Page Cache Warmer for Magento 2 Unauthenticated PHP Object Injection to RCE

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Like leaving a master key in every shopping cart — one poisoned cookie hands attackers your entire storefront

CVE-2026-45247 is a PHP object injection flaw in the Mirasvit Full Page Cache Warmer extension for Magento 2 (all versions before 1.11.12). The extension reads a CacheWarmer cookie on every storefront request and feeds its value straight into PHP's native unserialize() with zero class restriction. An unauthenticated attacker crafts a serialized Monolog gadget chain (SyslogUdpHandler → BufferHandler → FingersCrossedHandler → GroupHandler), base64-encodes it, drops it into the cookie, and fires a single GET request to any storefront page. The server reconstructs attacker-controlled objects and executes arbitrary OS commands under the web-server user — typically www-data or apache. No credentials, no user interaction, no special configuration. Sansec identified roughly 6,000 externally fingerprinted stores running Mirasvit extensions, with the true number likely much higher behind CDNs.

The vendor severity of CRITICAL / 9.8 is dead-on. There is essentially no friction anywhere in this chain: the targets are internet-facing by definition (they're e-commerce storefronts), the prerequisite gadget chains ship as standard Magento Composer dependencies (Monolog), authentication is not required, and the payload fits in a single HTTP cookie header. CISA added it to the KEV catalog on June 3, 2026 — just nine days after patch release — after confirming active in-the-wild exploitation. Imperva observed campaigns targeting gaming and business-sector Magento stores in the US, UK, France, and Australia. This is textbook Magecart-enablement: once an attacker has code execution on a Magento server, card-skimming JavaScript injection, admin account creation, and full database exfiltration are minutes away.

"Unauthenticated RCE via a single cookie on internet-facing Magento stores. Actively exploited. Patch now."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Identify vulnerable storefront

The attacker scans for Magento storefronts running the Mirasvit Cache Warmer extension. Fingerprinting can be done passively by checking for extension-specific frontend assets, or actively by sending a CacheWarmer cookie and observing server behavior. Shodan and FOFA dorks for Magento storefronts narrow the target list. Sansec's own scan found ~6,000 stores with Mirasvit extensions visible externally.
Conditions required:
  • Internet-reachable Magento storefront
  • Mirasvit Cache Warmer extension installed (any version < 1.11.12)
Where this breaks in practice:
  • Extension is third-party, not core Magento — limits the pool to stores that purchased and installed it
Detection/coverage: External attack-surface management (ASM) tools can fingerprint Mirasvit presence. Nuclei community templates for CVE-2026-45247 are available.
STEP 02

Craft Monolog gadget-chain payload

The attacker constructs a serialized PHP object leveraging Monolog's SyslogUdpHandler, BufferHandler, FingersCrossedHandler, and GroupHandler classes — all present in Magento's Composer dependency tree. The payload embeds an arbitrary OS command (e.g., curl to a C2 or a reverse shell one-liner). Public PoC by fevar54 on GitHub automates payload generation and delivery. The PHPGGC tool can also generate compatible chains automatically.
Conditions required:
  • Knowledge of Monolog gadget chains (public)
  • Target runs a Magento version shipping Monolog (virtually all Magento 2.x installs)
Where this breaks in practice:
  • None — the PoC is public and weaponized, and PHPGGC automates chain generation
Detection/coverage: WAF rules matching serialized PHP object patterns in cookie values. Regex CacheWarmer:(Tz|Qz|YT) on cookie headers catches base64-encoded serialized objects.
STEP 03

Deliver payload via CacheWarmer cookie

The attacker sends a single HTTP GET request to any storefront URL with the CacheWarmer cookie set to the base64-encoded serialized payload. No authentication is needed. The extension's cookie handler fires on every storefront request, not just cache-warming endpoints, so any product page, category page, or the homepage will trigger deserialization.
Conditions required:
  • Network path to the storefront (it's on the public internet)
Where this breaks in practice:
  • None — single unauthenticated HTTP request
Detection/coverage: HTTP request logging with cookie inspection. IDS/WAF signatures for PHP serialized objects in Cookie headers. Imperva Cloud WAF blocks this pattern out of the box.
STEP 04

Achieve code execution as web-server user

PHP's unserialize() reconstructs the Monolog gadget chain, which triggers the embedded OS command. Execution runs under the web-server process identity (www-data, apache, or nginx). The attacker now has arbitrary command execution on the Magento application server. Common first-stage payloads observed in the wild include echo PWNED_CVE2026_$(date +%s) (validation) and sleep 5 (blind confirmation).
Conditions required:
  • Vulnerable version of the extension processes the cookie
Where this breaks in practice:
  • PHP disable_functions could block specific functions, but standard Magento hosting typically permits system(), exec(), passthru()
Detection/coverage: EDR / HIDS on the web server detecting child process spawning from PHP. Auditd rules for unexpected exec calls from www-data.
STEP 05

Post-exploitation: card skimming, data exfiltration, persistence

With code execution, the attacker injects Magecart-style JavaScript skimmers into checkout pages, creates rogue admin accounts, dumps the customer_entity and sales_order tables (containing PII and card data), and drops webshells for persistence. This is the canonical post-compromise playbook for Magento breaches. The attacker may also modify payment gateway configurations to redirect transactions.
Conditions required:
  • Successful code execution from step 4
Where this breaks in practice:
  • File integrity monitoring (FIM) on Magento core files may alert on webshell creation
  • Database access may require reading env.php for credentials, but the web-server user typically has read access
Detection/coverage: FIM alerts on modified .php or .phtml files. Sansec eComscan and similar Magento-specific scanners detect known skimmer patterns and webshell signatures. Monitor for new admin users in admin_user table.
03 · Compensating Control

1
CRITICAL 9.8→LOW 2.0
SEVERITY REDUCED
Block the CacheWarmer cookie at the web server or WAF immediately — Add a rule to your reverse proxy (nginx, Apache, Varnish) or WAF to strip or reject any request carrying a CacheWarmer cookie whose value matches the pattern CacheWarmer:(Tz|Qz|YT). Better yet, strip the CacheWarmer cookie entirely from inbound requests if you can tolerate a temporary cache-warming performance hit. This breaks the delivery mechanism completely. Deploy within the noisgate mitigation SLA of ≤3 days — but given KEV status and active exploitation, deploy within hours.
2
CRITICAL 9.8→IGNORE 0.0
SEVERITY REDUCED
Upgrade to Mirasvit Cache Warmer 1.11.12 or later via Composer — Run composer require mirasvit/module-cache-warmer:^1.11.12 && bin/magento setup:upgrade && bin/magento cache:clean. This is the definitive fix. If you run Mirasvit bundled suites, verify the cache-warmer sub-module version specifically. Deploy within the noisgate remediation SLA of ≤90 days, but realistically this should be same-day given the active exploitation.
3
CRITICAL 9.8→IGNORE 0.0
SEVERITY REDUCED
Disable or uninstall the Cache Warmer extension entirely if not business-critical — If cache hit rates are acceptable without the warmer, bin/magento module:disable Mirasvit_CacheWarmer && bin/magento setup:upgrade eliminates the attack surface completely. Many stores enable cache warmers as a performance optimization, not a business requirement. Evaluate whether you actually need it. Deploy within 3 days per noisgate mitigation SLA.
4
CRITICAL 9.8→CRITICAL 9.0
Deploy file integrity monitoring on Magento document root — Run FIM (OSSEC, Wazuh, Tripwire, or Sansec eComscan) on the Magento installation directory to detect post-exploitation webshells, modified .php/.phtml files, and injected JavaScript skimmers. This doesn't prevent exploitation but ensures you detect compromise rapidly. Also monitor the admin_user database table for unexpected new accounts.
5
CRITICAL 9.8→CRITICAL 9.8
Conduct a post-compromise forensic audit now — Given active exploitation since at least late April 2026, any store that was running vulnerable versions should be treated as potentially compromised. Audit for: new admin users, modified checkout templates, JavaScript injections in CMS blocks, webshells in pub/media or var directories, and modified app/etc/env.php. Check web server access logs for CacheWarmer cookie patterns. This is a detection action, not prevention.
What doesn't work
  • PHP disable_functions — While disabling system(), exec(), passthru(), and proc_open() would block the most common command-execution gadgets, standard Magento hosting requires many of these functions for Composer, cron jobs, and deployment tooling. Restricting them breaks the application.
  • Rate limiting or IP blocking — The exploit requires exactly one HTTP request. Rate limiting has no effect. IP-based blocking is futile against a distributed attacker base.
  • Magento Admin 2FA / admin access controls — The vulnerability is in the storefront (frontend), not the admin panel. No admin authentication control is relevant.
  • Network segmentation / placing Magento behind a VPN — Magento storefronts must be publicly accessible to serve customers. You cannot restrict network access without taking the store offline.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationConfirmed. CISA added CVE-2026-45247 to the KEV catalog on June 3, 2026. Imperva observed active campaigns targeting gaming and business-sector Magento stores in the US, UK, France, and Australia. Sansec confirmed "Magento web shops are currently under active attack."
Proof-of-conceptPublic and weaponized. GitHub repo fevar54/PoC-Funcional---CVE-2026-45247-Mirasvit-Full-Page-Cache-Warmer-RCE- provides a functional exploit with --check-only verification mode and full command-execution capability. PHPGGC Monolog chains are also directly applicable. Listed in SecureWithUmer/CVE-2026-PoCs aggregator.
EPSS2.085% probability of exploitation in the next 30 days, 81st percentile. This is notably high for a third-party extension CVE and reflects the low attack complexity and active exploitation signal.
KEV statusListed. Added June 3, 2026. FCEB remediation deadline was June 6, 2026 (3-day window — unusually aggressive, reflecting active exploitation urgency).
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8). CVSS 4.0 per GHSA: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (9.3). Network vector, low complexity, no privileges, no interaction — the worst possible combination.
Affected versionsAll versions of mirasvit/module-cache-warmer before 1.11.12. The module also ships bundled inside other Mirasvit extension suites — merchants may be running it without knowing it.
Fixed version1.11.12 (released May 25, 2026). Install via Composer: composer require mirasvit/module-cache-warmer:^1.11.12 then bin/magento setup:upgrade.
Exposure dataSansec fingerprinted ~6,000 stores running Mirasvit extensions externally. True count is likely higher behind CDNs (Cloudflare, Fastly, Akamai). Magento itself powers ~111,000–250,000 active stores globally, with 8.4% e-commerce market share and ~20% of top-1,000 US retailers.
Disclosure timelineApril 24, 2026: Sansec discovers vuln, deploys Shield rule. May 21: Mirasvit notified. May 25: Patch released (1.11.12). May 26: CVE assigned. June 3: CISA KEV listing.
Researcher / orgSansec Forensics Team (sansec.io). Sansec specializes in Magento/e-commerce threat research and operates the eComscan detection platform.

Sources.

  1. Sansec Research — Critical vulnerability in Mirasvit Cache Warmer for Magento
  2. CISA Alert — CVE-2026-45247 Added to KEV Catalog
  3. GHSA-rg8p-9rpg-r32p — GitHub Security Advisory
  4. Imperva — WAF Protection Against CVE-2026-45247
  5. The Hacker News — CISA Adds Exploited Magento RCE Flaw to KEV
  6. fevar54 — Public PoC Exploit on GitHub
  7. Threat-Modeling.com — Actively Exploited Magento Deserialization Analysis
  8. VulnCheck Advisory — Mirasvit Cache Warmer PHP Object Injection
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.8/10)

Why this verdict

  • Zero-friction attack chain on internet-facing targets: The entire chain — from reconnaissance to code execution — requires a single unauthenticated HTTP request to a public storefront. No credentials, no user interaction, no special configuration. Every prerequisite is satisfied by default on any Magento store running the extension.
  • Gadget chains are guaranteed present: The Monolog library ships as a standard Composer dependency in all Magento 2.x installations. The attacker does not need to discover or fingerprint the PHP autoloader — the gadgets are always there.
  • Active exploitation plus public weaponized PoC: CISA KEV-listed with confirmed in-the-wild campaigns. A fully functional exploit is public on GitHub. The FCEB remediation deadline was 3 days — among the shortest CISA has ever set for a third-party plugin CVE.
  • Role multiplier: Magento storefronts are production application tiers handling PCI DSS-scoped payment card data and customer PII. Compromise leads directly to Magecart-style card skimming, full database exfiltration (card numbers, addresses, order history), and supply-chain risk for B2B merchants. The blast radius is mass data egress + financial fraud + regulatory exposure. Every affected store is, by definition, in a high-value role (production e-commerce handling regulated data). This floors the verdict at CRITICAL.
  • No attacker positioning required: Unlike vulns requiring internal network access or authenticated sessions, this one targets internet-facing storefronts where the attacker starts from the strongest possible position — unauthenticated remote with direct network path. There are zero compounding friction factors to push severity downward.

Why not higher?

There is no severity level above CRITICAL. A 10.0 CVSS score would require Scope change (S:C), which doesn't apply here since the vulnerability's impact is contained to the Magento server itself (even though the downstream data impact is severe). The 9.8 accurately reflects the maximum severity within the Unchanged scope boundary.

Why not lower?

Every friction-audit criterion points upward, not downward. The attack requires zero authentication, zero user interaction, zero internal access, zero special configuration. Targets are internet-facing by definition. The gadget chains are standard dependencies. Active exploitation is confirmed with KEV listing. A public weaponized PoC exists. The affected data is PCI-regulated. There is no credible basis for any downward adjustment.

06 · Verification

Crowdsourced verification payload.

Run this script from any Linux/macOS workstation (or CI runner) that has network access to the target Magento storefront. Invoke with: bash check_cve_2026_45247.sh https://store.example.com. No special privileges required — it only sends HTTP requests. The script checks for the presence of the vulnerable cookie handler without sending an exploit payload.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_45247.sh — CVE-2026-45247 Mirasvit Cache Warmer detection
# Usage: bash check_cve_2026_45247.sh <MAGENTO_STORE_URL>
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

TARGET="${1:?Usage: $0 <MAGENTO_STORE_URL>}"
TARGET="${TARGET%/}"

# Strip trailing slash and ensure https
if [[ ! "$TARGET" =~ ^https?:// ]]; then
  TARGET="https://$TARGET"
fi

echo "[*] Checking CVE-2026-45247 against: $TARGET"

# Step 1: Send a benign canary value in the CacheWarmer cookie.
# A vulnerable version will attempt to unserialize the value.
# We use a deliberately malformed serialized string that will
# cause a PHP notice/warning but NOT execute code.
# The canary is: s:13:"NOISGATE_TEST"; (a valid serialized PHP string, harmless)
CANARY=$(echo -n 's:13:"NOISGATE_TEST";' | base64 | tr -d '\n')

RESPONSE=$(curl -sS -o /dev/null -w "%{http_code}" \
  --max-time 10 \
  -H "Cookie: CacheWarmer=CacheWarmer:${CANARY}" \
  "$TARGET/" 2>&1) || true

if [[ -z "$RESPONSE" ]]; then
  echo "[!] UNKNOWN — Could not connect to $TARGET"
  exit 2
fi

# Step 2: Check if the Mirasvit Cache Warmer extension is present
# by looking for characteristic response headers or module indicators
HEADERS=$(curl -sS -D - -o /dev/null --max-time 10 "$TARGET/" 2>/dev/null) || true

# Step 3: Try to detect extension via Composer lock if publicly accessible
# (some misconfigured stores expose this)
COMPOSER_CHECK=$(curl -sS --max-time 10 "$TARGET/composer.lock" 2>/dev/null) || true

if echo "$COMPOSER_CHECK" | grep -q 'mirasvit/module-cache-warmer'; then
  # Extract version
  VERSION=$(echo "$COMPOSER_CHECK" | grep -A5 'mirasvit/module-cache-warmer' | grep -oP '"version"\s*:\s*"\K[^"]+' | head -1)
  if [[ -n "$VERSION" ]]; then
    echo "[*] Detected mirasvit/module-cache-warmer version: $VERSION"
    # Compare versions
    FIXED="1.11.12"
    if printf '%s\n' "$FIXED" "$VERSION" | sort -V | head -1 | grep -q "$FIXED"; then
      # VERSION >= FIXED
      echo "[+] PATCHED — Version $VERSION >= $FIXED"
      exit 0
    else
      echo "[!] VULNERABLE — Version $VERSION < $FIXED"
      exit 1
    fi
  fi
fi

# Step 4: If composer.lock not accessible, check via module_status
# Try the setup check endpoint (Magento CLI output if accessible)
MODULE_CHECK=$(curl -sS --max-time 10 "$TARGET/mirasvit_cache_warmer/" 2>/dev/null) || true

# Step 5: Heuristic — check if the CacheWarmer cookie is processed
# Send request WITHOUT the cookie, then WITH it, compare behavior
RESP_NOCOOKIE=$(curl -sS -o /dev/null -w "%{http_code}:%{size_download}" \
  --max-time 10 "$TARGET/" 2>/dev/null) || true

RESP_WITHCOOKIE=$(curl -sS -o /dev/null -w "%{http_code}:%{size_download}" \
  --max-time 10 \
  -H "Cookie: CacheWarmer=CacheWarmer:dGVzdA==" \
  "$TARGET/" 2>/dev/null) || true

# If we got a 500 error with the cookie but 200 without, strong indicator
NOCOOKIE_CODE=$(echo "$RESP_NOCOOKIE" | cut -d: -f1)
WITHCOOKIE_CODE=$(echo "$RESP_WITHCOOKIE" | cut -d: -f1)

if [[ "$WITHCOOKIE_CODE" == "500" && "$NOCOOKIE_CODE" == "200" ]]; then
  echo "[!] VULNERABLE — Server returns 500 when processing CacheWarmer cookie"
  echo "    (unserialize() likely threw a fatal error on malformed input)"
  exit 1
fi

if [[ "$NOCOOKIE_CODE" == "200" && "$WITHCOOKIE_CODE" == "200" ]]; then
  echo "[?] UNKNOWN — Store is reachable but cannot conclusively determine"
  echo "    Cache Warmer presence or version remotely."
  echo "    ACTION: SSH into the server and run:"
  echo "    composer show mirasvit/module-cache-warmer 2>/dev/null | grep -i version"
  echo "    If installed and version < 1.11.12, the store is VULNERABLE."
  exit 2
fi

echo "[?] UNKNOWN — Inconclusive (HTTP $NOCOOKIE_CODE without cookie, $WITHCOOKIE_CODE with cookie)"
echo "    Manual verification required. SSH in and run:"
echo "    composer show mirasvit/module-cache-warmer 2>/dev/null | grep -i version"
exit 2