Magento 2.4.6 is out of support, and StyleSmuggler is being exploited

1. Today: apply the StyleSmuggler hotfix

Adobe's hotfix is called VULN-39341 and is applied as a composer patch, following Adobe's "How to apply a composer patch provided by Adobe" procedure. Adobe made it available for every 2.4.6 patch level; which file you need depends on yours:

• Being on the latest patch level was no protection: Sansec reports a store on 2.4.6-p15 with the July and August patches that was compromised before the hotfix existed.
• Adobe Commerce: also install Adobe's October security release from APSB26-153. Adobe asks you to apply the StyleSmuggler hotfix "in addition to" it.
• Magento Open Source 2.4.6: the October fixes don't exist for your version. The hotfix covers StyleSmuggler, but the only way to get APSB26-153's fixes is to upgrade (section 4).

2. Rotate keys and passwords

Adobe says to apply the patch "and rotate your encryption keys". Its list, in short:

1. Put the store in maintenance mode and stop cron.
2. Rotate the Magento encryption key.
3. Change all admin passwords.
4. Regenerate REST, SOAP and GraphQL integration tokens, and rotate OAuth secrets.
5. Rotate payment gateway credentials at the provider (Stripe, Braintree, Adyen, PayPal and so on), and shipping, tax and other API keys at their source.
6. Rotate database credentials, SSH and deploy keys, and service accounts.
7. Flush the cache, start cron again and leave maintenance mode.

Adobe stresses rotating credentials "at their source (for example, at the payment gateway or third-party service), not only within Commerce". Sansec adds that rotating the encryption key alone "does not invalidate anything an attacker already read".

3. Check whether your store was already hit

Sansec, who found StyleSmuggler, saw the first confirmed attack on 4 September 2026, three days before Adobe's hotfix. In their words: "Patching closes the hole but does not clean a store that was already hit." Signs they list for defenders:

• Background processes named like system processes, some with no cron entry.
• Hidden files in cache directories and in /tmp, and unexpected cron entries.
• Unexpected PHP files under pub/media, including the product image cache.
• Changes to Magento core files under vendor/.
• Script code injected into the store's head HTML (Content → Design → Configuration, or design/head/includes in the database).
• A sudden burst of "Payment Transaction Failed" emails.

If you find any of these, treat it as a breach: clean the server (or rebuild it), rotate everything from section 2 again afterwards, and check your obligations towards your payment provider.

4. Upgrade: 2.4.8 or 2.4.9

• 2.4.8 runs on PHP 8.3 or 8.4 and is supported until 31 May 2028: the smaller step.
• 2.4.9 is supported a year longer, but Adobe lists only PHP 8.5 for it and, if you use MariaDB, version 12.3, so it changes more of your server.
• 2.4.6 itself runs on PHP 8.1 or 8.2. PHP 8.2's security support ends 31 December 2026, which Adobe flags as a PCI compliance risk. See our PHP 8.2 end-of-life guide.

What changes on the server

What usually breaks in extensions and themes

• PHP 8.4 / 8.5: Adobe notes "some modules and extensions broke under PHP 8.4". 2.4.9 also moves to Symfony 7.4.
• Logging: 2.4.8 moves to Monolog 3, which changes custom log handlers.
• Admin editor: TinyMCE 5 is replaced by TinyMCE 7 in 2.4.8; custom editor plugins need work.
• JavaScript libraries: jQuery fileUpload is replaced by Uppy, and several libraries are updated, which breaks admin and checkout customisations that depend on them.
• Caching: 2.4.9 replaces Zend_Cache with symfony/cache.
• Checkout security (from 2.4.7): a strict Content Security Policy on payment pages blocks inline scripts that aren't allow-listed, which often breaks tracking and payment add-ons.
• Shipping: since 2.4.7, FedEx and UPS use their REST APIs, so you need new carrier credentials.

How the upgrade runs

Adobe's documented process is the same for Open Source and Adobe Commerce: install the magento/composer-root-update-plugin, put the store in maintenance mode, stop cron and the queue consumers, require the new version with composer require-commerce, run composer update, clear the generated code and caches, run bin/magento setup:upgrade, and leave maintenance mode. Do it on a staging copy first, with the new PHP and database versions, and test checkout and payments end to end before going live.

5. Tools that help

• Adobe's Upgrade Compatibility Tool (free): checks your custom code and extensions against a target version. Only available for Adobe Commerce, not Magento Open Source.
• Sansec eComscan (paid; prices on Sansec's site): a server-side malware scanner from the team that found StyleSmuggler. The most direct way to check for this compromise, but it's a commercial agent running on your server.
• MageReport (free): a quick outside check of your store's patch status. It can't see inside the server, so it can't tell you whether you were compromised.
• Rector, PHPCompatibility and PHPStan (free): for the PHP side of the upgrade; see the PHP 8.2 guide for what each one does.

Sources

• Adobe security bulletin APSB26-146 (7 September 2026)
• Adobe knowledge base: APSB26-146 hotfix and credential rotation
• Adobe security bulletin APSB26-153 (13 October 2026)
• Sansec: StyleSmuggler advisory
• CISA Known Exploited Vulnerabilities catalog
• Adobe Commerce lifecycle policy
• Adobe: security patch releases (Open Source and extended support)
• Adobe Commerce system requirements
• Adobe: backward-incompatible changes
• Adobe: perform an upgrade
• Adobe: Upgrade Compatibility Tool
• Magento 2.4.8 release notes
• Magento 2.4.9 release notes
• Sansec eComscan
• MageReport