CVE-2026-75650 Adobe Commerce / Magento 2.4.4-2.4.9: 10.0 RCE in CISA KEV

CVE-2026-75650 is rated CVSS 10.0 and was added to the CISA KEV catalog on September 8, 2026 — the day after publication, with a three-day remediation deadline. It affects Adobe Commerce, Adobe Commerce B2B and Magento Open Source.

It's a template engine injection leading to arbitrary code execution, without authentication and without user interaction.

For an online store, the consequence goes beyond the usual server compromise: code execution on a Magento instance gives access to the payment flow, and that is exactly what skimming crews (Magecart) have been after for a decade.

The Vulnerability

Adobe's description:

Adobe Commerce is affected by an Improper Neutralization of Special Elements Used in a Template Engine vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue does not require user interaction. Scope is changed.

The S:C (scope changed) is what pushes this to 10.0: execution spills beyond the vulnerable component. On an e-commerce platform that's concrete — the template engine renders the pages customers see, so injected code runs in the context serving the checkout flow.

Why template engines are a recurring target

A template engine exists to evaluate expressions inside content. That's its job. Security therefore rests entirely on the boundary between "what the developer wrote" and "what the user supplied".

In Magento, that boundary is crossed by many legitimate paths: CMS content, static blocks, transactional email templates, price rules, product attributes. Each is an opportunity for attacker-controlled data to land in a context where it will be evaluated rather than displayed.

Adobe doesn't detail the exact entry point — I won't guess it. But the PR:N/UI:N vector says what matters: the path is reachable from outside, with no account.

Affected Versions

⚠️ These are the affected version boundaries NVD publishes, not the fixed releases. Adobe ships the fix as a per-branch security patch: get the number applicable to your exact version from the corresponding Adobe bulletin. I won't invent a target version.

The range covers the entire 2.4 line, so in practice: if you're on Magento 2.4 and haven't applied a September 2026 security patch, assume you're affected.

Check your version:

php bin/magento --version

# Security patches already applied
composer show magento/product-community-edition
composer show | grep -i "magento/module-.*patch"

What's Actually at Stake

Payment card theft

This is the primary outcome, and it doesn't depend on whether you store card numbers — you probably don't, and it makes no difference.

An attacker executing code on the server modifies client-rendered templates to inject a script capturing payment form fields before they reach the processor. The payment works normally, the customer sees nothing, the processor sees nothing unusual. That's how Magecart has operated since 2015, and Magento is its historic target.

PCI-DSS compliance is directly engaged, including for SAQ-A merchants who believe they've outsourced the risk: if your page hosts the form — even in a hijackable iframe — you're in scope.

Customer data

Addresses, order history, emails, phone numbers. A personal data breach under GDPR, with a 72-hour notification obligation.

Persistence

Magento is a platform rich in extension mechanisms. An attacker has many discreet places to reinstall: CMS blocks containing code, injected modules, scheduled tasks, altered email templates, core_config_data entries. A partial cleanup almost always leaves something behind.

Detection

Code integrity

The most reliable check, because the attacker has to write somewhere.

# Recently modified files outside volatile directories
find /var/www/magento -type f -newermt "-30 days" \
  -not -path "*/var/*" -not -path "*/generated/*" \
  -not -path "*/pub/static/*" -not -path "*/vendor/*" \
  -ls | head -50

# Compare against the original Composer packages
composer install --dry-run 2>&1 | grep -i modif
git status --porcelain   # if the deployment is version-controlled

CMS blocks and templates

Database storage is a skimmer's favourite location, because it survives a code redeploy:

-- CMS blocks and pages containing script
SELECT block_id, identifier, update_time FROM cms_block
  WHERE content LIKE '%<script%' OR content LIKE '%eval(%'
  OR content LIKE '%base64_decode%';

SELECT page_id, identifier, update_time FROM cms_page
  WHERE content LIKE '%<script%' OR content LIKE '%atob(%';

-- Recently changed configuration — including injected headers and scripts
SELECT path, value, updated_at FROM core_config_data
  ORDER BY updated_at DESC LIMIT 40;

Accounts and tasks

-- Administrator accounts, especially ones created outside your process
SELECT user_id, username, email, created, logdate FROM admin_user
  ORDER BY created DESC;

Also check system scheduled tasks (crontab -l for the web user) and installed modules nobody recognises.

Client-side — the decisive check

Load a checkout page in a browser and inspect outbound network requests. Any domain that isn't your declared payment processor is a problem. It's the most direct test for an active skimmer, and it requires no server access.

Mitigation

1. Apply the Adobe patch — immediately

The CISA deadline was September 11. With a 10.0, no authentication, no interaction and confirmed exploitation, this is an out-of-window intervention.

2. Reduction measures in the meantime

• WAF in front of the store: it fixes nothing but can filter some known payloads
• Admin interface restricted by IP and on a non-guessable URL — this CVE doesn't need it, but that surface is what matters for the next ones
• Content-Security-Policy on checkout pages: a strict CSP limiting destination domains is the most effective countermeasure against skimmer exfiltration, including when the server itself is compromised

3. If you conclude there was a compromise

Order matters, and cleaning in place is inadvisable.

1. Treat it as a payment data breach from the outset — notify your processor and acquirer, PCI-DSS obligations trigger
2. Redeploy code from a trusted source (Git repo + Composer); don't try to clean files in place
3. Audit the database: CMS blocks, core_config_data, admin accounts, email templates — clean code achieves nothing if the skimmer lives in the database
4. Rotate every secret: payment processor API keys, database credentials, env.php, encryption keys, admin passwords
5. Force customer password resets and invalidate sessions
6. Notify if personal data may have been exposed — GDPR, 72 hours

Why Continuous Monitoring of Your E-commerce Platform Matters

Magento receives security patches several times a year, and application lag is routinely measured in months — because an update touches a site generating revenue continuously, with third-party extensions whose compatibility has to be validated. Meanwhile, skimming operators scan constantly: Magento is their best-documented target.

With cveo.tech, inventory your e-commerce platform and its components with exact versions, and get automatic alerts whenever a critical CVE affects one — so the gap between an Adobe bulletin and your decision is measured in hours, not weeks.