Magento Zero-Day CVE-2026-75650: What to Patch, and Why WeltPixel 1.17.5 Is a Security Release

September 16, 2026|Dan Giura

TL;DR

On September 4, 2026 attackers started exploiting a Magento zero-day that Sansec named StyleSmuggler. It is unauthenticated remote code execution, scored 10.0, and it worked against stores that had every July and August patch applied. Adobe shipped an emergency hotfix on September 7 and its regular September bulletin on September 8. If you have not applied both, do that first, today. Then update your WeltPixel extensions: 1.17.5 is out for the entire catalog, free and paid, and it closes the same kinds of holes inside our code that Adobe just closed inside theirs: stored cross-site scripting through admin settings, SQL injection in two places, public endpoints that accepted any order id, admin actions that fell back to the generic admin permission, and TLS verification that was switched off on three outbound API calls. It also fixes a handful of performance problems we found on the way. If your Support & Updates plan has lapsed, you cannot pull 1.17.5 through Composer until you renew it in My Products.

Twelve days is how long this has been going on. The timeline matters, so here it is before anything else.

September 4: Sansec's forensics team sees the first StyleSmuggler compromise. The victim runs 2.4.6-p15 with the July and August 2026 patches applied and a clean security:patch-status.
September 5: Sansec publishes early, because stores are being hit and no fix exists.
September 7, 20:20 UTC: Adobe publishes APSB26-146 with priority 1, its highest, and a hotfix rather than a full release. The bug becomes CVE-2026-75650, CVSS 10.0.
September 8: Adobe publishes its scheduled September bulletin, APSB26-138, with eight more CVEs, two of them stored cross-site scripting rated 9.3 that need no authentication.
September 16: WeltPixel releases 1.17.5 for every extension in the catalog.

What StyleSmuggler is

Magento's email templates can carry style properties. StyleSmuggler abuses that: an attacker injects PHP into the template system, for example through a generated failure report, and then makes Magento execute it by triggering a "payment transaction failed" email. No login, no admin session, no form key. Sansec reproduced the full chain on clean installs of 2.4.7, 2.4.8 and 2.4.9.

What the attackers leave behind is a small Rust backdoor that hides as a kernel worker, fc-cache or chronyd, beacons to a command server disguised as NTP traffic, and reinstalls itself twice an hour from cron. A second group came in through the same hole and dropped a PHP web shell into the product image cache. Stores were being exploited for three days before a patch existed, and the operators changed payloads several times a day.

The uncomfortable part, and the reason we are writing this up at all: your patch level does not protect you. The first victim was fully patched. Moving sessions to Redis did not help. A 2.4.7-p10 store got probed on September 7. If your store runs anything from 2.4.4 to 2.4.9 and you have not applied the hotfix, assume you are exposed right now.

What to do in Magento, in order

