StyleSmuggler’s source data is the finding, not its CVSS score

The finding

The interesting number in the September Magento emergency is not 10.0. It is 14%. Of the 410 source addresses one sensor network links to exploitation attempts against CVE-2026-75650, only 57 appeared on that network's own reputation blocklist at the time of reporting ^[3]. For a campaign running at several hundred attempts a day against a platform that holds card entry, customer records and database credentials, address-based blocking caught roughly one source in seven.

That is the operational finding. The vulnerability itself is well documented and, for anyone running Adobe Commerce, already urgent for ordinary reasons.

What the flaw is

Adobe published APSB26-146 on 7 September 2026 at priority 1, its highest, for a vulnerability it categorises as improper neutralisation of special elements used in a template engine — CWE-1336 — with an impact of arbitrary code execution, no authentication required, scope changed, CVSS 3.1 base score 10.0 ^[1]. Adobe states in the same advisory that it is aware of exploitation in the wild ^[1]. The National Vulnerability Database description records the same class and notes that exploitation requires no user interaction ^[11].

Sansec, which discovered the flaw and named it StyleSmuggler, describes a two-stage sequence: attacker-controlled content is first written into data the platform stores itself, then executed when the platform renders a routine payment-failure notification, whether or not that notification is ever delivered ^[2]. The relevant detail for defenders is that both stages are reachable without credentials, and that the second stage runs through an ordinary application function rather than an obviously hostile request, and without user interaction ^[2][4][5].

Sansec recorded the first compromised store late on 4 September, on an installation that was running current security updates ^[2]. Adobe's hotfix followed on 7 September ^[1]. For three days, patch currency was not a defence.

What the source data says

CrowdSec published source telemetry on 14 September covering 9 to 13 September, the period from when its detection rule went live ^[3]. Four things in it are worth a practitioner's attention.

• Volume was bursty, not steady: 2,760 matching signals over five days, averaging 552 a day, peaking at 1,303 on 11 September from 193 distinct sources ^[3].
• Address counts and signal counts tell different stories. Two-thirds of the 410 catalogued addresses are American — 265, of which 155 are classified residential — yet the United States accounts for only 22% of signal volume ^[3].
• The inverse case is starker. Fourteen hosting and VPN addresses in Singapore sent 349 signals between them, while individual residential addresses sent a handful each ^[3].
• Several countries appear for exactly one day. Indonesia contributed 221 signals on 11 September and almost nothing otherwise; Mexico, Denmark and Kosovo each surfaced for a single day ^[3].

CrowdSec reads this as several operators each running one sweep through infrastructure they control, rather than one campaign scaling steadily, and notes an overlap of scanning sources with two other content-platform vulnerabilities — 23 addresses also probed a 2025 Magento flaw and 35 probed a WordPress flaw ^[3]. Its own stated caveats should travel with the figures: a matching request is an attempt, not a success; 500 unique addresses are not 500 actors when residential proxy networks are in play; and the counts describe traffic reaching participating sensors, which is a sample rather than a census ^[3].

Where the sources disagree

Two discrepancies are worth recording rather than smoothing over. On the US catalogue listing, CrowdSec gives 8 September with a three-day federal deadline of 11 September ^[3]; Security Affairs reports the addition on 10 September ^[9]; and a Japanese technical roundup states that as of 9 September the listing could not yet be confirmed ^[12]. On affected versions, Adobe's advisory lists Magento Open Source from 2.4.6 upward, while Sansec and several derived advisories describe every version from 2.4.4 as affected ^[1][2][7]. For patch decisions, the vendor advisory governs. For hunting decisions, assume the wider range.

What it means

Reputation lists work when adversary infrastructure is reused. They degrade sharply when the exit point is a rotating pool of consumer connections, because the address that attacked yesterday is a household router today and nothing useful is learned by blocking it ^[3]. This is not new as a concept; what the StyleSmuggler data gives is a measured figure for how badly it degrades in a live, commodity-phase campaign, against a sensor network that maintains its own blocklist and still only recognised 14% of sources in advance.

The practical consequence is a shift in the unit of decision. If the source address carries little signal, the request has to carry it: what the request contains, which endpoint it reaches, and whether that endpoint has any business receiving structured content from the internet at all. Request-level virtual patching buys time, but CrowdSec is explicit about the limits of its own — it inspects the URL and one header, not request bodies, and is a bridge to the hotfix rather than a substitute ^[3].

For teams in this region there is a second reading. Singapore, Indonesia and Cambodia appear prominently in the signal-volume breakdown ^[3]. That is a statement about where sensors saw traffic emitted, not about where victims are, and it should not be repeated as a regional threat claim. It does mean APAC hosting estates are being used as launch infrastructure, which is a hosting-provider abuse problem and an egress-monitoring problem for anyone operating in those estates.

What to do

For Adobe Commerce, Commerce B2B and Magento Open Source operators, in order:

• Apply the hotfix Adobe references in APSB26-146 to every instance, including internet-reachable staging copies, and verify the applied status rather than assuming deployment succeeded ^[1][2].
• Treat any store that was reachable and unpatched at any point after 4 September as requiring investigation, not just updating ^[2][3].
• Hunt for the published indicators: unexpected PHP files under the media directory, unexpected cron entries, and processes carrying system-looking names running from user or temporary directories ^[2][3].
• Rotate the platform encryption key, administrative passwords, API tokens, payment credentials and database credentials — and rotate them at source, since rotating the encryption key alone does not invalidate what an attacker has already read ^[2][7][6].
• If out-of-support, recognise that no vendor patch exists for those branches and that community backports are unreviewed; the fix is an upgrade ^[1][2].

Adobe also directs customers applying the separate September Commerce security release to apply this hotfix in addition, not instead ^[6]. Kudelski's advisory and NetSPI's write-up both make the same point in different words: this is an emergency hotfix, not a minor release, and the verification workflow matters ^[7][8].

Offensive security close

For red teams and detection engineers, the transferable lesson is about where the campaign's economics sit. The vulnerability was worth three days of exclusivity to whoever held it first; within four days of the patch it was being sprayed from proxy pools by operators who also probe unrelated content platforms ^[3][10]. That progression — narrow exploitation, public disclosure ahead of a fix because stores were already burning, then commodity scanning — is now the default lifecycle for a pre-authentication flaw in widely deployed web software ^[2][10]. Defensive testing should reflect it: exercise whether your controls detect a request that looks like ordinary application traffic, arriving from an address with no history, on an endpoint your team may not have listed as sensitive.