- The Mess: Adobe patched CVE-2026-75650, a critical unauthenticated RCE in Adobe Commerce and Magento Open Source. Attackers were exploiting it for three days before Adobe shipped the emergency hotfix.
- The Damage: A remote attacker can execute arbitrary code on an ecommerce server without credentials, and compromised stores have already been found running persistent backdoors.
- The Fix: Apply Adobe hotfix VULN-39341 immediately, rotate the Magento encryption key and all credentials protected by it, then scan the server for compromise.
This is a real zero-day, not a theoretical CVE
CVE-2026-75650 is the vulnerability now known as StyleSmuggler.
Adobe rates it Critical, gives it a CVSS 3.1 score of 10.0, and confirms that it is being exploited in the wild. The vulnerability is classified as CWE-1336 — improper neutralization of special elements used in a template engine.
The ugly part is the privilege requirement:
There isn’t one.
The vulnerable attack path does not require an authenticated Magento administrator or customer account.
Adobe’s published vector is:
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
In plain English:
network reachable + low complexity + no privileges + no user interaction + complete impact.
That is about as hostile as a web application vulnerability gets.
Attackers got there before the patch
Sansec’s forensic team says the first confirmed exploitation occurred on September 4, 2026.
Adobe published the emergency security bulletin and hotfix on September 7.
That created a three-day window in which Magento stores were being attacked while no official Adobe patch existed.
Sansec reproduced the complete unauthenticated attack chain against clean Magento Open Source installations running versions 2.4.7, 2.4.8 and 2.4.9.
Even more interesting: the first confirmed victim was running Magento 2.4.6-p15 with the July and August 2026 security patches installed.
So this was not simply a case of administrators ignoring an ancient vulnerable release.
The attack hit installations that appeared properly patched.
How StyleSmuggler gets code into Magento
The vulnerability sits in Magento’s template-processing logic.
Sansec describes a two-stage attack:
- The attacker injects PHP code into Magento-generated content.
- Magento later renders that poisoned content through a failed-payment email workflow.
The important detail is that the attacker does not need to directly upload a PHP web shell.
They poison data that Magento itself later processes.
That is what makes this bug nasty.
The application becomes part of the execution chain.
Sansec describes the attack as abusing the styles properties to bypass existing template safeguards, allowing malicious PHP to be inserted and subsequently executed when Magento processes the relevant failed-payment email.
The victim does not need to open the email.
The malicious code executes while Magento is rendering the message.
The attack surface is bigger than the CVE description
This is why the CVSS 10 score matters less than the mechanics.
A traditional web attack might look like:
request → vulnerable endpoint → RCE
StyleSmuggler is more interesting:
request → malicious template data → Magento storage/rendering → PHP execution
The vulnerable application effectively turns its own internal workflow into an execution primitive.
And once arbitrary PHP runs, the attacker is no longer fighting Magento’s application-level security.
They’re operating on the underlying server.
The malware showed up quickly
Sansec found a persistent Rust-based implant after successful exploitation.
One early version disguised itself as:
[kworker/u:8:0]
That name is deliberately chosen to resemble a Linux kernel worker thread.
Later variants used:
fc-cache
and:
chronyd
Both are legitimate-looking Linux process names.
The malware also created persistence mechanisms using cron.
Sansec documented variants living under paths such as:
~/.local/share/.gvfsd/gvfsd-user
and:
~/.cache/fontconfig/fc-cache
Another variant used:
/tmp/.chrony-<id>/chronyd
The point is obvious: simply looking for a suspiciously named process is not enough.
An attacker can name the process after something that administrators expect to see on a Linux server.
The attackers were not using one static payload
This campaign evolved quickly.
Sansec observed the implant changing its process name and persistence method after the initial attacks.
The fc-cache variant used NTP-looking UDP traffic for command-and-control.
The chronyd variant went further by impersonating the legitimate NTP daemon.
That creates a particularly nasty detection problem.
An administrator who sees chronyd communicating over UDP/123 may not investigate it because legitimate time synchronization normally does exactly that.
Sansec found behavioral differences that can expose the fake process, but the broader lesson is more important:
post-exploitation tooling was already changing while defenders were still analyzing the original exploit.
There was a second attacker
This gets even messier.
Sansec identified another operator exploiting the same StyleSmuggler entry point.
This actor used different tooling and dropped a PHP web shell under Magento’s media directory.
The shell was hidden behind an HTTP header requirement and could execute arbitrary PHP when that condition was met.
So a vulnerable store could potentially attract multiple attackers independently.
One campaign gets the initial RCE.
Another scans the same vulnerable surface.
A third actor may find the resulting backdoor later.
That’s how an ecommerce incident can escalate from vulnerability management into an actual compromise investigation.
Patching is not enough
This is the part Magento administrators need to understand.
If you patch CVE-2026-75650 today, you have closed the vulnerability.
You have not proved that nobody exploited it yesterday.
Sansec explicitly recommends scanning stores that were exposed before the Adobe hotfix became available.
Adobe also recommends rotating the Magento encryption key and credentials protected by it.
That includes credentials such as:
- administrator passwords,
- REST/SOAP/GraphQL integration tokens,
- OAuth secrets,
- payment gateway credentials,
- database credentials,
- SSH/deployment keys,
- third-party extension API keys.
Adobe’s guidance is important here:
rotating the encryption key alone does not invalidate credentials that an attacker already extracted.
Those credentials need to be rotated at their actual source.
What Magento administrators should do
1. Apply VULN-39341
Adobe released the emergency hotfix under APSB26-146.
The fix is distributed as a hotfix rather than simply waiting for a normal Magento release cycle.
Adobe’s documentation provides version-specific installation instructions.
2. Verify that the patch actually applied
Do not trust a successful deployment message.
Adobe/Sansec documentation provides a Magento patch-status check:
vendor/bin/magento-patches -n status | grep "39341\|Status"
The vulnerable installation should report the hotfix as applied.
3. Rotate the encryption key
Do this after patching according to Adobe’s recovery guidance.
But don’t stop there.
4. Rotate exposed credentials
Pay particular attention to:
- payment providers,
- database access,
- deployment systems,
- SSH,
- Magento integrations,
- API tokens,
- OAuth applications,
- third-party extensions.
A compromised ecommerce server can contain much more valuable information than the Magento database itself.
5. Hunt for persistence
Check for suspicious:
kworkerprocesses,fc-cacheprocesses,chronydprocesses,- unexpected cron entries,
- PHP files under
pub/media, - unexpected files under user
.cachedirectories, - binaries under
/tmp, - modified Magento PHP files.
Sansec published detailed indicators and forensic paths for the known StyleSmuggler implants.
6. Check the payment environment
Magento is not just another CMS.
It is an ecommerce platform.
If the server was compromised, investigate whether payment credentials, API keys, customer information or other sensitive integration data could have been accessed.
Do not assume that a clean storefront after patching means the incident is closed.
A compromised Magento server is a business problem
The obvious impact is remote code execution.
The less obvious impact is everything sitting behind that RCE.
An attacker landing on an ecommerce server may gain access to:
Magento → database → customer data → payment integrations → API credentials → deployment infrastructure
That is why StyleSmuggler is much more dangerous than a generic template injection bug.
The vulnerable component is the storefront.
The potential blast radius is the entire ecommerce environment.
Bugstoday’s take
CVE-2026-75650 is exactly the kind of vulnerability that turns “we’ll patch after the weekend” into an incident-response ticket.
Adobe confirmed active exploitation.
Sansec found compromised stores.
Attackers deployed persistence.
The payloads evolved.
And the official patch arrived only after exploitation had already started.
If you run Magento or Adobe Commerce, patching is step one, not the finish line.
Patch the platform.
Rotate the secrets.
Hunt for the backdoor.
Then check the payment integrations.
Because when an attacker gets unauthenticated RCE on an ecommerce server, the vulnerability is only the beginning.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
- Adobe — Security Bulletin APSB26-146 / CVE-2026-75650
- Adobe Experience League — Commerce APSB26-146 emergency hotfix guidance
- Sansec Forensics — StyleSmuggler: Magento and Adobe Commerce 0-day RCE
- CVE Program — CVE-2026-75650
