What happened

CISA's September 8 alert added four entries to the KEV catalog: this Adobe Commerce and Magento flaw, an N-able N-central pre-auth RCE (see our N-central post) and two Windows local bugs. CISA's entry calls CVE-2026-75650 an "Improper Neutralization of Special Elements Used in a Template Engine Vulnerability." Adobe's description in NVD says it "could result in arbitrary code execution," needs no user interaction, and the scope is changed.

The timeline, from Sansec's research log:

  • August 23: first unsuccessful probes.
  • September 4, 22:20 UTC: first confirmed exploitation.
  • September 5: Sansec publishes its analysis while no patch exists.
  • September 7, about 20:20 UTC: Adobe publishes APSB26-146 (priority 1, its highest) and hotfix VULN-39341.
  • September 8: CISA adds the CVE to the KEV; Scandiweb backports the fix to 41 older versions.

Sansec describes a two-stage chain. The first request puts PHP source in the query string of /paypal/transparent/response/; the request fails, and Magento writes the whole request into a report file under var/report/. The second request goes to /graphql with styles parameters that point back at that report file and build a gadget chain, which runs when Magento renders its "Payment Transaction Failed Reminder" email. Both endpoints are public on a normal storefront.

Sansec saw at least two distinct actors. Payloads include a Rust backdoor that installs to ~/.local/share/.gvfsd/gvfsd-user, masquerades as the kernel thread [kworker/u:8:0] and restarts from cron every five minutes, plus PHP web shells under pub/media/catalog/product/cache/ and later tooling such as gs-netcat and WraithC2. Adobe, CISA and NVD have not published indicators of their own; the indicators circulating come from Sansec. No public victim count has been published.

Which versions are affected

Sources disagree on the Magento Open Source floor. Tenable, summarizing Adobe's bulletin, lists Adobe Commerce 2.4.4 to 2.4.9, Adobe Commerce B2B 1.3.3 to 1.5.3 and Magento Open Source 2.4.6 to 2.4.9. Sansec says every version from 2.4.4 to 2.4.9 is vulnerable, and that unsupported 2.2, 2.3 and 2.4.0 to 2.4.3 are affected too but get no official fix. We could not load Adobe's bulletin directly while writing this. The safe reading: if you run any Magento 2 or Adobe Commerce release, assume you are affected until the hotfix is confirmed installed.

Why it matters if you run public infrastructure

An online store cannot hide behind a VPN; the vulnerable endpoints are the ones customers use. That leaves patch speed as the only control, and for three days there was nothing to patch. A compromised store also holds more than its own data: payment gateway credentials, integration tokens and customer records. Sansec's point that rotating the Magento encryption key does not by itself invalidate credentials that were already stolen is the one most teams will miss.

What to check this week

  1. Install hotfix VULN-39341 on every Adobe Commerce and Magento instance, including staging copies that share a database or keys with production. Sansec suggests vendor/bin/magento-patches -n status | grep "39341\|Status" to confirm it is applied.
  2. If you run an unsupported release, there is no official hotfix. Use a community backport as a stopgap, enable your web application firewall provider's rule for this CVE if it offers one, and plan the upgrade.
  3. Assume compromise if you were unpatched after September 4. Look for ~/.local/share/.gvfsd/, cron entries mentioning gvfsd, processes named like kernel threads running as the web user, hidden directories in /tmp and PHP files under pub/media/catalog/product/cache/.
  4. Rotate everything the store knows. Admin passwords, the encryption key, integration and API tokens, payment gateway credentials at the provider, database passwords and deploy keys.
  5. Inventory your stores. Old microsites, regional storefronts and abandoned campaign shops on subdomains are the ones nobody patches.

How Attack Surface Scan covers this

Honestly, only at the edges. Magento and Adobe Commerce are not in the product catalog our vulnerability matching recognizes, so we will not tell you whether a store is running a vulnerable release or raise a CVE finding for it. We also do not look for web shells or backdoors inside the server. What we do provide is the inventory the last check above needs: every host under your verified domains, including subdomains found in certificate transparency logs, the web ports each one answers on, its TLS and header posture, and an alert when a new host or service appears. That is how a forgotten storefront shows up on a list; whether it is patched has to be checked on the server. We never send exploit payloads. See Vulnerability matching for which products we do match.

Sources