Putting Magento Behind Cloudflare: What a WAF Does, and What It Cannot
Shakewell ·
When StyleSmuggler broke, the most common advice after “patch” was “put a WAF in front of it”. It is good advice, and it is worth being precise about what it buys you, because the timeline of this particular vulnerability shows the limits clearly.
| Date (2026) | What happened |
|---|---|
| 4 September | Exploitation of CVE-2026-75650 begins |
| 5 September | Sansec discloses StyleSmuggler |
| 7 September | Adobe ships the hotfix, APSB26-146 |
| 10 September | Cloudflare adds a Block rule for CVE-2026-75650 to its Managed Ruleset |
The vendor’s managed rule arrived six days after exploitation began and three days after the patch. That is not a criticism of Cloudflare, which was quick. It is how managed rules work: someone has to analyse the attack before they can write a rule for it. A managed ruleset protects you against yesterday’s attacks. It is not a shield against a zero-day on the day it lands.
So a WAF is worth having for Magento. Just not for the reason people usually give.
What a WAF actually does for a Magento store
Blocks known attack patterns. Managed rules catch the exploit traffic for published vulnerabilities, including the long tail of old Magento bugs that scanners still probe every day. This is where most of the value sits for a store that is otherwise patched: the noise never reaches your server.
Buys time when you cannot patch today. A change freeze, a heavily customised build, a version the patch does not apply to cleanly. A block rule in front of the store, managed or written by you, narrows the window while the real fix is scheduled. For StyleSmuggler, the stores that needed this most were the ones on versions older than 2.4.4, which get no official patch at all.
Lets you write your own rule faster than the vendor. When a vulnerability is disclosed with enough detail, a custom rule blocking the vulnerable request pattern can be in place in minutes, days before a managed rule. This is the most useful thing a WAF does in a zero-day week, and it needs someone who knows both the store and the attack.
Stops bots doing damage. Credential stuffing on customer login, fake account creation, and card testing on the payment step, where bots try stolen card numbers in bulk and leave you with the chargebacks and a gateway asking questions. Rate limits and bot rules on those endpoints are routine and effective.
The settings that matter
Lock the origin. This is the one most setups get wrong. If your server’s real IP address is discoverable, an attacker can skip Cloudflare entirely and talk to the store directly. Firewall the origin so it accepts traffic only from Cloudflare’s addresses, or connect it through Cloudflare Tunnel so it has no public address at all. Without this, everything else on this list is optional for the attacker.
Rate-limit the endpoints attackers use. Customer login, account creation, password reset, /graphql, the REST API, and the checkout payment step. Set the limits from your real traffic, so a script is stopped and a busy sale is not.
Restrict the admin. The Magento admin should not be reachable by the whole internet. Keep a custom admin path, and put an identity check or an IP allowlist in front of it at the edge, so an attacker never sees a login form to attack.
Turn on the managed rules, and watch what they block. Cloudflare’s Managed Ruleset is part of its paid plans. Enable it, then review what it blocks for the first week. False positives on a checkout cost real orders, and the fix is a targeted exception, not switching the ruleset off.
Cache what is safe to cache. Static assets at the edge take load off the origin and make the site faster. Full-page caching of Magento pages needs more care, because carts, prices and customer sessions must never be served to the wrong person.
What a WAF cannot do
- It does not fix the vulnerability. The flaw is still in the code. A variation on the attack, or a request the rule does not recognise, still reaches it.
- It cannot clean a compromised store. If someone got in before the rule existed, the web shell, the cron entry and the stolen credentials are still there. We covered what to check after StyleSmuggler separately.
- It cannot see what an admin does. A stolen admin session looks like a legitimate admin.
- It does not replace patching. A WAF narrows the window; only the patch closes it.
The order to do it in
- Patch. Scheduled releases and hotfixes, separately, as Adobe ships them. Our Magento security tracker lists every 2026 bulletin and flags the ones that must be applied on their own.
- Lock the origin, so the WAF cannot be bypassed.
- Rate-limit and restrict the login, API, checkout and admin endpoints.
- Enable managed rules, and tune them against real traffic.
- Keep someone on call who can write a custom rule the day a disclosure lands.
We run Magento stores in production and work with Cloudflare across our own platforms and client sites. More on our Cloudflare work and Magento support.
Sources: Cloudflare WAF emergency release, 10 September 2026, Adobe APSB26-146, and Sansec’s StyleSmuggler research.
Common questions
Does Cloudflare protect Magento from StyleSmuggler?
It does now, as a second layer. Cloudflare added a rule for CVE-2026-75650 to its Managed Ruleset on 10 September 2026, with a default action of Block. Exploitation began on 4 September and Adobe's hotfix shipped on 7 September, so the managed rule arrived after the patch. It is a useful backstop, not a substitute for applying APSB26-146.
Is a WAF a replacement for Magento security patches?
No. A WAF blocks requests that match known attack patterns before they reach the store. It does not fix the vulnerability, it cannot clean a store that was already compromised, and a variation on an attack can slip past a rule written for the original. Patch first; treat the WAF as the layer that buys time when a patch is not yet available or not yet applied.
What is the most common mistake putting Magento behind Cloudflare?
Leaving the origin server reachable directly. If an attacker can find the server's real IP address, they can send requests straight to it and bypass the WAF entirely. Lock the origin so it only accepts traffic from Cloudflare, or connect it through a tunnel so it has no public address at all.
Which Magento URLs need rate limiting?
The ones attackers hammer: customer login, account creation and password reset, the GraphQL and REST endpoints, and the checkout payment step, where card-testing bots try stolen card numbers in bulk. Limits should be set from your real traffic, so they stop scripts without blocking a busy sale.