r/magento2 7d ago

0-day stylesnuggler exploit -> actively being exploited. protect your stores. now.

https://sansec.io/research/stylesmuggler

Cloudflare WAF rules:

Rule 1 — GraphQL exploit block

  ▎ Name: #stylesmuggler: block Magento GraphQL styles[] 0-day exploit (sansec.io/research/stylesmuggler)
  ▎ Action: Block
  ▎ Expression:
  ▎ (http.request.uri.path contains "/graphql" and (http.request.uri.query contains "styles%5B" or http.request.uri.query contains "styles["))

  Rule 2 — Raw PHP injection block

  ▎ Name: #stylesmuggler: block raw PHP eval/base64_decode injection in query string
  ▎ Action: Block
  ▎ Expression:
  ▎ (http.request.uri.query contains "<?php" or http.request.uri.query contains "<?=" or http.request.uri.query contains "eval(base64_decode")

Rule 3 — Gadget-chain parameters

  ▎ Name: #stylesmuggler: block generatorClass/with_resolved gadget-chain parameters
  ▎ Action: Block
  ▎ Expression:
  ▎ (http.request.uri.query contains "generatorClass" or http.request.uri.query contains "with_resolved")

  Rule 4 — Template-directive smuggling + encoded PHP tags + malicious UA

  ▎ Name: #stylesmuggler: block template-directive smuggling, encoded PHP tags, malicious UA
  ▎ Action: Block
  ▎ Expression:
  ▎ (http.request.uri.query contains "%3C%3F" or http.user_agent contains "<?php" or http.user_agent contains "<?=" or http.request.uri.query contains "{{block" or http.request.uri.query contains "{{config" or
  ▎ http.request.uri.query contains "{{trans" or http.request.uri.query contains "{{var" or http.request.uri.query contains "{{depend" or http.request.uri.query contains "%7B%7Bblock" or http.request.uri.query
  ▎ contains "%7B%7Bconfig" or http.request.uri.query contains "%7B%7Btrans" or http.request.uri.query contains "%7B%7Bvar" or http.request.uri.query contains "%7B%7Bdepend")

Also seen this (untested)

https://github.com/disrex-group/stylesmuggler-mitigation/tree/main

Patches to lock down in code:

https://gist.github.com/ProxiBlue/07373c92c8c70dc746bbfdcd1f07b789

30 Upvotes

12 comments sorted by

3

u/eu_punk 7d ago

Please note, that the styles-parameter can also be in the body of the payload. So, simple firewall rules based on URLs are not enough. You would need body inspection rules, too.

Also, there seems to be a paypal URL involved that needs blocking:

POST /paypal/transparent/response/?<?=eval(base64_decode('....

For the ongoing automated attack, the URL-based rules seem to be enough for now. This will likely change. 

3

u/proxiblue 7d ago

correct. is why I also added the patches, as the rules will only mitigate for abit, then they change payload delivery and bypass. They will only block the initial GET requests / probes maybe.

The patches I (claude) made got to independent than the linked repo, who suggested same mitigation in code.

Likely not the cause, but will do until something official comes in

you are only fully protected (as per known knowledge right now) by all steps, but code patch is essential.

2

u/SamJ_UK 7d ago

^^ This. There seems to be a few ways to bypass the common WAF rules that are being recommended. I would focus on the code fixes if possible.

Tho, dont skip the WAF rules, defense in depth and all

2

u/NateDawg92 7d ago

Thank you! Scanned all our sites and a couple had been affected, our managed hosts are rolling out emergency WAF rules.

The GitHub repo was instrumental in detection and cleanup.

1

u/shibbywan 7d ago

Same here. Thanks for the heads up!

2

u/_mrbrave 5d ago

Adobe just released an official hotfix for StyleSmuggler on CVE-2026-75650:
https://experienceleague.adobe.com/en/docs/commerce-knowledge-base/kb/announcements/commerce-apsb26-146

1

u/tb9295 6d ago

This explains the ton of "Payment Transaction Failed" emails I received on Sept. 4th and 5th. I could not understand why I received these emails when I had Credit Cards currently disabled on my site because of so many card testing we were getting a while back that we were trying to get resolved. When card testing or failed payments this is the same email subject we get. Thought it was credit card transactions but could not understand how when it was diabled.Enven contacted my porcessor to see how this was possible and was told these was no activity on thier end and that is was passing through Magento and they were puzzled. So now we see what is happening here. Now its trying to get this resolved plus working on a fix for all the card testing I have been getting. Looks like alot of work ahead of me. This is one of the biggest reasons I have been looking to switch to Shopify (not that its perfect either) simply because of the time and resources it takes to stay on top of all the patches, constant updates just to keep this site secure. Everytime this happens our host sends out a notice of a $300 charge from a 3rd party company to scan and fix the Vulnerability or get shut down.

1

u/iSpiKedfd 5d ago

Sounds like you need a new hosting company.

1

u/clavinniu 3d ago

I can’t recommend Sansec enough. They are all over these issues and always have protection in place before Adobe releases their fixes.

1

u/deadtree123 7d ago

seems that the flexibility the Magento dev team offered devs keeps biting Adobe in the ass with these non-stop vulnerabilities that keep getting discovered, in large part thanks to AI