{"uuid": "bfe81600-010e-4428-a6cb-c49cd7e8bc56", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-34102", "type": "seen", "source": "https://gist.github.com/ProxiBlue/2000292a9d30e556107509a14e2b2303", "content": "# Cloudflare + Magento 2 \u2014 best practice guide (compiled 2026-09-29)\n\nCompiled from Cloudflare's own official docs + community sources, cross-checked\nagainst this zone's actual live config. Written as a follow-up to the two\nsame-day OWASP CRS false-positive incidents on ticket #400 (storefront cookie\nwalls, then the admin `catalog/product/validate` RCE false-positive).\n\n## 1. The single highest-leverage fix for THIS zone\n\nThe #400 fix (05:04 UTC) set the OWASP ruleset override to:\n\n```json\n\"overrides\": {\n  \"action\": \"managed_challenge\",\n  \"categories\": [ ...paranoia levels 2-4 disabled... ],\n  \"rules\": [ { \"action\": \"log\", \"id\": \"...843b323c\" } ]  // 949110 only\n}\n```\n\n**This is the root cause of both incidents, not just the two rule IDs found\nso far.** Per Cloudflare's own docs (Concepts page), OWASP CRS is designed as\nan *anomaly-scoring* system: ~178 of ~179 rules just add points (`action:\nscore`) to a running total, and only the **last** rule \u2014 `949110: Inbound\nAnomaly Score Exceeded` \u2014 checks that total against a threshold (default 40)\nand takes the real action (block/challenge/log).\n\nSetting a **top-level `overrides.action`** overrides the native action of\n*every* rule in the ruleset that doesn't have its own explicit override \u2014\nincluding the ~178 pure scoring rules. That silently converts them from\n\"contributes to a cumulative score\" into \"independently blocks/challenges on\nits own first match.\" This is why two unrelated rules (920273/274 today, then\n932130 a few hours later) each independently walled traffic on the same day:\nevery one of the 179 individual rules is now a single point of failure, not\njust the intended anomaly-threshold rule.\n\n**Fix:** remove the top-level `\"action\"` key from the overrides object\nentirely. Leave the paranoia-level category disables as-is, and keep (only)\nper-rule overrides for `949110` (and any other rule you deliberately want to\nsoften). This restores OWASP's intended behavior \u2014 many weak signals must\naccumulate before anything is blocked/challenged, instead of any single PL1\nrule match acting alone. Apply on both zones (`.com.au` and `.co.nz`).\n\n## 2. Official Cloudflare guidance on false positives (verbatim, from\n   [developers.cloudflare.com/waf/managed-rules/troubleshooting](https://developers.cloudflare.com/waf/managed-rules/troubleshooting/))\n\n> If one specific rule causes false positives, disable that specific rule and\n> not the entire ruleset.\n>\n> For false positives with the administrator area of your website, add an\n> exception disabling a managed rule for the admin section of your site\n> resources. You can use an expression similar to:\n> `http.host eq \"example.com\" and starts_with(http.request.uri.path, \"/admin\")`\n\nThis is Cloudflare's own prescribed pattern for exactly the admin-panel\nscenario we hit today \u2014 and their worked example in that same doc cites rule\nID `...843b323c` (949110), the *exact* rule this zone already had to\noverride. Confirms this is a known, common failure mode, not a one-off.\n\n**Recommended for this zone:** a Configuration Rule / exception that skips\nthe OWASP ruleset (or all Managed Rules) for `/UadminU2nme/*`, since it's an\nauthenticated, low-traffic, staff-only surface \u2014 not the public attack\nsurface OWASP protects. Combine with \u00a71 above; \u00a71 fixes the structural\nscoring bug, this adds defense-in-depth so admin product content (rich HTML,\nMagento `{{...}}` directives, scraped copy) never trips *any* future PL1 rule.\n\n## 3. Cloudflare's own stance on OWASP CRS\n\nFrom [developers.cloudflare.com/waf/managed-rules/reference/owasp-core-ruleset](https://developers.cloudflare.com/waf/managed-rules/reference/owasp-core-ruleset/)\n(their words, not ours):\n\n> The Cloudflare OWASP Core Ruleset is prone to false positives and offers\n> only marginal benefits when added on top of Cloudflare Managed Ruleset and\n> WAF attack score. If you decide to deploy this managed ruleset, you will\n> need to monitor and adjust its settings based on your traffic to prevent\n> false positives.\n\nCloudflare positions OWASP CRS (generic, scoring-based, \"requires manual\ntuning\") as inferior to their own **Managed Ruleset** (signature-based,\nmaintained by Cloudflare, includes CVE-specific virtual patches shipped within\nhours of disclosure) plus **WAF Attack Score** (ML-based, catches obfuscated/\nnovel payloads without needing an exact signature).\n\n**Verified for this zone:** the Cloudflare Managed Ruleset already includes\n~10 Magento-specific rules (CVE-2022-24086, CVE-2024-34102 XXE, Magento 2\nunrestricted file upload, Drupal/Magento deserialization, etc.) \u2014 8 of 10\nenabled, all with `action: block` (not challenge), and none of them fired\ntoday. This is the ruleset actually earning its keep; OWASP CRS is the one\ncausing incidents. **Recommendation: consider whether OWASP CRS earns its\nfalse-positive cost on this zone at all**, given Managed Ruleset + Attack\nScore already cover Magento-specific threats natively. If kept, treat it as\na PL1-only, rarely-touched tripwire \u2014 not a rule set to actively tune rule-by-\nrule as false positives surface (see \u00a71 \u2014 most of that tuning burden\ndisappears once the scoring model is restored).\n\n## 4. OWASP Top 10 coverage mapping (for reference)\n\n| Attack class | Handled by |\n|---|---|\n| SQLi / XSS / RCE (932XXX/941XXX/942XXX) | OWASP CRS (generic) + Managed Ruleset (Magento-specific signatures) |\n| Path traversal / `.env`, `.git` access (930XXX) | OWASP CRS + Managed Ruleset |\n| Insecure deserialization (944XXX) | OWASP CRS + Managed Ruleset (Magento/Drupal PHP deserialization, explicitly) |\n| SSRF (934XXX) | OWASP CRS + Managed Ruleset |\n| New/unpatched CVEs | Managed Ruleset only (virtual patching, hours after disclosure) \u2014 OWASP CRS is static |\n| Credential stuffing / bot abuse | Bot Management, Leaked Credentials Check \u2014 neither ruleset |\n| TLS/crypto, logging/monitoring, secure design | Not WAF's job \u2014 platform config / app-level |\n\n## 5. Cache & routing rules for Magento 2 (general best practice, not\n   specific to today's incident)\n\nStandard bypass list for a Magento 2 storefront behind Cloudflare (cache\nrules / \"Bypass Cache on Cookie\" equivalent):\n\n- `/checkout*`, `/customer*`, `/catalogsearch*`, `/cart*`, admin path \u2014 never\n  cache, always pass through\n- Cookie-based bypass: `admin=.*|PHPSESSID=.*|private_content_version=.*|section_data_ids=.*`\n  \u2014 note `section_data_ids` and `mage-*` cookies are exactly what caused the\n  first #400 incident (920273/274 flagging their JSON content), so this\n  bypass is a caching concern *and* a WAF-scope concern; both point the same\n  direction: authenticated/dynamic paths need different treatment than\n  anonymous storefront browsing.\n- `Cache Everything` for anonymous PDP/PLP/CMS pages is safe and is Cloudflare's\n  standard recommendation for Magento \u2014 static HTML caching plus the bypass\n  list above covers the split correctly.\n\n## 6. Summary checklist for this zone\n\n- [ ] Remove top-level `overrides.action` from the OWASP ruleset entrypoint on\n      both zones \u2014 restores anomaly-scoring, fixes the root cause of both\n      today's incidents (\u00a71)\n- [ ] Add admin-path exception/skip for Managed Rules per Cloudflare's own\n      prescribed pattern (\u00a72)\n- [ ] Re-evaluate whether OWASP CRS should stay deployed at all, given\n      Managed Ruleset + Attack Score already cover Magento-specific threats\n      with fewer false positives (\u00a73)\n- [ ] Confirm the 2 currently-disabled Magento-specific Managed Ruleset rules\n      (Setup File Access APPSEC-1421, SQLi CVE-2015-1397) are disabled\n      deliberately and not by oversight\n- [ ] Verify cache/cookie bypass list covers `/checkout`, `/customer`,\n      `/catalogsearch`, `/cart`, admin path, and `mage-*`/`section_data_ids`\n      cookies (\u00a75)\n\n## Sources\n\n- [Troubleshoot managed rules \u2014 Cloudflare WAF docs](https://developers.cloudflare.com/waf/managed-rules/troubleshooting/)\n- [Cloudflare OWASP Core Ruleset \u2014 reference](https://developers.cloudflare.com/waf/managed-rules/reference/owasp-core-ruleset/)\n- [OWASP ruleset concepts \u2014 paranoia level, scoring, threshold](https://developers.cloudflare.com/waf/managed-rules/reference/owasp-core-ruleset/concepts/)\n- [Cloudflare WAF Configuration: Rules & Best Practices \u2014 AppSecure](https://www.appsecure.security/blog/guide-to-cloudfare-firewall-setup)\n- [Cloudflare Managed Ruleset: What the WAF Rules Actually Do \u2014 RunXBuild](https://www.runxbuild.com/blog/cloudflare-managed-ruleset/)\n- [How to Restrict Magento Admin Panel Access in Cloudflare \u2014 Liquid Web](https://www.liquidweb.com/magento/admin/restrict-panel-access-cloudflare/)\n- [Cloudflare recommended Caching rules for Magento2 \u2014 Cloudflare Community](https://community.cloudflare.com/t/cloudflare-recommended-caching-rules-for-magento2-website/760524)\n- [Caching Anonymous Page Views for Magento 2 with Cache Rules \u2014 Cloudflare Community](https://community.cloudflare.com/t/caching-anonymous-page-views-for-magento-2-with-cache-rules/635841)\n- Live zone config verified directly via Cloudflare API against `laptoplcdscreen.com.au` (rulesets, overrides, Managed Ruleset Magento-specific rule list) \u2014 2026-09-29\n", "creation_timestamp": "2026-09-29T11:23:44.000000Z"}