1. Apply the VULN-39341 hotfix. It ships as a composer patch, not as a new Magento version. Download VULN-39341-composer-patches.zip from repo.magento.com (Adobe's KB article lists a different patch file per version range, from 2.4.4 up to 2.4.9-2026-aug) and apply it the way you apply any Adobe composer patch. Then confirm it is actually in:

vendor/bin/magento-patches -n status | grep "39341\|Status"

You want to see Applied. Adobe tested the hotfix against the 2026-aug releases of 2.4.4 through 2.4.9. Older patch levels in those branches are affected too but unverified, so test on staging first. If you are still on 2.2, 2.3 or 2.4.0 to 2.4.3, Adobe publishes nothing for you; Scandiweb has backported the fix to 41 older releases, one patch file per version, and Sansec has not reviewed those, so treat them with the same staging discipline.

2. Apply the September security update, APSB26-138. This is the regular release: 2.4.9-2026-sep, 2.4.8-2026-sep, 2.4.7-2026-sep and so on. It carries two unauthenticated stored XSS bugs rated 9.3 (CVE-2026-76200 and CVE-2026-76201), five incorrect-authorization bugs and a path traversal. Adobe is not aware of exploitation of these, but the first two are the exact class attackers pick up next once the headline bug is closed.

3. Rotate the encryption key, then everything it protected. Adobe's remediation checklist is explicit that rotating the key on its own invalidates nothing an attacker already read. Rotate at the source: admin passwords, REST/SOAP/GraphQL integration tokens, OAuth client secrets, payment gateway API credentials at the gateway, database credentials, SSH and deploy keys, and the API keys of every third-party extension, including the ones you use with our GA4 addons. Put the store in maintenance mode and disable cron while you do it.

4. Scan for compromise before you assume you are clean. Patching closes the hole; it does not remove a backdoor that landed on September 5. Run Sansec's eComscan or an equivalent, and check the cheap indicators yourself:

crontab -l | grep -i gvfsd
ps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'
find pub/media -name '*.php'
grep -ril 'x_trace_' var/report/

An empty crontab is not evidence of a clean host. The chronyd variant relaunches itself with no cron entry at all.

Why your extensions belong on the same checklist

Every extension you install runs inside the same PHP process as Magento, with the same database credentials, and renders into the same storefront pages. A core patch fixes core. It does nothing for a public controller in a third-party module that loads any order id you hand it, or for an admin setting that gets concatenated raw into a stylesheet served to every visitor.

You have probably watched the aftermath of one of these on a client store: the core patch went in on day one, and three weeks later the web shell turned out to have come through a module nobody had looked at since 2019. Extension code is where attackers go once core is closed, because it is where nobody is looking.

So while Adobe was working on APSB26-146, we ran a security audit across every WeltPixel module, 52 code repositories, and fixed what we found. The audit was framed by the classes in Adobe's two September bulletins: stored cross-site scripting, incorrect authorization, path traversal, and anything reachable without authentication. 1.17.5 is the result, a hardening release with no new features. Every extension in the catalog gets it, including the free ones, because the free modules ship inside the Pearl theme and the Marketing Suite PRO and run on the same stores. For the free modules, 1.17.5 is delivered in those bundled editions through Composer; the public GitHub repositories are not updated with this release.

What 1.17.5 fixes

Every module has its own dated 1.17.5 entry on docs.weltpixel.com, and the per-module notes are the reference. The list below is the shape of the release, with the findings worth naming.

Stored cross-site scripting through admin settings. This was the largest class by far. Colour, size, label, message and custom-CSS settings in more than twenty modules were written into stylesheets, inline scripts and page markup exactly as stored, and the only validation on those fields was in the browser. A crafted value saved by anyone with configuration access, or in some modules with only content or catalog access, ran for every visitor. The Owl Carousel banner fields, the Product Labels rule fields, the Google Consent Mode v2 description (which was being HTML-decoded before rendering, the inverse of a filter), the Quick Cart minicart style block that renders on every page, the Mega Menu category labels, the Custom Header custom CSS/HTML field and the search autocomplete texts are the notable ones. Every one of those values is now validated as a real colour or length, or escaped for the exact context it lands in, with a small formatting allowlist where merchants legitimately use a link or a line break. For a valid configuration the generated stylesheets are byte-identical to before.

SQL injection, twice. The Layered Navigation rating filter concatenated the rating range from the URL straight into the query on public category and search pages (only on stores with the rating filter enabled, but that is not rare). And the shared WeltPixel Backend module, which every extension depends on, built its licence lookup query from the module name instead of binding it. Both now use strictly validated, bound values. The Product Page visitor counter had a third, reachable only through a stored setting, and it is fixed too.

Public endpoints that trusted the order id you sent. The GA4 purchase tracking endpoint and the server-side tracking endpoint in all nine Conversions API addons loaded whatever order or cart id was posted to them, with no check that it belonged to the current session. A remote caller could force or duplicate a conversion for any order in your store, and read the error message to learn which order ids existed. Every one of those endpoints now only sends events for the session's own order or cart, and the error is a generic one. The promotion tracking endpoints also cap the work they do per request.

Admin actions that fell back to the generic admin permission. Product Feed named an ACL resource that did not exist, so Magento allowed any admin user through. Sitemap, Smart Product Tabs and Speed Optimization had mass-delete or wizard actions with no resource declared. Maxmind's chargeback action, GA4's export actions and Email Template Editor's test-send were the same. All of them now declare the permission they should have had, and state-changing actions accept POST only.

TLS verification switched off. Three outbound calls ran with certificate verification disabled: the Maxmind minFraud request (which carries your licence key and the order's customer data), the Social Login token exchange (which carries the client secret and returns the profile the login is based on), and the Backend licence activation call. Instagram Widget's client had it off as well. A network attacker could read or forge any of them. All four verify now.

Secrets and files where they should not be. The Command module's configuration export decrypted every encrypted setting and wrote it in cleartext to a world-readable file in the working directory, which can be the document root. Exports are now redacted and written under var/ with restricted permissions. Product Feed's file name was used unvalidated in a path, so a feed could be written or downloaded outside the feed folder. Speed Optimization's JS collection endpoint accepted writes from anyone whether the feature was on or not. User Profile let anyone edit any profile by request parameter and enumerate customers through the reviews endpoint. Advanced Wishlist let a signed-in customer take over another customer's wishlist. Social Login let anyone unlink any account by guessing a sequential id.

The performance fixes that came out of the same audit

Reading code this closely turns up things that are slow as well as things that are unsafe. The ones worth your attention:

Email Template Editor fetched a Google Fonts stylesheet on every transactional email with curl's default 300-second timeout, and it did so even when no font was configured. A slow or blocked font host sat in front of every order confirmation, and of checkout on stores that send confirmations synchronously. It now skips the request when there is nothing to fetch, times out at 5 seconds, and caches the stylesheet for a day.
Google Automated Discounts ran its expired-discount cleanup every minute, and each run flushed cache tags for every product it touched. On a busy store that was a self-inflicted Full Page Cache invalidation storm. It runs every fifteen minutes now; expired rows were never served regardless.
Full Page Scroll loaded its two stylesheets on every page of the store, rendering nothing. They now load only on pages that have sections.
Quick Cart raised an error on every page of a store where its configuration section was only partially saved. Google Consent Mode v2 could take the whole store down from a stale configuration cache. Frontend Options answered the entire storefront with a 500 if a single breakpoint was stored as text. All three now fall back to shipped defaults.
Rich Snippets was silently discarding the Product rich result on any product whose description contained a line break, which the shipped sample data does. The structured data is now built as data and encoded, so Google gets valid JSON-LD and text that is not HTML-encoded.
Maxmind and Social Login both failed outright on PHP 8.5 because of a deprecated curl call. Fixed.

How to update

Update through Composer as usual:

composer update "weltpixel/*"
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy
bin/magento cache:clean

A few modules changed constructor signatures, so clear generated/code and generated/metadata before setup:di:compile so the interceptors are rebuilt. Pearl theme templates and several frontend scripts changed, so production stores need the static content deploy and var/view_preprocessed cleared. User Profile adds a column and needs setup:upgrade. The per-module changelog on docs.weltpixel.com says which of these apply to each extension.

Check your plans and Composer access in My Products

Three behaviour notes. Custom Header's custom CSS/HTML field now renders through a tag allowlist, so an HTML5 section or figure element in that field degrades to its text; use a div. Google Consent Mode v2 drops a target attribute on a policy link, so it opens in the same tab. Social Login on a server without a working CA bundle will see Facebook, Instagram and Twitter logins fail, because those providers now verify the certificate like the others always did.

If your Support & Updates plan has lapsed

Composer serves new versions of WeltPixel extensions while your Support & Updates plan is active. When it expires, your store keeps running the version it has, and it keeps every bug that version has. Until this month that was a reasonable trade for a store that was not changing much. After StyleSmuggler it is a different calculation: your Magento core gets a hotfix, and the extension code sitting next to it stays at whatever it was.

If any of your WeltPixel plans have expired, renew them at weltpixel.com/account under My Products, and 1.17.5 becomes available through Composer immediately. Renewals carry a 30-day refund window and can be cancelled at any time from the same page, so the downside of renewing today to get this release is small. The downside of running 1.17.4 or older through the next few months, while attackers work through the extension layer of every Magento store they can reach, is not.

Renew your plan in My Products

Key Takeaways

CVE-2026-75650 (StyleSmuggler) is unauthenticated remote code execution on Magento 2.4.4 through 2.4.9, exploited since September 4, 2026, and it worked against fully patched stores. Apply Adobe's VULN-39341 hotfix from APSB26-146 first, then the APSB26-138 September update.
Confirm the hotfix with vendor/bin/magento-patches -n status, rotate the encryption key and every credential it protected at the source, and scan for the backdoor before assuming you are clean.
A core patch does not fix extension code. WeltPixel 1.17.5 is a catalog-wide security release covering stored XSS through admin settings, SQL injection in the Layered Navigation rating filter and the shared Backend licence lookup, tracking endpoints that accepted any order id, admin actions with no permission declared, and TLS verification that was switched off.
The same audit fixed real performance problems: a 300-second font fetch in front of every transactional email, a per-minute cache flush in Google Automated Discounts, and stylesheets loaded on every page by Full Page Scroll.
Update with Composer, clear generated/, run setup:upgrade and a static content deploy. Every module's exact notes are on docs.weltpixel.com.
1.17.5 is available through Composer only on an active Support & Updates plan, and for the free modules only in the Pearl Theme and Suite PRO bundles. Renew a lapsed plan in My Products at weltpixel.com/account; renewals have a 30-day refund window.

FAQ

Does 1.17.5 fix CVE-2026-75650?

No. That vulnerability is in Magento core and only Adobe's hotfix fixes it. 1.17.5 fixes vulnerabilities of the same classes inside WeltPixel's own extension code, which the Adobe hotfix does not touch. You need both.

Which WeltPixel products are included in 1.17.5?

All of them: every paid extension, every free extension, the Pearl theme (101.17.5), the Stack Framework, the Marketing Suite PRO, Google Analytics 4 and all nine server-side Conversions API addons. The free modules are included because they ship inside Pearl and Suite PRO.

Does anything change on my storefront after updating?

For a valid configuration, no. Generated stylesheets are byte-identical and every escaped value that was already clean renders the same. The three documented exceptions are HTML5 sectioning tags in the Custom Header custom CSS/HTML field, the target attribute on Consent Mode v2 policy links, and Social Login on servers with no CA bundle.

I run a free WeltPixel module from GitHub. Do I get 1.17.5?

The free modules received the same hardening, but 1.17.5 ships only in the editions bundled with the Pearl Theme and the Marketing Suite PRO, delivered through Composer on an active Support & Updates plan. The public GitHub repositories keep their previous version. If you rely on a free module from GitHub on a store that handles payments, this is a good moment to move to the bundled edition.

My Support & Updates plan expired. Can I still get 1.17.5?

Not through Composer until you renew. Renew in My Products at weltpixel.com/account and the new version is available immediately. Renewals carry a 30-day refund window.

Is my store already compromised?

Patching does not answer that. Run Sansec's eComscan or an equivalent scanner, check for the fc-cache and chronyd processes and for PHP files under pub/media, and rotate credentials regardless. Stores were being exploited for three days before any fix existed.