What happened
Sansec recorded the first confirmed StyleSmuggler exploitation on September 4, 2026, at 22:20 UTC. Adobe published APSB26-146 and the CVE-2026-75650 hotfix on September 7, 2026. Reporting published on September 28, 2026 said more than 3,800 Magento and Adobe Commerce stores had been compromised. CVE-2026-75650 is an unauthenticated template-injection vulnerability rated CVSS 10.0 that can permit arbitrary code execution. Adobe lists Adobe Commerce and Magento Open Source 2.4.4 through 2.4.9 release lines as affected. The newly reported operational impact is more than 3,800 compromised Magento and Adobe Commerce stores. The reporting represents a scale update to an attack that began before the emergency hotfix, not a newly disclosed vulnerability.
Sansec identifies VULN-39341-composer-patches.zip as the Adobe hotfix package and recommends verifying patch status rather than assuming a current release is protected. A published patch check is vendor/bin/magento-patches -n status | grep “39341|Status”. Published host indicators include processes named [kworker/u:8:0], fc-cache or chronyd and paths under ~/.local/share/.gvfsd/, ~/.cache/fontconfig/ and /tmp/.chrony-*. Sansec reported command-and-control use of 99.84.67.186 and NTP-themed domains including ntp.timesync.to on UDP port 123. Observed payloads changed names and persistence behaviour, while another actor used the same entry path to place a PHP web shell. That variation means a single hash, process name or network block is insufficient to rule out compromise.
Why this matters now
The newly reported scale changes this from an emergency patch task into a potentially material incident portfolio. Commerce servers combine public exposure, executable application code, payment integrations, customer records and credentials for databases, deployment systems and third-party extensions. A single compromised node can therefore create several parallel risks: persistent server access, checkout manipulation, secret theft, regulatory notification and loss of transaction integrity. Organisations that installed the hotfix but did not inspect the pre-patch interval have not yet answered whether an attacker arrived first.
The operational distinction is critical because Sansec observed multiple implant names, changing persistence methods and more than one actor using the vulnerability. Signature-only checking or a clean package version cannot establish closure. Merchants, managed-service providers and digital agencies also need node-level evidence across load-balanced, autoscaled, disaster-recovery and dormant environments. The business owner must understand that an apparently functioning storefront can remain compromised while continuing to process payments and customer activity.
The decision for security leaders
Make two independently tracked decisions: whether every affected instance is remediated and whether any instance was compromised before remediation. Do not allow a green vulnerability dashboard, a current package label or a managed-provider attestation to close the second question. Require platform owners to identify the earliest defensible protection time for each node and compare that time with retained web, process, file, authentication and network evidence.
Where evidence is incomplete, choose a documented risk disposition rather than silently assuming absence of compromise. Systems processing card data or storing privileged integration secrets warrant containment, credential rotation and payment-security involvement at a lower evidentiary threshold. Managed hosting does not transfer the decision: obtain node-specific assurance, indicator coverage and confirmation that old images, recovery systems and auxiliary administration hosts were assessed.
Evidence of closure
- Signed inventory showing no unsupported or unassessed commerce instance.
- Node-level patch output confirming hotfix 39341 is installed.
- Forensic hunt report covering published host and network indicators.
The Security.io assessment
The campaign demonstrates why emergency patching and incident response must run in parallel for exploited public-facing applications. The reported scale is credible enough to demand executive coordination, but it should not be interpreted as a complete or independently audited victim census. The cited sources did not publish a definitive independently verified victim list. Affected organisations should therefore base their own conclusion on local evidence, not on whether they appear in public reporting.
Attribution posture: Reporting linked the campaign to an actor using the name Lockster, but no authoritative attribution has been established. The important enterprise fact is the demonstrated exploitation path and persistence, not the actor label. Closure requires evidence that the hotfix is present everywhere, the published and behavioural indicators were investigated, exposed credentials were addressed and any payment or customer-data consequences received an explicit disposition.
Questions for the morning meeting
- Can we prove hotfix coverage across every commerce node rather than by release label alone?
- Which credentials become exposed if a storefront host has been compromised?
- Who can take checkout offline if indicators appear during trading hours?
- What evidence would support a no-compromise conclusion for payment stakeholders?