Slowloris vuln returned by security scan

we’ve got a new site going live and did a vuln. scan using It came back with the following issue (see below).
We’re confused as this shouldn’t be a thing with the Netlify CDN, should it?
Please can you advise on how you can remediate or help us understand in a devops-level overview of how this issue is prevented from becoming problematic?

Full test results and vuln. report below.

SLOWLORIS Denial of Service. Slowloris works by opening multiple connections to the targeted web server and keeping them open as long as possible. It does this by continuously sending partial HTTP requests, none of which are ever completed. The attacked servers open more and connections open, waiting for each of the attack requests to be completed. Periodically, the Slowloris sends subsequent HTTP headers for each request, but never actually completes the request. Ultimately, the targeted server’s maximum concurrent connection pool is filled, and additional (legitimate) connection attempts are denied. By sending partial, as opposed to malformed, packets, Slowloris can easily slip by traditional Intrusion Detection systems. Known Affected Configurations • Apache 1.x, 2.x (CVE-2007-6750) • Apache Tomcat 7.0.x (CVE-2012-5568) • All versions prior to Node.js 6.15.0, 8.14.0, 10.14.0 and 11.3.0 (CVE-2018-12122) • Flask, development mode. Example: See Also

Contents Test Started: 18/03/2021 - 18:32:26 Test Ended: 18/03/2021 - 18:33:13 Socket timeout appears to be set to 35.2688407898 seconds, for the baseline request Socket timepout was 47.1134738922 seconds, for the payload request Delay in response between the base line request and payload request was 11.8442749977 seconds Summary The web server appears to be vulnerable to a Slowloris DoS attack Example: See Also Contents Test Started: 18/03/2021 - 18:33:14 Test Ended: 18/03/2021 - 18:34:00 Socket timeout appears to be set to 35.3628752232 seconds, for the baseline request Socket timepout was 46.4805440903 seconds, for the payload request Delay in response between the base line request and payload request was 11.1015357971 seconds Summary The web server appears to be vulnerable to a Slowloris DoS attack

Hi again Frank,

Really disappointed to see that you posted this here, particularly after I gave you kudos for not posting new vulnerabilities publicly in your identical report through the helpdesk. There are a lot of places to read about why doing so is really irresponsible; this Wikipedia article is a reasonable one: Responsible disclosure - Wikipedia.

Please let me know if you don’t understand why this is a problem, and I will be happy to talk with you in more detail.

Fortunately, this report is not a major problem for our platform as I’ll explain for the other readers of this thread below. Before I do, let me highlight the appropriate and responsible ways to report a security vulnerability to Netlify:

These two methods are open to anyone, customer or not:

  1. visit our bug bounty program page at HackerOne. They will accept your report, triage it, and work with our team to assign a severity and pay rewards in case it is a previously-unreported vulnerability with any impact to our customers.
  2. email; this will auto-respond with a message about how to initiate the process in #1.

If you are a paying customer, you have at least one other option:

  1. every paying customer can email from your Netlify login email address (shown and changeable at Netlify App) to submit through our helpdesk. Our Support Engineers know how to handle these cases and generally work with our Security Engineers to review them.
  2. if you are an enterprise customer, your account exec can help you get the report to our team privately.

Thank you for your future help in protecting all of our customers - including you - from the potential effects of irresponsible reporting.

So, on to discussing why our CDN is not generally vulnerable to the slow loris attack.

I’ve reviewed with our security and networking teams, and they are aware of this attack vector.

However, since our CDN is event-based, not thread-based, that design should make us inherently non-vulnerable to those kinds of resource exhaustion attacks. Put another way, our incoming connection pool is not limited, and thus, our systems will not experience any negative impact even if you can successfully run a slowloris attack tool on our CDN. We have done some fairly extensive testing on this (before you wrote in), and feel confident in this assertion.


I only did as I was directed to by netlify. After posting the help ticket, it said: why not also post this on our forums?

It would have been much * less * work just to post the support ticket as I had to join the forums to do so, I literally only did to be helpful.

So, I’m disappointed to see you are disappointed as I was only doing what it seemed like I was being directed to do.

In that context, it feels surprising to be told off as ‘irresponsible’.

I was following the onscreen instructions given to me by the vendor, after all.

Drat. Hoisted by my own petard: I wrote that messaging, since it applies to every single interaction in the helpdesk…except security, billing, and abuse reports. As you point out, this is a “one size fits most” guidance, and in this case, it was off. So, I owe you a large scale apology - I had forgotten about it entirely.

I think the messaging still stands for every other type of case, so I’ll work with our community team on an update to that messaging to be more specific about what’s appropriate for the forum, thanks to your feedback.

In the end, please take away that we are thankful that you let us know and appreciate your help in making it a teaching moment for others that may come afterwards.

1 Like

Understood. Thanks. Appreciate the note.
Reflecting on it yesterday, I realised that yes, this looked like a vuln. report on your forums, which I get why you are sensitive about. I was in ‘automatic’ mode chasing lots of deadlines and wasn’t considering that, just bashing through another job trying to get a site live, so updates to those instructions would probably help people like me in ‘too much to do to think’ mode.