Unpatched Magento and Adobe Commerce flaw exploited to backdoor online stores since 4 September

Server-side template injection turns data into code. Magento renders email templates by expanding placeholders such as {{var ...}} into live values, and a rendering engine that can call PHP is effectively an interpreter. If an attacker can get their own text into something that engine later renders, the template system will faithfully execute it, because it cannot tell attacker-supplied text from developer-supplied text. That is why StyleSmuggler needs no login: the dangerous step happens inside a trusted internal function, not at the front door.

Two-stage exploits separate the write from the trigger. Many web attacks first find a way to place content on disk, then find a separate feature that reads and processes that content. Each half may look harmless on its own; a failure report being written is normal, and a reminder email being rendered is normal. The vulnerability lives in the combination, which is why threat modelling should trace where user-influenced data ends up and every code path that later consumes it.

Persistence is about surviving restarts, not just getting in. The backdoor here is re-launched by cron every five minutes and named to look like a kernel worker thread, which is a classic masquerading technique. Cron is a scheduler that runs commands on a timetable with the privileges of the user who owns the entry, so a single line can resurrect malware indefinitely. Defenders who only kill a process without removing the scheduler entry will watch it come back within minutes.

Hardening limits what an attacker can do after the bug fires. Disabling proc_open removes a PHP function used to spawn external programs, and mounting temporary directories with noexec tells the kernel to refuse to run binaries stored there. Neither fixes the vulnerability, but together they break steps in the attacker's chain, which is the essence of defence in depth. This works because most exploit chains assume a permissive environment, and every assumption you violate raises the attacker's cost.

Virtual patching buys time when the vendor cannot. Community patches and web application firewall rules that block the specific request pattern are ways of closing a hole without touching the vulnerable code itself. They are imperfect, because a clever variation may slip past, but they are fast to deploy and easy to remove once the official fix arrives. Knowing where such a rule would go in your stack is half the preparation. A useful habit is to write the rule as narrowly as the exploit requires, so legitimate traffic keeps flowing and the rule can be reasoned about later.