Skip to content

Adobe Commerce / Magento template-engine RCE: KEV, actively exploited (CVE-2026-75650)

Source: hourly offensive-security scan of CISA KEV and GitHub Security Advisories on 2026-09-09. CISA added CVE-2026-75650 to KEV on 2026-09-08 with CISA due date 2026-09-11 (BOD 26-04) and the forensic-triage flag set. The vendor records (Adobe APSB26-146 / GitHub GHSA-fj37-xm58-mf28) name it an Improper Neutralization of Special Elements Used in a Template Engine vulnerability (CWE-1336) that allows arbitrary code execution in the context of the current user, with NVD-assigned CVSS 10.0 (AV:N/AC:L/PR:N/UI:N/S:C) and the record noting exploitation does not require user interaction. CISA SSVC marks it exploitation: active, automatable: yes, technicalImpact: total. Affected lines per the NVD/CVE record: Adobe Commerce / Magento Open Source ≤ 2.4.9-2026-aug (through 2.4.4-2026-aug), Adobe Commerce B2B ≤ 1.5.3-2026-aug (through 1.3.3-2026-aug); fixed by the vendor's "Hotfix for CVE-2026-7565".

Why this is worth an operator page

  1. Unauthenticated, remote, no user interaction, actively exploited is the top-priority asset class in any perimeter sweep — Magento/Adobe Commerce stores are the ecommerce equivalent of the N-Central/Ivanti appliance bucket: they sit behind CDNs, talk to payment rails, hold customer PII, and frequently carry a large third-party extension surface.
  2. CWE-1336 (template-engine injection) as a KEV class means attacker-controlled material reaches PHP template syntax that the engine evaluates. In Magento 2 that means user-influenced strings flowing into .phtml/Mustache/{{...}}-style evaluation contexts — product attributes, CMS content, customer-entered data, order/checkout fields, review bodies, and anything rendered server-side into HTML. The audit axis: which unauthenticated request fields can plant template-syntax fragments into server-rendered output or server-side template evaluation, and does the hotfix close only one sink?
  3. Scope-changed CVSS 10.0 signals the bug crosses a trust boundary (e.g., storefront context → admin/host execution context), so the impact model is not "session steal on the store" — it is "arbitrary code on the app server", with the database (often multi-tenant), admin panel, and payment integration as the next hops.

What is public (confirmed)

  • NVD/CVE record: published 2026-09-07, analyzed; description as above; CVSS 3.1 10.0; CISA exploit-add 2026-09-08, action-due 2026-09-11.
  • Vendor: Adobe shipped a hotfix named "Hotfix for CVE-2026-7565" covering both Commerce and Commerce B2B affected lines (per APSB26-146). No public request-level PoC or technical writeup had been published at scan time; the mechanism is not publicly documented.
  • GitHub advisory GHSA-fj37-xm58-mf28 (critical, unreviewed) carries the same vendor text; no package-ecosystem range data, so version scoping comes from the CVE record's version list.

