What just happened (short and snackable)

Security researchers discovered an active zero-day in Magento Open Source and Adobe Commerce that lets attackers run code on a store server without logging in. The flaw has been weaponized in the wild: criminals are poisoning store files, triggering Magento to execute the malicious bits, and then installing a persistent backdoor so they can pop back in whenever they feel like it.

Adobe hasn’t shipped a fix yet, so this is one of those lovely situations where owners need to act fast and think dirty to keep things clean.

How the attack works and what it leaves behind

Think of the exploit as a two-act play. Act one: attackers sneak PHP into files Magento writes (log files, error dumps, etc.). Act two: they nudge Magento into executing that file by firing a routine that builds a “payment failed” message — the platform renders the message and runs the injected PHP, whether or not anyone ever reads the email.

That PHP dropper then tries a handful of PHP functions until it can launch a process. If successful, it downloads or spawns a small, stripped binary (reported as a Rust build) into the site user’s home directory, registers a cron line to relaunch itself every five minutes, and disguises itself as a kernel worker by using a bracketed process name.

The implant can be surprisingly quiet: on some infected stores it didn’t phone home at all, instead talking only to the site’s own Redis session storage and keeping everything local. On others it connected to remote hosts for command-and-control or downloads. In short: it’s persistent, sneaky, and built to survive naive cleanup attempts.

  • Typical fake process name seen: [kworker/u:8:0] running under the site user (real kernel threads are owned by root).
  • Common implant locations: ~/.local/share/.gvfsd/gvfsd-user (binary) and cron entries that restart it every five minutes.
  • Attack vector trigger points: files under var/report/ and var/log/system.log (don’t assume only one is used).
  • Notable behavior: implant may read Redis session storage and re-add cron lines instantly if removed.

The exploit chain relies on Magento rendering certain pieces of code while building output; one protection is to stop that code path from running where it shouldn’t. Researchers also noticed the attack often abuses GraphQL-driven storefronts, so disabling GraphQL temporarily is a practical stopgap if your setup allows it (but note headless or PWA storefronts may need GraphQL).

Indicators published by response teams include file names, cron patterns and a handful of hashes and IPs. If you see any of those artifacts, treat the site as compromised until you’ve fully validated otherwise.

Quick checklist: what to do right now

Here’s a pragmatic, no-nonsense to-do list. Mix and match based on access and hosting model — but don’t do nothing.

  • Temporarily disable GraphQL if your storefront can live without it.
  • Search both var/report/ and var/log/system.log for suspicious markers that look like crafted headers (variants of X-TRACE- with hex).
  • Look for the fake process name running as the site user; check running binary hashes via /proc/<pid>/exe as well as the file on disk.
  • Inspect crontabs for entries that relaunch unknown binaries every five minutes; remove the cron entry before killing any suspect process (the process may recreate it).
  • Consider server-level hardening: add critical PHP functions (for example ones used to start processes) to disable_functions, and mount /tmp, /var/tmp, and /dev/shm with noexec so downloaded binaries can’t run.
  • Apply webserver rules (nginx/Apache) that block suspicious request patterns, but know that blocking only query strings can be bypassed if attackers move payloads into POST or JSON bodies.
  • If you patch Magento files manually, use a durable patch mechanism (composer-patches or similar) because composer installs will overwrite edits.
  • Preserve evidence if you suspect compromise: don’t reboot, don’t run commands that overwrite timestamps before grabbing forensic copies, and don’t run composer install until you’ve captured what you need.
  • After cleanup, flush session storage, rotate the crypt/key in app/etc/env.php, change all admin passwords, and rotate all payment/API credentials and integration keys.

And a small but crucial housekeeping tip: sudden spikes in “Payment Transaction Failed Reminder” emails are a possible indicator — check those stores first.

Finally, if you don’t have the stomach for live incident response, contact your hosting provider or a trusted incident responder immediately. This thing tries to be stealthy and persistent, and half-measures will leave you vulnerable.