An intermittent outage at Cloudflare<\/strong> on Tuesday briefly knocked many of the Internet\u2019s top destinations offline. Some affected Cloudflare customers were able to pivot away from the platform temporarily so that visitors could still access their websites. But security experts say doing so may have also triggered an impromptu network penetration test for organizations that have come to rely on Cloudflare to block many types of abusive and malicious traffic.<\/p>\n At around 6:30 EST\/11:30 UTC on Nov. 18, Cloudflare\u2019s status page acknowledged the company was experiencing \u201can internal service degradation.\u201d After several hours of Cloudflare services coming back up and failing again, many websites behind Cloudflare found they could not migrate away from using the company\u2019s services because the Cloudflare portal was unreachable and\/or because they also were getting their domain name system (DNS) services from Cloudflare.<\/p>\n However, some customers did manage to pivot their domains away from Cloudflare during the outage. And many of those organizations probably need to take a closer look at their web application firewall (WAF) logs during that time, said Aaron Turner<\/strong>, a faculty member at IANS Research<\/strong>.<\/p>\n Turner said Cloudflare\u2019s WAF does a good job filtering out malicious traffic that matches any one of the top ten types of application-layer attacks<\/a>, including credential stuffing, cross-site scripting, SQL injection, bot attacks and API abuse. But he said this outage might be a good opportunity for Cloudflare customers to better understand how their own app and website defenses may be failing without Cloudflare\u2019s help.<\/p>\n \u201cYour developers could have been lazy in the past for SQL injection because Cloudflare stopped that stuff at the edge,\u201d Turner said. \u201cMaybe you didn\u2019t have the best security QA [quality assurance] for certain things because Cloudflare was the control layer to compensate for that.\u201d<\/p>\n Turner said one company he\u2019s working with saw a huge increase in log volume and they are still trying to figure out what was \u201clegit malicious\u201d versus just noise.<\/p>\n \u201cIt looks like there was about an eight hour window when several high-profile sites decided to bypass Cloudflare for the sake of availability,\u201d Turner said. \u201cMany companies have essentially relied on Cloudflare for the OWASP Top Ten<\/a> [web application vulnerabilities] and a whole range of bot blocking. How much badness could have happened in that window? Any organization that made that decision needs to look closely at any exposed infrastructure to see if they have someone persisting after they\u2019ve switched back to Cloudflare protections.\u201d<\/span><\/p>\n Turner said some cybercrime groups likely noticed when an online merchant they normally stalk stopped using Cloudflare\u2019s services during the outage.<\/p>\n \u201cLet\u2019s say you were an attacker, trying to grind your way into a target, but you felt that Cloudflare was in the way in the past,\u201d he said. \u201cThen you see through DNS changes that the target has eliminated Cloudflare from their web stack due to the outage. You\u2019re now going to launch a whole bunch of new attacks because the protective layer is no longer in place.\u201d<\/p>\n Nicole Scott<\/strong>, senior product marketing manager at the McLean, Va. based Replica Cyber<\/strong>, called yesterday\u2019s outage \u201ca free tabletop exercise, whether you meant to run one or not.\u201d<\/p>\n \u201cThat few-hour window was a live stress test of how your organization routes around its own control plane and shadow IT blossoms under the sunlamp of time pressure,\u201d Scott said in a post<\/a> on LinkedIn.\u00a0\u201cYes, look at the traffic that hit you while protections were weakened. But also look hard at the behavior inside your org.\u201d<\/p>\n Scott said organizations seeking security insights from the Cloudflare outage should ask themselves:<\/p>\n 1. What was turned off or bypassed (WAF, bot protections, geo blocks), and for how long?![\"\"](\"https:\/\/i0.wp.com\/krebsonsecurity.com\/wp-content\/uploads\/2025\/11\/cfoutage.png?resize=747%2C464&ssl=1\")
<\/p>\n
\n2. What emergency DNS or routing changes were made, and who approved them?
\n3. Did people shift work to personal devices, home Wi-Fi, or unsanctioned Software-as-a-Service providers to get around the outage?
\n4. Did anyone stand up new services, tunnels, or vendor accounts \u201cjust for now\u201d?
\n5. Is there a plan to unwind those changes, or are they now permanent workarounds?
\n6. For the next incident, what\u2019s the intentional fallback plan, instead of decentralized improvisation?<\/p>\n