Recon: exposure and version fingerprinting

  • Product markers: Magento/Adobe Commerce storefronts are heavily fingerprintable — /media/ asset layout, X-Magento-Bsid/X-Magento-Type response headers, Magento-branded footer/legal routes, and admin-panel paths (/admin or a custom /admin_* route). Record whether the admin panel is internet-exposed or VPN-gated; an unauth RCE does not need admin access, but an exposed admin is the post-exploitation control panel.
  • Version scoping (read-only): the vulnerable window is the August 2026 update lines — Magento/Adobe Commerce through 2.4.9-2026-aug and B2B through 1.5.3-2026-aug. Anything on or below those is in-scope; the hotfix (or later official release) is the fixed marker. Version evidence comes from error bodies, release-notes pages, the store's public "powered by" markers, or deployment manifests when in scope. If you cannot pin an exact build, record the fingerprint evidence and mark version confirmation as inferred.
  • Exposure classification: CDN-fronted direct internet (priority tier), VPN-gated, or trusted-IP-restricted. Note whether WAF/CDN rules strip common template-syntax characters ({{, <?php, {{%) from request bodies and query strings — that changes which injection field is reachable, not whether the store is patched.
# Inert recon on an authorized scope: find Magento/Adobe Commerce front-ends
httpx -l scope.txt -title -tech-detect -content-length -server -silent -json > httpx_magento.json
# Read-only version/probe pass on a confirmed host
curl -sk -D - https://TARGET/ -o /dev/null -w "HTTP %{http_code}\n"
curl -sk -D - https://TARGET/admin -o /dev/null | grep -i 'location\|set-cookie'

Label inference. Do not record "patched" from the absence of a marker. The hotfix is a vendor build, not a detectable header; version evidence must come from an actual build identifier or release artifact.

Validation boundaries (authorized targets / lab only)

Since no public request-level PoC exists, the safe work in an authorized assessment is patch-state + boundary confirmation, not payload guessing:

  1. Confirm product, version line, and hotfix state with the read-only markers above. Do not send template-engine injection payloads at a production store without explicit owner approval for that specific action — on a live store this is an incident and a data-exposure event (customer PII).
  2. In a lab (or owner-approved canary store) on an in-scope build: enumerate the unauthenticated fields that reach server-side rendering or template evaluation — guest checkout inputs, product/review submission paths, CMS-block content, import/upload endpoints that store strings rendered later, and URL/param material reflected into templates. Record the field → template-context matrix per build.
  3. Characterize the injection boundary without execution: demonstrate that an unauthenticated request can get a template-syntax fragment (e.g., a marker like {{canary}} or a benign Mustache section) accepted into a server-side evaluation or rendered context on the vulnerable build. Stop at acceptance/eval-logging evidence. Do not achieve code execution, do not write to the database, do not touch payment integration state.
  4. Negative control: repeat the same shapes on the hotfixed build and record the denial. "Patched" must be verified against the hotfix's actual behavior, consistent with the Magento KEV history (the 2026-06-03 Mirasvit Cache Warmer entry showed that a third-party extension can be the only reachable sink — the core patch does not close extension paths).
  5. Extension-surface pass: because CWE-1336 KEVs on Magento have historically reached their sink through third-party modules, include the installed-extension inventory (module names/versions from the deployment or bin/magento module:status when CLI access is in scope) in the field → sink matrix. Extensions that accept user strings into echo/template contexts are the likeliest unpatched writers.
  6. Do not run untrusted third-party exploit code against any store. Public records give no safe request shape; and any unapproved accepted request on a live Magento store is both a legal and a data-breach risk.

Evidence to capture: exact version/build strings, hotfix state, the field→template-context matrix (pre-hotfix acceptance vs. hotfix denial), extension inventory, and the negative control. Redact all credentials, session material, and customer data.

Durable operator value

  1. KEV-template-engine-RCE on a web app = first sweep tier for ecommerce fleets. Magento/Adobe Commerce belongs on the default internet-exposure watchlist alongside the appliance class; a store RCE with scope-change is a PII + payment-rail incident in one step.
  2. CWE-1336 KEVs are render-context audits. The question is not "can I send an XSS string?" but "which unauthenticated fields survive into template syntax the server evaluates, and did the hotfix harden only the core sink?" Test core and extension writers, not just the one the advisory implies.
  3. Version-line scoping beats product evidence. The decisive fact is the build (affected: ≤ 2.4.9-2026-aug / B2B ≤ 1.5.3-2026-aug; fixed: "Hotfix for CVE-2026-7565"). Record exact builds for every in-scope instance; "it's Magento 2.4" is not a risk determination.
  4. CDN/WAF rules change reachability, not patch state. If a WAF strips {{ from bodies, the sink moves to URL-encoded, JSON, or multipart paths — re-test the matrix per channel instead of concluding the store is safe.

Safety

  • Authorized scope only. Unauth RCE on a live store = customer data exposure; any unapproved request that gets accepted is an incident.
  • No execution in scope unless explicitly owner-approved; no code execution, no DB writes, no payment/checkout state changes, no customer PII collection.
  • No untrusted public exploit code against targets; lab reproduction only with full sign-off.
  • Preserve evidence on owner-directed compromise checks; app-server access logs, template/render logs, and session-store timestamps are the read-only first pass.

Sources: CISA KEV catalog — CVE-2026-75650 · Adobe security advisory APSB26-146 · NVD record CVE-2026-75650 · GitHub advisory GHSA-fj37-xm58-mf28